From nobody Thu Aug 5 09:20:39 2021 Return-Path: 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 A3F053A1827 for ; Thu, 5 Aug 2021 09:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=bell.ca 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 7NxYFovllICl for ; Thu, 5 Aug 2021 09:20:33 -0700 (PDT) Received: from ESA2-Dor.bell.ca (esa2-dor.bell.ca [204.101.223.59]) (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 35DBF3A1826 for ; Thu, 5 Aug 2021 09:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1628180433; x=1659716433; h=from:to:subject:date:message-id:mime-version; bh=u1plYKrEne1j9Gnc2FwHGgbdPgJ7EGtHgfNGEco/iOU=; b=LhC0tsxznl1cPc2GQaB/j6aaCJZLEO2oLSF0FHrCATBQgRU1xh3IKB42 5+2oIge2UfF9y7MdNd+AYNUPso3b/zkscjGNBJrjEb8pBaDHQbagtlQDi LxLFjtoBM5nidJiKEyTbVKJX+DaEcUYoEble+D9EXZhiiWzm1G2pI5D/Q jz82GkFDFtv8vxOT9aHB8PpGjmZfIKu4XVOU70OG5utMGQD9bsLeEjro9 FmNUGQhEcg0Ra96JY5lgIU1tOwO6yA11/T8GXM8pJ+18cz/0O3lif4T2/ y8xJ4YEZ0dQsMZ8hoGEJwAaOz1GCXefjsjbJ8dU93SeUXYMI7515eG0L/ g==; IronPort-SDR: 1tHVFK8owqLTjJNwEd0GS5Fyu3cHf16CdLog/KrznhNE6dN2W990tjSvukzFUcfu9XSi/u2PqG INsGi2Fmmwpw== Received: from dc5cmy-d01.bellca.int.bell.ca (HELO DG3MBX03-WYN.bell.corp.bce.ca) ([198.235.121.230]) by esa02corp-dor.bell.corp.bce.ca with ESMTP; 05 Aug 2021 12:20:31 -0400 Received: from DG12MBX04-WYN.bell.corp.bce.ca (142.182.18.49) by DG3MBX03-WYN.bell.corp.bce.ca (142.182.18.25) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Thu, 5 Aug 2021 12:20:31 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX04-WYN.bell.corp.bce.ca (142.182.18.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Thu, 5 Aug 2021 12:20:31 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e418:76b1:f7e1:1d55]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e418:76b1:f7e1:1d55%4]) with mapi id 15.01.2242.010; Thu, 5 Aug 2021 12:20:31 -0400 From: "Caron, Guy" To: "ecrit@ietf.org" Thread-Topic: Remaining work in ECRIT Thread-Index: AdeKFbdRCf7eb3eKQ9iXJ29nuGoZ7g== Date: Thu, 5 Aug 2021 16:20:31 +0000 Message-ID: <27309a0be23f4991aef7a42c89bfcab1@bell.ca> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.76] Content-Type: multipart/alternative; boundary="_000_27309a0be23f4991aef7a42c89bfcab1bellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Ecrit] Remaining work in ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 16:20:39 -0000 --_000_27309a0be23f4991aef7a42c89bfcab1bellca_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I'm a long-time member of ECRIT and I'm concerned about the lack of activit= y on the remaining WG draft documents. The draft-ietf-ecrit-lost-planned-changes document has gone through WG Last= Call but never went further. I commented on the LC and voiced my opinion o= n this draft to proceed (with a few nits). For draft-ietf-ecrit-similar-location, I provided a number of comments on 2= 6 July 2016 but I don't remember if they were incorporated. These two documents are important for Emergency Services and should proceed= . As Emergency Services over IP networks are being deployed, other needs are = being found that will require some work to be handled in ECRIT. As such, th= is WG should remain open and active. I personally commit to stay active and to review any document that will be = submitted. Thank you. Guy Caron --_000_27309a0be23f4991aef7a42c89bfcab1bellca_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’m a long-time member of= ECRIT and I’m concerned about the lack of activity on the remaining = WG draft documents.

 

The draft-ietf-ecrit-lost-plann= ed-changes document has gone through WG Last Call but never went further. I= commented on the LC and voiced my opinion on this draft to proceed (with a= few nits).

 

For draft-ietf-ecrit-similar-lo= cation, I provided a number of comments on 26 July 2016 but I don’t r= emember if they were incorporated.

 

These two documents are importa= nt for Emergency Services and should proceed.

 

As Emergency Services over IP n= etworks are being deployed, other needs are being found that will require s= ome work to be handled in ECRIT. As such, this WG should remain open and ac= tive.

 

I personally commit to stay act= ive and to review any document that will be submitted.

 

Thank you.

 

Guy Caron

--_000_27309a0be23f4991aef7a42c89bfcab1bellca_-- From nobody Thu Aug 5 13:02:49 2021 Return-Path: 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 6AC7C3A20BC for ; Thu, 5 Aug 2021 13:02:47 -0700 (PDT) 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=equature-com.20150623.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 gfhgLT451OoM for ; Thu, 5 Aug 2021 13:02:42 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 98A553A20BA for ; Thu, 5 Aug 2021 13:02:42 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id 190so7539461qkk.12 for ; Thu, 05 Aug 2021 13:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=equature-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:mime-version:thread-index :content-language; bh=jBU0AgF3MOuES5ZUTTbNydXGJkHkbaV7gE+alPNztVo=; b=JawFmydQzfMZ2DSMb+5FxICvZLKl1AEZtxkTXRaNlK7KKGbejrpcEV5xMjt7Jgsaak YK3h8ICWFh0fKpX78KsJEz8x903tCkMP7hOea4XdnSfAUrfEouufiUM0LpqktfQLlqZn LBhjX1J2xI+fmpvN29TVcsvFYTlx+2ghtLWnTJl8OlWYr9aWCccAa7GNjmgrRceEi+bv XUvqyZ44h1ObeJVBHqHHrVpFwffhc6mi68Gpowq2z8Akmw3KqIEk6Vqw07+gOt4F2C1m UDzKSF9HQirVdIvl1iQm76CWZ9gaKXcYFzWimEBiavSWULoQayuy5I9nRL9yYp2MXi7e Qfqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :thread-index:content-language; bh=jBU0AgF3MOuES5ZUTTbNydXGJkHkbaV7gE+alPNztVo=; b=McQxroAXfdivDhnG2aV3k60ww4TpOiAoqWG8mwAs2onep9rlQhpxUJzqcuBG237nDI gtlY7XvHUJhffEV63K2hVyPqVIkuYhkdIWWyUYf2ZTxkyzNp0Ttl6aDqNmLEatcbEF+l WbVPtqGRNq2kTo+yM/uemOYju5jzgtuw/331rRS3UWNUBYoGpIXRllNRE+DFy+kwCjGP hkLehVOnfAyJnv5Q+jrITZDIYpOotoOAKre8COYMhwYc9Rw4CpcVwCmAWLQjlUjJV6BR u8O1r6+Ghu/M8LDaBEDr+ibflPQxtGQ7EXJk+mAerY3gQJp6UvztLr64LnAin/kiWOfP XZKA== X-Gm-Message-State: AOAM5335wyIY7KUb0idlmofZC/b8A8gVEt4H5Ha0FH0zsJcfQ2g3PEP/ KfqOxWAboqzp/3WDOU/mxU3GybQfFWIXFg== X-Google-Smtp-Source: ABdhPJxAT85sv67+bcAynNYdJZE8OjuIHS6LorUcWIgw/5AlRro/LkS9sDuDROZKn4faX8PhGdWPEg== X-Received: by 2002:a05:620a:15f5:: with SMTP id p21mr6586334qkm.380.1628193760801; Thu, 05 Aug 2021 13:02:40 -0700 (PDT) Received: from mlsprecision (2603-6010-ff12-8f00-bddb-a788-a5a4-87bb.res6.spectrum.com. [2603:6010:ff12:8f00:bddb:a788:a5a4:87bb]) by smtp.gmail.com with ESMTPSA id n25sm3531401qkh.21.2021.08.05.13.02.40 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Aug 2021 13:02:40 -0700 (PDT) From: "Michael Smith" To: Date: Thu, 5 Aug 2021 16:02:39 -0400 Message-ID: <00c701d78a34$d86c7d00$89457700$@equature.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C8_01D78A13.515C8AB0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdeKNErOjnlJgJ7BQU2FVH7kAsM6bA== Content-Language: en-us Archived-At: Subject: [Ecrit] Commitment to ecrit work X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 20:02:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C8_01D78A13.515C8AB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I've been on the ecrit list for several years under my old email address but have been inactive. I corrected my registration to this, my current email address, and wish to become active in the group's work. I will review and comment on group documents and discussions in the future. As a participant in several NENA working groups, I'd like to thank the ecrit working group for its past contributions for the benefit of emergency services communities around the world. Michael Smith Chief Technologist Ph: 606.877.2788 | Mobile: 606.231.0243 _____ Equature/DSS Corp. 18311 W. Ten Mile Road, Suite 200 Southfield, MI - 48075 Tel: 1-888.305.3428 Fax: 1-248.569.6567 www.equature.com ------=_NextPart_000_00C8_01D78A13.515C8AB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve been on the ecrit = list for several years under my old email address but have been = inactive. I corrected my registration to this, my current email address, = and wish to become active in the group’s work. I will review and = comment on group documents and discussions in the future. =

 

As a participant in several NENA working groups, = I’d like to thank the ecrit working group for its past = contributions for the benefit of emergency services communities around = the world.

 

 

Michael Smith
Chief Technologist
Ph: 606.877.2788 = | Mobile: 606.231.0243

Equature/DSS Corp.
18311   W. Ten Mile Road, Suite = 200
Southfield, MI - 48075
Tel: 1-888.305.3428
Fax: = 1-248.569.6567
www.equature.com

 

------=_NextPart_000_00C8_01D78A13.515C8AB0-- From nobody Thu Aug 5 23:11:14 2021 Return-Path: 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 F2EDC3A1F8E for ; Thu, 5 Aug 2021 23:11:12 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-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 (1024-bit key) header.d=egensajt.se 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 yQ70Ly3KYhVm for ; Thu, 5 Aug 2021 23:11:07 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (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 538993A1F8D for ; Thu, 5 Aug 2021 23:11:06 -0700 (PDT) Received: from [192.168.96.163] (host-217-213-135-35.mobileonline.telia.com [217.213.135.35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 8E5F720FBD for ; Fri, 6 Aug 2021 08:11:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1628230261; bh=431QFe8LN6FoNphztkzWUm0T4bZN8TWl9dSHcEKYrX0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=K0znayplS9aE9eSPKI98l0XXoDkn8deEMubNC7O6zrBZNdV+PMjzc/pwKOttSeMcR W6xTjToRHCsgYDskT0+D7ACjIm/x+WUsFW/unOVHSuFndrT9xNZDTgqm+gnn6+I3SQ dalsC0feuMaWTU+WNk0+1X9G230ftP2CUmUtOkos= To: ecrit@ietf.org References: <00c701d78a34$d86c7d00$89457700$@equature.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <92da1755-4cd9-5604-4146-52cf78a52ecb@ghaccess.se> Date: Fri, 6 Aug 2021 08:11:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <00c701d78a34$d86c7d00$89457700$@equature.com> Content-Type: multipart/alternative; boundary="------------8D9989B7D8C03B132317788B" Content-Language: sv Archived-At: Subject: Re: [Ecrit] Commitment to ecrit work X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 06:11:13 -0000 This is a multi-part message in MIME format. --------------8D9989B7D8C03B132317788B Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Same for me, I have refreshed my list membership and intend to review, comment and discuss. Regards Gunnar Hellström ------------------------------------------------------------------------- Gunnar Hellström GHAccess gunnar.hellstrom@ghaccess.se Den 2021-08-05 kl. 22:02, skrev Michael Smith: > > I’ve been on the ecrit list for several years under my old email > address but have been inactive. I corrected my registration to this, > my current email address, and wish to become active in the group’s > work. I will review and comment on group documents and discussions in > the future. > > As a participant in several NENA working groups, I’d like to thank the > ecrit working group for its past contributions for the benefit of > emergency services communities around the world. > > *Michael Smith* > Chief Technologist > Ph: 606.877.2788 | Mobile: 606.231.0243 > > ------------------------------------------------------------------------ > > *Equature/DSS Corp.** > **18311   W. Ten Mile Road, Suite 200 > Southfield, MI - 48075 > Tel: 1-888.305.3428 > Fax: 1-248.569.6567 > www.equature.com * > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Gunnar Hellström GHAccess gunnar.hellstrom@ghaccess.se --------------8D9989B7D8C03B132317788B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit 
Same for me,
I have refreshed my list membership and intend to review, comment and discuss.

Regards

Gunnar Hellström

-------------------------------------------------------------------------
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se
Den 2021-08-05 kl. 22:02, skrev Michael Smith:

I’ve been on the ecrit list for several years under my old email address but have been inactive. I corrected my registration to this, my current email address, and wish to become active in the group’s work. I will review and comment on group documents and discussions in the future.

 

As a participant in several NENA working groups, I’d like to thank the ecrit working group for its past contributions for the benefit of emergency services communities around the world.

 

 

Michael Smith
Chief Technologist
Ph: 606.877.2788 | Mobile: 606.231.0243

Equature/DSS Corp.
18311   W. Ten Mile Road, Suite 200
Southfield, MI - 48075
Tel: 1-888.305.3428
Fax: 1-248.569.6567
www.equature.com

 


_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se
--------------8D9989B7D8C03B132317788B-- From brandon@brandonabley.ninja Fri Aug 6 02:11:08 2021 Return-Path: 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 CB8413A2607 for ; Fri, 6 Aug 2021 02:11:08 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1505277.onmicrosoft.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 HE7V6th7sjKC for ; Fri, 6 Aug 2021 02:11:03 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2096.outbound.protection.outlook.com [40.107.92.96]) (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 A837C3A2603 for ; Fri, 6 Aug 2021 02:11:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DK3NWZiiqEy79ehefC/fdJSZTY54sXQEi70jghX3utYhyi6agrhv3XgZ3bdkTgYQidfp4QFmRlJEzJzgqVuSEeb2sGGGzbmklf4zpmkFDRpBUTDv8yfDd70i3olLXnkyp95PQsmua6j+P68vJLKL5ExnRPC3tK56+swxmWM12uUJql9teyzSPAigKVjRw2g74JBg15XOdPlDdO6zPgA4DVfk9A2KVGk6dJDhvCvtE+t+CUQV3A5Ksq5hkjCkW8HFJ0mIGXw+PcWnw9EJSRtWBczLNOrHp/06k1mHkoMSekI1NfYyX0UZnKL16CNSL9P085Jizm7QOYrvz8zf/Y+KpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o9ixBwaBHamBDIgB/rQm1DOOIn79bv4X1ggUfM1fgqQ=; b=DXmqh0e1PpToe4jNBhTgon3qGvydnBwup5fx2xAMWSw5qzD0S48Wo8jLVtqx0nuwXmRUaegSmZwuVq2F50ez8QbR0ZIRUOlo8QJZWeJsZu2/VjWMDMRNvUitEz+X5O12by+62JbPkqMGa4pcZ9e+JcDZnWNBGNMxdWg1HpLiQapybNAI/QUE2cT/4Ezibf3Oc5XMO9aasZsdqbktq3Li6qzFRV/HYaDWu66t70TQ5CqrPVU8c4y0dPbpT/dej7pfUX1+hjXWxlIa0yOx2DPkx9FtpSYbCmvs+UXeNirzawNTKkZxSDacC9j1HRD57XN67rxlcFhMKHjsqs3bcyBUnQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=brandonabley.ninja; dmarc=pass action=none header.from=brandonabley.ninja; dkim=pass header.d=brandonabley.ninja; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1505277.onmicrosoft.com; s=selector2-NETORGFT1505277-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o9ixBwaBHamBDIgB/rQm1DOOIn79bv4X1ggUfM1fgqQ=; b=ynSs0fYVa+WJaWhWHHBItNKmxuwv+OesgtIV7cB6Ho5kPam16Qi5A7F71hU1fYfPlyIYFAhebP4YT7YUFzwG7u3BZf0+j56hayQwgg/5OINE0b564KSBIGuBUHD0G9JlLw0IQsThsuZn9kL5tOdSxnHncNsWE7mSX7pTncHA1l0= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=brandonabley.ninja; Received: from DM6PR17MB2442.namprd17.prod.outlook.com (2603:10b6:5:6d::30) by DM6PR17MB2730.namprd17.prod.outlook.com (2603:10b6:5:131::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.16; Fri, 6 Aug 2021 09:11:00 +0000 Received: from DM6PR17MB2442.namprd17.prod.outlook.com ([fe80::e92b:5696:fb9b:a929]) by DM6PR17MB2442.namprd17.prod.outlook.com ([fe80::e92b:5696:fb9b:a929%7]) with mapi id 15.20.4373.026; Fri, 6 Aug 2021 09:11:00 +0000 X-Gm-Message-State: AOAM530Et24mRxzqtOc5VX/Yv5+169WaoNEsWQmvTxXpN5kfKrO7VnNY N8Y1ISl9Xj6vMNGqpg7L/W9DCXNRX0qGzvQlQcI= X-Google-Smtp-Source: ABdhPJyoybAgiKKEjLIndqEVADWCGeCIv1SroyHxv/rKsxk20EJZg6a3+dXtwMKRI/QBYwJwWfNaDgazhLWxHFeplQY= X-Received: by 2002:ac8:4d02:: with SMTP id w2mr7935006qtv.273.1628241057935; Fri, 06 Aug 2021 02:10:57 -0700 (PDT) References: <00c701d78a34$d86c7d00$89457700$@equature.com> <92da1755-4cd9-5604-4146-52cf78a52ecb@ghaccess.se> In-Reply-To: <92da1755-4cd9-5604-4146-52cf78a52ecb@ghaccess.se> From: Brandon Abley Date: Fri, 6 Aug 2021 12:10:47 +0300 X-Gmail-Original-Message-ID: Message-ID: To: ecrit@ietf.org Content-Type: multipart/alternative; boundary="000000000000ddf66005c8e06963" X-ClientProxiedBy: MN2PR18CA0022.namprd18.prod.outlook.com (2603:10b6:208:23c::27) To DM6PR17MB2442.namprd17.prod.outlook.com (2603:10b6:5:6d::30) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from mail-qt1-f175.google.com (209.85.160.175) by MN2PR18CA0022.namprd18.prod.outlook.com (2603:10b6:208:23c::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.17 via Frontend Transport; Fri, 6 Aug 2021 09:11:00 +0000 Received: by mail-qt1-f175.google.com with SMTP id w10so5975561qtj.3 for ; Fri, 06 Aug 2021 02:10:59 -0700 (PDT) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: edd9a43a-7ea2-482c-dffb-08d958ba1ba1 X-MS-TrafficTypeDiagnostic: DM6PR17MB2730: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:5516; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: nSLmSJHsYS033oyBKi27nqu8M3P5ZYk2zYvc7rVtgozwLPno9Q6YtV6KEdQ69rQ9ScrqNEnihgkSAUjW5bOOpTRtqVLJOL551V9kboYhTm+eKU1PZgjURDSz7o4eckRpGr70C+2+E1kqiSKgotiD8JfOTHMj/nH0KfQzR6qePdcWkcB2wCtIbqMww6Uiwazdo1m5FlmO9G6SOEX6RmV31buf9qeL4mPvfYfxVwfxFz5FN6V7m7eeh/8MbzR+EzJnJkq7rFYlb5LbC0AdJb0yvtwIdoK/snRVUa2E6Z3YPFIl0ODsaKmIQ4RcquGJbSGnQIu9HFwIOEz39REW/aZZSZACbUYTzyGJcQmpITuGWY2E1jL+BJGftFb1puCyBa8HenCTXcV92lsgwE7Mft90OpaDkb4mC+01O4nuj9stIzMZifq9SVemRwq+9jXyPGAmB5UHauV4YsQVRgOHi90Kgixxc/uTmFCzdIZDpOPf1ZQsH+FfAUY1Ecca8aMAVWocSyBXKmLKQOh0RI+cnAYMLPPgPkDTAe1ZC/jKbPSQkZTWhECXzuOJ1Lmn3wf+kvmfevSUSHhS8OQQJYwBpQacRtl5VCjQQCEaqfiGOFNdWl4aubXRO6D41L814mVTD1hUz2D/aAipvNWI4o/SZFqQYXdcUcPqBj8gUiOLgSSwuEuMwkZPp2joDetkI4NEMW9jZOFZel5vzj3fG7h4EpwQNLxVmOvo98DflsuaJs5en2UNusFHbrm9vNrLOeeaVpMq89fwa8cvJl6vfotkHpHOsUKiQwPvFhxkQ5IUngPiUjdX9P3AGpoeLm7r/1RE1oX0qdJVXqumB/YqUO/GBNRFe0o/JrKb19KjttJL0shL7lU= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR17MB2442.namprd17.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(39830400003)(346002)(376002)(136003)(52116002)(8676002)(26005)(8936002)(33964004)(186003)(2906002)(42186006)(55446002)(316002)(166002)(38350700002)(66556008)(66574015)(66476007)(966005)(86362001)(15974865002)(55236004)(83380400001)(38100700002)(9686003)(5660300002)(6666004)(478600001)(6916009)(66946007)(46492011); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VXRNOWdnZGU5U0VDMEErbUx5TFltNlRlMGhzQ0oyZGQwQjdzaEl1alRONVY3?= =?utf-8?B?K3RjQWcxcW9XQ1hPS0hDWVVhTEM4RDM0aVRZS2ZSSUdVVzJCKzl1emw0VnVx?= =?utf-8?B?WndoZWpLeXZ6Z3RpdzF2OFhXdGNLaEVvQmR3TXVOS1BkMFhoMFc0U3JxUFAw?= =?utf-8?B?SHJIRGpONmppQThia3JPTmlkV2Y3OWtVbFBlODNDcUJXZW92ZUVwc1hNQndG?= =?utf-8?B?bFhBbi9kSk1tY2F4UHFabk1rOGlKY0s5NXUwQWprYjFTUmhDQlRRVTcxRWM5?= =?utf-8?B?YWlBTWxpVHRnakFXZEVoUDJnL2NoVnZHUnZXMWNpYUIzNW5NZktrMm5TK1RY?= =?utf-8?B?T0t3NmhSU2ovQnU5NzNTakg1UFhEQmw5R3k4VHFhOWpDb2d5UGt4U1grSW1o?= =?utf-8?B?S2RObjB5dTFqTk5BYmVKSVVlandqWmMveGtlUCtOWHZzRHFUdy93M2IrZzRv?= =?utf-8?B?NmhVSFcyY2tCR0FRUnBZRURrWFoxMmZsV3NDK3YrZE5EbWxlSUxCd0dhVHRU?= =?utf-8?B?cTlKZ25qWWxwMDNhWTlRMEJWY01hekpNbkgvTmVMM05pRjhaemdLS0RhRmpa?= =?utf-8?B?Rm1GQy92c1dkYWc1V2N1eGNVSFdqcUdSY3pKdG0zOFkrUVFSMHJhZm9PenYx?= =?utf-8?B?Z2poZ09NL0VjcHdzN0p2MkJlSHpDV3dzUE1GeWVaRGVVeEFHZGhCb0VMM3gw?= =?utf-8?B?endpVWdvYjlGTjYxaG5DZzE3V3Jtb1dSYnFMdWRnbjduSXJmUXlvc3l5ZWta?= =?utf-8?B?dTQvY1F5Y1pnQXdQZkJ3cDlPcDk4MlRab09IMXRYeFhLSnIyUVJqbXZWYTZS?= =?utf-8?B?VjRSYm5RQzY5V0R0MnlZdzZEZXVCNVVVRFVYVldxMWxyRHNQL2s5Q2haVWdZ?= =?utf-8?B?NmJBbTdaTEhYek5SQUV3THJDaVc4ZWRISXZDektNeGlhVkRTZG5IYUpHMUVk?= =?utf-8?B?dWkyRlRGdmNwU2tHOEdHU0hBOVp2R0xaVHJqSUZSZVJEQWxpK1U1TE83MnZl?= =?utf-8?B?WUExNkFsR2ZMcnJ6dlNjT1JobjVPVHhOWkJDY200b1Y0MWZhOWtYZ2xlZ0pU?= =?utf-8?B?UUxYWEdlV0Fsc1NlTTU5eGJIVHNNKzczSzJ6dHlrc1JRYjU0ZEs4NmU2Tjdz?= =?utf-8?B?cGpQWGZFVG4zY3ZkS25UdkF0MjJYWHdyTmdpY3dYWHRmT21YM0Vjb3RnYXE2?= =?utf-8?B?cDJLVE1pb3piSHJmMi9vdXpDQ2x5ZFlIKzExQmN4UEhJYU9jeUFQUWpxaWtM?= =?utf-8?B?NmpIZDNGTW1NS0xiYXRYQlJpYWdpRGMwLzA0S1d4L3o5WFFkYWNqTno3N216?= =?utf-8?B?KzlsT2s0TXZuUWw0SXhObndMU1Q0ZDRaT1JCUWtReDhON2NENk5CMHVXTmhG?= =?utf-8?B?UUJQUGN1VmhVV3UxVGthaU9XR2dxb3JDN3dKcVlhMUVZRDVXTUpRNUl1VXhy?= =?utf-8?B?YmN4NFJzaXpTZ1FadG9XdllSY05sOElCNGNnMFJidEV3K1lFT3UwaFdEMFJ5?= =?utf-8?B?OVRnbDlJKzE1NXplYXRVMzlmcndxV25GYkkwMFlFWmlSMit3R2VJeGNzM1BB?= =?utf-8?B?NGhFeThwNGIyU3FuNU9KQnlPNGQ2YXNDNkhvbjdEU0tzNVZ5N3BCRGZOaHFB?= =?utf-8?B?a1NqZXRZYUltZ0ZIVmw4VC8rWTdpVm14M0Q4dCt6Q3pJNm9tNkpiVkcvYkdz?= =?utf-8?B?OVp4aXNFNmE0VHFVeE5ZSk4zMFJhM2Uvai9xUHEreHh1Y1NlaDhBOUtzYjBU?= =?utf-8?Q?uEtreSCDlE7Onjk3Mg9qmAIJUdOiwddiLGwQdVB?= X-OriginatorOrg: brandonabley.ninja X-MS-Exchange-CrossTenant-Network-Message-Id: edd9a43a-7ea2-482c-dffb-08d958ba1ba1 X-MS-Exchange-CrossTenant-AuthSource: DM6PR17MB2442.namprd17.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Aug 2021 09:11:00.5987 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 8a588c78-8076-4fdc-8495-a7fe35eb6c8c X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: AfQ4BdeVgiVm5EyMXG44r+UyvsgZAH/ScHVZ8W+aG2vzBvQPud+lnbkvE8iSPfNwFwCCHDfO5xuv7UGzXUFQ3siOBKoI4J2P+lfa/9cMLkg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB2730 Archived-At: X-Mailman-Approved-At: Mon, 09 Aug 2021 09:25:52 -0700 Subject: Re: [Ecrit] Commitment to ecrit work X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 10:05:15 -0000 --000000000000ddf66005c8e06963 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello all, Registering with ECRIT via a personal email for future-proofing's sake, but many of you are familiar with me from NENA. I intend to read, comment and discuss. I also am willing to author and shepherd documents, but will need some mentorship in this regard. I have much background in standards development at other orgs but have only read many RFCs; I haven't participated in them. That said I do have a draft RFC to introduce with a colleague shortly for implementing registries that some NENA standards need. I have also recruited a couple of new members that will sign up and introduce themselves eventually for some fresh perspectives. For background for those unfamiliar, I am director of technology at NENA, an SDO dedicated to emergency calling standards, so my interest in ECRIT is part and parcel of my duties at NENA. -Brandon Abley NENA On Fri, Aug 6, 2021, 9:11 AM Gunnar Hellstr=C3=B6m wrote: > Same for me, > I have refreshed my list membership and intend to review, comment and dis= cuss. > > Regards > > Gunnar Hellstr=C3=B6m > > ------------------------------------------------------------------------- > Gunnar Hellstr=C3=B6m > GHAccessgunnar.hellstrom@ghaccess.se > > Den 2021-08-05 kl. 22:02, skrev Michael Smith: > > I=E2=80=99ve been on the ecrit list for several years under my old email = address > but have been inactive. I corrected my registration to this, my current > email address, and wish to become active in the group=E2=80=99s work. I w= ill review > and comment on group documents and discussions in the future. > > > > As a participant in several NENA working groups, I=E2=80=99d like to than= k the > ecrit working group for its past contributions for the benefit of emergen= cy > services communities around the world. > > > > > > *Michael Smith* > Chief Technologist > Ph: 606.877.2788 | Mobile: 606.231.0243 > ------------------------------ > > *Equature/DSS Corp.* > > > > > *18311 W. Ten Mile Road, Suite 200 Southfield, MI - 48075 Tel: > 1-888.305.3428 Fax: 1-248.569.6567 www.equature.com > * > > > > _______________________________________________ > Ecrit mailing listEcrit@ietf.orghttps://www.ietf.org/mailman/listinfo/ecr= it > > -- > Gunnar Hellstr=C3=B6m > GHAccessgunnar.hellstrom@ghaccess.se > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > --000000000000ddf66005c8e06963 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all, 

Registering with ECRIT via a personal email for future-proofing's= sake, but many of you are familiar with me from NENA. 

I intend to read, comment and discuss= . I also am willing to author and shepherd documents, but will need some me= ntorship in this regard. I have much background in standards development at= other orgs but have only read many RFCs; I haven't participated in them. T= hat said I do have a draft RFC to introduce with a colleague shortly for im= plementing registries that some NENA standards need. 

I have also recruited a couple of new me= mbers that will sign up and introduce themselves eventually for some fresh = perspectives. 

For = background for those unfamiliar, I am director of technology at NENA, an SD= O dedicated to emergency calling standards, so my interest in ECRIT is part= and parcel of my duties at NENA. 

-Brandon Abley
NENA


On Fri, Aug 6= , 2021, 9:11 AM Gunnar Hellstr=C3=B6m <gunnar.hellstrom@ghaccess.se> wrote:
=20 =20 =20 
Same for me,
I have refreshed my list membership and intend to review, comment and discu=
ss.

Regards

Gunnar Hellstr=C3=B6m

-------------------------------------------------------------------------
Gunnar Hellstr=C3=B6m
GHAccess
gunnar.hellstrom@ghaccess.se
Den 2021-08-05 kl. 22:02, skrev Michael Smith:
=20 =20 =20 =20

I=E2=80=99ve been on the ecrit list for seve= ral years under my old email address but have been inactive. I corrected my registration to this, my current email address, and wish to become active in the group=E2=80=99s work. I will rev= iew and comment on group documents and discussions in the future.

 

As a participant in several NENA working groups, I=E2=80=99d like to thank the ecrit working group for its= past contributions for the benefit of emergency services communities around the world.

 

 

Michael Smith
Chief Technologist
Ph: 606.877.2788 | Mobile: 606.231.0243

Equature/DSS Corp.
18311   W. Ten Mile Road, Suite 200
Southfield, MI - 48075
Tel: 1-888.305.3428
Fax: 1-248.569.6567
www.equature.= com

 


_______________________________________________
Ecrit mailing list
Ecri=
t@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

--=20
Gunnar Hellstr=C3=B6m
GHAccess
gunnar.hellstrom@ghaccess.se
_______________________________________________
Ecrit mailing list
Ecri= t@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
--000000000000ddf66005c8e06963-- From nobody Mon Aug 9 09:26:10 2021 Return-Path: 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 60C103A1807 for ; Thu, 5 Aug 2021 09:15:41 -0700 (PDT) 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=equature-com.20150623.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 SmXHowMk36W7 for ; Thu, 5 Aug 2021 09:15:36 -0700 (PDT) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (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 840DE3A1805 for ; Thu, 5 Aug 2021 09:15:35 -0700 (PDT) Received: by mail-qv1-xf30.google.com with SMTP id f91so3216054qva.9 for ; Thu, 05 Aug 2021 09:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=equature-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:mime-version:thread-index :content-language; bh=bbVcVxUTlk4MGu5BxKKd5af1K8yK32ljz1Jcyq78CWU=; b=06ydkfCByhrbpqZIaBaFl05HL4WRehqZhvUtJXN42EUXoCZPHNjOvoBrHoFUqJIbco A2Og+8QcMJXWe/JWFjdSe/MUFQLps8emD4h2I0kF6sUnYgm++TE1W9g+Aols5hxips5r i6d+JbqCNX7UvNTGNMvX7+tZUVXAAWa1DK+gcpHjy0of2kwlVm9T00RBKFfU8mxbCEcn oOnHn9e/Vx9mqgJ1wXIBTKCLbb5GfwYK2VShxTZo478F4Kh58GDFH8jfVL1izZqsAs8u yduazJLs7yP/pLZaAEf9FQnkLTYrXswRjHbCaUupte0zQzNwb5WFTyyfG+KQUG17D0dG CTxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :thread-index:content-language; bh=bbVcVxUTlk4MGu5BxKKd5af1K8yK32ljz1Jcyq78CWU=; b=Px1xjthJH8wrVmcmrzziWL5eD9TQ4Vp1uyQA+r1pw8Yw5IZ0V43fWIe09mWMImLSuk JQL9DKyjEGns//q6E/sZx9oi1fsp+iD7RC+3a5JANil5i974eqf7QgimqoAePF/jO02/ WFB3bIdfZNIn3UwUZotynNphplxX7N4qunLoy74ktlxH3CgHxH0/FIw1AFeLMq1wIV8p pLA6+8ioRgoavRO7uWQEgFTIN08qgapBKU6rKF48trMrZh8MsSUKMb0VXi5Xj0ElJ7yQ Q9SI15gAOkUC1d/KuVUlC0NlXsSIcdZZVCKty82d4zfA2Ut1lsxAUj/BHtui9O5IBdfY u48Q== X-Gm-Message-State: AOAM533c6SQLNoGYxJQk+nl6rXXvcKlA0aWLvXjDVZ7k7BhQgyrtbAo1 p9d3U4rvc1oZ3ZONhL5bISlCyZ63zc6OLg== X-Google-Smtp-Source: ABdhPJytGWHU16esusR9waoSpoxi7XJMsIwkMTrZv+RAhLPBLdBDZAIot+ZnwI5z9f8UIwSIvL7sgQ== X-Received: by 2002:a05:6214:1230:: with SMTP id p16mr6178478qvv.42.1628180133069; Thu, 05 Aug 2021 09:15:33 -0700 (PDT) Received: from mlsprecision (2603-6010-ff12-8f00-bddb-a788-a5a4-87bb.res6.spectrum.com. [2603:6010:ff12:8f00:bddb:a788:a5a4:87bb]) by smtp.gmail.com with ESMTPSA id bj36sm2387076qkb.51.2021.08.05.09.15.32 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Aug 2021 09:15:32 -0700 (PDT) From: "Michael Smith" To: Date: Thu, 5 Aug 2021 12:15:31 -0400 Message-ID: <006301d78a15$1d117a70$57346f50$@equature.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0064_01D789F3.95FFDA70" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdeKE+Su0K7xJSpqS5CmEdC10I000w== Content-Language: en-us Archived-At: X-Mailman-Approved-At: Mon, 09 Aug 2021 09:26:08 -0700 Subject: [Ecrit] Commitment to ecrit work X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 16:15:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0064_01D789F3.95FFDA70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I've been on the ecrit list for several years but have been inactive. Because I think the ecrit work is critical to improving emergency services worldwide, I will now dedicate a portion of my time to reviewing ecrit documents and participating in group discussions. As a participant in several NENA working groups, I'd like to thank the ecrit working group for its past contributions for the benefit of emergency services communities around the world. Michael Smith Chief Technologist Ph: 606.877.2788 | Mobile: 606.231.0243 _____ Equature/DSS Corp. 18311 W. Ten Mile Road, Suite 200 Southfield, MI - 48075 Tel: 1-888.305.3428 Fax: 1-248.569.6567 www.equature.com ------=_NextPart_000_0064_01D789F3.95FFDA70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve been on the ecrit = list for several years but have been inactive. Because I think the ecrit = work is critical to improving emergency services worldwide, I will now = dedicate a portion of my time to reviewing ecrit documents and = participating in group discussions.

 

As a = participant in several NENA working groups, I’d like to thank the = ecrit working group for its past contributions for the benefit of = emergency services communities around the world.

 

Michael Smith
Chief Technologist
Ph: 606.877.2788 = | Mobile: 606.231.0243

Equature/DSS Corp.
18311   W. Ten Mile Road, Suite = 200
Southfield, MI - 48075
Tel: 1-888.305.3428
Fax: = 1-248.569.6567
www.equature.com

 

------=_NextPart_000_0064_01D789F3.95FFDA70-- From nobody Tue Aug 10 07:08:25 2021 Return-Path: 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 1A4D43A2108; Mon, 9 Aug 2021 18:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=comtechtel.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 kxPBW7fzObtx; Mon, 9 Aug 2021 18:32:20 -0700 (PDT) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2127.outbound.protection.outlook.com [40.107.91.127]) (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 3D4203A2105; Mon, 9 Aug 2021 18:32:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dCcLbvdiuzBzH590DHpVpr6+VnVQ7IQVlPd1alnRIqk/hV/bMRo8NqhmTUJoL63W0aNVG+W5JsfYaRmFP/6hVEl8Fx6QvjpQjrc2MvDU9YqwXk3KWTbj/qWqNtcGVukDkkw/E2SemX5jki0p+JtkaJZ9s2HxhuqnG9DgYLjAv26CzZqu6QrI1G1FtkQgpg5VQ3ksvmjy5rViQ7FwjLcawqFSjUnE8/0XZKo5w5WZ/O3XJaHgoKD2ZUsAbC8eKiLyqL3W6PDCG7UBMARPZJnzX3U7HVIijJ26XuUth1CD3LCX75MgR6xPRPgrnBonTxUOBs5YJKjpLwvP+ihAlCdPbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7ntHoLIt3w1INk0pmdXMoA6Hm5vECBfvPKTf/f+/9po=; b=g8bWQ5KYmwdks5rr8FqSJ3g8LN1RasBCFdF/CLDbfnpgqNAFwDWHbGiNVyHAxWG52I1MwjYpHW8ok+p5Oq+tQVod/iy5ukkj+kW7V5PM9/OSlZLMtwgu5g65XrC3gjUUIeLuvQIrP+NGWKYFjwziZH0NpwBDfJ3m41BNDYfPc1yU37XEOr+2h/V0LeoVqf6cPBlRp7NyX6Qcuj2eKvDGDUkRcr1cYBVwNDr0vWMA4AwgIDRgj6/uR2MSwDQT9vsTbHMm9rVvOUm7una9qpkImyqpaLjd204B28vGwyIqa5cFGnC3KpnnGFPdckWosET+/4960rne05STI3RwvRu81Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comtechtel.com; dmarc=pass action=none header.from=comtechtel.com; dkim=pass header.d=comtechtel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comtechtel.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7ntHoLIt3w1INk0pmdXMoA6Hm5vECBfvPKTf/f+/9po=; b=Zyma0hWvj/kHMO3+O4AAlBmUEXK78nAzeyw6zcw+0PjvdmVzDR8CgsKKBBtphlMvVDCqBvAIOe9Hwuqwngbf2DrBG/TwjvXDN1Ui7aHnksrSBJkEkOOYibrRnezTa+gixSNm/XQ8Fj6/ZINVBwAdB++Zwl6WZ3ss3cRcsHrS63+bU0aqPXK42SpBVo4/IWTxK4cIBZ+WoKTbtQzZNe0D/8BuwWIndzoy1C3b3RBUELQDM+0OaRsusfJEtbdiEv4j8u53tEdY9emDdhGQFU00PAD8ow7DjZiCjBqOz9c/t4GZZBWbvsaBOFkPC7ko9V2nBxTLBlwZ9yqgGsDkxEYbdQ== Received: from CO6PR09MB8007.namprd09.prod.outlook.com (2603:10b6:303:cd::13) by CO6PR09MB8791.namprd09.prod.outlook.com (2603:10b6:303:cd::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.18; Tue, 10 Aug 2021 01:32:18 +0000 Received: from CO6PR09MB8007.namprd09.prod.outlook.com ([fe80::dd83:7dfa:ce01:8a4f]) by CO6PR09MB8007.namprd09.prod.outlook.com ([fe80::dd83:7dfa:ce01:8a4f%7]) with mapi id 15.20.4394.023; Tue, 10 Aug 2021 01:32:18 +0000 From: Victor Burton To: "ecrit@ietf.org" , "'ecrit-request@ietf.org'" CC: Victor Burton Thread-Topic: ECRIT Support Thread-Index: AdeNhz6MJJROT49YTU+5sl0SA4z9sg== Date: Tue, 10 Aug 2021 01:32:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=comtechtel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f02683a5-70e1-47f9-12a9-08d95b9eb13d x-ms-traffictypediagnostic: CO6PR09MB8791: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LZ68O2tOIFCHHf40zx+hUzB/bCIXRn+xUS3xpveKX3vMIzmJU8F0T8dsRlyR9a8KKoQNONYtbsHkF/+AbfHHez3/FSPOBwdHgT5JNHFrFcq3vfWu6J+XW/m/xj3uNbKoMB7eaOhjSPkyZcbOy4yqCV5VfeaKVj7RwEFoJNhDC7L8jR+0rzZlcudLw2GnyE7eWvLP6tq5WeoGVmRbXKay6kBiZ2Hmqour9/2tia0PKqCrgkDcX2kmKEgTTx+3O+bpxQIaKZpl4xT7hbfHm2CJ3shldWwovEJTQ/wt7owhi0AGIt2zmJMknU2o9tGldsvGgrXbSJ4ihzhb9m2Hzw7Ja0dSBcNLtTmEAk4smlq9gL0QZoT5BaeeMUJPE2uhIcWgvRxJwDyPgNzGqCZpTdnyNZ/zjoQP783++R5yEJ+AvK4csc5v1lGA+YSMoEB0yz36hJxVrrHDn5iFEJg7nuo6Mlsz0HfZPATSXBwC9wLXLpa7UBFz4PZJsngVEd/qF31Cox2BxFW8ojE5Dx5zcBooEeHIrE9FDHFpXzH22RnKsUGx+lBDH0jEDxezBSChS8MTpsby3ZuJAlEPupquNHLLVemU0CaGVsdp+d1FmeuUfm3a4Wy0n9iABdRoWQG8dQ96b74jKAeP1QbvZkta6efIadvS2AtUujJIuCPD8HATyOLdTPiHZkuR4l4H+Es8Mu8yHyLR+rOkTBY0j4Gi6ku7Cvy4D9J7d00m+ytm0RU9On0= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO6PR09MB8007.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(110136005)(122000001)(186003)(4326008)(66476007)(55016002)(107886003)(66946007)(508600001)(38100700002)(71200400001)(66446008)(76116006)(38070700005)(64756008)(5660300002)(8936002)(44832011)(66556008)(9686003)(8676002)(26005)(7116003)(450100002)(316002)(2906002)(33656002)(52536014)(6506007)(83380400001)(7696005)(86362001)(3480700007)(491001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?JofLLbpPXd079p/bAJOdWyJGlFCkG8HFTIiBsSEogP7KTQMMfbi9mecgoDnv?= =?us-ascii?Q?6oCNSly9CWPTi4VcDQXK29kYUPcihStfXl7B0vUFnRg97XBfrV3ChBxIzyEh?= =?us-ascii?Q?g/uZjPBDQoNZeE20We01/m/FnfbjUafioh7Tog66NevLP4fr6jo63MKkN99R?= =?us-ascii?Q?6bswGtqg+inQ/ur8Wntfb5omz8XE75q0aF8hLOti80CtzCf/puipk7aofjcZ?= =?us-ascii?Q?bK3VYf7stC9dpFnGrLnWWK3TKP3MRYFWpfS1VpytkVVtyu6NtoGaQOF1Leyz?= =?us-ascii?Q?11S9bofrzjjFHKAzWzoqSRphVKA3QEVqeQGaFPELORpXrojhcnbYUTBUzSch?= =?us-ascii?Q?4Xmij3YMhFASkP9X5nkPJWm2/K9Y3oGS35iyiOrsMbnmIByueoOlMrQYPD1l?= =?us-ascii?Q?A4jJNW3jihXShU3mux3/eaUHVOLuqm/3zR2Sz30P8SX5Z8WK9fVamweVqFSk?= =?us-ascii?Q?t9NHFlnVyXAvK1ro4/NLeo09RQnuYCF1VBejSzjf4Qq3GeZZkLbUqQ+M8bmp?= =?us-ascii?Q?cUgzQ2hl7pVaHLY5kWpL+Qr/g2OOk8rO7FWutXV3b0jO/4cGgUF01KBJVqVh?= =?us-ascii?Q?JGJQ1R7Iw3beT6SbXPHRa5LPIwealA6SfudC5xugWqyHaSwBwPFeJK7uqPmF?= =?us-ascii?Q?6vCHi2rjswFQ9Uon60f9b7T3qAjLIgA+ISMHBAlru+FyDHo4lJ0bgAgVr0Jy?= =?us-ascii?Q?OuX/vh5tCiQRgll+3SkbOsOw7X4DIRqUqQN72oUj0Gt+TdGdmJ1DzutThK46?= =?us-ascii?Q?jzdH5UnRuiXp/2jQslj+am83wT2nU3r73KyslUTWnjgYj5kPRASoG7K9cvxb?= =?us-ascii?Q?QQCjVyQcAb4ZhIG/JTdsCPbRWCHtv77DgeoLuiPaUNZ9MKWWl4D2PfZQY8HD?= =?us-ascii?Q?VtFsvCkCeGo7vcgoC/PzjulzdKyTP29dfD2nbS83EpUOyr05gSfeU3HXHj62?= =?us-ascii?Q?hoPnPhT4Dz/DwlNxmHiNXbqcggL5sNE+K6mGvD6wwlhkApR9h/X8g/F7jEeX?= =?us-ascii?Q?X7vjk5BWiAV5aLFP5pbzEKfDAHRyz71p1bhvEH3DfRUSq8caDx3jSbTI1Xaa?= =?us-ascii?Q?wbVdQCLXfdXpjep6qhs+/neuuIGUzgCe0WBVWV0dmCg64c3h1OgI0I08LHwP?= =?us-ascii?Q?s2kpb5PdQpKB2g72Tb9liF2Tz6r8VhT9mEx3xoOP7IchT9p4LdFJ2RzHDysO?= =?us-ascii?Q?DQQmlNPGhDD09zCdXTsxI4IVarUAvRMd/HM3p7oJ99liIe8xmVrCwzl0NAwo?= =?us-ascii?Q?kRn3hmaM09sLUx7UEo9TvyLkoYcaRfbgxvGs3zWTvymk+VgMbKgugM4eClGb?= =?us-ascii?Q?MKu6RwJdi1Cbh0WhOGtJF9jT?= Content-Type: multipart/alternative; boundary="_000_CO6PR09MB800711AF6988A95595606C8C98F79CO6PR09MB8007namp_" MIME-Version: 1.0 X-OriginatorOrg: comtechtel.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO6PR09MB8007.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f02683a5-70e1-47f9-12a9-08d95b9eb13d X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2021 01:32:18.4891 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a9a26e69-6ae0-40c1-bd80-1ca6cc677828 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR09MB8791 Archived-At: X-Mailman-Approved-At: Tue, 10 Aug 2021 07:08:24 -0700 Subject: [Ecrit] ECRIT Support X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2021 01:32:26 -0000 --_000_CO6PR09MB800711AF6988A95595606C8C98F79CO6PR09MB8007namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi - I have been member of ECRIT and agree to do the following: [A] Read documents that are up for discussion; and [B] Send comments on the documents to the list Thanks, Victor NOTICE TO RECIPIENT: This email, including attachments, may contain informa= tion which is confidential, proprietary, attorney-client privileged and / o= r controlled under U.S. export laws and regulations and may be restricted f= rom disclosure by applicable State and Federal law. Nothing in this email s= hall create any legal binding agreement between the parties unless expressl= y stated herein and provided by an authorized representative of Comtech Tel= ecommunications Corp. or its subsidiaries. If you are not the intended reci= pient of this message, be advised that any dissemination, distribution, or = use of the contents of this message is strictly prohibited. If you received= this message in error, please notify us immediately by return email and pe= rmanently delete all copies of the original email and any attached document= ation from any computer or other media. --_000_CO6PR09MB800711AF6988A95595606C8C98F79CO6PR09MB8007namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi –

 

I have been member of ECRIT and agree to do the following:

[A] Read documents that are up for discussion; and
[B] Send comments on the documents to the list

 

Thanks,

Victor

NOTICE TO RECIPIENT: This email, including attachments, may contain informa= tion which is confidential, proprietary, attorney-client privileged and / o= r controlled under U.S. export laws and regulations and may be restricted f= rom disclosure by applicable State and Federal law. Nothing in this email shall create any legal binding agre= ement between the parties unless expressly stated herein and provided by an= authorized representative of Comtech Telecommunications Corp. or its subsi= diaries. If you are not the intended recipient of this message, be advised that any dissemination, distribution= , or use of the contents of this message is strictly prohibited. If you rec= eived this message in error, please notify us immediately by return email a= nd permanently delete all copies of the original email and any attached documentation from any computer or = other media. --_000_CO6PR09MB800711AF6988A95595606C8C98F79CO6PR09MB8007namp_-- From oconor.ecrit@gmail.com Thu Aug 12 10:04:01 2021 Return-Path: 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 7AB623A4315 for ; Thu, 12 Aug 2021 10:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 81SUhLRdE4QG for ; Thu, 12 Aug 2021 10:03:56 -0700 (PDT) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 5468F3A4303 for ; Thu, 12 Aug 2021 10:03:56 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id d1so8135918pll.1 for ; Thu, 12 Aug 2021 10:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=OlNSasv8CRjuCPo5wPxUS1kGCID8C0kWD508OvLrFlQ=; b=GXgKjlZh88Lb/mlaM25l/UPP8jhQozs6Urk7vg+G5eqCngu7M9aKT6F23fLlpyeHTE UrJpr5CarW87t7VvLqx+ngmyWQFPXJw+7AhCty5rrKzT+yqJH8ahQ6K66iKDbK2X7ed1 agYwdvIAj4UseoLC/XgalndCEWzophfqUJ+WU8IUTAs+4vBZIXQOdFXz7BkRsezibPge eRmk7QazSvT+IHbvSbwxaUl3LrC5d34KMu0jpCX8h6YDb8sHIvebw41ha3OGuzRv9I2P aX/GgUvBhQ2vz/jQR17kABQFyDqsjtkF9/C7Whl0f0kFtngRz0PPt0yRp8tX3IqpPhsR +uEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OlNSasv8CRjuCPo5wPxUS1kGCID8C0kWD508OvLrFlQ=; b=rjl0KoIJB4BqKr3tjoyLfwCVNdEnrTia3vR4SIMY/EMHzq2oAJTkuWXJ9UwBKCNHHA yqwpKAcSylgPbWx1D4XR3Nx28mqAlRQXJdXHIqJkPR3zA8bNrvVlDy/UD0+eXKV5rqAW bOjQGxNnYIh8ZxUMnut/vY4zP8mgPivTfj4g04TWLdQyuAtWwL4BN+ragyUpBFjHD3ka eTDmAeaIhmPoIUh2NlqPGkiM1zJRfNiVfx222PU6c0M5tL97ZsvfdG7eBYRGEve7Aux7 CUgCiuTvAzw2Lcgnk/SXF2pnQT7B8GAEEc48BkBm9oaY7GF2ca4vpZCStp5Zr3H/tmld 5Z8Q== X-Gm-Message-State: AOAM531wGs3NXOsYrymNg5nwN+IOOywob/JdYeidlPxC2reJHs8qrIGx B2nyS+fdtaC8PxzM8wR+9FqkQXW8DI9CA8elRgj40RCrhi1CnJon X-Google-Smtp-Source: ABdhPJwdSWekdwwC/LWBupEfTCtHxt5ASQXhYEAcSgGTYxJgUFjjZ8+R+8KupJIUBnwdOaFBw6rLc40jzRIvcWo3UCs= X-Received: by 2002:a17:90a:2802:: with SMTP id e2mr7573485pjd.215.1628787834202; Thu, 12 Aug 2021 10:03:54 -0700 (PDT) MIME-Version: 1.0 From: "Stephen O'Conor" Date: Thu, 12 Aug 2021 13:09:21 -0400 Message-ID: To: ecrit@ietf.org Content-Type: multipart/alternative; boundary="00000000000045afa405c95fb804" Archived-At: Subject: [Ecrit] New Member X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2021 17:44:43 -0000 --00000000000045afa405c95fb804 Content-Type: text/plain; charset="UTF-8" I have joined the list and agree to 1) read documents that are up for discussion, and 2) send comments to the list. Looking forward to helping move this important work along. Steve O'Conor, ENP Co-Chair NENA 911 Core Services Committee Co-Chair NENA i3 Architecture Working Group --00000000000045afa405c95fb804 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have joined the list and agree to 1) read documents that= are up for discussion, and 2) send comments to the list.

Looking forward to helping move this important work along.

Steve O'Conor, ENP
Co-Chair NENA 911 Core Services C= ommittee
Co-Chair NENA i3 Architecture Working Group
<= /div> --00000000000045afa405c95fb804-- From nobody Mon Aug 16 21:53:49 2021 Return-Path: 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 71AC23A1A6B for ; Mon, 16 Aug 2021 21:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 HJJ5iKeYcsPh for ; Mon, 16 Aug 2021 21:53:37 -0700 (PDT) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 BB32D3A1A5C for ; Mon, 16 Aug 2021 21:53:37 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id e9so12403649vst.6 for ; Mon, 16 Aug 2021 21:53:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=RfpLumt6qmGt4DPUZp7sfzjoF/7aQxuaxw3CNimulsE=; b=Ech5/ZVSgwflZpzfVpmyG6CJ40V+ESU7928SffPGPGz8LmW+Qq3VDW3dJ/WCQnfKTB wft3HJwbzB8sb9kQ7hfc9dHuwDs1D1bgCuiHU6HOWdmvTgjbQFy50Wb6gzpPlAYj6QD5 4J+3OQN8ijD7ATqRmmr4iF5gZrTQ8RgZ/Nnwuo6MTDQ9CI5/AgWmrj0urdn/itE0ttLJ lnRr9vy3eEYquVKBtJySeKJIj+voB8TjNDW4V5lGSPJ9KNHVEtgioQIMz0tQKIe85EkI OpV7zcdkxH9DP0PnvAusvydOL1eWvUFgsAqMal3CPQhX0UkBdxpxKqn+XzOpCDAF9zk8 Vd0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=RfpLumt6qmGt4DPUZp7sfzjoF/7aQxuaxw3CNimulsE=; b=m+LNQJZJNQ0Ke43qse8Od6+Eti0tSA2NpAOI2FwqyWKD3uNOmjuYBNIWp0QMzMizQw 8xchtMwl+DM5QQNxT6DV5edFk/7z3K0EtivbfjvCq7JC83/K9tGt9XneOyDoMXslOSc9 7y95PXSGJG5DEvj3eBRU8GLDxMl46mOpQkQZPqkXMSKqdq1QIvfQahowOQS7aaR4Xvl0 2tf4ouytgDcStP73iJ0l3vE3tlDmm7KEj6o9r88N1bBT5lZ9ruyWzts/MWQFXBEWpVUg VveDBjxcYvu0sPPAT2iIgsfMB0Ut9KpJ2rz/jZHimR/e8qSj17hA6+JIxiQWdVGyQPW9 /WKQ== X-Gm-Message-State: AOAM5319yE2pH2wTF6wmyyAbDftqHU/w076P5ZeESBRyyXyCOJf5Vudb EzLittNQReZX1KmrTELJuGmpkbsIENnpmjZlzYP8SB/3mH/UPw== X-Google-Smtp-Source: ABdhPJx4LPlOpkHZksnhXUkU1+SwP7KD1EsVaKjw6L6z28Lbpm39RJ5bkPpH7J+p83Dntl6lAU+woy2gyBx+dq0RxAo= X-Received: by 2002:a67:df0c:: with SMTP id s12mr1166283vsk.0.1629176015758; Mon, 16 Aug 2021 21:53:35 -0700 (PDT) MIME-Version: 1.0 References: <20210604064031.47491F40725@rfc-editor.org> In-Reply-To: <20210604064031.47491F40725@rfc-editor.org> From: "Murray S. Kucherawy" Date: Mon, 16 Aug 2021 21:53:23 -0700 Message-ID: To: ecrit@ietf.org Content-Type: multipart/alternative; boundary="000000000000b22cab05c9ba19ee" Archived-At: Subject: Re: [Ecrit] RFC 9036 on Changing the Location-to-Service Translation (LoST) Location Profiles Registry Policy X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2021 04:53:45 -0000 --000000000000b22cab05c9ba19ee Content-Type: text/plain; charset="UTF-8" On Thu, Jun 3, 2021 at 11:41 PM wrote: > A new Request for Comments is now available in online RFC libraries. > > > RFC 9036 > > Title: Changing the Location-to-Service Translation (LoST) > Location Profiles Registry Policy > Author: R. Gellens > Status: Standards Track > Stream: IETF > Date: June 2021 > Mailbox: rg+ietf@coretechnologyconsulting.com > Pages: 4 > Updates: RFC 5222 > > I-D Tag: > draft-ietf-ecrit-location-profile-registry-policy-02.txt > > URL: https://www.rfc-editor.org/info/rfc9036 > > DOI: 10.17487/RFC9036 > > This document changes the policy of the "Location-to-Service > Translation (LoST) Location Profiles" IANA registry established by > RFC 5222 from Standards Action to Specification Required. This > allows standards development organizations (SDOs) other than the IETF > to add new values. > > This document is a product of the Emergency Context Resolution with > Internet Technologies Working Group of the IETF. > > This is now a Proposed Standard. > [...] > The IESG has approved, and would like to thank, Henning Schulzrinne for serving as the Designated Expert for the IANA registry associated with this work. -MSK, ART AD --000000000000b22cab05c9ba19ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 3, 2021 at 11:41 PM <rfc-editor@rfc-ed= itor.org> wrote:
A new Request for Comments is now availa= ble in online RFC libraries.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 9036

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 Changing the Locatio= n-to-Service Translation (LoST)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Locat= ion Profiles Registry Policy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author:=C2=A0 =C2=A0 =C2=A0R. Gellens
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0Standards Track
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stream:=C2=A0 =C2=A0 =C2=A0IETF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date:=C2=A0 =C2=A0 =C2=A0 =C2=A0June 2021
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Mailbox:=C2=A0 =C2=A0 rg+ietf@coretechnologyco= nsulting.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 4
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Updates:=C2=A0 =C2=A0 RFC 5222

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I-D Tag:=C2=A0 =C2=A0 draft-ietf-ecrit-location= -profile-registry-policy-02.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 h= ttps://www.rfc-editor.org/info/rfc9036

=C2=A0 =C2=A0 =C2=A0 =C2=A0 DOI:=C2=A0 =C2=A0 =C2=A0 =C2=A0 10.17487/RFC903= 6

This document changes the policy of the "Location-to-Service
Translation (LoST) Location Profiles" IANA registry established by
RFC 5222 from Standards Action to Specification Required.=C2=A0 This
allows standards development organizations (SDOs) other than the IETF
to add new values.

This document is a product of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF.

This is now a Proposed Standard.
[...]

The IESG has approved, and would = like to thank,=20 Henning Schulzrinne for serving as the Des= ignated Expert for the IANA registry associated with this work.
<= br>
-MSK, ART AD
--000000000000b22cab05c9ba19ee-- From nobody Mon Aug 16 21:56:46 2021 Return-Path: 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 67B413A1C0F for ; Mon, 16 Aug 2021 21:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 BdHF4LEurW2F for ; Mon, 16 Aug 2021 21:56:42 -0700 (PDT) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (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 60CD83A1C06 for ; Mon, 16 Aug 2021 21:56:42 -0700 (PDT) Received: by mail-ua1-x92a.google.com with SMTP id 67so8519785uaq.4 for ; Mon, 16 Aug 2021 21:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=60UeJ6dFsl+0c2UJu+raWLy2Gfd/zvaKvxx+IqCj2cE=; b=oE9g1Q6PgLoCsECP0X65gamw5hlckUgg/tYwhWoO1C4MOrwD5PIpvlyF48kx94yHVZ 6RQtD4v4Us5aR0jN/nlFVkg/400GzEUc9y0lN7vo8b/fvFb6nsnn0H/zcJiQ/J4rah+x 3RcUshYSSixb95J56Q1DHQKvQpna6OP9EZ3bDHUciDqftVNsFbF3w+t+58s7C0UtOCr5 K47jg0+xFC7Sfmvjw1LSFrolI6gLjtYcPJ2IttXzvpd9tVIbc+rkMpRmmzDwMGHPOPsh 47TNQCvIb45ekCHH+5pRcEO41faF0Pb4IPaBbOmOAbobnRBfU9lu7Y0wrG4OJqet9wns ZtiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=60UeJ6dFsl+0c2UJu+raWLy2Gfd/zvaKvxx+IqCj2cE=; b=HDw8FKii1U/O830A9Xh1h7NyyExa4nPpgGkVrQRcTjMVt5LvQAUoUArvf+dS0SwWzM jnvN5Dcz2tvNtIoBFMs+i1oivOC7zZZJsVhjrbDUc0P+mWS6M18UvtBfSRCIQFpkxzya tG9AIdmmGevoU1B0kVDtx4V8AjO03nPSuQUDk0jJE7RvCje7XjW9cCc9Q2ySYqSP1bpZ GukhCaEg2xx7nxpRONi6CFdsAVPLSmYxPVRFnaLGTsCj1ULYP1XmNb16AvOqpWi4VYss ISjHwQVE3u74AUoSnuag1bogCMQGSt35jOEyy4cJOWctf8JZ/1zf/IoplP7cB/70+QM2 g0Fg== X-Gm-Message-State: AOAM531+tMwkuONXUyVOsMXs1UHCtkKAi7qj//LAu+/ReDG1MomWwl+K NFdY82yoN7gavOz3NE2xXdxeTT3SZyqZaxzNsrqpiwch1gM= X-Google-Smtp-Source: ABdhPJxa7IM41syE5/PDhpYctSIb41pUj46IsAQPNNay0vR5srFmK5EUoW9ninzM9ppjDV2XTZGTclR4dl3cPtKxfig= X-Received: by 2002:ab0:694b:: with SMTP id c11mr747723uas.87.1629176200089; Mon, 16 Aug 2021 21:56:40 -0700 (PDT) MIME-Version: 1.0 From: "Murray S. Kucherawy" Date: Mon, 16 Aug 2021 21:56:28 -0700 Message-ID: To: ecrit@ietf.org Content-Type: multipart/alternative; boundary="000000000000aed2e805c9ba24b6" Archived-At: Subject: [Ecrit] Additional co-chair for ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2021 04:56:46 -0000 --000000000000aed2e805c9ba24b6 Content-Type: text/plain; charset="UTF-8" Colleagues, I would like to welcome Randall Gellens as a new co-chair for ECRIT. Randall has plenty of IETF experience, and I believe you're in good hands as we work to resume progress toward our remaining milestones and the future. Thank you, Randall! -MSK, ART AD --000000000000aed2e805c9ba24b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Colleagues,

I would like to = welcome Randall Gellens as a new co-chair for ECRIT.=C2=A0 Randall has plen= ty of IETF experience, and I believe you're in good hands as we work to= resume progress toward our remaining milestones and the future.

Thank you, Randall!

-MSK, ART AD
=
--000000000000aed2e805c9ba24b6-- From nobody Mon Aug 16 22:10:49 2021 Return-Path: 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 9A2613A12B5 for ; Mon, 16 Aug 2021 22:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.337 X-Spam-Level: * X-Spam-Status: No, score=1.337 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, MIME_HTML_ONLY=0.1, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 9sI7tWHCE-lI for ; Mon, 16 Aug 2021 22:10:43 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 831643A12A5 for ; Mon, 16 Aug 2021 22:10:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1629177036; bh=/tup4KyriyQpQEIOEUiACEOVcwbnvZ0L3y5kmOnwd/4=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=eGtTettak4QkCKopNr7pzTMc3WKHGO/Qf60gYvSsApZakj7OuaoPtTcPQSdRtMlPB 408eWqBrw2e+KO2ioBSzGVAKM2PWzAxwpn9vDs+3lg24nVgg+6kRVhKGtJ8WmfAg+s CElE7wm4zBOIMSN2ZcwB3Y7lzs4q1g+AqMnyKw6Y= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [213.162.73.6] ([213.162.73.6]) by web-mail.gmx.net (3c-app-gmx-bs13.server.lan [172.19.170.65]) (via HTTP); Tue, 17 Aug 2021 07:10:36 +0200 MIME-Version: 1.0 Message-ID: From: Hannes Tschofenig To: "Murray S. Kucherawy" Cc: ecrit@ietf.org Content-Type: text/html; charset=UTF-8 Date: Tue, 17 Aug 2021 07:10:36 +0200 Importance: normal Sensitivity: Normal In-Reply-To: References: X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:vjRuTzk3YwECoeoIfU/IbdrE4e9ffmPpi1Kmp4pU3ZXfZUmF8uSG3aIZnd+Kb9OTpd44l eftwLPXV9GLUiPo6XvPNkGQlvF3yCjADHTKzwscc5XpQXXG2UUhbvaIjiWWpoGgWMrhs1S5l3PVn wR5MmOk4dFE990GhO7bUGCb7XS1Vbhr+FvoOvW91KdZsdyyDa2MK4oSa1tio1B4RRxvOIWtHZpPr wnGwjKbTkF8yRcgA44sAQTYEe63iOfX2UxGmv25oO0vpIzsd8+GXBD9raEHgCEN3i8J/2SjMucJK lQ= X-UI-Out-Filterresults: notjunk:1;V03:K0:EbEDfRwNJUQ=:E6Du9mtyGhfkYf1Zh2hfIc yiM8DO2CJvmy1sazSLzuiM87yWIVLPqB3Wqw0vk0yR2vd9evfvZsMDfq49Y0jaKGKKyxl/DYv hbrXn69mX+oRXbfL1WH9MzrxHhZ2D9ev1De+Sv1VRYihjB/DVSnPmr2H1qGdXdirKlE5h/UdV HZhwoUNNGWgzRJ+HnEuvxQw6TjSz6kFffQYJ3Q+tSdUCnStULlkBpNZDDFBh3CPd/6fDQIPh8 9feC2B9lNJpx/7nxdonrW9AmQECUSS5wLAp8ZYSY2obN9A5bjBJZfasAJCX3u4HiN+yDyiAwI uXGvRKoxyxvB+cQjrY6CMQa0KRc8PpLzH6d/+RGhK7IIRGOg+IJXJBJ5VhKDRTvt5S1jDLWxg fJtVqzUKAxvMC3drBz2mhTooigI11qre2uRbSHPVXTocPS4g8lZb5WvU8Vu0Q9ueR9FhFpZGi GpSUxflJ00h9beA6H1QZBAWxu3Tm7yscuEJ1EthpoEQreXbRvEFJ62nyqsKErf0w+scpHq5kw SBG1i/pKm0wCjXxMjLrUJi9jMgorjI6RYun2DGFIS4up+RFgAlhsfvHChj0vOePKH6MzblDaN feBm94OmHHmlvm4fZn3YB097lfisLPAK9xhdEu/8gB4H/uXzYhsToF2zAOZ5V62XpadqNmDxP 6vQmeuC4S/Fio9cqVwWDW9Er0nHUaK9+iaER/EHHyiDN8uHA4sOjragryNoWiaNBsnONVNmiw Zd1rFFpxzr3Amb2ZFLfs6ijBXHpiLEFFz9Ql5kxAjdIfaBDGTRn5Tg5Ful+Hk9Vr0R8+aTwIg Erg7V9s9Fp7nXhK5q7/013G7iyDEeV+QDazW6UivAieovSoiaQ= Archived-At: Subject: Re: [Ecrit] Additional co-chair for ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2021 05:10:48 -0000
A good decision, Murray.
 
Welcome Randy!
 
 
Gesendet: Dienstag, 17. August 2021 um 06:56 Uhr
Von: "Murray S. Kucherawy" <superuser@gmail.com>
An: ecrit@ietf.org
Betreff: [Ecrit] Additional co-chair for ECRIT
Colleagues,
 
I would like to welcome Randall Gellens as a new co-chair for ECRIT.  Randall has plenty of IETF experience, and I believe you're in good hands as we work to resume progress toward our remaining milestones and the future.
 
Thank you, Randall!
 
-MSK, ART AD
_______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit
From nobody Wed Aug 18 17:02:49 2021 Return-Path: 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 6B1A13A20EC; Wed, 18 Aug 2021 17:02:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ecrit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ecrit@ietf.org Message-ID: <162933135738.584.17771791319436789321@ietfa.amsl.com> Date: Wed, 18 Aug 2021 17:02:37 -0700 Archived-At: Subject: [Ecrit] I-D Action: draft-ietf-ecrit-similar-location-09.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2021 00:02:45 -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-09.txt Pages : 18 Date : 2021-08-18 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 a completed civic address element set for a valid location response, and one or more suggested sets of similar location information for invalid LoST responses. 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 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-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-similar-location-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 19 06:19:41 2021 Return-Path: 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 BB0AB3A15DA for ; Thu, 19 Aug 2021 06:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.061 X-Spam-Level: X-Spam-Status: No, score=0.061 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, 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 (1024-bit key) header.d=indigital.net 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 zIgtccDhJ1jX for ; Thu, 19 Aug 2021 06:18:25 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 C87E93A15D6 for ; Thu, 19 Aug 2021 06:18:24 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id i9so12876231lfg.10 for ; Thu, 19 Aug 2021 06:18:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=indigital.net; s=google; h=mime-version:from:date:message-id:subject:to; bh=RMKd18+866gYWAr4IxQ/SDBZtMwA/QoY7f95XthXazw=; b=ml5TXwi7OeZ9v7Qp1Ug8XdXlK3GmjteAmGhIX/cLY/K/xZb6B8W001uENZO/02nKQk WaAooeI8b7ngiqLyrJCteCQCDd0OMPa1QOCLMOeLXUWwiLJz+3RDb5l/5yBXcb8PUjZY NnwcA3ZksC196q5GUzTct4sfZbHYyx3wY/pG8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RMKd18+866gYWAr4IxQ/SDBZtMwA/QoY7f95XthXazw=; b=IIlW7xmspfPPSb8Y4Vy7gUiJx2FryOeMdujcesBHnxWDW5kFl0RbfBGoMVCtxRdlfe WednSXPHWricsoRUkp9TVaO7IRKsFXDsFNCNFINsw3GL8iV6Xr0E60V6BrHnHUcB9PYS Bje244oAvwwd1Kii1Qf2d8ONen9mDPvL6sDdFWVMx3NvySc5KDUIUsl05650yDKb62Gr GYAtloDlBOMiIJfIn575O+6++AsKOfFKExkgrNDWwJaa1CvsBYs9/4FUObw+VPUvlyka VWPDLuriF9gmHGvFZjuaq8A7SwIbJ29GvDa9jF1zOjXSxx3A75i/q3Sl11XwEzswS68n zIrw== X-Gm-Message-State: AOAM5322Qcuj6n6VRX0Ivyf6EyiVCtS+s9AZV5k4oeZ8xnyZs+SXA3jU fPct8YCRrEc0Chk2fwdXXbRF695JKOG0ut4dfT6rRNXlIWOFGg== X-Google-Smtp-Source: ABdhPJzPyQ0RdnkXgi8bNLoLxDIa7IZVXh2zHbIj99cs2CSX2KfqzLaleHo0RL7Xk1MoN0wFHa4J6hPcRfS8mQJNiOg= X-Received: by 2002:a05:6512:2286:: with SMTP id f6mr10778904lfu.433.1629379101154; Thu, 19 Aug 2021 06:18:21 -0700 (PDT) MIME-Version: 1.0 From: James Kinney Date: Thu, 19 Aug 2021 09:18:11 -0400 Message-ID: To: ecrit@ietf.org Content-Type: multipart/alternative; boundary="00000000000087757b05c9e96298" Archived-At: Subject: [Ecrit] Joining Ecrit X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2021 13:18:31 -0000 --00000000000087757b05c9e96298 Content-Type: text/plain; charset="UTF-8" Dear Ecrit colleagues. I am joining the list/group and will read documents that are up for discussion and send comments on the documents to the list. Thanks, looking forward to working with you all anew, *James Kinney* *Chief Innovation Officer | INdigital * --00000000000087757b05c9e96298 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Ecrit colleagues.

I am joining the list/group = and will=C2=A0read documents that are up for discussion = and send comments on the documents to the list.

Thanks, looking forward to working with you all anew,
James Kinney

Chief Innovation Officer | INdigital=C2= =A0

--00000000000087757b05c9e96298-- From nobody Thu Aug 19 14:08:58 2021 Return-Path: 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 AC73B3A08E7 for ; Thu, 19 Aug 2021 14:08:56 -0700 (PDT) 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.20150623.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 kqjLpdQNXt1K for ; Thu, 19 Aug 2021 14:08:51 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 9A2AA3A08E9 for ; Thu, 19 Aug 2021 14:08:51 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id z1so9506577ioh.7 for ; Thu, 19 Aug 2021 14:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=KXRctkVyewmw/B07t1nVpLZNsFRWkhQOfYavuXeFx1k=; b=JRfgO8myJXUBc0aKDZYG2LOmSRXtOXr4HvdQKX34TSApgeOMtTt/EP5uO+2KIyDoHc UdxTFdyM/IlzjrO0fvHceIO0+GJTKABXFWnIN6TG7vTfM8YYExHgqmOiPf5XHHMT7xJd wFOl32SiIFGalztDLTCrEIK3/QAEGcD4u+Ow5xFn/rl9ql26Dec5bEB3o0z9wqs2dIvP Fy7+UWRPU06YjH68RxSc+Va+N4AuO3NDlP4/K2pHWWE72E35WKbt3coJJqO2cjgA3+Ic CFRl4p1rSqj9+CRhafzfFcKKD31d6SCXPCpycUFjxSFt2bVtwdXAgDunrbLFt17xBMRn 4cEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=KXRctkVyewmw/B07t1nVpLZNsFRWkhQOfYavuXeFx1k=; b=RcUsYPOP9w75ZDdxNdLTx2eeg8RAPnfpLp6bFL6WNcEck9aXfZpL4/+HDwSC6k1h5L kHXH9HM5V7MnEEZPj069Lw0/3K6gvLpfMAWJ8GlN3AoXFwCsyoyFG1RqsrBNXuJUIyUw L/qTN2obKZKtjYUc9aO2Bo+l35b1LkqL8ASs7N4Kpj7DtcA4T2arsgTfJdnHPcJdgsG3 5nxIONGZAp6jap1Pf54Y96TtVd+ZHvVlpLgbwoqmkQ6piIZlypT8HlFPsazGSwTHjwo3 VxJ09eFLR4asIwRIrgl9FZk9F4p/nvl0PbafhiFLkfKfmDIvyZQNoFVlvIiTv1PC144I exVg== X-Gm-Message-State: AOAM533+h1dGtZfeQw20FE8YPNq1IxMw64ee6actGUKwB6YptrLB7doB WhaAQehXEFPIWv7maiuLDwNF0ClbEDZ4ZkxQ X-Google-Smtp-Source: ABdhPJxt8/mrXUSRgFaCEbSvy2n11XnGtewGewIXh69oD3jAWDCmvt9eYTxQ9OBlyCiIEGWkLjffXg== X-Received: by 2002:a5d:818b:: with SMTP id u11mr12969731ion.43.1629407329412; Thu, 19 Aug 2021 14:08:49 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id t15sm2086061ilq.88.2021.08.19.14.08.48 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Aug 2021 14:08:49 -0700 (PDT) From: Brian Rosen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Thu, 19 Aug 2021 17:08:48 -0400 References: <162933135738.584.17771791319436789321@ietfa.amsl.com> To: ecrit@ietf.org In-Reply-To: <162933135738.584.17771791319436789321@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-similar-location-09.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2021 21:08:57 -0000 At long last, I have updated this draft. I have hopefully captured all = comments made against prior revisions and I have tried to get the xml = correct. =20 Thanks to Randall for looking over an advance copy of the doc and making = some suggestions for improvement. Hopefully we can progress it swiftly now. I have no good excuse for not completing this task earlier. Brian > On Aug 18, 2021, at 8:02 PM, 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-09.txt > Pages : 18 > Date : 2021-08-18 >=20 > 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 a completed civic address > element set for a valid location response, and one or more suggested > sets of similar location information for invalid LoST responses. > 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. >=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-09= >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-similar-location-09= >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Thu Aug 19 17:27:51 2021 Return-Path: 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 E4A513A1274; Thu, 19 Aug 2021 17:27:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ecrit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ecrit@ietf.org Message-ID: <162941926169.9620.8527061840228167005@ietfa.amsl.com> Date: Thu, 19 Aug 2021 17:27:41 -0700 Archived-At: Subject: [Ecrit] I-D Action: draft-ietf-ecrit-lost-planned-changes-04.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2021 00:27:42 -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 : Validation of Locations Around a Planned Change Author : Brian Rosen Filename : draft-ietf-ecrit-lost-planned-changes-04.txt Pages : 19 Date : 2021-08-19 Abstract: This document defines an extension to LoST (RFC5222) that allows a planned change to the data in the LoST server to occur. Records that previously were valid will become invalid at a date in the future, and new locations will become valid after the date. The extension adds two elements to the request: A URI to be used to inform the LIS that previously valid locations will be invalid after the planned change date, and add a date which requests the server to perform validation as of the date specified. It also adds an optional Time-To-Live element to the response, which informs clients about the current expected lifetime of the validation. This document also provides a conventional XML schema for LoST, as backwards compatible alternative to the RelaxNG schema in RFC5222 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-planned-changes/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ecrit-lost-planned-changes-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-lost-planned-changes-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 19 17:35:06 2021 Return-Path: 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 C7F783A1310 for ; Thu, 19 Aug 2021 17:35:03 -0700 (PDT) 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.20150623.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 z3WTdjZ_QKGP for ; Thu, 19 Aug 2021 17:34:58 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 BB6F53A1311 for ; Thu, 19 Aug 2021 17:34:58 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id h29so7795976ila.2 for ; Thu, 19 Aug 2021 17:34:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=W9w00DqzI/fGHLtko5EjpotS5Q5YcO2w1cJvpoYIlus=; b=vXcOewZTyXOfTjHgMnpcyP1cEQSp4Vkp76eE7Xs1rpim/jLZOp2ZGFmG1S1TPNchRL T1v6p6eB12g1oIuh3qZ37meIpsBTC6WngaMbxmcpX4Oc5ZdobNbg1h/owuFJkNIFZD11 u4VgnGqOXPVg5Y0FpX6TUuM8N5Zr/Ln8ynyZ2RnIXUJ2u6DH3PVusvc3jRNg7Wb41Y8y OpQKs/IQ2Aflc+RUY1soLiKsYICvcBBhBBiGsMcxHZ0v26TLP/pjS7T9QFqcxClWemE/ JLRRait/qw2gRJ6ZMpTr9wP9WSzmrLRX/tk/q5D1RTjKnUa+I0PRCb83wEHksK/vDDS/ cIiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=W9w00DqzI/fGHLtko5EjpotS5Q5YcO2w1cJvpoYIlus=; b=Q3o54Jfsog14ZN2LYV+stFNxnjP/36gF+HWy2Krjp0QyuiTFHVXU0TLnqlwbjmb0rL fPLnyh3f7NvAxR0fBtrcHVXxIflCBBVU/aZGEyaeKMtrksWaAjokcImCLkb4l2DYLiv9 F3yjmv0s7RBF6b0SQyjCJrv/3swLnDC8O25Jj7f7lr35YmKqNfc0MpcvNrSon5jxPdOg /eEL74SQBaTA6NPE3l/DnAKGrRwQq9xVUzcF1I+lxnIi+wY2XVrolGSxDfn2YKUHS9Qj sDEyGJsadtJ0on8eEV6blL3HcuUxMffgv7A9dmke6X6XykQu5ATeqFQrKlsL/hyobdiF hvJg== X-Gm-Message-State: AOAM532ILZHMGDf6pwxFCk7gc9ckO8szjgWXmRTmPLgbN5n0HZL8VpSf SpQh/6sZF52eIN5KBFAnhesI++FDwiRpvwIc X-Google-Smtp-Source: ABdhPJwJuEDs8wRhm0FMcFeTppBH3FvgkCbbUsSCE8jGidoPb7cKNqR7NUWhk+zbB2wRvy5o9m34hw== X-Received: by 2002:a92:c80e:: with SMTP id v14mr12262110iln.57.1629419696618; Thu, 19 Aug 2021 17:34:56 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id e2sm2562357ioc.0.2021.08.19.17.34.55 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Aug 2021 17:34:56 -0700 (PDT) From: Brian Rosen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Thu, 19 Aug 2021 20:34:54 -0400 References: <162941926169.9620.8527061840228167005@ietfa.amsl.com> To: ECRIT In-Reply-To: <162941926169.9620.8527061840228167005@ietfa.amsl.com> Message-Id: <35C2A468-9290-4DC8-9A77-8A67CA73630B@brianrosen.net> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-lost-planned-changes-04.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2021 00:35:04 -0000 This too, finally, is redone. I believe all comments were addressed. = XML should be checked, but I THINK it=E2=80=99s right now. There is a = bit of new text that explains the LoST server doesn=E2=80=99t have to = save the Location Information that was sent in the findService request. = That means that the notification, if requested, will be sent for any = change, which means the client could get a notification to revalidate = only to find they got the same result. =20 I did specify the Content-Type as application/xml instead of defining a = new media type. I think that=E2=80=99s okay, comments welcome. Brian > On Aug 19, 2021, at 8:27 PM, 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 : Validation of Locations Around a Planned = Change > Author : Brian Rosen > Filename : draft-ietf-ecrit-lost-planned-changes-04.txt > Pages : 19 > Date : 2021-08-19 >=20 > Abstract: > This document defines an extension to LoST (RFC5222) that allows a > planned change to the data in the LoST server to occur. Records = that > previously were valid will become invalid at a date in the future, > and new locations will become valid after the date. The extension > adds two elements to the request: A URI to be used to > inform the LIS that previously valid locations will be invalid after > the planned change date, and add a date which requests the server to > perform validation as of the date specified. It also adds an > optional Time-To-Live element to the response, which informs clients > about the current expected lifetime of the validation. This = document > also provides a conventional XML schema for LoST, as backwards > compatible alternative to the RelaxNG schema in RFC5222 >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-planned-changes/ >=20 > There is also an htmlized version available at: > = https://datatracker.ietf.org/doc/html/draft-ietf-ecrit-lost-planned-change= s-04 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-lost-planned-changes-= 04 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Aug 20 09:58:13 2021 Return-Path: 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 030873A161D for ; Fri, 20 Aug 2021 09:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 CMBTdnp1ANl5 for ; Fri, 20 Aug 2021 09:58:07 -0700 (PDT) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 E2FB63A161C for ; Fri, 20 Aug 2021 09:58:06 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id u3so21526584ejz.1 for ; Fri, 20 Aug 2021 09:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=R2sKnooucKagr8t4cvqWNR73VSWvSV/B8emDg4GaEC4=; b=ZhdbSftv2aAGC9fMyPUlAJ54WJcCTEPB8xDGgCi+AR9TSsfkgCMSiRFOOesNFTMUBS jJznTJ8QTVFiAeZHU1HPAhLM7Ryp9Q8kcl5PDoZmv1fMu/1PbniQUU85rscdPKBcNh5L Ey6/VqcZ6ni/oz5kK7qEFHmevKEMzgVXYJGxVK8TxUDCl7Hb2wLA1kh7JPqgJP2lWkgF jVdpbisZzj3OMsgyL4eGqK0oRuw1I6vLpBxSEaf+0zhuoYHswqB+6VAzg3ZLUuom1cPW LKXvXjwb04noQ7ixpxjIApRnJEcR498916BxdczK5Yana34QJAlso2LdacKKO3zo02mX C8XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=R2sKnooucKagr8t4cvqWNR73VSWvSV/B8emDg4GaEC4=; b=T6X9FUXF1jwTv0F2hgsc02JOXNn+QHC2ulSq0Wwquk0omqsOFrvDUQKp2BQ6tnJ8Ib umX03S5+zpU2H5vz/5fmX7PtFdV3Zk7CEKnCPSi/voF7Ct6viZ5yS+h0tKpDH2rTABcH 2JYKpvlh2R1E6L1hti+M9/gXbNkKNFjRC1rE+Qnw/ngaYyC/lwf2F5eYjgeSlC5/NZpt Cz8iUMcvQX+vkotiUPptwo7NKVkLYRl0ob0Ji3bBu+TstR+dDJZmmS5kDFq5oyKhQzT+ 7aM8AuLdqPK0C9eIdFq50gCC9wF0JbZXS/+7pPNEbZKh6vNAUSEbNUPG4qQ2InGDD4Cw hDog== X-Gm-Message-State: AOAM531qcPqc2EDFR8CtVReql9rG693OmpXYtnKrW/8YqmDuGxmNrLll F/2s+Cs2Ok2sJD+wBagz5FBahqKj7d80cZA+pK7mzFBNVXk= X-Google-Smtp-Source: ABdhPJwmbmjyeTOrMv85Hac+M92riLBjWAZGz+7+xF5p3z+sBgXulWnV5ADEDsh1hMMAk42GukxqfnX9AOe6iyjxlu8= X-Received: by 2002:a17:906:2f15:: with SMTP id v21mr10815275eji.444.1629478680659; Fri, 20 Aug 2021 09:58:00 -0700 (PDT) MIME-Version: 1.0 References: <162933135738.584.17771791319436789321@ietfa.amsl.com> In-Reply-To: <162933135738.584.17771791319436789321@ietfa.amsl.com> From: Dwight Purtle Date: Fri, 20 Aug 2021 11:57:49 -0500 Message-ID: To: ecrit@ietf.org Content-Type: multipart/alternative; boundary="000000000000ee0de605ca009117" Archived-At: Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-similar-location-09.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2021 16:58:12 -0000 --000000000000ee0de605ca009117 Content-Type: text/plain; charset="UTF-8" New group member here. I suggest three minor changes to the similar location document. 1. On page 6, fourth paragraph, the second sentence beginning with the word "Because" is an incomplete sentence. I think it can be fixed by simply deleting the word "Because". 2. In that same sentence, the word "element" should be "elements", to read "these additional elements had been included". 3. On page 7, in section 4, second paragraph, fourth sentence, the word "suppose" should be "supposed", to read "what the intended location information was supposed to be". Thanks! Dwight Purtle - retired PSAP tech guy On Wed, Aug 18, 2021 at 7:04 PM wrote: > > 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-09.txt > Pages : 18 > Date : 2021-08-18 > > 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 a completed civic address > element set for a valid location response, and one or more suggested > sets of similar location information for invalid LoST responses. > 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 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-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-similar-location-09 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > --000000000000ee0de605ca009117 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
New group member here.=C2=A0 I suggest three minor changes= to the similar location document.

1.=C2=A0 On page 6, f= ourth paragraph, the second sentence beginning with the word "Because&= quot; is an incomplete sentence.=C2=A0 I think it can be fixed by simply de= leting the word "Because".

2.=C2=A0 In t= hat same sentence, the word "element" should be "elements&qu= ot;, to read "these additional elements had been included".
=

3.=C2=A0 On page 7, in section 4, second paragraph, fou= rth sentence, the word "suppose" should be "supposed", = to read "what the intended location information was supposed to be&quo= t;.

Thanks!

Dwight Purtle= - retired PSAP tech guy

On Wed, Aug 18, 2021 at 7:04 PM <internet-drafts@ietf.org> wrote= :

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= A LoST extension to return complete and similar location info
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Bria= n Rosen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Roger Marshall
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Jeff Martin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-ecrit-similar-location-09.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 18
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2021-08-18

Abstract:
=C2=A0 =C2=A0This document introduces a new way to provide returned locatio= n
=C2=A0 =C2=A0information in LoST responses that is either of a completed or=
=C2=A0 =C2=A0similar form to the original input civic location, based on wh= ether
=C2=A0 =C2=A0valid or invalid civic address elements are returned within th= e
=C2=A0 =C2=A0findServiceResponse message.=C2=A0 This document defines a new= extension
=C2=A0 =C2=A0to the findServiceResponse message within the LoST protocol [R= FC5222]
=C2=A0 =C2=A0that enables the LoST protocol to return a completed civic add= ress
=C2=A0 =C2=A0element set for a valid location response, and one or more sug= gested
=C2=A0 =C2=A0sets of similar location information for invalid LoST response= s.
=C2=A0 =C2=A0These two types of civic addresses are referred to as either =C2=A0 =C2=A0"complete location" or "similar location",= and are included as a
=C2=A0 =C2=A0compilation of CAtype xml elements within the existing LoST =C2=A0 =C2=A0findServiceResponse message structure.


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.o= rg/doc/html/draft-ietf-ecrit-similar-location-09

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


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
--000000000000ee0de605ca009117-- From nobody Fri Aug 20 10:31:53 2021 Return-Path: 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 D27BE3A189F for ; Fri, 20 Aug 2021 10:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, 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.20150623.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 aWeO1qCfAo74 for ; Fri, 20 Aug 2021 10:31:45 -0700 (PDT) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 ED1233A189E for ; Fri, 20 Aug 2021 10:31:44 -0700 (PDT) Received: by mail-il1-x12f.google.com with SMTP id s16so10241172ilo.9 for ; Fri, 20 Aug 2021 10:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=CsGoB7n3SPDDAFTzB35c2Uc4XNxaxIX2TYVDfHmXxWU=; b=c9jRRpRBbal1oidACZ9zbrfstzX4t0jLjWJPnt987YBeuqciZH2Q1x3mca8I4Ily+8 AEypgqeOY7fIbuKmhMPBV1Xvy2imE8Bj9GCQ6KDoe9k9yCdHE/19EeWLyQsFRa0vimwE 3s53irecJymE+/2BrMfT0k3XSyHyg3IMKqfMHl/fmplRnxHRepRtLu7H9Ni2BNx3s58g WCVy6DOKlTY+wA5+xt3fYAjOntYXX+SdNTZWZYjPI9WW9M7LigKzPcl1DtET9Ux/E1HT gTq6JXn6dHfsUvdhDvTrWBsuQiGXppPsaWSIoWTwElQUjsE42etPpgcmo2YYOYMt5Vcf ScdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=CsGoB7n3SPDDAFTzB35c2Uc4XNxaxIX2TYVDfHmXxWU=; b=JhLkBz+V8pS3cakJ3GYW/fA2Ke614ozKHYLy6HBJL0CTyzUSD0scTTgUPhjJL7hjj+ jcjTLxGvRvDI3BQz9SYdAcryoGgC7U/DX0t3StRCm3X5MDclGisgdR3LpnGKopjtcrRM 2RiBewvrCKzvMQrmu3SwUWB52Y+FoYFztCPcJxu+iUueSLA7ytw0B4wkJsK396hUVH5U bIy+/kw1YsVLapNoaktFJNWzfoqIUnLKqEk2S0A4vKCsvdSqYOIatcllGkPpEDSly9SQ KfLIpnFCZB/caU+lbravyD+kn6aQ0uSXEA3M3YdAKTgLHXDQ/QDunBlF76w3l9WRR5qL oWoA== X-Gm-Message-State: AOAM532o0wBHaP1aiiexHADqeuAAbpig5+Ow6k1RkIx1VRpOpcGnMWtv c0rzCwIy5DP+g7cHW+N9IQZGhw== X-Google-Smtp-Source: ABdhPJz9tWWjpJMk9WeBO4Aa8/9i8xk4L+Hx0sSgfri0sHQspbaRw54gL0UOB268svByKlff3SefJg== X-Received: by 2002:a05:6e02:1e09:: with SMTP id g9mr10292027ila.198.1629480702803; Fri, 20 Aug 2021 10:31:42 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id g14sm3452386ila.28.2021.08.20.10.31.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Aug 2021 10:31:42 -0700 (PDT) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C2B1634B-D1B6-4C83-8730-1B85C54C3094" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Fri, 20 Aug 2021 13:31:41 -0400 In-Reply-To: Cc: ecrit@ietf.org To: Dwight Purtle References: <162933135738.584.17771791319436789321@ietfa.amsl.com> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-similar-location-09.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2021 17:31:50 -0000 --Apple-Mail=_C2B1634B-D1B6-4C83-8730-1B85C54C3094 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Happy to make these changes. Thanks for the review. Brian > On Aug 20, 2021, at 12:57 PM, Dwight Purtle = wrote: >=20 > New group member here. I suggest three minor changes to the similar = location document. >=20 > 1. On page 6, fourth paragraph, the second sentence beginning with = the word "Because" is an incomplete sentence. I think it can be fixed = by simply deleting the word "Because". >=20 > 2. In that same sentence, the word "element" should be "elements", to = read "these additional elements had been included". >=20 > 3. On page 7, in section 4, second paragraph, fourth sentence, the = word "suppose" should be "supposed", to read "what the intended location = information was supposed to be". >=20 > Thanks! >=20 > Dwight Purtle - retired PSAP tech guy >=20 > On Wed, Aug 18, 2021 at 7:04 PM > wrote: >=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-09.txt > Pages : 18 > Date : 2021-08-18 >=20 > 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 a completed civic address > element set for a valid location response, and one or more = suggested > sets of similar location information for invalid LoST responses. > 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. >=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-09= = >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-similar-location-09= = = >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ = >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit = > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --Apple-Mail=_C2B1634B-D1B6-4C83-8730-1B85C54C3094 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Happy= to make these changes.  Thanks for the review.

Brian


On Aug 20, 2021, at 12:57 PM, Dwight Purtle <dwightpurtle@gmail.com> wrote:

New group member here.  I suggest three minor changes to = the similar location document.

1.  On page 6, fourth paragraph, the second sentence = beginning with the word "Because" is an incomplete sentence.  I = think it can be fixed by simply deleting the word "Because".

2.  In that same = sentence, the word "element" should be "elements", to read "these = additional elements had been included".

3.  On page 7, in section 4, = second paragraph, fourth sentence, the word "suppose" should be = "supposed", to read "what the intended location information was supposed = to be".

Thanks!

Dwight Purtle - retired PSAP tech guy

On Wed, Aug 18, 2021 at 7:04 PM <internet-drafts@ietf.org> wrote:

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-09.txt
        Pages          =  : 18
        Date          =   : 2021-08-18

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 a completed civic = address
   element set for a valid location response, and one or more = suggested
   sets of similar location information for invalid LoST = responses.
   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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ecrit-similar-locat= ion/

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-similar-lo= cation-09


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit = mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

= --Apple-Mail=_C2B1634B-D1B6-4C83-8730-1B85C54C3094-- From nobody Sat Aug 21 10:34:16 2021 Return-Path: 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 2F4873A18D9 for ; Sat, 21 Aug 2021 10:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-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 (1024-bit key) header.d=egensajt.se 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 g8dPFun54_AV for ; Sat, 21 Aug 2021 10:34:07 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (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 312743A18DA for ; Sat, 21 Aug 2021 10:34:05 -0700 (PDT) Received: from [192.168.2.136] (h79-138-72-140.cust.a3fiber.se [79.138.72.140]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 4C6BC20F2A; Sat, 21 Aug 2021 19:34:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1629567241; bh=rVVD5dQ8hw8kkzKFN1ZtLf1DOCYSMFU1Q14qb5cD5hY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=OMiTClB4HZSl5s2OggxaQ98Vcoewgiewc6TVB/hPCIq2539SqXWd6untICzrodymN omCNFbgx8ktYUwxUeWJ5nus2760ldoWY0eFZbREoz26jg8bbIDOVLp8OdRK9WB7AjC 9ekY8Tf+ONT0EKnDYLLn8HE2TTQRs5sSYNDKSoQY= To: Brian Rosen , ECRIT References: <162941926169.9620.8527061840228167005@ietfa.amsl.com> <35C2A468-9290-4DC8-9A77-8A67CA73630B@brianrosen.net> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: Date: Sat, 21 Aug 2021 19:33:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <35C2A468-9290-4DC8-9A77-8A67CA73630B@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: sv Archived-At: Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-lost-planned-changes-04.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2021 17:34:13 -0000 Brian, I think this one looks good and mature. I have only found a few editorials and traditional xml mistakes ( if I got it right ): 1. In Abstract, "" s.b. "" 2. In Abstract, in the middle, ", and add a date" s.b. ", and a date" 3. In Abstract: Full stop missing at the end. 4.  In 1. Introduction, second line, "" s.b. "" 5.  In 1. Introduction, third paragraph: Full stop missing at the end. 6.  In 4. second paragraph, second line:  findService s.b. 7.  In 7. first line "The Relax" s.b. "the Relax" 8.  In 8. In the "plannedChange" element, "invalidAsOf"  got its leading quoutation mark changed to a curly leading double quote instead of a straight double quote. Was that intentional, and is that safe, or should you return to using straight double quote? 9.  In 8. Section 8 contains extensions to the schema presented in section 7. Is the editing instruction notations formal enough to reliably create the extended schema correctly. Would it not be safer, and more convenient for developers if you provided the completed schema, with easily found comments around the extensions, so that anyone interested in creating the schema in section 7 could do that? Please explain why it is the schema in section 7 that is provided as a complete schema and 8 just as editing instructions and not the other way around, when it is the schema resulting from section 8 that is the purpose of the specification. 10. In 9.  I think the following two lines are missing before the last line:           Regards Gunnar -- Gunnar Hellström GHAccess gunnar.hellstrom@ghaccess.se Den 2021-08-20 kl. 02:34, skrev Brian Rosen: > This too, finally, is redone. I believe all comments were addressed. XML should be checked, but I THINK it’s right now. There is a bit of new text that explains the LoST server doesn’t have to save the Location Information that was sent in the findService request. That means that the notification, if requested, will be sent for any change, which means the client could get a notification to revalidate only to find they got the same result. > > I did specify the Content-Type as application/xml instead of defining a new media type. I think that’s okay, comments welcome. > > Brian > >> On Aug 19, 2021, at 8:27 PM, internet-drafts@ietf.org wrote: >> >> >> 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 : Validation of Locations Around a Planned Change >> Author : Brian Rosen >> Filename : draft-ietf-ecrit-lost-planned-changes-04.txt >> Pages : 19 >> Date : 2021-08-19 >> >> Abstract: >> This document defines an extension to LoST (RFC5222) that allows a >> planned change to the data in the LoST server to occur. Records that >> previously were valid will become invalid at a date in the future, >> and new locations will become valid after the date. The extension >> adds two elements to the request: A URI to be used to >> inform the LIS that previously valid locations will be invalid after >> the planned change date, and add a date which requests the server to >> perform validation as of the date specified. It also adds an >> optional Time-To-Live element to the response, which informs clients >> about the current expected lifetime of the validation. This document >> also provides a conventional XML schema for LoST, as backwards >> compatible alternative to the RelaxNG schema in RFC5222 >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-planned-changes/ >> >> There is also an htmlized version available at: >> https://datatracker.ietf.org/doc/html/draft-ietf-ecrit-lost-planned-changes-04 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-lost-planned-changes-04 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Gunnar Hellström GHAccess gunnar.hellstrom@ghaccess.se From nobody Mon Aug 23 12:31:41 2021 Return-Path: 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 19EA43A0EE1 for ; Mon, 23 Aug 2021 12:31:07 -0700 (PDT) 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.20150623.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 K3_58xx3mkls for ; Mon, 23 Aug 2021 12:31:01 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 7BE043A0EF2 for ; Mon, 23 Aug 2021 12:31:01 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id s16so18147092ilo.9 for ; Mon, 23 Aug 2021 12:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AUuk0MuUJ5S/k9O7DuX9FfpVN9W2Br0tHnumj1Fyvqw=; b=EqZkBo4MlkV89W+cnjxIv9YoVXtrew56jJjtYmFCSEk4O5QIJE2Kne7DUFObof8PPd /Vz2GeP/Cst7r1MZoCH80kStkothhqsh/d7h6H3eeradYooU0mD2j6wtguip/aZgILdu +8QjBKcO/Rnaw1A1hVDpy7D5fM8ciKDoNc18WVOmqC0YAlJ7zeur95yXzCblDBb4x5GD zHXc2bxdtJybCb/GHx1B4jhuSfrEAtU/5tcrTuKgiTFeJH8auhw46cmA5mkq/VXgcZyM J/oRz74Q2Dlw1vET8MlttKt7xsJOramM6yXvlOcmKlNygYy2WXCzhal5R6SeKZXwOTNv HAeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AUuk0MuUJ5S/k9O7DuX9FfpVN9W2Br0tHnumj1Fyvqw=; b=rekznPExu12WacPJjL/jx2FKsID6hLWNgRhTVEoxLbL5r4zQdYTVC9nSKNDAI83xDS c89IivSyRXuDyypRr+hGBX3rtCgxU7ML5Qp3EGWEXLlKEIW2m1hiKIXThE75yKewn7F9 XusX5EEaW3JtmsrM9TlNwHh3LJwKYePbPFMkmSu3bivsLq4KhQN0yJg8U6S87QzPbfHi LmciURCin5gbH+Iqb0zXF5qrx1urnDdHgkIyx8u+lDB+JcdZTPlcZsDUbnh3HR1yGU+G TaXErdSqZoR4Ok4cSl3Fgki3KyrBrvKsRoAy9d42iakKebpZYS7P3H+1dXoQ2Lzqk6q3 QCbA== X-Gm-Message-State: AOAM532NWfVqQsDHTn2Ms/z3HvRKcemZWtQ4XNcwLLN1kCBuuVbYejMv 05sB2WvL1gYd61QS2+m/N1of59eFiEyhq4QZ X-Google-Smtp-Source: ABdhPJxR1YZzVcEYjEYvunvqjutb1+4ULIxL1hH5YUJWYZovqkXg8Nq20gLvJq/elM981WmFcZa8/w== X-Received: by 2002:a92:cb12:: with SMTP id s18mr24077390ilo.32.1629747059384; Mon, 23 Aug 2021 12:30:59 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id d14sm7057536iod.18.2021.08.23.12.30.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Aug 2021 12:30:59 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Brian Rosen In-Reply-To: Date: Mon, 23 Aug 2021 15:30:57 -0400 Cc: ECRIT Content-Transfer-Encoding: quoted-printable Message-Id: <135B478F-7980-4963-82D8-6FE2A2C65150@brianrosen.net> References: <162941926169.9620.8527061840228167005@ietfa.amsl.com> <35C2A468-9290-4DC8-9A77-8A67CA73630B@brianrosen.net> To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-lost-planned-changes-04.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 19:31:19 -0000 Thanks for the close read, and especially thanks for looking at the xml. I will make all of the changes for 1-7. On #8, it should be a straight = quote. I will fix it. On 9, that=E2=80=99s the way I=E2=80=99ve usually seen IETF docs use an = extension point. I will make any changes the work group decides here. = One possibility is to tie planned-changes to -similar-location and have = the schema in the latter incorporate all the extensions. This is more = xml work for me, and it=E2=80=99s not my strong suit, but I=E2=80=99ll = do whatever the WG decides. I=E2=80=99m clearly not communicating how the mechanism works well = enough in the document. I will have to try harder. The extension to findService offers an (optional) URI to be passed in = the request. The server stashes the URI with the record. If a change = in the record occurs later, the server does a POST to the URI using the = object defined in Section 7. That object is not related to the rest of = the LoST schemas because it=E2=80=99s not part of the LoST protocol, but = rather a side effect of one aspect of the protocol. When the LoST = server does that POST, it=E2=80=99s actually a client to the LoST = client=E2=80=99s web service. I will fix - 10. I must have made a late editing error. Brian > On Aug 21, 2021, at 1:33 PM, Gunnar Hellstr=C3=B6m = wrote: >=20 > Brian, >=20 > I think this one looks good and mature. >=20 > I have only found a few editorials and traditional xml mistakes ( if I = got it right ): >=20 > 1. In Abstract, "" s.b. "" >=20 > 2. In Abstract, in the middle, ", and add a date" s.b. ", and a date" >=20 > 3. In Abstract: Full stop missing at the end. >=20 > 4. In 1. Introduction, second line, "" s.b. = "" >=20 > 5. In 1. Introduction, third paragraph: Full stop missing at the end. >=20 > 6. In 4. second paragraph, second line: findService s.b. = >=20 > 7. In 7. first line "The Relax" s.b. "the Relax" >=20 > 8. In 8. In the "plannedChange" element, "invalidAsOf" got its = leading quoutation mark changed to a curly leading double quote instead = of a straight double quote. Was that intentional, and is that safe, or = should you return to using straight double quote? >=20 > 9. In 8. Section 8 contains extensions to the schema presented in = section 7. Is the editing instruction notations formal enough to = reliably create the extended schema correctly. Would it not be safer, = and more convenient for developers if you provided the completed schema, = with easily found comments around the extensions, so that anyone = interested in creating the schema in section 7 could do that? > Please explain why it is the schema in section 7 that is provided as a = complete schema and 8 just as editing instructions and not the other way = around, when it is the schema resulting from section 8 that is the = purpose of the specification. >=20 > 10. In 9. I think the following two lines are missing before the last = line: > > >=20 >=20 > Regards >=20 > Gunnar >=20 > --=20 > Gunnar Hellstr=C3=B6m > GHAccess > gunnar.hellstrom@ghaccess.se >=20 >=20 >=20 > Den 2021-08-20 kl. 02:34, skrev Brian Rosen: >> This too, finally, is redone. I believe all comments were addressed. = XML should be checked, but I THINK it=E2=80=99s right now. There is a = bit of new text that explains the LoST server doesn=E2=80=99t have to = save the Location Information that was sent in the findService request. = That means that the notification, if requested, will be sent for any = change, which means the client could get a notification to revalidate = only to find they got the same result. >>=20 >> I did specify the Content-Type as application/xml instead of defining = a new media type. I think that=E2=80=99s okay, comments welcome. >>=20 >> Brian >>=20 >>> On Aug 19, 2021, at 8:27 PM, 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 : Validation of Locations Around a Planned = Change >>> Author : Brian Rosen >>> Filename : draft-ietf-ecrit-lost-planned-changes-04.txt >>> Pages : 19 >>> Date : 2021-08-19 >>>=20 >>> Abstract: >>> This document defines an extension to LoST (RFC5222) that allows a >>> planned change to the data in the LoST server to occur. Records = that >>> previously were valid will become invalid at a date in the future, >>> and new locations will become valid after the date. The extension >>> adds two elements to the request: A URI to be used = to >>> inform the LIS that previously valid locations will be invalid = after >>> the planned change date, and add a date which requests the server = to >>> perform validation as of the date specified. It also adds an >>> optional Time-To-Live element to the response, which informs = clients >>> about the current expected lifetime of the validation. This = document >>> also provides a conventional XML schema for LoST, as backwards >>> compatible alternative to the RelaxNG schema in RFC5222 >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> = https://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-planned-changes/ >>>=20 >>> There is also an htmlized version available at: >>> = https://datatracker.ietf.org/doc/html/draft-ietf-ecrit-lost-planned-change= s-04 >>>=20 >>> A diff from the previous version is available at: >>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-lost-planned-changes-= 04 >>>=20 >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>>=20 >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > --=20 > Gunnar Hellstr=C3=B6m > GHAccess > gunnar.hellstrom@ghaccess.se >=20 From nobody Mon Aug 23 13:14:53 2021 Return-Path: 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 EDEB23A1404 for ; Mon, 23 Aug 2021 13:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=bell.ca 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 TDWbxGDogBaQ for ; Mon, 23 Aug 2021 13:14:35 -0700 (PDT) Received: from ESA2-Wyn.bell.ca (esa2-wyn.bell.ca [67.69.243.180]) (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 306A83A1465 for ; Mon, 23 Aug 2021 13:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1629749672; x=1661285672; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=hS5TP6SIsTLVngppq7O//cupPZTRU2Dl2wqqxbisfqo=; b=glAvyvXUiJR65XpwoVZEfbXNLD9p5Ei5zRrVmnqyyo0QgdgaHq0QLbXR YNup9tzlr0a73/Ih1veIZ99nZAPbDnjAnCXrLqigBhUynIcpMcodxmFpP N9ljkjpaCwxhHAedpQF2IK+x3nq3qufDfBklz/eez14fisEYgqwxp4FGU GO8NeLqyDFAtU1lvSdXN6AB+wy/qmdbJbOfIBH/uCJMc+Y5RbSGHaITde O8D1Rkk3qr54HIOkF+KyxLThHmmH5mnLqroWD0eAlwJAuScDQIZQA3i2J VKsW4ciz3F9DTHEPXZOG6kJzqW78upNpfFkP24OPAzkFwC0iJ+dn9FPS0 g==; IronPort-SDR: LPhkZuYApTMigKqsuh8YOSxv/SmNF432K6R2ew4CMAEu1bGyQoTInJOB7p+zRn4WJnTycbc9e/ /GP0svy7QC6g== Received: from dm5cch-d01.bellca.int.bell.ca (HELO DG1MBX01-WYN.bell.corp.bce.ca) ([198.235.102.31]) by esa02corp-wyn.bell.corp.bce.ca with ESMTP; 23 Aug 2021 16:14:28 -0400 Received: from DG12MBX02-WYN.bell.corp.bce.ca (142.182.18.47) by DG1MBX01-WYN.bell.corp.bce.ca (142.182.18.11) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 23 Aug 2021 16:14:27 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX02-WYN.bell.corp.bce.ca (142.182.18.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Mon, 23 Aug 2021 16:14:27 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Mon, 23 Aug 2021 16:14:27 -0400 From: "Caron, Guy" To: Brian Rosen , ECRIT Thread-Topic: [EXT]Re: [Ecrit] I-D Action: draft-ietf-ecrit-lost-planned-changes-04.txt Thread-Index: AQHXlVs8YjeO9kpmEkypFrDR4rG3AauBi6eQ Date: Mon, 23 Aug 2021 20:14:27 +0000 Message-ID: References: <162941926169.9620.8527061840228167005@ietfa.amsl.com> <35C2A468-9290-4DC8-9A77-8A67CA73630B@brianrosen.net> In-Reply-To: <35C2A468-9290-4DC8-9A77-8A67CA73630B@brianrosen.net> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.79] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-lost-planned-changes-04.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 20:14:51 -0000 SGkgYWxsLA0KDQpJIGRpZCByZXZpZXcgdGhlIG5vdGVkIGRyYWZ0IGFuZCBoYXZlIHN1YnN0YW50 aXZlIGNvbW1lbnRzIHRoYXQgSSB3aWxsIHBvc3QgdW5kZXIgZGlzdGluY3Qgb2JqZWN0IGxpbmVz Lg0KDQpUaGFua3MgZm9yIHVwZGF0aW5nIHRoaXMgbG9uZyBhd2FpdGluZyBkcmFmdC4NCg0KR3V5 DQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogRWNyaXQgPGVjcml0LWJvdW5j ZXNAaWV0Zi5vcmc+IERlIGxhIHBhcnQgZGUgQnJpYW4gUm9zZW4NCkVudm95w6nCoDogMTkgYW/D u3QgMjAyMSAyMDozNQ0Kw4DCoDogRUNSSVQgPGVjcml0QGlldGYub3JnPg0KT2JqZXTCoDogW0VY VF1SZTogW0Vjcml0XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWVjcml0LWxvc3QtcGxhbm5lZC1j aGFuZ2VzLTA0LnR4dA0KDQpUaGlzIHRvbywgZmluYWxseSwgaXMgcmVkb25lLiAgSSBiZWxpZXZl IGFsbCBjb21tZW50cyB3ZXJlIGFkZHJlc3NlZC4gIFhNTCBzaG91bGQgYmUgY2hlY2tlZCwgYnV0 IEkgVEhJTksgaXTigJlzIHJpZ2h0IG5vdy4gIFRoZXJlIGlzIGEgYml0IG9mIG5ldyB0ZXh0IHRo YXQgZXhwbGFpbnMgdGhlIExvU1Qgc2VydmVyIGRvZXNu4oCZdCBoYXZlIHRvIHNhdmUgdGhlIExv Y2F0aW9uIEluZm9ybWF0aW9uIHRoYXQgd2FzIHNlbnQgaW4gdGhlIGZpbmRTZXJ2aWNlIHJlcXVl c3QuICBUaGF0IG1lYW5zIHRoYXQgdGhlIG5vdGlmaWNhdGlvbiwgaWYgcmVxdWVzdGVkLCB3aWxs IGJlIHNlbnQgZm9yIGFueSBjaGFuZ2UsIHdoaWNoIG1lYW5zIHRoZSBjbGllbnQgY291bGQgZ2V0 IGEgbm90aWZpY2F0aW9uIHRvIHJldmFsaWRhdGUgb25seSB0byBmaW5kIHRoZXkgZ290IHRoZSBz YW1lIHJlc3VsdC4gIA0KDQpJIGRpZCBzcGVjaWZ5IHRoZSBDb250ZW50LVR5cGUgYXMgYXBwbGlj YXRpb24veG1sIGluc3RlYWQgb2YgZGVmaW5pbmcgYSBuZXcgbWVkaWEgdHlwZS4gIEkgdGhpbmsg dGhhdOKAmXMgb2theSwgY29tbWVudHMgd2VsY29tZS4NCg0KQnJpYW4NCg0KPiBPbiBBdWcgMTks IDIwMjEsIGF0IDg6MjcgUE0sIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyB3cm90ZToNCj4gDQo+ IA0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJ bnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0g b2YgdGhlIEVtZXJnZW5jeSBDb250ZXh0IFJlc29sdXRpb24gd2l0aCBJbnRlcm5ldCBUZWNobm9s b2dpZXMgV0cgb2YgdGhlIElFVEYuDQo+IA0KPiAgICAgICAgVGl0bGUgICAgICAgICAgIDogVmFs aWRhdGlvbiBvZiBMb2NhdGlvbnMgQXJvdW5kIGEgUGxhbm5lZCBDaGFuZ2UNCj4gICAgICAgIEF1 dGhvciAgICAgICAgICA6IEJyaWFuIFJvc2VuDQo+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1p ZXRmLWVjcml0LWxvc3QtcGxhbm5lZC1jaGFuZ2VzLTA0LnR4dA0KPiAJUGFnZXMgICAgICAgICAg IDogMTkNCj4gCURhdGUgICAgICAgICAgICA6IDIwMjEtMDgtMTkNCj4gDQo+IEFic3RyYWN0Og0K PiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhbiBleHRlbnNpb24gdG8gTG9TVCAoUkZDNTIyMikg dGhhdCBhbGxvd3MgYQ0KPiAgIHBsYW5uZWQgY2hhbmdlIHRvIHRoZSBkYXRhIGluIHRoZSBMb1NU IHNlcnZlciB0byBvY2N1ci4gIFJlY29yZHMgdGhhdA0KPiAgIHByZXZpb3VzbHkgd2VyZSB2YWxp ZCB3aWxsIGJlY29tZSBpbnZhbGlkIGF0IGEgZGF0ZSBpbiB0aGUgZnV0dXJlLA0KPiAgIGFuZCBu ZXcgbG9jYXRpb25zIHdpbGwgYmVjb21lIHZhbGlkIGFmdGVyIHRoZSBkYXRlLiAgVGhlIGV4dGVu c2lvbg0KPiAgIGFkZHMgdHdvIGVsZW1lbnRzIHRvIHRoZSA8ZmluZHNlcnZpY2U+IHJlcXVlc3Q6 IEEgVVJJIHRvIGJlIHVzZWQgdG8NCj4gICBpbmZvcm0gdGhlIExJUyB0aGF0IHByZXZpb3VzbHkg dmFsaWQgbG9jYXRpb25zIHdpbGwgYmUgaW52YWxpZCBhZnRlcg0KPiAgIHRoZSBwbGFubmVkIGNo YW5nZSBkYXRlLCBhbmQgYWRkIGEgZGF0ZSB3aGljaCByZXF1ZXN0cyB0aGUgc2VydmVyIHRvDQo+ ICAgcGVyZm9ybSB2YWxpZGF0aW9uIGFzIG9mIHRoZSBkYXRlIHNwZWNpZmllZC4gIEl0IGFsc28g YWRkcyBhbg0KPiAgIG9wdGlvbmFsIFRpbWUtVG8tTGl2ZSBlbGVtZW50IHRvIHRoZSByZXNwb25z ZSwgd2hpY2ggaW5mb3JtcyBjbGllbnRzDQo+ICAgYWJvdXQgdGhlIGN1cnJlbnQgZXhwZWN0ZWQg bGlmZXRpbWUgb2YgdGhlIHZhbGlkYXRpb24uICBUaGlzIGRvY3VtZW50DQo+ICAgYWxzbyBwcm92 aWRlcyBhIGNvbnZlbnRpb25hbCBYTUwgc2NoZW1hIGZvciBMb1NULCBhcyBiYWNrd2FyZHMNCj4g ICBjb21wYXRpYmxlIGFsdGVybmF0aXZlIHRvIHRoZSBSZWxheE5HIHNjaGVtYSBpbiBSRkM1MjIy DQo+IA0KPiANCj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJh ZnQgaXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZWNy aXQtbG9zdC1wbGFubmVkLWNoYW5nZXMNCj4gLw0KPiANCj4gVGhlcmUgaXMgYWxzbyBhbiBodG1s aXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1pZXRmLWVjcml0LWxvc3QtcGxhbm5lZC1jaA0KPiBhbmdlcy0wNA0K PiANCj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1lY3JpdC1sb3N0 LXBsYW5uZWQtY2hhbmdlDQo+IHMtMDQNCj4gDQo+IA0KPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFs c28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdA0KPiBJLUQtQW5u b3VuY2VAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p LWQtYW5ub3VuY2UNCj4gSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0 Zi5vcmcvc2hhZG93Lmh0bWwgb3IgDQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ct c2l0ZXMudHh0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpFY3JpdCBtYWlsaW5nIGxpc3QNCkVjcml0QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkV4dGVy bmFsIEVtYWlsOiBQbGVhc2UgdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxpbmtzIGFuZCBhdHRh Y2htZW50cyAvIENvdXJyaWVsIGV4dGVybmU6IFNveWV6IHBydWRlbnQgYXZlYyBsZXMgbGllbnMg ZXQgZG9jdW1lbnRzIGpvaW50cw0K From nobody Mon Aug 23 13:32:11 2021 Return-Path: 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 52F233A1592 for ; Mon, 23 Aug 2021 13:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=bell.ca 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 radmpIVOAdJQ for ; Mon, 23 Aug 2021 13:32:04 -0700 (PDT) Received: from ESA4-Dor.bell.ca (esa4-dor.bell.ca [204.101.223.61]) (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 0D1043A158E for ; Mon, 23 Aug 2021 13:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1629750724; x=1661286724; h=from:to:subject:date:message-id:mime-version; bh=RSfkFdvgXcvVi2oeSz9+ub2IzMwQdl/wnrT5TABgWP4=; b=dQMSeHt3oq4o2Tk0MdswFneJlKxjbhg+Yrzk0gGaurDkA+ukSQxOVtgw CCT+DtQvq5/l628RxY7pRxig0tOGVMa+sa1k7zmshhoklGQz8PeYKoLn4 EDH9xx0jStjuH7vmY4sNWK/xfl8OPvvKlnkThJBNGkjjFFymQVL81DWK2 CGMBAnx/Ng5A/fI5XvEigpLakvA8S2VVlxkWyGEdDE2lCEL+I8ffMT0Em QVDffl3G875ZwZ9yBdJRf/4/8O2eLLkGubqems2kSVRASMdxbh9JllZ89 TKVemCQZKjSwR6npBPJsjM4WVgpLPBlk1vJ3Nyyw5OeCnqAiuadsIEbsn w==; IronPort-SDR: F7/isKIW8MJSjvoZC14gqAjyBswJ6oubdUFl7Thy8tMIjuSREI4+aV/WIyyoV+Wpqx80ZE8dIf ic4+RGAFrzqg== Received: from dc5cmz-d01.bellca.int.bell.ca (HELO DG3MBX02-WYN.bell.corp.bce.ca) ([198.235.121.232]) by esa04corp-dor.bell.corp.bce.ca with ESMTP; 23 Aug 2021 16:32:02 -0400 Received: from DG12MBX04-WYN.bell.corp.bce.ca (142.182.18.49) by DG3MBX02-WYN.bell.corp.bce.ca (142.182.18.24) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 23 Aug 2021 16:32:01 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX04-WYN.bell.corp.bce.ca (142.182.18.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Mon, 23 Aug 2021 16:32:01 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Mon, 23 Aug 2021 16:32:01 -0400 From: "Caron, Guy" To: "ecrit@ietf.org" , Brian Rosen Thread-Topic: lost-planned-changes-04: XML vs RelaxNG Thread-Index: AdeYW610lcAN4DSJTRSUJyajp2Zwpw== Date: Mon, 23 Aug 2021 20:32:01 +0000 Message-ID: Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.79] Content-Type: multipart/alternative; boundary="_000_bb19d7c9f0c34c44b233b14ff8eee635bellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Ecrit] lost-planned-changes-04: XML vs RelaxNG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 20:32:10 -0000 --_000_bb19d7c9f0c34c44b233b14ff8eee635bellca_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In section 7, the replacement XML schema is qualified as an "informative al= ternative" however, the text in the Intro states "Alternative schemas have = been circulated, which is undesirable, as they may not be in conformance to= the RelaxNG schema in [RFC5222]. This document provides an XML schema that= replaces the RelaxNG schema. It can be used by any implementation intercha= ngeably with the RelaxNG schema." The latter seems to indicate that the XML schema in section 7 is a normativ= e alternative rather than an informative one. I think this is what we want but the text must be adjusted accordingly. Thanks, Guy --_000_bb19d7c9f0c34c44b233b14ff8eee635bellca_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In section 7, the replacement X= ML schema is qualified as an “informative alternative” however,= the text in the Intro states “Alternative schemas have been circulat= ed, which is undesirable, as they may not be in conformance to the RelaxNG schema in [RFC5222]. This document provides an XML schema t= hat replaces the RelaxNG schema. It can be used by any implementation inter= changeably with the RelaxNG schema.”

 

The latter seems to indicate th= at the XML schema in section 7 is a normative alternative rather than an in= formative one.

 

I think this is what we want bu= t the text must be adjusted accordingly.

 

Thanks,

 

Guy

--_000_bb19d7c9f0c34c44b233b14ff8eee635bellca_-- From nobody Mon Aug 23 13:37:23 2021 Return-Path: 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 F05273A1604 for ; Mon, 23 Aug 2021 13:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, 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.20150623.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 NOi_9b-cbl3H for ; Mon, 23 Aug 2021 13:37:14 -0700 (PDT) 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 F30AD3A1600 for ; Mon, 23 Aug 2021 13:37:13 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id e186so23465478iof.12 for ; Mon, 23 Aug 2021 13:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZGe9zMTr0GJqAXXeCdj4iYIxH92rudzFm1x54C2bcCc=; b=D2gLHZQ24dmg34/yzdwyERCSeMfHUl+SYpKcRZCk+MBYwP/oMHp/nZApLktjbBV5aR 11mrigZeLkYJ8eNxXwC9BZEGh8t0jIMOHrIg0uDw3QoSlZ6fmWqxjJgNcE6afoEtHDm5 fM6hyh86BjvWwrepLv2tDqHu7VOBePAKMlvlej6PvVWUEDoSRUzbR2Y0wkaAKMbXISui alhae8aq5jYi0pdPRqlXH2cskfcdjMA7ulX2PMTIMHM1CEnXFrSI7Vffv6yZ1vfqnR66 hceCzdNqEwNPegeX8eafQdD7z2LXh1MLpvNQ7GvdUZ2oPzap4kT2N712h2ujySu6alDW VV/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZGe9zMTr0GJqAXXeCdj4iYIxH92rudzFm1x54C2bcCc=; b=K5HjRMwdJNEePP5jk9ZIY+Czl8CCQRdqqq3+asxXX6riMeKnFx+yVyZfgt/Fjnnclc AJVK/nmwKnY5oLbJz++i7fpgzFurBY5rO52tx9rSAGPMlern8LIIMl7OE8KKfgZGXtit cwVNXysjcPrpRFo77lrZJKC6AuZQcf9U+rFOYkVP3iH/4ULmUwMSyPO7ePRdPmf3fYJD s9fDc0Y5veYXsZgVlDvXrGzTbr3HnrxJoTchjYYjahvYC1JaXejWlX8NOC7+LTBrMcwA y6txShzYIo/+oMEX4xXJDy7xw6gJKsMl1BLdcpUVOeKsdKBostFSU/Zn3OegBv6Cok5A PNug== X-Gm-Message-State: AOAM530rFvbS18RA7hDYy/a936oZAH2KpCdgfGYb+aT6XaJrMu4s3iP0 2jTSb8R7RYRjkHY2MZqRll55RPMuJH7FaMvOCfCgyw== X-Google-Smtp-Source: ABdhPJz+Tuo+D9YJbXr1vYvLRcyKpYUm76h3cam9yPDgj8lvnGITxWolTBmjM+9C9dIWZt+Cz3SjtbCSv043rEvMvbs= X-Received: by 2002:a02:ca06:: with SMTP id i6mr30881066jak.81.1629751031833; Mon, 23 Aug 2021 13:37:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Rosen Date: Mon, 23 Aug 2021 16:37:01 -0400 Message-ID: To: "Caron, Guy" Cc: "ecrit@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005340b205ca3ffb48" Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: XML vs RelaxNG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 20:37:20 -0000 --0000000000005340b205ca3ffb48 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We have had comments suggesting it be non normative, which is why it says what it does now. My personal view is that it should replace the Relax NG schema, and any subsequent changes and extensions should only reference this one. No one that I know uses the Relax NG schema one way or another they get an xml schema and use that. But I will go with whatever the consensus is Brian On Mon, Aug 23, 2021 at 4:32 PM Caron, Guy wrote: > In section 7, the replacement XML schema is qualified as an =E2=80=9Cinfo= rmative > alternative=E2=80=9D however, the text in the Intro states =E2=80=9CAlter= native schemas > have been circulated, which is undesirable, as they may not be in > conformance to the RelaxNG schema in [RFC5222]. This document provides an > XML schema that replaces the RelaxNG schema. It can be used by any > implementation interchangeably with the RelaxNG schema.=E2=80=9D > > > > The latter seems to indicate that the XML schema in section 7 is a > normative alternative rather than an informative one. > > > > I think this is what we want but the text must be adjusted accordingly. > > > > Thanks, > > > > Guy > --0000000000005340b205ca3ffb48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We have had comments suggesting it be non normative, whic= h is why it says what it does now.=C2=A0

<= div dir=3D"auto">My personal view is that it should replace the Relax NG sc= hema, and any subsequent changes and extensions should only reference this = one. No one that I know uses the Relax NG schema one way or another they ge= t an xml schema and use that.=C2=A0

But I will go with whatever the consensus is =C2=A0

Brian

On Mon, Aug 23, 2021 at 4= :32 PM Caron, Guy <g.caron@bell.ca> wrote:

In section 7, the replacement X= ML schema is qualified as an =E2=80=9Cinformative alternative=E2=80=9D howe= ver, the text in the Intro states =E2=80=9CAlternative schemas have been ci= rculated, which is undesirable, as they may not be in conformance to the RelaxNG schema in [RFC5222]. This document provides an XML schema t= hat replaces the RelaxNG schema. It can be used by any implementation inter= changeably with the RelaxNG schema.=E2=80=9D

=C2=A0

The latter seems to indicate th= at the XML schema in section 7 is a normative alternative rather than an in= formative one.

=C2=A0

I think this is what we want bu= t the text must be adjusted accordingly.

=C2=A0

Thanks,

<= div lang=3D"FR-CA" link=3D"#0563C1" vlink=3D"#954F72">

=

=C2=A0

Guy

--0000000000005340b205ca3ffb48-- From nobody Mon Aug 23 13:59:24 2021 Return-Path: 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 0A8B83A17DE for ; Mon, 23 Aug 2021 13:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=bell.ca 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 mGamHPJ_MWvK for ; Mon, 23 Aug 2021 13:59:16 -0700 (PDT) Received: from ESA2-Wyn.bell.ca (esa2-wyn.bell.ca [67.69.243.180]) (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 D39E63A17D9 for ; Mon, 23 Aug 2021 13:59:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1629752356; x=1661288356; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=FjAB83loCXyyfd1V/46kPdnEUhiCeMkUdWcYt8yAThk=; b=UO8ibWLNuVlVyfXXxL6ZTdEG+KvFOSEbCgzM9Mkp58vNB3Vs/7pDR5xo sqjOH9vH5hunG1LknkOhZltHvQxhtKmnw9cHDz6rG/7WPCWlUI/OrarG8 6Msa0XyZUu+njcTTI9jMEy2pd/vz1lziPUp6jxGg3GQoqQNj4VVMbKiML LeFRnKrCUQeuebYJvx02i7l1emsycfPZbfRRb0oLrDrrBTblLZ7SmNQK4 48n4RUV65moWNbeqr2Q6BLSJDDPBknrtc2DAOD3Cufms6zfwM1yoLFEHp hmaTneww7xFeW/G74I/3CWlrRP6bfLoJkXgok7vmL395CPFAAk8kSsOn9 w==; IronPort-SDR: vC9QE4uXtahZC+1eX9njb9UuoI4mOmzlni1l//dty65iuZF5NEneZMazKzsILA/vqU9EeegJ8R OuBAyqpl9PJA== Received: from dm5czo-d01.bellca.int.bell.ca (HELO DG4MBX01-WYN.bell.corp.bce.ca) ([198.235.102.33]) by esa02corp-wyn.bell.corp.bce.ca with ESMTP; 23 Aug 2021 16:59:09 -0400 Received: from DG12MBX02-WYN.bell.corp.bce.ca (142.182.18.47) by DG4MBX01-WYN.bell.corp.bce.ca (142.182.18.27) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 23 Aug 2021 16:59:09 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX02-WYN.bell.corp.bce.ca (142.182.18.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Mon, 23 Aug 2021 16:59:09 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Mon, 23 Aug 2021 16:59:09 -0400 From: "Caron, Guy" To: Brian Rosen CC: "ecrit@ietf.org" Thread-Topic: [EXT]Re: lost-planned-changes-04: XML vs RelaxNG Thread-Index: AdeYW610lcAN4DSJTRSUJyajp2ZwpwAJHmmAAAgbylA= Date: Mon, 23 Aug 2021 20:59:09 +0000 Message-ID: <7f40b92699324c7588a8baab528aab36@bell.ca> References: In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.79] Content-Type: multipart/alternative; boundary="_000_7f40b92699324c7588a8baab528aab36bellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: XML vs RelaxNG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 20:59:22 -0000 --_000_7f40b92699324c7588a8baab528aab36bellca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgeW91IHJlZmVyIHRvIGdlbmVyYWwgY29tbWVudHMgbWFkZSBpbiB0aGUgZWFybHkgZGF5cyBv ZiBMb1NULCBzb21lIDE1IHllYXJzIGFnbywgSSBndWVzcyB0aW1lIHRlbGxzIHRoYXQgUmVsYXhO RyBkaWQgbm90IHJhbXAgdXAgYXMgZXhwZWN0ZWQuDQoNCkkgY2Fu4oCZdCBmaW5kIGNvbW1lbnRz IG9uIHRoZSBFQ1JJVCBsaXN0IHNwZWNpZmljIHRvIHBsYW5uZWQtY2hhbmdlcyBhc2tpbmcgZm9y IFhNTCBzY2hlbWFzIHRvIGJlIGluZm9ybWF0aXZlIHdoaWxlIHVwZGF0aW5nIFJGQzUyMjIuDQoN CkkgYWdyZWUgd2l0aCB5b3VyIHNlbnRpbWVudCB0aGF0IFhNTCBzY2hlbWFzIHNob3VsZCBiZSBh IG5vcm1hdGl2ZSBhbHRlcm5hdGl2ZSAoaS5lLiwgZG9lcyBub3QgZGVwcmVjYXRlcykgdG8gUmVs YXhORy4NCg0KQmVzaWRlcywgYnkgbm90IHByb3ZpZGluZyBSZWxheE5HIGVxdWl2YWxlbnRzIGZv ciB0aGUgZXh0ZW5zaW9ucywgaXNu4oCZdCB0aGF0IHdoYXQgeW91IGFyZSBkb2luZyBhbnl3YXk/ DQoNClRoYW5rcywNCg0KR3V5DQoNCkRlIDogQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0 Pg0KRW52b3nDqSA6IDIzIGFvw7t0IDIwMjEgMTY6MzcNCsOAIDogQ2Fyb24sIEd1eSA8Zy5jYXJv bkBiZWxsLmNhPg0KQ2MgOiBlY3JpdEBpZXRmLm9yZw0KT2JqZXQgOiBbRVhUXVJlOiBsb3N0LXBs YW5uZWQtY2hhbmdlcy0wNDogWE1MIHZzIFJlbGF4TkcNCg0KV2UgaGF2ZSBoYWQgY29tbWVudHMg c3VnZ2VzdGluZyBpdCBiZSBub24gbm9ybWF0aXZlLCB3aGljaCBpcyB3aHkgaXQgc2F5cyB3aGF0 IGl0IGRvZXMgbm93Lg0KDQpNeSBwZXJzb25hbCB2aWV3IGlzIHRoYXQgaXQgc2hvdWxkIHJlcGxh Y2UgdGhlIFJlbGF4IE5HIHNjaGVtYSwgYW5kIGFueSBzdWJzZXF1ZW50IGNoYW5nZXMgYW5kIGV4 dGVuc2lvbnMgc2hvdWxkIG9ubHkgcmVmZXJlbmNlIHRoaXMgb25lLiBObyBvbmUgdGhhdCBJIGtu b3cgdXNlcyB0aGUgUmVsYXggTkcgc2NoZW1hIG9uZSB3YXkgb3IgYW5vdGhlciB0aGV5IGdldCBh biB4bWwgc2NoZW1hIGFuZCB1c2UgdGhhdC4NCg0KQnV0IEkgd2lsbCBnbyB3aXRoIHdoYXRldmVy IHRoZSBjb25zZW5zdXMgaXMNCg0KQnJpYW4NCg0KT24gTW9uLCBBdWcgMjMsIDIwMjEgYXQgNDoz MiBQTSBDYXJvbiwgR3V5IDxnLmNhcm9uQGJlbGwuY2E8bWFpbHRvOmcuY2Fyb25AYmVsbC5jYT4+ IHdyb3RlOg0KSW4gc2VjdGlvbiA3LCB0aGUgcmVwbGFjZW1lbnQgWE1MIHNjaGVtYSBpcyBxdWFs aWZpZWQgYXMgYW4g4oCcaW5mb3JtYXRpdmUgYWx0ZXJuYXRpdmXigJ0gaG93ZXZlciwgdGhlIHRl eHQgaW4gdGhlIEludHJvIHN0YXRlcyDigJxBbHRlcm5hdGl2ZSBzY2hlbWFzIGhhdmUgYmVlbiBj aXJjdWxhdGVkLCB3aGljaCBpcyB1bmRlc2lyYWJsZSwgYXMgdGhleSBtYXkgbm90IGJlIGluIGNv bmZvcm1hbmNlIHRvIHRoZSBSZWxheE5HIHNjaGVtYSBpbiBbUkZDNTIyMl0uIFRoaXMgZG9jdW1l bnQgcHJvdmlkZXMgYW4gWE1MIHNjaGVtYSB0aGF0IHJlcGxhY2VzIHRoZSBSZWxheE5HIHNjaGVt YS4gSXQgY2FuIGJlIHVzZWQgYnkgYW55IGltcGxlbWVudGF0aW9uIGludGVyY2hhbmdlYWJseSB3 aXRoIHRoZSBSZWxheE5HIHNjaGVtYS7igJ0NCg0KVGhlIGxhdHRlciBzZWVtcyB0byBpbmRpY2F0 ZSB0aGF0IHRoZSBYTUwgc2NoZW1hIGluIHNlY3Rpb24gNyBpcyBhIG5vcm1hdGl2ZSBhbHRlcm5h dGl2ZSByYXRoZXIgdGhhbiBhbiBpbmZvcm1hdGl2ZSBvbmUuDQoNCkkgdGhpbmsgdGhpcyBpcyB3 aGF0IHdlIHdhbnQgYnV0IHRoZSB0ZXh0IG11c3QgYmUgYWRqdXN0ZWQgYWNjb3JkaW5nbHkuDQoN ClRoYW5rcywNCg0KR3V5DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRXh0ZXJu YWwgRW1haWw6IFBsZWFzZSB1c2UgY2F1dGlvbiB3aGVuIG9wZW5pbmcgbGlua3MgYW5kIGF0dGFj aG1lbnRzIC8gQ291cnJpZWwgZXh0ZXJuZTogU295ZXogcHJ1ZGVudCBhdmVjIGxlcyBsaWVucyBl dCBkb2N1bWVudHMgam9pbnRzDQo= --_000_7f40b92699324c7588a8baab528aab36bellca_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5t c29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFt ZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBw dCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlItQ0EiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+SWYgeW91IHJlZmVyIHRvIGdlbmVyYWwgY29tbWVudHMgbWFkZSBpbiB0aGUg ZWFybHkgZGF5cyBvZiBMb1NULCBzb21lIDE1IHllYXJzIGFnbywgSSBndWVzcyB0aW1lIHRlbGxz IHRoYXQgUmVsYXhORyBkaWQNCiBub3QgcmFtcCB1cCBhcyBleHBlY3RlZC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBj YW7igJl0IGZpbmQgY29tbWVudHMgb24gdGhlIEVDUklUIGxpc3Qgc3BlY2lmaWMgdG8gcGxhbm5l ZC1jaGFuZ2VzIGFza2luZyBmb3IgWE1MIHNjaGVtYXMgdG8gYmUgaW5mb3JtYXRpdmUgd2hpbGUg dXBkYXRpbmcNCiBSRkM1MjIyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGFncmVlIHdpdGggeW91ciBzZW50aW1lbnQg dGhhdCBYTUwgc2NoZW1hcyBzaG91bGQgYmUgYSBub3JtYXRpdmUgYWx0ZXJuYXRpdmUgKGkuZS4s IGRvZXMgbm90IGRlcHJlY2F0ZXMpIHRvIFJlbGF4TkcuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkJlc2lkZXMsIGJ5IG5v dCBwcm92aWRpbmcgUmVsYXhORyBlcXVpdmFsZW50cyBmb3IgdGhlIGV4dGVuc2lvbnMsIGlzbuKA mXQgdGhhdCB3aGF0IHlvdSBhcmUgZG9pbmcgYW55d2F5PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPkd1eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9 IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRlIiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+IEJyaWFuIFJvc2VuICZsdDtickBicmlhbnJvc2VuLm5ldCZndDsNCjxicj4NCjxiPkVu dm95w6kmbmJzcDs6PC9iPiAyMyBhb8O7dCAyMDIxIDE2OjM3PGJyPg0KPGI+w4AmbmJzcDs6PC9i PiBDYXJvbiwgR3V5ICZsdDtnLmNhcm9uQGJlbGwuY2EmZ3Q7PGJyPg0KPGI+Q2MmbmJzcDs6PC9i PiBlY3JpdEBpZXRmLm9yZzxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gW0VYVF1SZTogbG9zdC1w bGFubmVkLWNoYW5nZXMtMDQ6IFhNTCB2cyBSZWxheE5HPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+V2UgaGF2ZSBoYWQgY29tbWVudHMgc3VnZ2VzdGluZyBpdCBiZSBub24g bm9ybWF0aXZlLCB3aGljaCBpcyB3aHkgaXQgc2F5cyB3aGF0IGl0IGRvZXMgbm93LiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBw ZXJzb25hbCB2aWV3IGlzIHRoYXQgaXQgc2hvdWxkIHJlcGxhY2UgdGhlIFJlbGF4IE5HIHNjaGVt YSwgYW5kIGFueSBzdWJzZXF1ZW50IGNoYW5nZXMgYW5kIGV4dGVuc2lvbnMgc2hvdWxkIG9ubHkg cmVmZXJlbmNlIHRoaXMgb25lLiBObyBvbmUgdGhhdCBJIGtub3cgdXNlcyB0aGUgUmVsYXggTkcg c2NoZW1hIG9uZSB3YXkgb3IgYW5vdGhlciB0aGV5IGdldCBhbiB4bWwgc2NoZW1hIGFuZCB1c2Ug dGhhdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QnV0IEkgd2lsbCBnbyB3aXRoIHdoYXRldmVyIHRoZSBjb25zZW5zdXMgaXMgJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkJyaWFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gTW9uLCBBdWcgMjMsIDIwMjEgYXQgNDozMiBQTSBDYXJvbiwgR3V5ICZsdDs8YSBocmVm PSJtYWlsdG86Zy5jYXJvbkBiZWxsLmNhIj5nLmNhcm9uQGJlbGwuY2E8L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSI+SW4gc2VjdGlvbiA3LCB0aGUgcmVw bGFjZW1lbnQgWE1MIHNjaGVtYSBpcyBxdWFsaWZpZWQgYXMgYW4g4oCcaW5mb3JtYXRpdmUgYWx0 ZXJuYXRpdmXigJ0gaG93ZXZlciwgdGhlIHRleHQgaW4gdGhlIEludHJvIHN0YXRlcyDigJxBbHRl cm5hdGl2ZSBzY2hlbWFzIGhhdmUgYmVlbiBjaXJjdWxhdGVkLA0KIHdoaWNoIGlzIHVuZGVzaXJh YmxlLCBhcyB0aGV5IG1heSBub3QgYmUgaW4gY29uZm9ybWFuY2UgdG8gdGhlIFJlbGF4Tkcgc2No ZW1hIGluIFtSRkM1MjIyXS4gVGhpcyBkb2N1bWVudCBwcm92aWRlcyBhbiBYTUwgc2NoZW1hIHRo YXQgcmVwbGFjZXMgdGhlIFJlbGF4Tkcgc2NoZW1hLiBJdCBjYW4gYmUgdXNlZCBieSBhbnkgaW1w bGVtZW50YXRpb24gaW50ZXJjaGFuZ2VhYmx5IHdpdGggdGhlIFJlbGF4Tkcgc2NoZW1hLuKAnTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tQ0EiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tQ0EiPlRoZSBsYXR0ZXIgc2VlbXMgdG8gaW5kaWNhdGUgdGhhdCB0 aGUgWE1MIHNjaGVtYSBpbiBzZWN0aW9uIDcgaXMgYSBub3JtYXRpdmUgYWx0ZXJuYXRpdmUgcmF0 aGVyIHRoYW4gYW4gaW5mb3JtYXRpdmUgb25lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiPkkgdGhp bmsgdGhpcyBpcyB3aGF0IHdlIHdhbnQgYnV0IHRoZSB0ZXh0IG11c3QgYmUgYWRqdXN0ZWQgYWNj b3JkaW5nbHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSI+VGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tQ0EiPkd1eTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50 ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2NvbG9yOmJsdWUiPkV4dGVybmFsIEVtYWlsOjwvc3Bhbj48L2k+PC9zdHJvbmc+PGVtPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+IFBsZWFzZSB1c2UgY2F1dGlv biB3aGVuIG9wZW5pbmcgbGlua3MgYW5kIGF0dGFjaG1lbnRzIC8NCjwvc3Bhbj48L2VtPjxzdHJv bmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj5Db3VycmllbCBl eHRlcm5lOjwvc3Bhbj48L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Y29sb3I6Ymx1ZSI+IFNveWV6IHBydWRlbnQgYXZlYyBsZXMgbGllbnMgZXQgZG9jdW1lbnRz IGpvaW50cw0KPC9zcGFuPjwvZW0+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_7f40b92699324c7588a8baab528aab36bellca_-- From nobody Mon Aug 23 14:07:42 2021 Return-Path: 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 81C023A188A for ; Mon, 23 Aug 2021 14:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=bell.ca 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 WHxYeNL-UVQ6 for ; Mon, 23 Aug 2021 14:07:34 -0700 (PDT) Received: from ESA2-Dor.bell.ca (esa2-dor.bell.ca [204.101.223.59]) (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 55E503A1888 for ; Mon, 23 Aug 2021 14:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1629752854; x=1661288854; h=from:to:subject:date:message-id:mime-version; bh=jRpJYxb8t+9b7ceVkG9uymHyzOq6X5ldKPeWs2QOAhE=; b=MbUpkoCk41hVHNVsO1Oqk9wqPVseWsNJO+Bwhygj+o068iRY8byy+gUr VDMh6eEO89QSy3QS2rr9TS5AWLGwI0KW1/M9yNV7441pB2FKaQ0EeIbWM pbkVPt6OK1898BSCStYyLh7qxB0N/0s/8lPnXSPskGrIcBeOXrumnbpSq wVLWaFZt6eMkYLdhJs6sVbjuEOeDhwAnmVZs8iSQp4vwGzpcec9rrplve kgsYXVw4smA9eisWdaZOdvHSQE62MmwLNOsv8VREpSZX0CzNAudb6zTlr qQ/Ar6guR091mMa0zgqTB4FSVJWmWwvv/imrhRCve4QAznLxBFg+CfcRe w==; IronPort-SDR: JKFtQr+vNWdPtS1sceiPpPT9cGcxSTK2DZhU4KceXXY9Gktsir0f6fBKWCfYILN64nZM7cpsEL b4+1z3UraFQA== Received: from dc5cmy-d01.bellca.int.bell.ca (HELO DG6MBX01-WYN.bell.corp.bce.ca) ([198.235.121.230]) by esa02corp-dor.bell.corp.bce.ca with ESMTP; 23 Aug 2021 17:07:32 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG6MBX01-WYN.bell.corp.bce.ca (142.182.18.36) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 23 Aug 2021 17:07:32 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Mon, 23 Aug 2021 17:07:32 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Mon, 23 Aug 2021 17:07:32 -0400 From: "Caron, Guy" To: Brian Rosen , "ecrit@ietf.org" Thread-Topic: lost-planned-changes-04: plannedChange bound to validateLocation? Thread-Index: AdeYYhykIa0/cXEHQDGV6seRBYfoOQ== Date: Mon, 23 Aug 2021 21:07:32 +0000 Message-ID: <8bdda7ea7d004b4591ff715526d93a73@bell.ca> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.79] Content-Type: multipart/alternative; boundary="_000_8bdda7ea7d004b4591ff715526d93a73bellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 21:07:41 -0000 --_000_8bdda7ea7d004b4591ff715526d93a73bellca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm90IGFsbCBMb1NUIHNlcnZlciBpbXBsZW1lbnRhdGlvbnMgcGVyZm9ybSBsb2NhdGlvbiB2YWxp ZGF0aW9ucy4gV2hlbiBsb2NhdGlvbiB2YWxpZGF0aW9uIGlzIHJlcXVlc3RlZCBieSB0aGUgY2xp ZW50LCBpdCBhZGRzIHRoZSDigJx2YWxpZGF0ZUxvY2F0aW9u4oCdIGF0dHJpYnV0ZSB0byB0aGUg PGZpbmRTZXJ2aWNlPiBlbGVtZW50Lg0KDQpTbyB0aGUgcXVlc3Rpb24gaXM6IFNob3VsZCDigJxw bGFubmVkQ2hhbmdl4oCdIGJlIGJvdW5kIHRvIOKAnHZhbGlkYXRlTG9jYXRpb27igJ0/DQoNCklm IHlvdSBiZWxpZXZlIG5vdCwgd2hhdCB3b3VsZCBiZSB0aGUgZXhwZWN0ZWQgYmVoYXZpb3VyIG9m IGEgTG9TVCBzZXJ2ZXIgcmVjZWl2aW5nIGEgPHBsYW5uZWRDaGFuZ2U+IGVsZW1lbnQgb3V0c2lk ZSBvZiBhIHZhbGlkYXRpb24gcmVxdWVzdD8NCg0KVGhhbmtzLA0KDQpHdXkNCg== --_000_8bdda7ea7d004b4591ff715526d93a73bellca_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRlItQ0EiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Tm90IGFs bCBMb1NUIHNlcnZlciBpbXBsZW1lbnRhdGlvbnMgcGVyZm9ybSBsb2NhdGlvbiB2YWxpZGF0aW9u cy4gV2hlbiBsb2NhdGlvbiB2YWxpZGF0aW9uIGlzIHJlcXVlc3RlZCBieSB0aGUgY2xpZW50LA0K IGl0IGFkZHMgdGhlIOKAnHZhbGlkYXRlTG9jYXRpb27igJ0gYXR0cmlidXRlIHRvIHRoZSAmbHQ7 ZmluZFNlcnZpY2UmZ3Q7IGVsZW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlNvIHRoZSBxdWVzdGlvbiBpczogU2hv dWxkIOKAnHBsYW5uZWRDaGFuZ2XigJ0gYmUgYm91bmQgdG8g4oCcdmFsaWRhdGVMb2NhdGlvbuKA nT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+SWYgeW91IGJlbGlldmUgbm90LCB3aGF0IHdvdWxkIGJlIHRoZSBleHBlY3Rl ZCBiZWhhdmlvdXIgb2YgYSBMb1NUIHNlcnZlciByZWNlaXZpbmcgYSAmbHQ7cGxhbm5lZENoYW5n ZSZndDsgZWxlbWVudCBvdXRzaWRlDQogb2YgYSB2YWxpZGF0aW9uIHJlcXVlc3Q/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+R3V5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGVtPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Nv bG9yOmJsdWUiPjwvc3Bhbj48L2VtPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8bdda7ea7d004b4591ff715526d93a73bellca_-- From nobody Mon Aug 23 14:12:01 2021 Return-Path: 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 2BBCB3A18F4 for ; Mon, 23 Aug 2021 14:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, 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.20150623.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 Tb8bC9JtVJ34 for ; Mon, 23 Aug 2021 14:11:53 -0700 (PDT) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 54E513A18F1 for ; Mon, 23 Aug 2021 14:11:53 -0700 (PDT) Received: by mail-il1-x135.google.com with SMTP id h29so18460269ila.2 for ; Mon, 23 Aug 2021 14:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=igKBHkx2gUADM1npPmJxCuzjbdWnL+8JQ3ZJyxcblto=; b=d3qzqOYADhcXKonGNNOkrPNf26RVegnqC9PcsLwg+N3LcRiNw0jOVVMHqXIeDawbWo xhh0Sr4e4+s7I+d2MdKWzbVUh9XwHfoJC2vVCRyuaQeFYE0ivcIlcQ0O+aWpIy+D1KO5 vzlArhXOPWac2RJDa0feN1ymfTQkpiYXXCUVyrNzsiK6RmpXWBRFtheyCtNVpqiULVGK hIP/KHdIdVGFZelkl1jrgfC2z3J8HkOMZBAZR0Wt2ig/nLisGmcBcAOAdavCepBBK6Np 5OTEh4H604njRmt1tQKVG/6Pnr3dS+Lgsdyn/Fph8Y+MywNkhDtj7xo3Kyrtal/1Xoqt 82ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=igKBHkx2gUADM1npPmJxCuzjbdWnL+8JQ3ZJyxcblto=; b=YE3qyAMjSdPoiFKIv1ESWhra2sA9xY3yJvKVOyVv3wWFg+uImUBBnjinS+WQYpJ4si 42Q7MDWI/hQ6z67FLI7zuzH4UX2YQzjLcZFqveopr4BfzjhGbb2w34TTCxiznh520MmZ vT+9jys29ED0CCLJsDaKXiK47av+j9+8g3dXCMHW/90O9BqTQhrOn3R7da/tfory5uzm F6X9XqS2KfIsUmeYzhk1Oy+lFqA9GSxHdxQsx2q1eDxFdaZ7BpktfZQvrjptX62SZwDE Iw0LNwteHIvOh2tSx+40qsZ/jV2HPgjynhQXXnUhC+lG3Ldj66+wOu7v/g2rpMynjWH2 gCYg== X-Gm-Message-State: AOAM530SouzKcSTIM6THFL1Y87thdRXWgWbInTJ2vZTXhJjWtx9ceBx2 Kd7GyWSydEPHGzNVJLYaUzQRJg== X-Google-Smtp-Source: ABdhPJzUyr55kpspPKtsm51ixev5yxaAVw0BfDdGYzbVo9u4HUr7ki378ANH0uISyYGI3dEifrntRw== X-Received: by 2002:a92:cccf:: with SMTP id u15mr25717127ilq.144.1629753111712; Mon, 23 Aug 2021 14:11:51 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id a17sm9352757ilm.27.2021.08.23.14.11.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Aug 2021 14:11:51 -0700 (PDT) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D8321B27-4971-4641-92AA-5082AB505F69" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Mon, 23 Aug 2021 17:11:49 -0400 In-Reply-To: <7f40b92699324c7588a8baab528aab36@bell.ca> Cc: "ecrit@ietf.org" To: "Caron, Guy" References: <7f40b92699324c7588a8baab528aab36@bell.ca> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: XML vs RelaxNG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 21:11:59 -0000 --Apple-Mail=_D8321B27-4971-4641-92AA-5082AB505F69 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 https://mailarchive.ietf.org/arch/msg/ecrit/oTPSzxsLp3YNy8J6HOwYjxdx1bI/ If we don=E2=80=99t deprecate the RelaxNG schema, shouldn=E2=80=99t = extensions have to provide Relax NG? That=E2=80=99s my setf serving = reason to deprecate it. I guess we could not actually deprecate it, = but normatively update 5222 to say that extensions should reference the = xml schema. Brian > On Aug 23, 2021, at 4:59 PM, Caron, Guy wrote: >=20 > If you refer to general comments made in the early days of LoST, some = 15 years ago, I guess time tells that RelaxNG did not ramp up as = expected. > =20 > I can=E2=80=99t find comments on the ECRIT list specific to = planned-changes asking for XML schemas to be informative while updating = RFC5222. > =20 > I agree with your sentiment that XML schemas should be a normative = alternative (i.e., does not deprecates) to RelaxNG. > =20 > Besides, by not providing RelaxNG equivalents for the extensions, = isn=E2=80=99t that what you are doing anyway? > =20 > Thanks, > =20 > Guy > =20 > De : Brian Rosen =20 > Envoy=C3=A9 : 23 ao=C3=BBt 2021 16:37 > =C3=80 : Caron, Guy > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: XML vs RelaxNG > =20 > We have had comments suggesting it be non normative, which is why it = says what it does now.=20 > =20 > My personal view is that it should replace the Relax NG schema, and = any subsequent changes and extensions should only reference this one. No = one that I know uses the Relax NG schema one way or another they get an = xml schema and use that.=20 > =20 > But I will go with whatever the consensus is =20 > =20 > Brian > =20 > On Mon, Aug 23, 2021 at 4:32 PM Caron, Guy > wrote: > In section 7, the replacement XML schema is qualified as an = =E2=80=9Cinformative alternative=E2=80=9D however, the text in the Intro = states =E2=80=9CAlternative schemas have been circulated, which is = undesirable, as they may not be in conformance to the RelaxNG schema in = [RFC5222]. This document provides an XML schema that replaces the = RelaxNG schema. It can be used by any implementation interchangeably = with the RelaxNG schema.=E2=80=9D > =20 > The latter seems to indicate that the XML schema in section 7 is a = normative alternative rather than an informative one. > =20 > I think this is what we want but the text must be adjusted = accordingly. > =20 > Thanks, > =20 > Guy > External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints --Apple-Mail=_D8321B27-4971-4641-92AA-5082AB505F69 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 https://mailarchive.ietf.org/arch/msg/ecrit/oTPSzxsLp3YNy8J6HOw= Yjxdx1bI/

If we = don=E2=80=99t deprecate the RelaxNG schema, shouldn=E2=80=99t extensions = have to provide Relax NG?   That=E2=80=99s my setf serving reason = to deprecate it.   I guess we could not actually deprecate it, but = normatively update 5222 to say that extensions should reference the xml = schema.

Brian



On Aug 23, 2021, at 4:59 PM, Caron, Guy = <g.caron@bell.ca> wrote:

If you refer to general = comments made in the early days of LoST, some 15 years ago, I guess time = tells that RelaxNG did not ramp up as expected.
 
I = can=E2=80=99t find comments on the ECRIT list specific to = planned-changes asking for XML schemas to be informative while updating = RFC5222.
 
I agree with your sentiment that XML schemas should be a = normative alternative (i.e., does not deprecates) to RelaxNG.
 
Besides, by not providing RelaxNG equivalents for the = extensions, isn=E2=80=99t that what you are doing anyway?
 
Thanks,
 
Guy
 
De : Brian Rosen = <br@brianrosen.net> 
Envoy=C3=A9 : 23 ao=C3=BBt 2021 16:37
=C3=80 : Caron, Guy = <g.caron@bell.ca>
Cc : ecrit@ietf.org
Objet : [EXT]Re: = lost-planned-changes-04: XML vs RelaxNG
 
We have had comments = suggesting it be non normative, which is why it says what it does = now. 
 
My personal view is that it should = replace the Relax NG schema, and any subsequent changes and extensions = should only reference this one. No one that I know uses the Relax NG = schema one way or another they get an xml schema and use that. 
 
But I will = go with whatever the consensus is  
 
Brian
 
On Mon, Aug = 23, 2021 at 4:32 PM Caron, Guy <g.caron@bell.ca> wrote:
In = section 7, the replacement XML schema is qualified as an =E2=80=9Cinformat= ive alternative=E2=80=9D however, the text in the Intro states = =E2=80=9CAlternative schemas have been circulated, which is undesirable, = as they may not be in conformance to the RelaxNG schema in [RFC5222]. = This document provides an XML schema that replaces the RelaxNG schema. = It can be used by any implementation interchangeably with the RelaxNG = schema.=E2=80=9D
 
The = latter seems to indicate that the XML schema in section 7 is a normative = alternative rather than an informative one.
 
I think this is what we want = but the text must be adjusted accordingly.
 
Thanks,
 
Guy
External Email: Please use caution when = opening links and attachments / Courriel externe: Soyez prudent avec les = liens et documents = joints

= --Apple-Mail=_D8321B27-4971-4641-92AA-5082AB505F69-- From nobody Mon Aug 23 14:21:58 2021 Return-Path: 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 59F5C3A1B41 for ; Mon, 23 Aug 2021 14:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, 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.20150623.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 6TP5SpnKgcMQ for ; Mon, 23 Aug 2021 14:21:51 -0700 (PDT) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 29B223A1B3F for ; Mon, 23 Aug 2021 14:21:51 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id x5so18478603ill.3 for ; Mon, 23 Aug 2021 14:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=8J9LMvoduU3uOs8tA2ZZUwIbaVo5viz0IszgGT10pII=; b=S2SKJLNpt3zM1miK8tJw6x20WLRUAoE38JUDkLsC9opqjDinT6CgI7XiECDq8K6OiM 7x6UcPrqO2DpwYdkrWu+qpqCI+bcD7FK2vqouIX3bPzYJgoomMUcR34/HcAXo+5bDtXQ MsP1geG9sZCP0O9+9p/kErweLghALHU+2lg0BVMBGoKay9d7+rXJT1x2bPY809FJGs9+ gPwolKz6+UJ38yoBKgwtzz/3p3z4nYRZYoCADfHIZVfWlTTwEfGYFm4g0T3E4V6chKl6 zyVw/Azn9UW2qnBrk2ohbThIIa0jxgdf6uN/BDw42+/dx61B/Cg69N7h3j5353J88elM zU9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=8J9LMvoduU3uOs8tA2ZZUwIbaVo5viz0IszgGT10pII=; b=PBK4kDsIs1JHN/7N3JE8dOVaDREz5XIpBYeLm2vXqwO8tmY0YfLu9RF3v6DBOhF4Ef ftPXbvh8YpJqOdLRR7dz6zfXOnIQKNY3YeEbk1ZQd35nAOJr/5ilMMW/NeCW7OE7jr47 KgXnY878NFtuIqvya1Wfy06pLMDK5obCdhSZ5ulngiijXDeriOAiJvUCDLvjeXRGjPf+ ZjEAi01OFzYNemLXc5U3FdaU/IefAaAYQVUTxT3rcRyen4OdEyQJUegL1RaNPM/woJlR /661XImj8m0jHdWOhcwuZMUcOsudLDIsNHMr/G6T1stvn+K++VRLTpdpIcoMzIr1uqri xeCA== X-Gm-Message-State: AOAM532k0san0KCvo5w0ZzHmrYSOkiIUGi42yZD2gZ2YK8k4+AaKvfFn IU+OAE/h3/QBo+dvZnl5b+79gg== X-Google-Smtp-Source: ABdhPJylX6ITxPolpSzsx7ad+V+lW0ptOZL6p08llsaKlZtb6OeMQnKipdrFeaBt/FUNF5pWhhSBEg== X-Received: by 2002:a92:de0a:: with SMTP id x10mr25399023ilm.277.1629753709848; Mon, 23 Aug 2021 14:21:49 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id v5sm8708411iln.42.2021.08.23.14.21.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Aug 2021 14:21:49 -0700 (PDT) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_31561198-51A4-4C4A-9DF5-4C5959E09D6B" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Mon, 23 Aug 2021 17:21:47 -0400 In-Reply-To: <8bdda7ea7d004b4591ff715526d93a73@bell.ca> Cc: "ecrit@ietf.org" To: "Caron, Guy" References: <8bdda7ea7d004b4591ff715526d93a73@bell.ca> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 21:21:57 -0000 --Apple-Mail=_31561198-51A4-4C4A-9DF5-4C5959E09D6B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 validateLocation is an attribute, not an element, so I can=E2=80=99t = extend it. =20 There isn=E2=80=99t an actual requirement to tie plannedChange to = validateLocation. It may not make a lot of sense, but if you did it, = the LoST server would not return validation data, would retain the URI = and would send the notification if the record changed. Note my text = that the LoST server doesn=E2=80=99t store the LI - the notification is = =E2=80=9Csomething changed=E2=80=9D not =E2=80=9Cwhat you sent is = guaranteed to be invalid=E2=80=9D or even =E2=80=9Cone or more of the = elements you sent changed". I thought about changing the name of the = notification, but I didn=E2=80=99t do that. The practical use case = remains the same. Brian > On Aug 23, 2021, at 5:07 PM, Caron, Guy wrote: >=20 > Not all LoST server implementations perform location validations. When = location validation is requested by the client, it adds the = =E2=80=9CvalidateLocation=E2=80=9D attribute to the = element. > =20 > So the question is: Should =E2=80=9CplannedChange=E2=80=9D be bound to = =E2=80=9CvalidateLocation=E2=80=9D? > =20 > If you believe not, what would be the expected behaviour of a LoST = server receiving a element outside of a validation = request? > =20 > Thanks, > =20 > Guy --Apple-Mail=_31561198-51A4-4C4A-9DF5-4C5959E09D6B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 validateLocation is an attribute, not an element, so I = can=E2=80=99t extend it.  

There isn=E2=80=99t an actual requirement to tie = plannedChange to validateLocation.  It may not make a lot of sense, = but if you did it, the LoST server would not return validation data, = would retain the URI and would send the notification if the record = changed.  Note my text that the LoST server doesn=E2=80=99t store = the LI - the notification is =E2=80=9Csomething changed=E2=80=9D not = =E2=80=9Cwhat you sent is guaranteed to be invalid=E2=80=9D or even = =E2=80=9Cone or more of the elements you sent changed".  I thought = about changing the name of the notification, but I didn=E2=80=99t do = that.  The practical use case remains the same.

Brian

On Aug 23, 2021, at 5:07 PM, Caron, Guy <g.caron@bell.ca> = wrote:

Not all LoST server = implementations perform location validations. When location validation = is requested by the client, it adds the =E2=80=9CvalidateLocation=E2=80=9D= attribute to the <findService> element.
 
So = the question is: Should =E2=80=9CplannedChange=E2=80=9D be bound to = =E2=80=9CvalidateLocation=E2=80=9D?
 
If = you believe not, what would be the expected behaviour of a LoST server = receiving a <plannedChange> element outside of a validation = request?
 
Thanks,
 
Guy

= --Apple-Mail=_31561198-51A4-4C4A-9DF5-4C5959E09D6B-- From nobody Mon Aug 23 14:23:49 2021 Return-Path: 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 C8C813A1B70 for ; Mon, 23 Aug 2021 14:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, 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 8cmhRHGptV4M for ; Mon, 23 Aug 2021 14:23:29 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 53EA13A1B4E for ; Mon, 23 Aug 2021 14:23:29 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 23 Aug 2021 14:23:28 -0700 From: "Randall Gellens" To: "Caron, Guy" Cc: ecrit@ietf.org, "Brian Rosen" Date: Mon, 23 Aug 2021 14:23:27 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_93D715FD-786F-4206-A151-109046474000_=" Embedded-HTML: [{"HTML":[711, 2161], "plain":[380, 630], "uuid":"A3896798-5C81-4226-8C03-81880B441583"}] Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: XML vs RelaxNG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 21:23:46 -0000 --=_MailMate_93D715FD-786F-4206-A151-109046474000_= Content-Type: text/plain; format=flowed This is a good point; when I read the text, I interpreted it as "this is an official but informative alternative schema". In my suggested edits I have "Informal alternative schemas have been circulated", which makes for a more clear distinction between the official one in the document and the informal ones circulated. --Randall On 23 Aug 2021, at 13:32, Caron, Guy wrote: > In section 7, the replacement XML schema is qualified as an > "informative alternative" however, the text in the Intro states > "Alternative schemas have been circulated, which is undesirable, as > they may not be in conformance to the RelaxNG schema in [RFC5222]. > This document provides an XML schema that replaces the RelaxNG schema. > It can be used by any implementation interchangeably with the RelaxNG > schema." > > The latter seems to indicate that the XML schema in section 7 is a > normative alternative rather than an informative one. > > I think this is what we want but the text must be adjusted > accordingly. > > Thanks, > > Guy > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --=_MailMate_93D715FD-786F-4206-A151-109046474000_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">This is a good point; when I read the text, I interpreted = it as "this is an official but informative alternative schema". In my su= ggested edits I have "Informal alternative schemas have been circulated",= which makes for a more clear distinction between the official one in the= document and the informal ones circulated.

--Randall

On 23 Aug 2021, at 13:32, Caron, Guy wrote:

= In section 7, the replacement XML schema is qualified as an =E2=80=9Cinfo= rmative alternative=E2=80=9D however, the text in the Intro states =E2=80= =9CAlternative schemas have been circulated, which is undesirable, as the= y may not be in conformance to the RelaxNG schema in [RFC5222]. This document provides an XML schema= that replaces the RelaxNG schema. It can be used by any implementation i= nterchangeably with the RelaxNG schema.=E2=80=9D

= =C2=A0

= The latter seems to indicate that the XML schema in section 7 is a normat= ive alternative rather than an informative one.

= =C2=A0

= I think this is what we want but the text must be adjusted accordingly.

= =C2=A0

= Thanks,

= =C2=A0

= Guy

______________________= _________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

--=_MailMate_93D715FD-786F-4206-A151-109046474000_=-- From nobody Mon Aug 23 14:25:01 2021 Return-Path: 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 2B2703A1B89 for ; Mon, 23 Aug 2021 14:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=bell.ca 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 tcRkWfglgbVS for ; Mon, 23 Aug 2021 14:24:42 -0700 (PDT) Received: from ESA2-Wyn.bell.ca (esa2-wyn.bell.ca [67.69.243.180]) (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 A0F6A3A1B7E for ; Mon, 23 Aug 2021 14:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1629753882; x=1661289882; h=from:to:subject:date:message-id:mime-version; bh=vvpwDTsdwJ3/qV2roKc6o1i6HyzgwvWVahXuzjlsSLM=; b=fj4qfp+z+s00oNNM6eVzzFEwYVFNVrN28MzGmhqG1fgGsKk4oFSUt2Vq siw7+i0elcFXAD/1xsJQMlyX6iJuDg1Hh5cGQzpctx6DCS6jVbzfrK5NA BQpT6N4acBMOLH2GscRBfT4wCNEzE5JgH2mWK+KREKN6VQKN9jq2iqi4J CrX6YINCQW7iao79vpo+1vQASdmv5FpUi/ofnLhucYBBN4Fo/0L/bZdt0 x/vn+g6jf2JtOWD6h/VJlZpAybjttnqziWng8ALPi8IqDQuKkqyXkccNp GZ1cHKw1mYpzhsAPx41pcGRT9HfLKLFZlydNfBOUsWsxY8pXAvySR8jye A==; IronPort-SDR: Pjvr4J+/Uqy+YqIaMcc6RW3UqOmcJ1FaRItVy5DNh7R/BrZRm3fVAmJJIWo7KlZPxdqZcOoYzS Stg1pQrRQh9A== Received: from dm5czo-d01.bellca.int.bell.ca (HELO DG6MBX01-WYN.bell.corp.bce.ca) ([198.235.102.33]) by esa02corp-wyn.bell.corp.bce.ca with ESMTP; 23 Aug 2021 17:24:41 -0400 Received: from DG12MBX03-WYN.bell.corp.bce.ca (142.182.18.48) by DG6MBX01-WYN.bell.corp.bce.ca (142.182.18.36) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 23 Aug 2021 17:24:41 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX03-WYN.bell.corp.bce.ca (142.182.18.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Mon, 23 Aug 2021 17:24:40 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Mon, 23 Aug 2021 17:24:40 -0400 From: "Caron, Guy" To: Brian Rosen , "ecrit@ietf.org" Thread-Topic: lost-planned-changes-04: Locations are not always invalidated Thread-Index: AdeYZFeQ2SDl+s67TUyTfs68kd40mw== Date: Mon, 23 Aug 2021 21:24:40 +0000 Message-ID: Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.79] Content-Type: multipart/alternative; boundary="_000_df4f1c24a29047a3b97d393863c6a3dfbellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Ecrit] lost-planned-changes-04: Locations are not always invalidated X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 21:25:00 -0000 --_000_df4f1c24a29047a3b97d393863c6a3dfbellca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBuZXcgdmVyc2lvbiBpbnRyb2R1Y2VzIHZhcmlhYmlsaXR5IGluIHdoZXRoZXIgYSBsb2Nh dGlvbiBpcyBpbmRlZWQgaW52YWxpZGF0ZWQgb3Igbm90IGJ5IGEgY2hhbmdlLCB3aGljaCBJIGFn cmVlIHdpdGguDQoNCkdpdmVuIHRoaXMsIHRoZSBuYW1lcyDigJxsb2NhdGlvbkludmFsaWRhdGVk 4oCdIGFuZCDigJxpbnZhbGlkYXRlZEFzT2bigJ0gc2VlbSBtaXNsZWFkaW5nLiBTaG91bGQg4oCc aW52YWxpZGF0ZWTigJ0gYmUgY2hhbmdlZCB0byBzb21ldGhpbmcgbGlrZSDigJxJbXBhY3RlZOKA nT8NCg0KVGhhbmtzLA0KDQpHdXkNCg0KDQo= --_000_df4f1c24a29047a3b97d393863c6a3dfbellca_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUi1D QSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGlzIG5ldyB2ZXJzaW9uIGlu dHJvZHVjZXMgdmFyaWFiaWxpdHkgaW4gd2hldGhlciBhIGxvY2F0aW9uIGlzIGluZGVlZCBpbnZh bGlkYXRlZCBvciBub3QgYnkgYSBjaGFuZ2UsIHdoaWNoIEkgYWdyZWUNCiB3aXRoLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5HaXZlbiB0aGlzLCB0aGUgbmFtZXMg4oCcbG9jYXRpb25JbnZhbGlkYXRlZOKAnSBhbmQg4oCc aW52YWxpZGF0ZWRBc09m4oCdIHNlZW0gbWlzbGVhZGluZy4gU2hvdWxkIOKAnGludmFsaWRhdGVk 4oCdIGJlIGNoYW5nZWQgdG8NCiBzb21ldGhpbmcgbGlrZSDigJxJbXBhY3RlZOKAnT88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5HdXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_df4f1c24a29047a3b97d393863c6a3dfbellca_-- From nobody Mon Aug 23 14:26:59 2021 Return-Path: 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 3383E3A1B56 for ; Mon, 23 Aug 2021 14:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, 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 H6p3dTAyN1Dr for ; Mon, 23 Aug 2021 14:26:52 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D5FC63A1B54 for ; Mon, 23 Aug 2021 14:26:51 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 23 Aug 2021 14:26:51 -0700 From: "Randall Gellens" To: "Brian Rosen" Cc: "Caron, Guy" , ecrit@ietf.org Date: Mon, 23 Aug 2021 14:26:51 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: References: <8bdda7ea7d004b4591ff715526d93a73@bell.ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_54352B9F-2A51-493B-B6EE-416E04B73EC7_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[489, 4439], "plain":[158, 1212], "uuid":"D7D73743-E72F-411F-86DA-9D44C9832B7D"}] Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 21:26:57 -0000 --=_MailMate_54352B9F-2A51-493B-B6EE-416E04B73EC7_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit In my suggested edits, I added clarifying text that the extension is only useful when validating. --Randall On 23 Aug 2021, at 14:21, Brian Rosen wrote: > validateLocation is an attribute, not an element, so I can’t extend > it. > > There isn’t an actual requirement to tie plannedChange to > validateLocation. It may not make a lot of sense, but if you did it, > the LoST server would not return validation data, would retain the URI > and would send the notification if the record changed. Note my text > that the LoST server doesn’t store the LI - the notification is > “something changed†not “what you sent is guaranteed to be > invalid†or even “one or more of the elements you sent changed". > I thought about changing the name of the notification, but I didn’t > do that. The practical use case remains the same. > > Brian > >> On Aug 23, 2021, at 5:07 PM, Caron, Guy wrote: >> >> Not all LoST server implementations perform location validations. >> When location validation is requested by the client, it adds the >> “validateLocation†attribute to the element. >> >> So the question is: Should “plannedChange†be bound to >> “validateLocation� >> >> If you believe not, what would be the expected behaviour of a LoST >> server receiving a element outside of a validation >> request? >> >> Thanks, >> >> Guy > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --=_MailMate_54352B9F-2A51-493B-B6EE-416E04B73EC7_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">In my suggested edits, I added clarifying text that the ex= tension is only useful when validating.

--Randall

On 23 Aug 2021, at 14:21, Brian Rosen wrote:

validateLocation is an attribute, not an e= lement, so I can=E2=80=99t extend it.  

There isn=E2=80=99t an actual requirement to tie = plannedChange to validateLocation.  It may not make a lot of sense, = but if you did it, the LoST server would not return validation data, woul= d retain the URI and would send the notification if the record changed. &= nbsp;Note my text that the LoST server doesn=E2=80=99t store the LI - the= notification is =E2=80=9Csomething changed=E2=80=9D not =E2=80=9Cwhat yo= u sent is guaranteed to be invalid=E2=80=9D or even =E2=80=9Cone or more = of the elements you sent changed".  I thought about changing the nam= e of the notification, but I didn=E2=80=99t do that.  The practical = use case remains the same.

Brian

--=_MailMate_54352B9F-2A51-493B-B6EE-416E04B73EC7_=-- From nobody Mon Aug 23 14:27:15 2021 Return-Path: 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 6D13E3A1BA2 for ; Mon, 23 Aug 2021 14:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.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 pR2roIYzNp5e for ; Mon, 23 Aug 2021 14:27:02 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 D18013A1B71 for ; Mon, 23 Aug 2021 14:27:01 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id n24so23674823ion.10 for ; Mon, 23 Aug 2021 14:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5rU/paXLbWxEZ5seVM/7MCV8g/sCpdH6uFKyk6S+GTg=; b=0enFtBbUCwFPoKdqb9PU3AP4PF21C7u7bfa7GOvtwKuCa5S8R6IdHItjJWFr2MPi7F gFWu99468sgsL7u44CClkUPdZKmFSsZMH4GDSiPwQQ0YxtT6bQ+MoyC7esV1AYc7ftEf E6o45SQuKPvXY34pNH16+DKIWtallem9ehXxxG6C9GD/sp7f149zPFYTl3MGf47dpg1V tHssdLNWoCxf2zOjp4XgIxMqRZezDed99RjKJNNqe5xZg0yzyDVSgUJFjJZF3jTspaFm Aq7JXobfpdhZECB/4m3kX3r1CvqvtnrifcaxO6DbPG/Qhc+poeBOfDvuHpb/z7MkyRtk YarQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=5rU/paXLbWxEZ5seVM/7MCV8g/sCpdH6uFKyk6S+GTg=; b=S+SW8qArPj5GG8diyhIc6rE+p7bq3Q4Mi1XP7MJLuuPiKTa6DAZ6qMrlKFJtSLKCW8 MApBckcD/yqtEbd84XrF34wJnGhTIZUuvD8KtvbFBw0OL5iXVYSc7wGjA5hiPL1Dc8Wo cZqDxnLucLNsQZkjixG4I2JnYfNJFqZxdNWDw9ICql4hivXfEKTY5RP/9gkCWclTxsEk N24Pr5v5MzzAVG1XDDdcBSmrNyZXeVtPMVFyZQxu9103907QL1qYIH+GYFJZ0zWMfV2H QncdzRGpe5+g3IKfXJD3HlcUB+rcQYp11IXXOf6ac/jPp8CLVpUj7LGkWJHjBBjVSFFm 7RDQ== X-Gm-Message-State: AOAM531U7a2RcJE+oTbYgb9LCgkWbi/SzzFSzudOhv1D6bsM3ruDs2/z 4pT7hfM+zoDqlYIH1v3gGhZnpg== X-Google-Smtp-Source: ABdhPJyLjKjpa205CJAJE9Wu1+DnEufAEbOxPv7gUO14L5v7LpZ6t36AtdDzZyudmSqTdSC0tiHFXg== X-Received: by 2002:a5d:94c6:: with SMTP id y6mr29011238ior.202.1629754019433; Mon, 23 Aug 2021 14:26:59 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id i3sm8562684ilu.46.2021.08.23.14.26.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Aug 2021 14:26:58 -0700 (PDT) From: Brian Rosen Message-Id: <75190478-2914-47FE-99CB-968D90E14E86@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_4B44E23F-0B0F-4E03-877C-992886222202" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Mon, 23 Aug 2021 17:26:57 -0400 In-Reply-To: Cc: "Caron, Guy" , ecrit@ietf.org To: Randall Gellens References: X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: XML vs RelaxNG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 21:27:14 -0000 --Apple-Mail=_4B44E23F-0B0F-4E03-877C-992886222202 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I don=E2=80=99t really care what happens to the RelaxNG schema. I do care if we have to create RelaxNG extensions What is the argument for keeping RelaxNG? Brian > On Aug 23, 2021, at 5:23 PM, Randall Gellens = wrote: >=20 > This is a good point; when I read the text, I interpreted it as "this = is an official but informative alternative schema". In my suggested = edits I have "Informal alternative schemas have been circulated", which = makes for a more clear distinction between the official one in the = document and the informal ones circulated. >=20 > --Randall >=20 > On 23 Aug 2021, at 13:32, Caron, Guy wrote: >=20 > In section 7, the replacement XML schema is qualified as an = =E2=80=9Cinformative alternative=E2=80=9D however, the text in the Intro = states =E2=80=9CAlternative schemas have been circulated, which is = undesirable, as they may not be in conformance to the RelaxNG schema in = [RFC5222]. This document provides an XML schema that replaces the = RelaxNG schema. It can be used by any implementation interchangeably = with the RelaxNG schema.=E2=80=9D > =20 > The latter seems to indicate that the XML schema in section 7 is a = normative alternative rather than an informative one. > =20 > I think this is what we want but the text must be adjusted = accordingly. > =20 > Thanks, > =20 > Guy > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit = --Apple-Mail=_4B44E23F-0B0F-4E03-877C-992886222202 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = don=E2=80=99t really care what happens to the RelaxNG schema.

I do care if we have to = create RelaxNG extensions

What is the argument for keeping RelaxNG?

Brian

On Aug 23, 2021, at 5:23 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

This = is a good point; when I read the text, I interpreted it as "this is an = official but informative alternative schema". In my suggested edits I = have "Informal alternative schemas have been circulated", which makes = for a more clear distinction between the official one in the document = and the informal ones circulated.

--Randall

On 23 Aug 2021, at = 13:32, Caron, Guy wrote:

In section 7, the replacement = XML schema is qualified as an =E2=80=9Cinformative alternative=E2=80=9D = however, the text in the Intro states =E2=80=9CAlternative schemas have = been circulated, which is undesirable, as they may not be in conformance to the RelaxNG schema in [RFC5222]. This document provides an XML = schema that replaces the RelaxNG schema. It can be used by any = implementation interchangeably with the RelaxNG = schema.=E2=80=9D

 

The latter seems to indicate that the XML = schema in section 7 is a normative alternative rather than an = informative one.

 

I think this is what we want but the text must = be adjusted accordingly.

 

Thanks,

 

Guy
=

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit


= --Apple-Mail=_4B44E23F-0B0F-4E03-877C-992886222202-- From nobody Mon Aug 23 14:32:32 2021 Return-Path: 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 DB6803A1BE4 for ; Mon, 23 Aug 2021 14:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, 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.20150623.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 i5hnh6lzIUDd for ; Mon, 23 Aug 2021 14:32:26 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 00CBB3A1BE1 for ; Mon, 23 Aug 2021 14:32:26 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id f6so16126101iox.0 for ; Mon, 23 Aug 2021 14:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=YdxiD/oOTROWtWthhrUhJrydRb89WgDwbyF3cehD/hY=; b=TfhPF78LoIWF2JdM299CDVuGCyMtMb/2Z+DrHIF6czf1odk1voGKH7dNwdzS5d0Erh kBI1LLUySAy7wjfG48/V5hNoZrTxOmzYd5MP9d5dG2SN24XsusoVh5M3zZyVJa8FPCuE SNgHRkHq+WEf9hcqJjeYeJAywZDuV9vxs5x/wfaXoyDF4IUVeBdvgRfo1MFwGMSfNrUK kxh/bUV1kO6kDxOnzw5A8WKzII5Fz/dOavsdry/uaeWeavr757zUu4hUtahiDJR/Qyqs 37CqKv/XQwKZkytxyRYSlAmiEZbxS3sO3uWJTV2R4VTUhab5d/7AGm9CYjyy6MGbM6D0 qbTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=YdxiD/oOTROWtWthhrUhJrydRb89WgDwbyF3cehD/hY=; b=K92lWVRl+tQJq8RwR3k28aYaykMw+eviB4RZzl1NAyrhzIKYDjeOun6BxlSaDWEPUS 3kUxADFzKeO5d3nhb4Y76A6aIw/OGWhncDw1nx6VnX5Yr8y0p9vHMk8o0TvvExHubWoD hNfv0rNDeqMB319OfFusUWH1IhicgOZz8gEosgIOZ8pOVT9bC+mg0ZRtk5eyoqDTFBkj bsauUFvkerMUSh4lSi379fwO+R8eWqRs/Yeu8DZQZFdHAg5ZwkjimBGMVpE2iofdHhuJ JhD2wLLhHxS1M2ReuCXNSPZ2S+FTT1VGI4wfzAE5uTG2/cfMv6L7pUn/UV1xnxnzBMuC dTjQ== X-Gm-Message-State: AOAM531dngvAvEmmXJy3jp8Ats7wJm7WXNkvt9ffOcIbOfEsQzeUzE2+ 9fq+4nsUO4mG/0z63ZPqlNplOg== X-Google-Smtp-Source: ABdhPJyDU6i15UEhPSaBv3J4Q7Qonym+OpljwUf4Zj50OzyQaCbMXLe58f0JfJ7DK8tT0NVO2fcj0Q== X-Received: by 2002:a5d:8986:: with SMTP id m6mr27843289iol.87.1629754344645; Mon, 23 Aug 2021 14:32:24 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id q14sm9017185ilj.34.2021.08.23.14.32.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Aug 2021 14:32:24 -0700 (PDT) From: Brian Rosen Message-Id: <23790DB9-2731-46D5-B7A3-9B62D8B5DD63@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_BFEEC41E-0966-45E7-B74C-02755525A43A" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Mon, 23 Aug 2021 17:32:22 -0400 In-Reply-To: Cc: "ecrit@ietf.org" To: "Caron, Guy" References: X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: Locations are not always invalidated X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 21:32:31 -0000 --Apple-Mail=_BFEEC41E-0966-45E7-B74C-02755525A43A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 One of the reasons I didn=E2=80=99t do this is the name of the draft = should change. But of course, I will do whatever consensus of the work group is. Brian > On Aug 23, 2021, at 5:24 PM, Caron, Guy wrote: >=20 > This new version introduces variability in whether a location is = indeed invalidated or not by a change, which I agree with. > =20 > Given this, the names =E2=80=9ClocationInvalidated=E2=80=9D and = =E2=80=9CinvalidatedAsOf=E2=80=9D seem misleading. Should = =E2=80=9Cinvalidated=E2=80=9D be changed to something like = =E2=80=9CImpacted=E2=80=9D? > =20 > Thanks, > =20 > Guy --Apple-Mail=_BFEEC41E-0966-45E7-B74C-02755525A43A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 One = of the reasons I didn=E2=80=99t do this is the name of the draft should = change.

But of = course, I will do whatever consensus of the work group is.

Brian


On Aug 23, 2021, at 5:24 PM, Caron, Guy = <g.caron@bell.ca> = wrote:

This new version = introduces variability in whether a location is indeed invalidated or = not by a change, which I agree with.
 
Given this, the names =E2=80=9ClocationInvalidated=E2=80=9D = and =E2=80=9CinvalidatedAsOf=E2=80=9D seem misleading. Should = =E2=80=9Cinvalidated=E2=80=9D be changed to something like = =E2=80=9CImpacted=E2=80=9D?
 
Thanks,
 
Guy

= --Apple-Mail=_BFEEC41E-0966-45E7-B74C-02755525A43A-- From nobody Mon Aug 23 14:33:27 2021 Return-Path: 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 00D213A1BF6 for ; Mon, 23 Aug 2021 14:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=bell.ca 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 WQ11cWC7mt1t for ; Mon, 23 Aug 2021 14:33:19 -0700 (PDT) Received: from ESA3-Dor.bell.ca (esa3-dor.bell.ca [204.101.223.60]) (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 E204B3A1BF2 for ; Mon, 23 Aug 2021 14:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1629754398; x=1661290398; h=from:to:subject:date:message-id:mime-version; bh=FHLpjTZgaz7PvQQvw5/NkXgHOQQZYdbgn8YZGPDQsZ8=; b=QbvzJrkWmz6ufK3MlQlBwpYmaIi/5d6T6vlKiDz5aCTe5SbbbddEw7/c 6zBAjGF6Zn0HchLz+0YZqOyag5ihAZPQl48wsmER0AImvcv/L991f2qlw oleY3PmzPhcTi+YUxzsSnVeu3bKwcxLFvHRsh5Az37SNiieScYdb5+9Cg yWruS3Jozt0JVqhZUyo6BCCkm6Z6lMlIJeuAH8FN00XPtmF4+fdsGjja4 thqaVVnDpFf/HLUaFkjdR/upxyjCy0MICKRfukhRBXremQefO/VHBZhfS GW26r+EtriQjUCy4wmap+mHDjL3uYraacobkq8DvrGBz/SSxvwFOE5oJA w==; IronPort-SDR: t6zJuzawFgp/fdm/QaD4IZ1/0w/PqZ2M5TzQPHlSoAPIwgOM6bMBHQzQR0AhNn0Kh+foG1BErx mKpboC33qvvQ== Received: from dc5cmz-d00.bellca.int.bell.ca (HELO DG4MBX04-WYN.bell.corp.bce.ca) ([198.235.121.231]) by esa03corp-dor.bell.corp.bce.ca with ESMTP; 23 Aug 2021 17:33:17 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG4MBX04-WYN.bell.corp.bce.ca (142.182.18.30) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 23 Aug 2021 17:33:16 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Mon, 23 Aug 2021 17:33:17 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Mon, 23 Aug 2021 17:33:17 -0400 From: "Caron, Guy" To: Brian Rosen , "ecrit@ietf.org" Thread-Topic: lost-planned-changes-04: XML schema does not validate Thread-Index: AdeYZdWljDZXrsOZSNaWz+LTuj7rkw== Date: Mon, 23 Aug 2021 21:33:17 +0000 Message-ID: <57959e67d4774ac98e8e2526a93a5b93@bell.ca> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.79] Content-Type: multipart/alternative; boundary="_000_57959e67d4774ac98e8e2526a93a5b93bellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Ecrit] lost-planned-changes-04: XML schema does not validate X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 21:33:25 -0000 --_000_57959e67d4774ac98e8e2526a93a5b93bellca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBwYXNzZWQgdGhlIHByb3Bvc2VkIExvU1QgWE1MIHNjaGVtYSB0aHJvdWdoIGEgdmFsaWRhdG9y IGFuZCBvbmUgZXJyb3IgcG9wcGVkIHVwOg0KDQo8eHM6ZWxlbWVudCBuYW1lPSJsb2NhdGlvblBy b2ZpbGVVbnJlY29nbml6ZWQiPiB0eXBlPSJiYXNpY0V4Y2VwdGlvbiIvPg0KDQpTaG91bGQgYmU6 DQoNCjx4czplbGVtZW50IG5hbWU9ImxvY2F0aW9uUHJvZmlsZVVucmVjb2duaXplZCIgdHlwZT0i YmFzaWNFeGNlcHRpb24iLz4NCg0KVGhhbmtzLA0KDQpHdXkNCg0K --_000_57959e67d4774ac98e8e2526a93a5b93bellca_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30N CnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSLUNBIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgcGFzc2VkIHRoZSBwcm9wb3NlZCBMb1NUIFhNTCBz Y2hlbWEgdGhyb3VnaCBhIHZhbGlkYXRvciBhbmQgb25lIGVycm9yIHBvcHBlZCB1cDo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDoxMDkuMzVwdDttYXJnaW4tYm90dG9tOjBj bTttYXJnaW4tbGVmdDo3MS4zNXB0O21hcmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWluZGVudDot NDcuNTVwdDtsaW5lLWhlaWdodDoxMDUlO3RleHQtYXV0b3NwYWNlOm5vbmUiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS41cHQ7bGluZS1oZWlnaHQ6MTA1JTtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ Jmx0O3hzOmVsZW1lbnQgbmFtZT0mcXVvdDtsb2NhdGlvblByb2ZpbGVVbnJlY29nbml6ZWQmcXVv dDsmZ3Q7IHR5cGU9JnF1b3Q7YmFzaWNFeGNlcHRpb24mcXVvdDsvJmd0Ozwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtsaW5lLWhlaWdodDoxMDUlO2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+U2hvdWxkIGJlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJp Z2h0OjEwOS4zNXB0O21hcmdpbi1ib3R0b206MGNtO21hcmdpbi1sZWZ0OjcxLjM1cHQ7bWFyZ2lu LWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50Oi00Ny41NXB0O2xpbmUtaGVpZ2h0OjEwNSU7dGV4 dC1hdXRvc3BhY2U6bm9uZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5 LjVwdDtsaW5lLWhlaWdodDoxMDUlO2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbHQ7eHM6ZWxlbWVudCBuYW1lPSZxdW90O2xv Y2F0aW9uUHJvZmlsZVVucmVjb2duaXplZCZxdW90OyB0eXBlPSZxdW90O2Jhc2ljRXhjZXB0aW9u JnF1b3Q7LyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5r cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkd1eTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_57959e67d4774ac98e8e2526a93a5b93bellca_-- From nobody Mon Aug 23 14:35:42 2021 Return-Path: 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 7231C3A1C24 for ; Mon, 23 Aug 2021 14:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, 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.20150623.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 kn4lB6U8bVYe for ; Mon, 23 Aug 2021 14:35:35 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 866CC3A1C1A for ; Mon, 23 Aug 2021 14:35:35 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id y18so8081212ioc.1 for ; Mon, 23 Aug 2021 14:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=1t+44t+pyr7DcS+ZYzLmfL+Y5vTHCAH4+uKVS3mIK9M=; b=j2SvtOc5q/ErNOqlaPG+xTAc4zk/74TV4lYAeiSH3TAirh9PwIdtXiliDxWtdgxEkc zd6I6Aw2xsncnlt2HTB2YTv1vIbREoqafnTpiPXwVh72Y4knZ0zZn5J9t6rz+Gmp3O6F y4O+iLvhyUf3p8LWqo53h7Es2MuFIoy/GT8IhW26ob1Zuby6vP1uZ14diOnKNRcRhh9l yG7N2cmOO3K4zIXrjrisYHviujbUuA3lEwljY3yeT2Y8OQXo/jb0pW+KcfyLxKGsPeWG OBkNrrnL4GMZcQ8NCzdtc8MhaaFd3jYJkFyoLKCzIKGrfL3h9/FodXWysAP4KXhMe5Q6 PGVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=1t+44t+pyr7DcS+ZYzLmfL+Y5vTHCAH4+uKVS3mIK9M=; b=nPCCBItn656YFVEwNOYKKdRJXbEunVs6K8JsU3qTxogs5WuIxqO99/nIEWV6TlJtlC T4jmzGosIQ7vdR0pnC+WVAdM91otkVnMA8iuKkOp/9lkROGjLmx74jBk1fWt2tk2V6rm EKh9bzvaMRBlcTKK+/FPNzNgafuxG/pletBWntl2lxokX69kyLtAwgRB5h+y+PBmaaKL QVG9TfmxPBMueKCnrt4p4xcYtlz2Rmau+81hsz+VtMps9lOYzuiW8HOADLJIYLbS2qpQ CWIWbibT5DeiqIrSguPmmldx7EekXLCIKOSLuarjCD93PwHPcNFwukzn5v5KBKGhywGD t/DQ== X-Gm-Message-State: AOAM532QEVVMTwxGT8CWeO0HqbjvRcn82yNKrsOs7eOJPNaYEOgKPPah B87t43JsXDzNucKW6s2DOvRq4Q== X-Google-Smtp-Source: ABdhPJy9LAnX8UWr55rHWfEavT7V0yLK4tiSxYdK7hzyPnGysd64iiQ2Y3damJKyz4mKLqNhv6WNoQ== X-Received: by 2002:a05:6638:168f:: with SMTP id f15mr31378256jat.85.1629754529982; Mon, 23 Aug 2021 14:35:29 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id a4sm8934189ioe.19.2021.08.23.14.35.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Aug 2021 14:35:29 -0700 (PDT) From: Brian Rosen Message-Id: <6CEB3DA8-3C4F-43C5-A0B1-3478B5D9EE5B@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_9AB47DC9-2A24-469D-83E2-A164FBA4FB8E" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Mon, 23 Aug 2021 17:35:28 -0400 In-Reply-To: <57959e67d4774ac98e8e2526a93a5b93@bell.ca> Cc: "ecrit@ietf.org" To: "Caron, Guy" References: <57959e67d4774ac98e8e2526a93a5b93@bell.ca> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: XML schema does not validate X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 21:35:41 -0000 --Apple-Mail=_9AB47DC9-2A24-469D-83E2-A164FBA4FB8E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Huh. At one point I did run it through a validator. I must have done = an inadvertent edit. I will fix it. Thanks for finding it. Brian > On Aug 23, 2021, at 5:33 PM, Caron, Guy wrote: >=20 > I passed the proposed LoST XML schema through a validator and one = error popped up: > =20 > = type=3D"basicException"/> > =20 > Should be: > =20 > > =20 > Thanks, > =20 > Guy --Apple-Mail=_9AB47DC9-2A24-469D-83E2-A164FBA4FB8E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Huh. =  At one point I did run it through a validator.  I must have = done an inadvertent edit.  I will fix it.  Thanks for finding = it.

Brian


On Aug 23, 2021, at 5:33 PM, Caron, Guy = <g.caron@bell.ca> = wrote:

I passed the proposed = LoST XML schema through a validator and one error popped up:
 
<xs:element = name=3D"locationProfileUnrecognized"> = type=3D"basicException"/>
 
Should be:
 
<xs:element name=3D"locationProfileUnrecognized"= type=3D"basicException"/>
 
Thanks,
 
Guy

= --Apple-Mail=_9AB47DC9-2A24-469D-83E2-A164FBA4FB8E-- From nobody Mon Aug 23 14:35:55 2021 Return-Path: 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 3EDE33A1C3F for ; Mon, 23 Aug 2021 14:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=bell.ca 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 zTmLBV-CDgfA for ; Mon, 23 Aug 2021 14:35:43 -0700 (PDT) Received: from ESA1-Wyn.bell.ca (esa1-wyn.bell.ca [67.69.243.161]) (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 4F1033A1C2A for ; Mon, 23 Aug 2021 14:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1629754543; x=1661290543; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=mO9xxC50ud5rsY28H5pYgZ2tGBl57zcKLsBlU7gpuo0=; b=A0LkjKziwFIIYQBFKW/746XtTvS+/mXOgnmdoMM9jSe9d7srR+agfn40 kvZLoYf1reIfRvlM4jKy/6sJhcm5r2ZR58noQv3/OiFUr7n9M5cSRjZLo C0HtU8y3vAFaDXjTIwkN4lI0s5bUZm0gqwAndnksxyC2D/gJdKCdhu1kY OyKu6lw96RBv5Xn7/vWLvnKclcFLDxh9w8yBvs3ld+jxXL/iuNPT6GjCR v3h6S5dPESPfLEyyDQkUEinvq2BlXKpWD33pM+ltduXPNHRpfKsTgCCd8 /9Lfdyq48QepnaQGrCv15no9s8xfJFpi7azW/4rXKYwo/XKEiZJFOF3I0 Q==; IronPort-SDR: rJorAjbTLWlYkPMz+bEvKIXTldemRmtxMgNfhsJej0gxUvGaBo4QAgoqRQLlO3lZbd+OyPAS8c g/sZieA87iIw== Received: from dm5cch-d00.bellca.int.bell.ca (HELO DG3MBX01-WYN.bell.corp.bce.ca) ([198.235.102.30]) by esa01corp-wyn.bell.corp.bce.ca with ESMTP; 23 Aug 2021 17:35:42 -0400 Received: from DG12MBX02-WYN.bell.corp.bce.ca (142.182.18.47) by DG3MBX01-WYN.bell.corp.bce.ca (142.182.18.23) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 23 Aug 2021 17:35:41 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX02-WYN.bell.corp.bce.ca (142.182.18.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Mon, 23 Aug 2021 17:35:41 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Mon, 23 Aug 2021 17:35:41 -0400 From: "Caron, Guy" To: Brian Rosen CC: "ecrit@ietf.org" Thread-Topic: [EXT]Re: lost-planned-changes-04: Locations are not always invalidated Thread-Index: AdeYZFeQ2SDl+s67TUyTfs68kd40mwAI4sAAAAhW7BA= Date: Mon, 23 Aug 2021 21:35:41 +0000 Message-ID: References: <23790DB9-2731-46D5-B7A3-9B62D8B5DD63@brianrosen.net> In-Reply-To: <23790DB9-2731-46D5-B7A3-9B62D8B5DD63@brianrosen.net> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.79] Content-Type: multipart/alternative; boundary="_000_d9bbc311b8e0417dbb730255435aacd6bellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: Locations are not always invalidated X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 21:35:54 -0000 --_000_d9bbc311b8e0417dbb730255435aacd6bellca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IHNlZSB3aHkgdGhlIG5hbWUgb2YgdGhlIGRyYWZ0IHdvdWxkIGNoYW5nZS4gSXQg aXMgc3RpbGwgcGxhbm5lZCBjaGFuZ2VzIHRoYXQgYXJlIG5vdGlmaWVkLiBJdCBpcyBqdXN0IHRo ZSBhc3N1bXB0aW9uIHRoYXQgdGhlIG5vdGlmaWNhdGlvbiBpcyBhbHdheXMgYWJvdXQgYSBsb2Nh dGlvbiBiZWNvbWluZyBpbnZhbGlkIHRoYXQgY2hhbmdlcy4NCg0KVGhhbmtzLA0KDQpHdXkNCg0K RGUgOiBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ+DQpFbnZvecOpIDogMjMgYW/Du3Qg MjAyMSAxNzozMg0Kw4AgOiBDYXJvbiwgR3V5IDxnLmNhcm9uQGJlbGwuY2E+DQpDYyA6IGVjcml0 QGlldGYub3JnDQpPYmpldCA6IFtFWFRdUmU6IGxvc3QtcGxhbm5lZC1jaGFuZ2VzLTA0OiBMb2Nh dGlvbnMgYXJlIG5vdCBhbHdheXMgaW52YWxpZGF0ZWQNCg0KT25lIG9mIHRoZSByZWFzb25zIEkg ZGlkbuKAmXQgZG8gdGhpcyBpcyB0aGUgbmFtZSBvZiB0aGUgZHJhZnQgc2hvdWxkIGNoYW5nZS4N Cg0KQnV0IG9mIGNvdXJzZSwgSSB3aWxsIGRvIHdoYXRldmVyIGNvbnNlbnN1cyBvZiB0aGUgd29y ayBncm91cCBpcy4NCg0KQnJpYW4NCg0KDQoNCk9uIEF1ZyAyMywgMjAyMSwgYXQgNToyNCBQTSwg Q2Fyb24sIEd1eSA8Zy5jYXJvbkBiZWxsLmNhPG1haWx0bzpnLmNhcm9uQGJlbGwuY2E+PiB3cm90 ZToNCg0KVGhpcyBuZXcgdmVyc2lvbiBpbnRyb2R1Y2VzIHZhcmlhYmlsaXR5IGluIHdoZXRoZXIg YSBsb2NhdGlvbiBpcyBpbmRlZWQgaW52YWxpZGF0ZWQgb3Igbm90IGJ5IGEgY2hhbmdlLCB3aGlj aCBJIGFncmVlIHdpdGguDQoNCkdpdmVuIHRoaXMsIHRoZSBuYW1lcyDigJxsb2NhdGlvbkludmFs aWRhdGVk4oCdIGFuZCDigJxpbnZhbGlkYXRlZEFzT2bigJ0gc2VlbSBtaXNsZWFkaW5nLiBTaG91 bGQg4oCcaW52YWxpZGF0ZWTigJ0gYmUgY2hhbmdlZCB0byBzb21ldGhpbmcgbGlrZSDigJxJbXBh Y3RlZOKAnT8NCg0KVGhhbmtzLA0KDQpHdXkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkV4dGVybmFsIEVtYWlsOiBQbGVhc2UgdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxp bmtzIGFuZCBhdHRhY2htZW50cyAvIENvdXJyaWVsIGV4dGVybmU6IFNveWV6IHBydWRlbnQgYXZl YyBsZXMgbGllbnMgZXQgZG9jdW1lbnRzIGpvaW50cw0K --_000_d9bbc311b8e0417dbb730255435aacd6bellca_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5t c29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFt ZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUi1DQSIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGRvbuKAmXQgc2VlIHdoeSB0aGUgbmFtZSBvZiB0aGUg ZHJhZnQgd291bGQgY2hhbmdlLiBJdCBpcyBzdGlsbCBwbGFubmVkIGNoYW5nZXMgdGhhdCBhcmUg bm90aWZpZWQuIEl0IGlzIGp1c3QgdGhlIGFzc3VtcHRpb24NCiB0aGF0IHRoZSBub3RpZmljYXRp b24gaXMgYWx3YXlzIGFib3V0IGEgbG9jYXRpb24gYmVjb21pbmcgaW52YWxpZCB0aGF0IGNoYW5n ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+R3V5PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxh bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRlIiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+IEJyaWFuIFJvc2VuICZsdDtickBicmlhbnJvc2VuLm5ldCZndDsNCjxicj4NCjxi PkVudm95w6kmbmJzcDs6PC9iPiAyMyBhb8O7dCAyMDIxIDE3OjMyPGJyPg0KPGI+w4AmbmJzcDs6 PC9iPiBDYXJvbiwgR3V5ICZsdDtnLmNhcm9uQGJlbGwuY2EmZ3Q7PGJyPg0KPGI+Q2MmbmJzcDs6 PC9iPiBlY3JpdEBpZXRmLm9yZzxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gW0VYVF1SZTogbG9z dC1wbGFubmVkLWNoYW5nZXMtMDQ6IExvY2F0aW9ucyBhcmUgbm90IGFsd2F5cyBpbnZhbGlkYXRl ZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uZSBvZiB0 aGUgcmVhc29ucyBJIGRpZG7igJl0IGRvIHRoaXMgaXMgdGhlIG5hbWUgb2YgdGhlIGRyYWZ0IHNo b3VsZCBjaGFuZ2UuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5CdXQgb2YgY291cnNlLCBJIHdpbGwgZG8gd2hhdGV2ZXIgY29uc2Vuc3VzIG9mIHRoZSB3b3Jr IGdyb3VwIGlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5CcmlhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBBdWcgMjMsIDIwMjEsIGF0IDU6MjQgUE0sIENhcm9uLCBHdXkgJmx0OzxhIGhyZWY9 Im1haWx0bzpnLmNhcm9uQGJlbGwuY2EiPmcuY2Fyb25AYmVsbC5jYTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGlzIG5ldyB2ZXJzaW9uIGludHJvZHVj ZXMgdmFyaWFiaWxpdHkgaW4gd2hldGhlciBhIGxvY2F0aW9uIGlzIGluZGVlZCBpbnZhbGlkYXRl ZCBvciBub3QgYnkgYSBjaGFuZ2UsIHdoaWNoIEkgYWdyZWUgd2l0aC48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+R2l2ZW4gdGhpcywgdGhlIG5hbWVzIOKAnGxvY2F0 aW9uSW52YWxpZGF0ZWTigJ0gYW5kIOKAnGludmFsaWRhdGVkQXNPZuKAnSBzZWVtIG1pc2xlYWRp bmcuIFNob3VsZCDigJxpbnZhbGlkYXRlZOKAnSBiZSBjaGFuZ2VkIHRvIHNvbWV0aGluZyBsaWtl IOKAnEltcGFjdGVk4oCdPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkd1eTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNl bnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Y29sb3I6Ymx1ZSI+RXh0ZXJuYWwgRW1haWw6PC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj4gUGxlYXNlIHVzZSBjYXV0 aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQgYXR0YWNobWVudHMgLw0KPC9zcGFuPjwvZW0+PHN0 cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPkNvdXJyaWVs IGV4dGVybmU6PC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtjb2xvcjpibHVlIj4gU295ZXogcHJ1ZGVudCBhdmVjIGxlcyBsaWVucyBldCBkb2N1bWVu dHMgam9pbnRzDQo8L3NwYW4+PC9lbT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_d9bbc311b8e0417dbb730255435aacd6bellca_-- From nobody Mon Aug 23 14:36:08 2021 Return-Path: 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 B5C3D3A1C56 for ; Mon, 23 Aug 2021 14:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01] 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 rfcfeGYqctv4 for ; Mon, 23 Aug 2021 14:35:59 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8011F3A1C47 for ; Mon, 23 Aug 2021 14:35:59 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 23 Aug 2021 14:35:59 -0700 From: "Randall Gellens" To: ECRIT Date: Mon, 23 Aug 2021 14:35:58 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <44B53B6F-4ABC-48A9-9AE0-AE19D43CA706@randy.pensive.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: [Ecrit] Review of draft-ietf-ecrit-lost-planned-changes-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 21:36:07 -0000 Earlier today I sent my review of the draft to the ECRIT list, but it is being held pending approval by a list owner because the body is too large. I'm trying to get it sent. --Randall From nobody Mon Aug 23 14:41:47 2021 Return-Path: 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 AD76F3A18F5 for ; Mon, 23 Aug 2021 14:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.62 X-Spam-Level: X-Spam-Status: No, score=0.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CONTENT_AFTER_HTML=2.499, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, T_HTML_ATTACH=0.01, 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 NPttdkeCU3JM for ; Mon, 23 Aug 2021 14:12:17 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8BADB3A1915 for ; Mon, 23 Aug 2021 14:12:16 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 23 Aug 2021 14:12:16 -0700 From: "Randall Gellens" To: ecrit@ietf.org Date: Mon, 23 Aug 2021 14:12:15 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <2B7FD550-34D6-4A80-956C-7CCDA7D34847@randy.pensive.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_MailMate_321F8108-A8BB-4A6C-AC31-1622E59E899C_=" Archived-At: X-Mailman-Approved-At: Mon, 23 Aug 2021 14:41:45 -0700 Subject: [Ecrit] Review of draft-ietf-ecrit-lost-planned-changes-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 21:12:27 -0000 --=_MailMate_321F8108-A8BB-4A6C-AC31-1622E59E899C_= Content-Type: text/plain; format=flowed; markup=markdown (1) Should the Time to Live information in a validation response be an attribute rather than an element? Logically, it seems more an attribute of the response, and also it mirrors the 'expires' attribute on which it is modeled. (2) In the extension schema, are 'invalidAsOf' and 'asOf' swapped? ('AsOf' should be part of the element but looks like maybe it is part of the response, while 'invalidAsOf' is part of ). (3) I'm not sure that "The server MUST have policy that limits use of this mechanism by a given client" is warranted; I think using "SHOULD" is more easily justified. I have a number of suggested edits for clarification or language. Attached are four files: draft-ietf-ecrit-lost-planned-changes-04-rg.xml The XML uploaded by Brian, with my edits. draft-ietf-ecrit-lost-planned-changes-04-rg.txt The TXT generated from the XML with my edits. Diff-txt.html An IETF tools diff showing my edits to the TXT, side by side. Diff-xml.html An IETF tools diff showing my edits to the XML, side by side. --Randall --=_MailMate_321F8108-A8BB-4A6C-AC31-1622E59E899C_= Content-Disposition: attachment; filename=draft-ietf-ecrit-lost-planned-changes-04-rg.txt Content-Type: text/plain Content-Transfer-Encoding: quoted-printable ecrit B. Rosen Internet-Draft August 23, 2021 Updates: RFC5222 (if approved) Intended status: Standards Track Expires: February 24, 2022 Validation of Locations Around a Planned Change draft-ietf-ecrit-lost-planned-changes-04 Abstract This document defines an extension to the Location to Service Translation (LoST) protocol (RFC5222) that allows a LoST server to notify a client of planned changes to the data. This extension is only useful with the validation function of LoST. It is beneficial for LoST validation clients to be aware of planned changes, as records that previously were valid may become invalid at a known future date, and new locations may become valid after the date. This extension adds two elements to the request: A URI that the LoST server can use to inform the LoST client (e.g., a Location Information Server [LIS]) that previously valid locations will be invalid after a planned change date, and a date that allows the LoST client to request that the server perform validation as of the date specified. It also adds an optional Time-To-Live element to the response, which informs clients of the current expected lifetime of a validation. This document also provides a conventional XML schema for LoST, as a backwards compatible alternative to the RelaxNG schema in RFC5222 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 24, 2022. Rosen Expires February 24, 2022 [Page 1] =0C Internet-Draft LoST Planned Changes August 2021 Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. element . . . . . . . . . . . . . . . . . . . 4 4. object . . . . . . . . . . . . . . . . 5 5. URI Not Stored Warning . . . . . . . . . . . . . . . . . . . 6 6. Time-To-Live (TTL) in Response . . . . . . . . . . . . . . . 6 7. Replacement XML schema . . . . . . . . . . . . . . . . . . . 7 8. Extension XML Schema . . . . . . . . . . . . . . . . . . . . 15 9. locationInvalidated Schema . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11.1. Replacement XML Schema Registration . . . . . . . . . . 18 11.2. Planned Change Extension XML Schema Registration . . . . 18 11.3. locationInvalidated XML Schema Registration . . . . . . 19 12. Normative References . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction This document describes an extension to the Location to Service Translation (LoST) protocol [RFC5222] to assist with planned changes to the underlying location information in the server. The extension allows a request to optionally contain a URI, and optionally a date. This extension is useful in the context of the validation function of LoST. It is beneficial for LoST validation clients to be aware of planned changes, as records that previously were valid may become invalid at a known future date, and new locations may become valid after the date. If specified, the URI may be retained by the LoST server and may be associated with the data record that was validated, and used to notify the the LoST client (e.g., a Location Information Server [LIS]) when a location which was Rosen Expires February 24, 2022 [Page 2] =0C Internet-Draft LoST Planned Changes August 2021 previously valid will become invalid. The date may be used by a client to ask a server to perform validation as of a future date. In addition to this mechanism, the is also extended to provide a Time-To-Live (TTL) for validation, after which the client should revalidate the location. Validation of civic locations involves dealing with data that may change over time. A typical example is when a portion of a county or province that was not part of a municipality is "annexed" to a municipality. Prior to the change, a Presence Information Data Format Location Object (PIDF-LO) specifying a civic location in the affected area would have a blank A3 element, or would contain some other value; after the change, a PIDF-LO specifying the same location would contain an A3 element set to the name of the municipality that annexed that part of the county/province. This kind of annexation has an effective date and time (typically 00:00 on the first or last day of a month), known in advance. Other kinds of changes may also occur, and these will almost always also have an effective date that is known in advance. Records in a LIS must change around these kinds of events. The old record must be discarded, and a new, validated record must be loaded into the LIS. It is often difficult for the LIS operator to know that records must be changed around such events. There are other circumstances where locations that were previously valid become invalid, such as a street renaming or renumbering event. Using [RFC5222] validation, the only way for a LIS to discover such changes is to periodically revalidate its entire database. Of course, this does not facilitate timely changes, is not coordinated with the actual change event, and also adds significant load to the LoST server as well as the LIS. Even if re-validation is contemplated, the server has no mechanism to control, or even suggest the time period for revalidation. This extension allows a LoST client to provide a stable URI that the LoST server may retain and may associate with the location information used in the request. In the event of a planned change, or any other circumstance where the location in the original request may become invalid, the server sends a notification to the URI to inform the client of a change. The notification contains the date and time when the location may become invalid. When a LIS receives such a notification, it may prepare a new record so that, at the precise planned event date and time, it may insert the new record into in its active database and delete the old record. As part of preparing the new record, the LIS may use the "as of" date component of this extension to perform a LoST validation of the new record as of the effective date. Rosen Expires February 24, 2022 [Page 3] =0C Internet-Draft LoST Planned Changes August 2021 The notification URI and "as of" date components of this extension allow a LIS to be prepared for and smoothly transition to planned changes, without the overhead and delay inherent in performing periodic revalidation of each location. The notification URI allows a LIS to be alerted to planned changes, while the "as of" date allows the LIS to verify the validity of locations before they become active. In situations where it is not practical or advisable for the LIS to maintain a stable URI for each of its records, periodic revalidation can still be used to maintain the data in the LIS. However, the LoST server should be able to influence the rate of such revalidation. For this purpose, this extension adds a Time to Live (TTL) element to the which provides advice from the server to the LIS of when validation is suggested. There are quite a few implementations of LoST. Experience with these implementations indicates that the RelaxNG schema is very difficult to deal with, both because many commonly used development tools don't support it, and development staff is often unfamiliar with it. Informal alternative schemas have been circulated, which is undesirable as they may not be in conformance with the RelaxNG schema in [RFC5222]. This document provides an XML schema that replaces the RelaxNG schema. It can be used by any implementation interchangeably with the RelaxNG schema. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. "Server" in this document refers to the LoST server and "Client" is the LoST client, even when the server is performing an operation on the client. 3. element This document defines a new element in the request called "plannedChange". This element contains two optional attributes: 'uri' and 'asOf'. When present, the 'uri' attribute MUST be a URI with a scheme of HTTPS. If the server supports this extension, it may store the URI and may associate it with the location in the request. The server uses the URI with the notification function defined below. To minimize storage requirements at the server, the length of the URI MUST not exceed 256 bytes. Each client of the server may only store one URI against a location, where "location" is defined by policy at the server, since Rosen Expires February 24, 2022 [Page 4] =0C Internet-Draft LoST Planned Changes August 2021 a given unique location may have many combinations of location elements that resolve to the same location. If the server receives a 'uri' for the same location from the same client, the URI in the request replaces the URI it previously retained. Policy at the server may limit how many URIs it retains for a given location. A new warning is defined below to indicate that the URI has not been stored. If the location in the request is invalid, the URI is not stored and the warning is returned. The 'asOf' attribute contains a date and time. The server validates the location in the request as of the date and time specified, taking into account planned changes. This allows a client to verify that it can make changes in the LIS commensurate with changes in the LoST server by validating locations in advance of a change. 4. object When a server needs to invalidate a location that has one or more associated client-supplied URIs (provided in a element), it transmits an HTTPS POST with a Content-Type of 'application/xml' containing a object to each associated URI. This is the notice from the server to the client that the location may be invalid and should be revalidated. The object contains an 'invalidAsOf' attribute, which specifies a date and time when the location may become invalid. If this is earlier than the current time, the location may already be invalid and the LIS should take immediate action. If the POST operation fails, the server MAY retry the operation immediately, and if it fails again, retry the operation later. Retry timing and duration or number of attempts is determined by the server. The LoST server is NOT REQUIRED to store the Location Information supplied in the original findService request. This means the server may not know if a planned change will in fact invalidate the location stored in the LoST client, because changes could be made in the LoST server that do not affect validation of the client's specific Location Information. The LoST client may find that upon revalidation with the changed server state, the validation data is the same as it was before the notification was received. The object does not contain information about the location, as the URI to which it is sent is determined by the requesting client and can be unique for each of the client's location records. Rosen Expires February 24, 2022 [Page 5] =0C Internet-Draft LoST Planned Changes August 2021 5. URI Not Stored Warning This extension adds a new warning to the exceptionContainer, 'uriNotStored'. This warning MUST NOT be returned unless the request contains a element with a 'uri' attribute. The warning is returned when the server decides not to store the URI. As discussed above, this may occur because, among other reasons, the policy at the server limits how many URIs will be stored against a specific location, the URI is not well formed or the policy at the server has some other restriction on the feature. 6. Time-To-Live (TTL) in Response This extension adds the element to the . The element contains a date and time after which the client may wish to revalidate the location at the server. A server MAY add this element to the response if validation is requested. This element takes the form of the 'expires' attribute pattern of [RFC5222], which allows the values 'NO CACHE' or 'NO EXPIRATION' to be returned instead of a dateTime value. However, for the element 'NO CACHE' has no meaning and MUST NOT be returned. 'NO EXPIRATION' means the server does not have a suggested revalidation period. Selecting a revalidation interval is a complex balancing of timeliness, server load, stability of the underlying data, and policy of the LoST server. Too short, and load on the server may overwhelm it. Too long and invalid data may persist in the server for unacceptable lengths of time. The URI notification mechanism provides timely notice to coordinate changes, but even with it, it is often advisable to revalidate data eventually. In areas that have little change in data, such as fully built out, stable communities already part of a municipality, it may be reasonable to set revalidation periods of 6 months or longer, especially if the URI mechanism is widely deployed at both the server and the clients. In areas that are quickly growing, 20-30 day revalidation may be more appropriate even though such revalidation would be the majority of the traffic on the LoST server. When a planned change is made, typically the TTL value for the affected records is lowered, so that revalidation is forced soon after the change is implemented. It is not advisable to set the expiration precisely at the planned change time if a large number of records will be changed, since that would cause a large spike in traffic at the change time. Rather, the expiration time should have a random additional time added to it to spread out the load. Rosen Expires February 24, 2022 [Page 6] =0C Internet-Draft LoST Planned Changes August 2021 7. Replacement XML schema This schema is an informative alternative to The Relax NG schema in [RFC5222] Rosen Expires February 24, 2022 [Page 7] =0C Internet-Draft LoST Planned Changes August 2021 Rosen Expires February 24, 2022 [Page 8] =0C Internet-Draft LoST Planned Changes August 2021 = Rosen Expires February 24, 2022 [Page 9] =0C Internet-Draft LoST Planned Changes August 2021 Rosen Expires February 24, 2022 [Page 10] =0C Internet-Draft LoST Planned Changes August 2021 Rosen Expires February 24, 2022 [Page 11] =0C Internet-Draft LoST Planned Changes August 2021 Rosen Expires February 24, 2022 [Page 12] =0C Internet-Draft LoST Planned Changes August 2021 Exception pattern. type=3D"basicException"/> Rosen Expires February 24, 2022 [Page 13] =0C Internet-Draft LoST Planned Changes August 2021 Any element not in the LoST namespace. A wildcard pattern for including any element from any other namespace. Rosen Expires February 24, 2022 [Page 14] =0C Internet-Draft LoST Planned Changes August 2021 A wildcard pattern for including any element from any other namespace. A point where future extensions (elements from other namespaces) can be added. 8. Extension XML Schema This schema provides the extension to the prior section schema for planned changes: Rosen Expires February 24, 2022 [Page 15] =0C Internet-Draft LoST Planned Changes August 2021 xs:group ref=3D"plannedChange" minOccurs=3D"1"/> 9. locationInvalidated Schema This schema defines the object used for the notification that a location is potentially invalidated sent by a LoST server to a client that requested it. Rosen Expires February 24, 2022 [Page 16] =0C Internet-Draft LoST Planned Changes August 2021 A point where future extensions (elements from other namespaces) can be added. 10. Security Considerations As an extension to LoST, this document inherits the security issues raised in [RFC5222]. The server could be tricked into storing a malicious URI which, when sent the locationInvalidated object could trigger something untoward. The server MUST NOT accept any data from the client in response to POSTing the locationInvalidated. The server is subject to abuse by clients because it is being asked to store something and may need to send data to an uncontrolled URI. Clients could request many URIs for the same location, for example. The server MUST have policy that limits use of this mechanism by a given client. If the policy is exceeded, the server returns the 'uriNotStored' warning. The server MUST validate that the content of the 'uri' attribute sent is syntactically valid and meets the 256 bytes limit. When sending the locationInvalidated object to the URI stored, the server MUST protect itself against common HTTP vulnerabilities. The mutual authentication between client and server is RECOMMENDED for both the initial operation that requests storing the URI and the sending of the 'locationInvalidated' object. The server should be well known to the client, and its credential should be learned in a reliable way. For example, a public safety system operating the LoST server may have a credential traceable to a well known Certificate Authority known to provide credentials for public Rosen Expires February 24, 2022 [Page 17] =0C Internet-Draft LoST Planned Changes August 2021 safety agencies. Clients may be operated by local ISPs or other service providers that can reasonably obtain a good credential to use for the server side of the LoST server's POST transaction using the URI. Where the loST server does not recognize the client, its policy MAY limit the use of this feature beyond what it would limit a client it recognizes. 11. IANA Considerations 11.1. Replacement XML Schema Registration URI: urn:ietf:params:xml:schema:lost3 Registrant Contact: IETF ECRIT Working Group, Brian Rosen (br@brianrosen.net). XML: BEGIN LoST Namespace

Namespace for LoST

urn:ietf:params:xml:ns:lost3

See RFC????.

END The XML Schema is found in Section 7. 11.2. Planned Change Extension XML Schema Registration Rosen Expires February 24, 2022 [Page 18] =0C Internet-Draft LoST Planned Changes August 2021 URI: urn:ietf:params:xml:schema:lostPlannedChange1 Registrant Contact: IETF ECRIT Working Group, Brian Rosen (br@brianrosen.net). XML: BEGIN LoST Planned Change Namespace

Namespace for LoST

urn:ietf:params:xml:ns:lostPlannedChange1

See RFC????.

END The XML Schema is found in Section 8. 11.3. locationInvalidated XML Schema Registration Rosen Expires February 24, 2022 [Page 19] =0C Internet-Draft LoST Planned Changes August 2021 URI: urn:ietf:params:xml:schema:lostLocationInvalidated1 Registrant Contact: IETF ECRIT Working Group, Brian Rosen (br@brianrosen.net). XML: BEGIN LoST Location Invalided Namespace

Namespace for LoST Location Invalidated notification

urn:ietf:params:xml:ns:lostLocationInvalidated1

See RFC????.

END The XML Schema is found in Section 9. 12. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008, . Author's Address Brian Rosen 470 Conrad Dr Mars, PA 16046 US EMail: br@brianrosen.net Rosen Expires February 24, 2022 [Page 20] --=_MailMate_321F8108-A8BB-4A6C-AC31-1622E59E899C_= Content-Disposition: attachment; filename=draft-ietf-ecrit-lost-planned-changes-04-rg.xml Content-Type: application/xml Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIj8+Cjw/eG1sLXN0eWxlc2hlZXQgdHlwZT0idGV4dC94c2wiIGhy ZWY9InJmYzI2MjkueHNsdCI/Pgo8IURPQ1RZUEUgcmZjIFNZU1RFTSAicmZjMjYyOS5kdGQiIFsK PCFFTlRJVFkgUkZDMjExOSBQVUJMSUMgIiIgImh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1Ymxp Yy9yZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMuMjExOS54bWwiPgo8IUVOVElUWSBSRkM1MjIyIFBV QkxJQyAiIiAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJl bmNlLlJGQy41MjIyLnhtbCI+Cl0+Cgo8P3JmYyByZmNlZHN0eWxlPSJ5ZXMiPz4KPD9yZmMgc3lt cmVmcz0ieWVzIj8+Cjw/cmZjIHNvcnRyZWZzPSJubyI/Pgo8P3JmYyBpcHJub3RpZmllZD0ieWVz Ij8+Cjw/cmZjIHN0cmljdD0ieWVzIj8+Cjw/cmZjIHRvYz0ieWVzIj8+Cjw/cmZjIHRvY2luZGVu dD0ieWVzIj8+Cgo8cmZjIGNhdGVnb3J5PSJzdGQiIGlwcj0idHJ1c3QyMDA5MDIiIHVwZGF0ZXM9 IlJGQzUyMjIiIGRvY05hbWU9ImRyYWZ0LWlldGYtZWNyaXQtbG9zdC1wbGFubmVkLWNoYW5nZXMt MDQiPgogIDxmcm9udD4KICAgIDx0aXRsZSBhYmJyZXY9IkxvU1QgUGxhbm5lZCBDaGFuZ2VzIj4K ICAgICAgVmFsaWRhdGlvbiBvZiBMb2NhdGlvbnMgQXJvdW5kIGEgUGxhbm5lZCBDaGFuZ2UKICAg IDwvdGl0bGU+CgogICAgPGF1dGhvciBpbml0aWFscz0iQi4iIHN1cm5hbWU9IlJvc2VuIiBmdWxs bmFtZT0iQnJpYW4gUm9zZW4iPgogICAgICAgPGFkZHJlc3M+CiAgICAgICAgPHBvc3RhbD4KICAg ICAgICAgIDxzdHJlZXQ+NDcwIENvbnJhZCBEcjwvc3RyZWV0PgogICAgICAgICAgPGNpdHk+TWFy czwvY2l0eT4KICAgICAgICAgIDxyZWdpb24+UEE8L3JlZ2lvbj4KICAgICAgICAgIDxjb2RlPjE2 MDQ2PC9jb2RlPgogICAgICAgICAgPGNvdW50cnk+VVM8L2NvdW50cnk+CiAgICAgICAgPC9wb3N0 YWw+CiAgICAgICAgPGVtYWlsPmJyQGJyaWFucm9zZW4ubmV0PC9lbWFpbD4KICAgICAgPC9hZGRy ZXNzPgogICAgPC9hdXRob3I+CgoKICAgIDxkYXRlIHllYXI9IjIwMjEiLz4KICAgIDxhcmVhPkFS VDwvYXJlYT4KICAgIDx3b3JrZ3JvdXA+w6ljcml0PC93b3JrZ3JvdXA+CiAgICA8a2V5d29yZD5J bnRlcm5ldC1EcmFmdDwva2V5d29yZD4KIAogICAgPGFic3RyYWN0PgogICAgICA8dD5UaGlzIGRv Y3VtZW50IGRlZmluZXMgYW4gZXh0ZW5zaW9uIHRvIHRoZSBMb2NhdGlvbiB0byBTZXJ2aWNlIFRy YW5zbGF0aW9uIChMb1NUKSBwcm90b2NvbCAoUkZDNTIyMikgdGhhdCBhbGxvd3MgYSBMb1NUIHNl cnZlciB0byBub3RpZnkgYSBjbGllbnQgb2YgcGxhbm5lZCBjaGFuZ2VzIHRvIHRoZSBkYXRhLiAg VGhpcyBleHRlbnNpb24gaXMgb25seSB1c2VmdWwgd2l0aCB0aGUgdmFsaWRhdGlvbiBmdW5jdGlv biBvZiBMb1NULiAgSXQgaXMgYmVuZWZpY2lhbCBmb3IgTG9TVCB2YWxpZGF0aW9uIGNsaWVudHMg dG8gYmUgYXdhcmUgb2YgcGxhbm5lZCBjaGFuZ2VzLCBhcyByZWNvcmRzIHRoYXQgcHJldmlvdXNs eSB3ZXJlIHZhbGlkIG1heSBiZWNvbWUgaW52YWxpZCBhdCBhIGtub3duIGZ1dHVyZSBkYXRlLCBh bmQgbmV3IGxvY2F0aW9ucyBtYXkgYmVjb21lIHZhbGlkIGFmdGVyIHRoZSBkYXRlLiAgVGhpcyBl eHRlbnNpb24gYWRkcyB0d28gZWxlbWVudHMgdG8gdGhlICZsdDtmaW5kU2VydmljZSZndDsgcmVx dWVzdDogQSBVUkkgdGhhdCB0aGUgTG9TVCBzZXJ2ZXIgY2FuIHVzZSB0byBpbmZvcm0gdGhlIExv U1QgY2xpZW50IChlLmcuLCBhIExvY2F0aW9uIEluZm9ybWF0aW9uIFNlcnZlciBbTElTXSkgdGhh dCBwcmV2aW91c2x5IHZhbGlkIGxvY2F0aW9ucyB3aWxsIGJlIGludmFsaWQgYWZ0ZXIgYSBwbGFu bmVkIGNoYW5nZSBkYXRlLCBhbmQgYSBkYXRlIHRoYXQgYWxsb3dzIHRoZSBMb1NUIGNsaWVudCB0 byByZXF1ZXN0IHRoYXQgdGhlIHNlcnZlciBwZXJmb3JtIHZhbGlkYXRpb24gYXMgb2YgdGhlIGRh dGUgc3BlY2lmaWVkLiAgSXQgYWxzbyBhZGRzIGFuIG9wdGlvbmFsIFRpbWUtVG8tTGl2ZSBlbGVt ZW50IHRvIHRoZSByZXNwb25zZSwgd2hpY2ggaW5mb3JtcyBjbGllbnRzIG9mIHRoZSBjdXJyZW50 IGV4cGVjdGVkIGxpZmV0aW1lIG9mIGEgdmFsaWRhdGlvbi4gIFRoaXMgZG9jdW1lbnQgYWxzbyBw cm92aWRlcyBhIGNvbnZlbnRpb25hbCBYTUwgc2NoZW1hIGZvciBMb1NULCBhcyBhIGJhY2t3YXJk cyBjb21wYXRpYmxlIGFsdGVybmF0aXZlIHRvIHRoZSBSZWxheE5HIHNjaGVtYSBpbiBSRkM1MjIy CiAgICAgIDwvdD4KICAgIDwvYWJzdHJhY3Q+CiAgPC9mcm9udD4KCiAgPG1pZGRsZT4KICAgIDxz ZWN0aW9uIHRpdGxlPSJJbnRyb2R1Y3Rpb24iPgogICAgICA8dD5UaGlzIGRvY3VtZW50IGRlc2Ny aWJlcyBhbiBleHRlbnNpb24gdG8gdGhlIExvY2F0aW9uIHRvIFNlcnZpY2UgVHJhbnNsYXRpb24g KExvU1QpIHByb3RvY29sIDx4cmVmIHRhcmdldD0iUkZDNTIyMiIvPiB0byBhc3Npc3Qgd2l0aCBw bGFubmVkIGNoYW5nZXMgdG8gdGhlIHVuZGVybHlpbmcgbG9jYXRpb24gaW5mb3JtYXRpb24gaW4g dGhlIHNlcnZlci4gIFRoZSBleHRlbnNpb24gYWxsb3dzIGEgJmx0O2ZpbmRTZXJ2aWNlJmd0OyBy ZXF1ZXN0IHRvIG9wdGlvbmFsbHkgY29udGFpbiBhIFVSSSwgYW5kIG9wdGlvbmFsbHkgYSBkYXRl LiAgVGhpcyBleHRlbnNpb24gaXMgdXNlZnVsIGluIHRoZSBjb250ZXh0IG9mIHRoZSB2YWxpZGF0 aW9uIGZ1bmN0aW9uIG9mIExvU1QuICBJdCBpcyBiZW5lZmljaWFsIGZvciBMb1NUIHZhbGlkYXRp b24gY2xpZW50cyB0byBiZSBhd2FyZSBvZiBwbGFubmVkIGNoYW5nZXMsIGFzIHJlY29yZHMgdGhh dCBwcmV2aW91c2x5IHdlcmUgdmFsaWQgbWF5IGJlY29tZSBpbnZhbGlkIGF0IGEga25vd24gZnV0 dXJlIGRhdGUsIGFuZCBuZXcgbG9jYXRpb25zIG1heSBiZWNvbWUgdmFsaWQgYWZ0ZXIgdGhlIGRh dGUuICBJZiBzcGVjaWZpZWQsIHRoZSBVUkkgbWF5IGJlIHJldGFpbmVkIGJ5IHRoZSBMb1NUIHNl cnZlciBhbmQgbWF5IGJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgZGF0YSByZWNvcmQgdGhhdCB3YXMg dmFsaWRhdGVkLCBhbmQgdXNlZCB0byBub3RpZnkgdGhlIHRoZSBMb1NUIGNsaWVudCAoZS5nLiwg YSBMb2NhdGlvbiBJbmZvcm1hdGlvbiBTZXJ2ZXIgW0xJU10pIHdoZW4gYSBsb2NhdGlvbiB3aGlj aCB3YXMgcHJldmlvdXNseSB2YWxpZCB3aWxsIGJlY29tZSBpbnZhbGlkLiAgVGhlIGRhdGUgbWF5 IGJlIHVzZWQgYnkgYSBjbGllbnQgdG8gYXNrIGEgc2VydmVyIHRvIHBlcmZvcm0gdmFsaWRhdGlv biBhcyBvZiBhIGZ1dHVyZSBkYXRlLiBJbiBhZGRpdGlvbiB0byB0aGlzIG1lY2hhbmlzbSwgdGhl ICZsdDtmaW5kc2VydmljZVJlc3BvbnNlJmd0OyBpcyBhbHNvIGV4dGVuZGVkIHRvIHByb3ZpZGUg YSBUaW1lLVRvLUxpdmUgKFRUTCkgZm9yIHZhbGlkYXRpb24sIGFmdGVyIHdoaWNoIHRoZSBjbGll bnQgc2hvdWxkIHJldmFsaWRhdGUgdGhlIGxvY2F0aW9uLgogICAgICA8L3Q+CiAgICAgIDx0PlZh bGlkYXRpb24gb2YgY2l2aWMgbG9jYXRpb25zIGludm9sdmVzIGRlYWxpbmcgd2l0aCBkYXRhIHRo YXQgbWF5IGNoYW5nZSBvdmVyIHRpbWUuICBBIHR5cGljYWwgZXhhbXBsZSBpcyB3aGVuIGEgcG9y dGlvbiBvZiBhIGNvdW50eSBvciBwcm92aW5jZSB0aGF0IHdhcyBub3QgcGFydCBvZiBhIG11bmlj aXBhbGl0eSBpcyAiYW5uZXhlZCIgdG8gYSBtdW5pY2lwYWxpdHkuICBQcmlvciB0byB0aGUgY2hh bmdlLCBhIFByZXNlbmNlIEluZm9ybWF0aW9uIERhdGEgRm9ybWF0IExvY2F0aW9uIE9iamVjdCAo UElERi1MTykgc3BlY2lmeWluZyBhIGNpdmljIGxvY2F0aW9uIGluIHRoZSBhZmZlY3RlZCBhcmVh IHdvdWxkIGhhdmUgYSBibGFuayBBMyBlbGVtZW50LCBvciB3b3VsZCBjb250YWluIHNvbWUgb3Ro ZXIgdmFsdWU7IGFmdGVyIHRoZSBjaGFuZ2UsIGEgUElERi1MTyBzcGVjaWZ5aW5nIHRoZSBzYW1l IGxvY2F0aW9uIHdvdWxkIGNvbnRhaW4gYW4gQTMgZWxlbWVudCBzZXQgdG8gdGhlIG5hbWUgb2Yg dGhlIG11bmljaXBhbGl0eSB0aGF0IGFubmV4ZWQgdGhhdCBwYXJ0IG9mIHRoZSBjb3VudHkvcHJv dmluY2UuICBUaGlzIGtpbmQgb2YgYW5uZXhhdGlvbiBoYXMgYW4gZWZmZWN0aXZlIGRhdGUgYW5k IHRpbWUgKHR5cGljYWxseSAwMDowMCBvbiB0aGUgZmlyc3Qgb3IgbGFzdCBkYXkgb2YgYSBtb250 aCksIGtub3duIGluIGFkdmFuY2UuICBPdGhlciBraW5kcyBvZiBjaGFuZ2VzIG1heSBhbHNvIG9j Y3VyLCBhbmQgdGhlc2Ugd2lsbCBhbG1vc3QgYWx3YXlzIGFsc28gaGF2ZSBhbiBlZmZlY3RpdmUg ZGF0ZSB0aGF0IGlzIGtub3duIGluIGFkdmFuY2UuPC90PgoKPHQ+UmVjb3JkcyBpbiBhIExJUyBt dXN0IGNoYW5nZSBhcm91bmQgdGhlc2Uga2luZHMgb2YgZXZlbnRzLiAgVGhlIG9sZCByZWNvcmQg bXVzdCBiZSBkaXNjYXJkZWQsIGFuZCBhIG5ldywgdmFsaWRhdGVkIHJlY29yZCBtdXN0IGJlIGxv YWRlZCBpbnRvIHRoZSBMSVMuICBJdCBpcyBvZnRlbiBkaWZmaWN1bHQgZm9yIHRoZSBMSVMgb3Bl cmF0b3IgdG8ga25vdyB0aGF0IHJlY29yZHMgbXVzdCBiZSBjaGFuZ2VkIGFyb3VuZCBzdWNoIGV2 ZW50cy4gIFRoZXJlIGFyZSBvdGhlciBjaXJjdW1zdGFuY2VzIHdoZXJlIGxvY2F0aW9ucyB0aGF0 IHdlcmUgcHJldmlvdXNseSB2YWxpZCBiZWNvbWUgaW52YWxpZCwgc3VjaCBhcyBhIHN0cmVldCBy ZW5hbWluZyBvciByZW51bWJlcmluZyBldmVudC4gIFVzaW5nIDx4cmVmIHRhcmdldD0iUkZDNTIy MiIvPiB2YWxpZGF0aW9uLCB0aGUgb25seSB3YXkgZm9yIGEgTElTIHRvIGRpc2NvdmVyIHN1Y2gg Y2hhbmdlcyBpcyB0byBwZXJpb2RpY2FsbHkgcmV2YWxpZGF0ZSBpdHMgZW50aXJlIGRhdGFiYXNl LiAgT2YgY291cnNlLCB0aGlzIGRvZXMgbm90IGZhY2lsaXRhdGUgdGltZWx5IGNoYW5nZXMsIGlz IG5vdCBjb29yZGluYXRlZCB3aXRoIHRoZSBhY3R1YWwgY2hhbmdlIGV2ZW50LCBhbmQgYWxzbyBh ZGRzIHNpZ25pZmljYW50IGxvYWQgdG8gdGhlIExvU1Qgc2VydmVyIGFzIHdlbGwgYXMgdGhlIExJ Uy4gIEV2ZW4gaWYgcmUtdmFsaWRhdGlvbiBpcyBjb250ZW1wbGF0ZWQsIHRoZSBzZXJ2ZXIgaGFz IG5vIG1lY2hhbmlzbSB0byBjb250cm9sLCBvciBldmVuIHN1Z2dlc3QgdGhlIHRpbWUgcGVyaW9k IGZvciByZXZhbGlkYXRpb24uPC90PgoKPHQ+VGhpcyBleHRlbnNpb24gYWxsb3dzIGEgTG9TVCBj bGllbnQgdG8gcHJvdmlkZSBhIHN0YWJsZSBVUkkgdGhhdCB0aGUgTG9TVCBzZXJ2ZXIgbWF5IHJl dGFpbiBhbmQgbWF5IGFzc29jaWF0ZSB3aXRoIHRoZSBsb2NhdGlvbiBpbmZvcm1hdGlvbiB1c2Vk IGluIHRoZSByZXF1ZXN0LiAgSW4gdGhlIGV2ZW50IG9mIGEgcGxhbm5lZCBjaGFuZ2UsIG9yIGFu eSBvdGhlciBjaXJjdW1zdGFuY2Ugd2hlcmUgdGhlIGxvY2F0aW9uIGluIHRoZSBvcmlnaW5hbCBy ZXF1ZXN0IG1heSBiZWNvbWUgaW52YWxpZCwgdGhlIHNlcnZlciBzZW5kcyBhIG5vdGlmaWNhdGlv biB0byB0aGUgVVJJIHRvIGluZm9ybSB0aGUgY2xpZW50IG9mIGEgY2hhbmdlLiAgVGhlIG5vdGlm aWNhdGlvbiBjb250YWlucyB0aGUgZGF0ZSBhbmQgdGltZSB3aGVuIHRoZSBsb2NhdGlvbiBtYXkg YmVjb21lIGludmFsaWQuPC90PgoKPHQ+V2hlbiBhIExJUyByZWNlaXZlcyBzdWNoIGEgbm90aWZp Y2F0aW9uLCBpdCBtYXkgcHJlcGFyZSBhIG5ldyByZWNvcmQgc28gdGhhdCwgYXQgdGhlIHByZWNp c2UgcGxhbm5lZCBldmVudCBkYXRlIGFuZCB0aW1lLCBpdCBtYXkgaW5zZXJ0IHRoZSBuZXcgcmVj b3JkIGludG8gaW4gaXRzIGFjdGl2ZSBkYXRhYmFzZSBhbmQgZGVsZXRlIHRoZSBvbGQgcmVjb3Jk LiAgQXMgcGFydCBvZiBwcmVwYXJpbmcgdGhlIG5ldyByZWNvcmQsIHRoZSBMSVMgbWF5IHVzZSB0 aGUgImFzIG9mIiBkYXRlIGNvbXBvbmVudCBvZiB0aGlzIGV4dGVuc2lvbiB0byBwZXJmb3JtIGEg TG9TVCB2YWxpZGF0aW9uIG9mIHRoZSBuZXcgcmVjb3JkIGFzIG9mIHRoZSBlZmZlY3RpdmUgZGF0 ZS48L3Q+Cgo8dD5UaGUgbm90aWZpY2F0aW9uIFVSSSBhbmQgImFzIG9mIiBkYXRlIGNvbXBvbmVu dHMgb2YgdGhpcyBleHRlbnNpb24gYWxsb3cgYSBMSVMgdG8gYmUgcHJlcGFyZWQgZm9yIGFuZCBz bW9vdGhseSB0cmFuc2l0aW9uIHRvIHBsYW5uZWQgY2hhbmdlcywgd2l0aG91dCB0aGUgb3Zlcmhl YWQgYW5kIGRlbGF5IGluaGVyZW50IGluIHBlcmZvcm1pbmcgcGVyaW9kaWMgcmV2YWxpZGF0aW9u IG9mIGVhY2ggbG9jYXRpb24uICBUaGUgbm90aWZpY2F0aW9uIFVSSSBhbGxvd3MgYSBMSVMgdG8g YmUgYWxlcnRlZCB0byBwbGFubmVkIGNoYW5nZXMsIHdoaWxlIHRoZSAiYXMgb2YiIGRhdGUgYWxs b3dzIHRoZSBMSVMgdG8gdmVyaWZ5IHRoZSB2YWxpZGl0eSBvZiBsb2NhdGlvbnMgYmVmb3JlIHRo ZXkgYmVjb21lIGFjdGl2ZS48L3Q+Cgo8dD5JbiBzaXR1YXRpb25zIHdoZXJlIGl0IGlzIG5vdCBw cmFjdGljYWwgb3IgYWR2aXNhYmxlIGZvciB0aGUgTElTIHRvIG1haW50YWluIGEgc3RhYmxlIFVS SSBmb3IgZWFjaCBvZiBpdHMgcmVjb3JkcywgcGVyaW9kaWMgcmV2YWxpZGF0aW9uIGNhbiBzdGls bCBiZSB1c2VkIHRvIG1haW50YWluIHRoZSBkYXRhIGluIHRoZSBMSVMuICBIb3dldmVyLCB0aGUg TG9TVCBzZXJ2ZXIgc2hvdWxkIGJlIGFibGUgdG8gaW5mbHVlbmNlIHRoZSByYXRlIG9mIHN1Y2gg cmV2YWxpZGF0aW9uLiAgRm9yIHRoaXMgcHVycG9zZSwgdGhpcyBleHRlbnNpb24gYWRkcyBhICBU aW1lIHRvIExpdmUgKFRUTCkgZWxlbWVudCB0byB0aGUgJmx0O2ZpbmRTZXJ2aWNlUmVzcG9uc2Um Z3Q7IHdoaWNoIHByb3ZpZGVzIGFkdmljZSBmcm9tIHRoZSBzZXJ2ZXIgdG8gdGhlIExJUyBvZiB3 aGVuIHZhbGlkYXRpb24gaXMgc3VnZ2VzdGVkLjwvdD4KCjx0PlRoZXJlIGFyZSBxdWl0ZSBhIGZl dyBpbXBsZW1lbnRhdGlvbnMgb2YgTG9TVC4gIEV4cGVyaWVuY2Ugd2l0aCB0aGVzZSBpbXBsZW1l bnRhdGlvbnMgaW5kaWNhdGVzIHRoYXQgdGhlIFJlbGF4Tkcgc2NoZW1hIGlzIHZlcnkgZGlmZmlj dWx0IHRvIGRlYWwgd2l0aCwgYm90aCBiZWNhdXNlIG1hbnkgY29tbW9ubHkgdXNlZCBkZXZlbG9w bWVudCB0b29scyBkb24ndCBzdXBwb3J0IGl0LCBhbmQgZGV2ZWxvcG1lbnQgc3RhZmYgaXMgb2Z0 ZW4gdW5mYW1pbGlhciB3aXRoIGl0LiAgSW5mb3JtYWwgYWx0ZXJuYXRpdmUgc2NoZW1hcyBoYXZl IGJlZW4gY2lyY3VsYXRlZCwgd2hpY2ggaXMgdW5kZXNpcmFibGUgYXMgdGhleSBtYXkgbm90IGJl IGluIGNvbmZvcm1hbmNlIHdpdGggdGhlIFJlbGF4Tkcgc2NoZW1hIGluIDx4cmVmIHRhcmdldD0i UkZDNTIyMiIvPi4gIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYW4gWE1MIHNjaGVtYSB0aGF0IHJl cGxhY2VzIHRoZSBSZWxheE5HIHNjaGVtYS4gIEl0IGNhbiBiZSB1c2VkIGJ5IGFueSBpbXBsZW1l bnRhdGlvbiBpbnRlcmNoYW5nZWFibHkgd2l0aCB0aGUgUmVsYXhORyBzY2hlbWEuIDwvdD4KCiAg ICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gYW5jaG9yPSJjb252ZW50aW9ucyIgdGl0bGU9IkNv bnZlbnRpb25zIHVzZWQgaW4gdGhpcyBkb2N1bWVudCI+CiAgICAgIDx0PlRoZSBrZXkgd29yZHMg Ik1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwgIlNI T1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwi IGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiA8 eHJlZiB0YXJnZXQ9IlJGQzIxMTkiLz4uCiAgICAgIDwvdD4KICAgICAgPHQ+IlNlcnZlciIgaW4g dGhpcyBkb2N1bWVudCByZWZlcnMgdG8gdGhlIExvU1Qgc2VydmVyIGFuZCAiQ2xpZW50IiBpcyB0 aGUgTG9TVCBjbGllbnQsIGV2ZW4gd2hlbiB0aGUgc2VydmVyIGlzIHBlcmZvcm1pbmcgYW4gb3Bl cmF0aW9uIG9uIHRoZSBjbGllbnQuPC90PgogICAgPC9zZWN0aW9uPgogICAgPHNlY3Rpb24gdGl0 bGU9IiZsdDtwbGFubmVkQ2hhbmdlJmd0OyBlbGVtZW50Ij4KICAgICAgPHQ+VGhpcyBkb2N1bWVu dCBkZWZpbmVzIGEgbmV3IGVsZW1lbnQgaW4gdGhlICZsdDtmaW5kU2VydmljZSZndDsgcmVxdWVz dCBjYWxsZWQgInBsYW5uZWRDaGFuZ2UiLiAgVGhpcyBlbGVtZW50IGNvbnRhaW5zIHR3byBvcHRp b25hbCBhdHRyaWJ1dGVzOiAndXJpJyBhbmQgJ2FzT2YnLiAgV2hlbiBwcmVzZW50LCB0aGUgJ3Vy aScgYXR0cmlidXRlIE1VU1QgYmUgYSBVUkkgd2l0aCBhIHNjaGVtZSBvZiBIVFRQUy4gSWYgdGhl IHNlcnZlciBzdXBwb3J0cyB0aGlzIGV4dGVuc2lvbiwgaXQgbWF5IHN0b3JlIHRoZSBVUkkgYW5k IG1heSBhc3NvY2lhdGUgaXQgd2l0aCB0aGUgbG9jYXRpb24gaW4gdGhlIHJlcXVlc3QuICBUaGUg c2VydmVyIHVzZXMgdGhlIFVSSSB3aXRoIHRoZSBub3RpZmljYXRpb24gZnVuY3Rpb24gZGVmaW5l ZCBiZWxvdy4gIFRvIG1pbmltaXplIHN0b3JhZ2UgcmVxdWlyZW1lbnRzIGF0IHRoZSBzZXJ2ZXIs IHRoZSBsZW5ndGggb2YgdGhlIFVSSSBNVVNUIG5vdCBleGNlZWQgMjU2IGJ5dGVzLiAgRWFjaCBj bGllbnQgb2YgdGhlIHNlcnZlciBtYXkgb25seSBzdG9yZSBvbmUgVVJJIGFnYWluc3QgYSBsb2Nh dGlvbiwgd2hlcmUgImxvY2F0aW9uIiBpcyBkZWZpbmVkIGJ5IHBvbGljeSBhdCB0aGUgc2VydmVy LCBzaW5jZSBhIGdpdmVuIHVuaXF1ZSBsb2NhdGlvbiBtYXkgaGF2ZSBtYW55IGNvbWJpbmF0aW9u cyBvZiBsb2NhdGlvbiBlbGVtZW50cyB0aGF0IHJlc29sdmUgdG8gdGhlIHNhbWUgbG9jYXRpb24u ICBJZiB0aGUgc2VydmVyIHJlY2VpdmVzIGEgJ3VyaScgZm9yIHRoZSBzYW1lIGxvY2F0aW9uIGZy b20gdGhlIHNhbWUgY2xpZW50LCB0aGUgVVJJIGluIHRoZSByZXF1ZXN0IHJlcGxhY2VzIHRoZSBV UkkgaXQgcHJldmlvdXNseSByZXRhaW5lZC4gIFBvbGljeSBhdCB0aGUgc2VydmVyIG1heSBsaW1p dCBob3cgbWFueSBVUklzIGl0IHJldGFpbnMgZm9yIGEgZ2l2ZW4gbG9jYXRpb24uIEEgbmV3IHdh cm5pbmcgaXMgZGVmaW5lZCBiZWxvdyB0byBpbmRpY2F0ZSB0aGF0IHRoZSBVUkkgaGFzIG5vdCBi ZWVuIHN0b3JlZC4gIElmIHRoZSBsb2NhdGlvbiBpbiB0aGUgcmVxdWVzdCBpcyBpbnZhbGlkLCB0 aGUgVVJJIGlzIG5vdCBzdG9yZWQgYW5kIHRoZSB3YXJuaW5nIGlzIHJldHVybmVkLgogICAgICA8 L3Q+Cjx0PlRoZSAnYXNPZicgYXR0cmlidXRlIGNvbnRhaW5zIGEgZGF0ZSBhbmQgdGltZS4gIFRo ZSBzZXJ2ZXIgdmFsaWRhdGVzIHRoZSBsb2NhdGlvbiBpbiB0aGUgcmVxdWVzdCBhcyBvZiB0aGUg ZGF0ZSBhbmQgdGltZSBzcGVjaWZpZWQsIHRha2luZyBpbnRvIGFjY291bnQgcGxhbm5lZCBjaGFu Z2VzLiAgVGhpcyBhbGxvd3MgYSBjbGllbnQgdG8gdmVyaWZ5IHRoYXQgaXQgY2FuIG1ha2UgY2hh bmdlcyBpbiB0aGUgTElTIGNvbW1lbnN1cmF0ZSB3aXRoIGNoYW5nZXMgaW4gdGhlIExvU1Qgc2Vy dmVyIGJ5IHZhbGlkYXRpbmcgbG9jYXRpb25zIGluIGFkdmFuY2Ugb2YgYSBjaGFuZ2UuPC90Pgog ICAgPC9zZWN0aW9uPgogICA8c2VjdGlvbiB0aXRsZT0iJmx0O2xvY2F0aW9uSW52YWxpZGF0ZWQm Z3Q7IG9iamVjdCI+Cjx0PldoZW4gYSBzZXJ2ZXIgbmVlZHMgdG8gaW52YWxpZGF0ZSBhIGxvY2F0 aW9uIHRoYXQgaGFzIG9uZSBvciBtb3JlIGFzc29jaWF0ZWQgY2xpZW50LXN1cHBsaWVkIFVSSXMg KHByb3ZpZGVkIGluIGEgJmx0O3BsYW5uZWRDaGFuZ2UmZ3Q7IGVsZW1lbnQpLAppdCB0cmFuc21p dHMgYW4gSFRUUFMgUE9TVCB3aXRoIGEgQ29udGVudC1UeXBlIG9mICdhcHBsaWNhdGlvbi94bWwn IGNvbnRhaW5pbmcgYSAmbHQ7bG9jYXRpb25JbnZhbGlkYXRlZCZndDsgb2JqZWN0IHRvIGVhY2gg YXNzb2NpYXRlZCBVUkkuClRoaXMgaXMgdGhlIG5vdGljZSBmcm9tIHRoZSBzZXJ2ZXIgdG8gdGhl IGNsaWVudCB0aGF0IHRoZSBsb2NhdGlvbiBtYXkgYmUgaW52YWxpZCBhbmQgc2hvdWxkIGJlIHJl dmFsaWRhdGVkLgpUaGUgJmx0O2xvY2F0aW9uSW52YWxpZGF0ZWQmZ3Q7IG9iamVjdCBjb250YWlu cyBhbiDigJhpbnZhbGlkQXNPZuKAmCBhdHRyaWJ1dGUsIHdoaWNoIHNwZWNpZmllcyBhIGRhdGUg YW5kIHRpbWUgd2hlbiB0aGUgbG9jYXRpb24gbWF5IGJlY29tZSBpbnZhbGlkLgpJZiB0aGlzIGlz IGVhcmxpZXIgdGhhbiB0aGUgY3VycmVudCB0aW1lLCB0aGUgbG9jYXRpb24gbWF5IGFscmVhZHkg YmUgaW52YWxpZCBhbmQgdGhlIExJUyBzaG91bGQgdGFrZSBpbW1lZGlhdGUgYWN0aW9uLiAgSWYg dGhlIFBPU1Qgb3BlcmF0aW9uIGZhaWxzLCB0aGUgc2VydmVyIE1BWSByZXRyeSB0aGUgb3BlcmF0 aW9uIGltbWVkaWF0ZWx5LCBhbmQgaWYgaXQgZmFpbHMgYWdhaW4sIHJldHJ5IHRoZSBvcGVyYXRp b24gbGF0ZXIuICBSZXRyeSB0aW1pbmcgYW5kIGR1cmF0aW9uIG9yIG51bWJlciBvZiBhdHRlbXB0 cyBpcyBkZXRlcm1pbmVkIGJ5IHRoZSBzZXJ2ZXIuPC90Pgo8dD5UaGUgTG9TVCBzZXJ2ZXIgaXMg Tk9UIFJFUVVJUkVEIHRvIHN0b3JlIHRoZSBMb2NhdGlvbiBJbmZvcm1hdGlvbiBzdXBwbGllZCBp biB0aGUgb3JpZ2luYWwgZmluZFNlcnZpY2UgcmVxdWVzdC4gIFRoaXMgbWVhbnMgdGhlIHNlcnZl ciBtYXkgbm90IGtub3cgaWYgYSBwbGFubmVkIGNoYW5nZSB3aWxsIGluIGZhY3QgaW52YWxpZGF0 ZSB0aGUgbG9jYXRpb24gc3RvcmVkIGluIHRoZSBMb1NUIGNsaWVudCwgYmVjYXVzZSBjaGFuZ2Vz IGNvdWxkIGJlIG1hZGUgaW4gdGhlIExvU1Qgc2VydmVyIHRoYXQgZG8gbm90IGFmZmVjdCB2YWxp ZGF0aW9uIG9mIHRoZSBjbGllbnQncyBzcGVjaWZpYyBMb2NhdGlvbiBJbmZvcm1hdGlvbi4gIFRo ZSBMb1NUIGNsaWVudCBtYXkgZmluZCB0aGF0IHVwb24gcmV2YWxpZGF0aW9uIHdpdGggdGhlIGNo YW5nZWQgc2VydmVyIHN0YXRlLCB0aGUgdmFsaWRhdGlvbiBkYXRhIGlzIHRoZSBzYW1lIGFzIGl0 IHdhcyBiZWZvcmUgdGhlIG5vdGlmaWNhdGlvbiB3YXMgcmVjZWl2ZWQuIDwvdD4KPHQ+VGhlICZs dDtsb2NhdGlvbkludmFsaWRhdGVkJmd0OyBvYmplY3QgZG9lcyBub3QgY29udGFpbiBpbmZvcm1h dGlvbiBhYm91dCB0aGUgbG9jYXRpb24sIGFzIHRoZSBVUkkgdG8gd2hpY2ggaXQgaXMgc2VudCBp cyBkZXRlcm1pbmVkIGJ5IHRoZSByZXF1ZXN0aW5nIGNsaWVudCBhbmQgY2FuIGJlIHVuaXF1ZSBm b3IgZWFjaCBvZiB0aGUgY2xpZW50J3MgbG9jYXRpb24gcmVjb3Jkcy48L3Q+CiAgIDwvc2VjdGlv bj4KPHNlY3Rpb24gdGl0bGU9IlVSSSBOb3QgU3RvcmVkIFdhcm5pbmciPgo8dD5UaGlzIGV4dGVu c2lvbiBhZGRzIGEgbmV3IHdhcm5pbmcgdG8gdGhlIGV4Y2VwdGlvbkNvbnRhaW5lciwgJ3VyaU5v dFN0b3JlZCcuICBUaGlzIHdhcm5pbmcgTVVTVCBOT1QgYmUgcmV0dXJuZWQgdW5sZXNzIHRoZSBy ZXF1ZXN0IGNvbnRhaW5zIGEgJmx0O3BsYW5uZWRDaGFuZ2UmZ3Q7IGVsZW1lbnQgd2l0aCBhICd1 cmknIGF0dHJpYnV0ZS4gIFRoZSB3YXJuaW5nIGlzIHJldHVybmVkIHdoZW4gdGhlIHNlcnZlciBk ZWNpZGVzIG5vdCB0byBzdG9yZSB0aGUgVVJJLiAgQXMgZGlzY3Vzc2VkIGFib3ZlLCB0aGlzIG1h eSBvY2N1ciBiZWNhdXNlLCBhbW9uZyBvdGhlciByZWFzb25zLCB0aGUgcG9saWN5IGF0IHRoZSBz ZXJ2ZXIgbGltaXRzIGhvdyBtYW55IFVSSXMgd2lsbCBiZSBzdG9yZWQgYWdhaW5zdCBhIHNwZWNp ZmljIGxvY2F0aW9uLCB0aGUgVVJJIGlzIG5vdCB3ZWxsIGZvcm1lZCBvciB0aGUgcG9saWN5IGF0 IHRoZSBzZXJ2ZXIgaGFzIHNvbWUgb3RoZXIgcmVzdHJpY3Rpb24gb24gdGhlIGZlYXR1cmUuPC90 PgogICA8L3NlY3Rpb24+CjxzZWN0aW9uIHRpdGxlPSJUaW1lLVRvLUxpdmUgKFRUTCkgaW4gUmVz cG9uc2UiPgo8dD5UaGlzIGV4dGVuc2lvbiBhZGRzIHRoZSAmbHQ7dHRsJmd0OyBlbGVtZW50IHRv IHRoZSAmbHQ7ZmluZFNlcnZpY2VSZXNwb25zZSZndDsuICBUaGUgJmx0O3R0bCZndDsgZWxlbWVu dApjb250YWlucyBhIGRhdGUgYW5kIHRpbWUgYWZ0ZXIgd2hpY2ggdGhlIGNsaWVudCBtYXkgd2lz aCB0byByZXZhbGlkYXRlIHRoZSBsb2NhdGlvbgphdCB0aGUgc2VydmVyLiAgQSBzZXJ2ZXIgTUFZ IGFkZCB0aGlzIGVsZW1lbnQgdG8gdGhlIHJlc3BvbnNlIGlmIHZhbGlkYXRpb24gaXMgcmVxdWVz dGVkLiAgVGhpcyBlbGVtZW50IHRha2VzIHRoZSBmb3JtIG9mIHRoZSAnZXhwaXJlcycgYXR0cmli dXRlIHBhdHRlcm4gb2YgPHhyZWYgdGFyZ2V0PSJSRkM1MjIyIi8+LCB3aGljaCBhbGxvd3MKdGhl IHZhbHVlcyAnTk8gQ0FDSEUnIG9yICdOTyBFWFBJUkFUSU9OJyB0byBiZSByZXR1cm5lZCBpbnN0 ZWFkIG9mIGEgZGF0ZVRpbWUgdmFsdWUuICBIb3dldmVyLCBmb3IgdGhlICZsdDt0dGwmZ3Q7IGVs ZW1lbnQgJ05PIENBQ0hFJyBoYXMgbm8KbWVhbmluZyBhbmQgTVVTVCBOT1QgYmUgcmV0dXJuZWQu ICAnTk8gRVhQSVJBVElPTicgbWVhbnMgdGhlIHNlcnZlciBkb2VzCm5vdCBoYXZlIGEgc3VnZ2Vz dGVkIHJldmFsaWRhdGlvbiBwZXJpb2QuPC90Pgo8dD5TZWxlY3RpbmcgYSByZXZhbGlkYXRpb24g aW50ZXJ2YWwgaXMgYSBjb21wbGV4IGJhbGFuY2luZyBvZiB0aW1lbGluZXNzLCBzZXJ2ZXIgbG9h ZCwgc3RhYmlsaXR5IG9mIHRoZSB1bmRlcmx5aW5nIGRhdGEsIGFuZCBwb2xpY3kgb2YgdGhlIExv U1Qgc2VydmVyLiAgVG9vIHNob3J0LCBhbmQgbG9hZCBvbiB0aGUgc2VydmVyIG1heSBvdmVyd2hl bG0gaXQuICBUb28gbG9uZyBhbmQgaW52YWxpZCBkYXRhIG1heSBwZXJzaXN0IGluIHRoZSBzZXJ2 ZXIgZm9yIHVuYWNjZXB0YWJsZSBsZW5ndGhzIG9mIHRpbWUuICBUaGUgVVJJIG5vdGlmaWNhdGlv biBtZWNoYW5pc20gcHJvdmlkZXMgdGltZWx5IG5vdGljZSB0byBjb29yZGluYXRlIGNoYW5nZXMs IGJ1dCBldmVuIHdpdGggaXQsIGl0IGlzIG9mdGVuIGFkdmlzYWJsZSB0byByZXZhbGlkYXRlIGRh dGEgZXZlbnR1YWxseS48L3Q+Cjx0PkluIGFyZWFzIHRoYXQgaGF2ZSBsaXR0bGUgY2hhbmdlIGlu IGRhdGEsIHN1Y2ggYXMgZnVsbHkgYnVpbHQgb3V0LCBzdGFibGUgY29tbXVuaXRpZXMgYWxyZWFk eSBwYXJ0IG9mIGEgbXVuaWNpcGFsaXR5LCBpdCBtYXkgYmUgcmVhc29uYWJsZSB0byBzZXQgcmV2 YWxpZGF0aW9uIHBlcmlvZHMgb2YgNiBtb250aHMgb3IgbG9uZ2VyLCBlc3BlY2lhbGx5IGlmIHRo ZSBVUkkgbWVjaGFuaXNtIGlzIHdpZGVseSBkZXBsb3llZCBhdCBib3RoIHRoZSBzZXJ2ZXIgYW5k IHRoZSBjbGllbnRzLiAgSW4gYXJlYXMgdGhhdCBhcmUgcXVpY2tseSBncm93aW5nLCAyMC0zMCBk YXkgcmV2YWxpZGF0aW9uIG1heSBiZSBtb3JlIGFwcHJvcHJpYXRlIGV2ZW4gdGhvdWdoIHN1Y2gg cmV2YWxpZGF0aW9uIHdvdWxkIGJlIHRoZSBtYWpvcml0eSBvZiB0aGUgdHJhZmZpYyBvbiB0aGUg TG9TVCBzZXJ2ZXIuPC90Pgo8dD5XaGVuIGEgcGxhbm5lZCBjaGFuZ2UgaXMgbWFkZSwgdHlwaWNh bGx5IHRoZSBUVEwgdmFsdWUgZm9yIHRoZSBhZmZlY3RlZCByZWNvcmRzIGlzIGxvd2VyZWQsIHNv IHRoYXQgcmV2YWxpZGF0aW9uIGlzIGZvcmNlZCBzb29uIGFmdGVyIHRoZSBjaGFuZ2UgaXMgaW1w bGVtZW50ZWQuICAgSXQgaXMgbm90IGFkdmlzYWJsZSB0byBzZXQgdGhlIGV4cGlyYXRpb24gcHJl Y2lzZWx5IGF0IHRoZSBwbGFubmVkIGNoYW5nZSB0aW1lIGlmIGEgbGFyZ2UgbnVtYmVyIG9mIHJl Y29yZHMgd2lsbCBiZSBjaGFuZ2VkLCBzaW5jZSB0aGF0IHdvdWxkIGNhdXNlIGEgbGFyZ2Ugc3Bp a2UgaW4gdHJhZmZpYyBhdCB0aGUgY2hhbmdlIHRpbWUuICBSYXRoZXIsIHRoZSBleHBpcmF0aW9u IHRpbWUgc2hvdWxkIGhhdmUgYSByYW5kb20gYWRkaXRpb25hbCB0aW1lIGFkZGVkIHRvIGl0IHRv IHNwcmVhZCBvdXQgdGhlIGxvYWQuPC90Pgo8L3NlY3Rpb24+CiAgICA8c2VjdGlvbiBhbmNob3I9 InNjaGVtYSIgdGl0bGU9IlJlcGxhY2VtZW50IFhNTCBzY2hlbWEiPgo8dD5UaGlzIHNjaGVtYSBp cyBhbiBpbmZvcm1hdGl2ZSBhbHRlcm5hdGl2ZSB0byBUaGUgUmVsYXggTkcgc2NoZW1hIGluIDx4 cmVmIHRhcmdldD0iUkZDNTIyMiIvPiA8L3Q+CjxmaWd1cmU+PGFydHdvcms+CiZsdDs/eG1sIHZl cnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8mZ3Q7CiZsdDt4czpzY2hlbWEgeG1sbnM6eHM9 Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIgogICAgICAgICAgIHhtbG5zPSJ1cm46 aWV0ZjpwYXJhbXM6eG1sOm5zOmxvc3QxIgogICAgICAgICAgIHRhcmdldE5hbWVzcGFjZT0idXJu OmlldGY6cGFyYW1zOnhtbDpuczpsb3N0MSIKICAgICAgICAgICBlbGVtZW50Rm9ybURlZmF1bHQ9 InF1YWxpZmllZCImZ3Q7CgogICZsdDt4czplbGVtZW50IG5hbWU9ImZpbmRTZXJ2aWNlIiZndDsK ICAgICZsdDt4czpjb21wbGV4VHlwZSZndDsKICAgICAgJmx0O3hzOnNlcXVlbmNlJmd0OwogICAg ICAgICZsdDt4czpncm91cCByZWY9InJlcXVlc3RMb2NhdGlvbiIvJmd0OwogICAgICAgICZsdDt4 czpncm91cCByZWY9ImNvbW1vblJlcXVlc3RQYXR0ZXJuIi8mZ3Q7CiAgICAgICZsdDsveHM6c2Vx dWVuY2UmZ3Q7CiAgICAgICZsdDt4czphdHRyaWJ1dGUgbmFtZT0idmFsaWRhdGVMb2NhdGlvbiIg dHlwZT0ieHM6Ym9vbGVhbiIvJmd0OwogICAgICAmbHQ7eHM6YXR0cmlidXRlIG5hbWU9InNlcnZp Y2VCb3VuZGFyeSImZ3Q7CiAgICAgICAgJmx0O3hzOnNpbXBsZVR5cGUmZ3Q7CiAgICAgICAgICAm bHQ7eHM6cmVzdHJpY3Rpb24gYmFzZT0ieHM6dG9rZW4iJmd0OwogICAgICAgICAgICAmbHQ7eHM6 ZW51bWVyYXRpb24gdmFsdWU9InJlZmVyZW5jZSIvJmd0OwogICAgICAgICAgICAmbHQ7eHM6ZW51 bWVyYXRpb24gdmFsdWU9InZhbHVlIi8mZ3Q7CiAgICAgICAgICAmbHQ7L3hzOnJlc3RyaWN0aW9u Jmd0OwogICAgICAgICZsdDsveHM6c2ltcGxlVHlwZSZndDsKICAgICAgJmx0Oy94czphdHRyaWJ1 dGUmZ3Q7CiAgICAgICZsdDt4czphdHRyaWJ1dGUgbmFtZT0icmVjdXJzaXZlIiB0eXBlPSJ4czpi b29sZWFuIi8mZ3Q7CiAgICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwogICZsdDsveHM6ZWxlbWVu dCZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ibGlzdFNlcnZpY2VzIiZndDsKICAgICZsdDt4 czpjb21wbGV4VHlwZSZndDsKICAgICAgJmx0O3hzOmdyb3VwIHJlZj0iY29tbW9uUmVxdWVzdFBh dHRlcm4iLyZndDsKICAgICZsdDsveHM6Y29tcGxleFR5cGUmZ3Q7CiAgJmx0Oy94czplbGVtZW50 Jmd0OwoKICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJsaXN0U2VydmljZXNCeUxvY2F0aW9uIiZndDsK ICAgICZsdDt4czpjb21wbGV4VHlwZSZndDsKICAgICAgJmx0O3hzOnNlcXVlbmNlJmd0OwogICAg ICAgICZsdDt4czpncm91cCByZWY9InJlcXVlc3RMb2NhdGlvbiIvJmd0OwogICAgICAgICZsdDt4 czpncm91cCByZWY9ImNvbW1vblJlcXVlc3RQYXR0ZXJuIi8mZ3Q7CiAgICAgICZsdDsveHM6c2Vx dWVuY2UmZ3Q7CiAgICAgICZsdDt4czphdHRyaWJ1dGUgbmFtZT0icmVjdXJzaXZlIiB0eXBlPSJ4 czpib29sZWFuIi8mZ3Q7CiAgICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwogICZsdDsveHM6ZWxl bWVudCZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iZ2V0U2VydmljZUJvdW5kYXJ5IiZndDsK ICAgICZsdDt4czpjb21wbGV4VHlwZSZndDsKICAgICAgJmx0O3hzOmdyb3VwIHJlZj0iZXh0ZW5z aW9uUG9pbnQiLyZndDsKICAgICAgJmx0O3hzOmF0dHJpYnV0ZUdyb3VwIHJlZj0ic2VydmljZUJv dW5kYXJ5S2V5Ii8mZ3Q7CiAgICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwogICZsdDsveHM6ZWxl bWVudCZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iZmluZFNlcnZpY2VSZXNwb25zZSImZ3Q7 CiAgICAmbHQ7eHM6Y29tcGxleFR5cGUmZ3Q7CiAgICAgICZsdDt4czpzZXF1ZW5jZSZndDsKICAg ICAgICAmbHQ7eHM6ZWxlbWVudCByZWY9Im1hcHBpbmciIG1heE9jY3Vycz0idW5ib3VuZGVkIi8m Z3Q7CiAgICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJsb2NhdGlvblZhbGlkYXRpb24iIG1pbk9j Y3Vycz0iMCIvJmd0OwogICAgICAgICZsdDt4czpncm91cCByZWY9ImNvbW1vblJlc3BvbnNlUGF0 dGVybiIvJmd0OwogICAgICAgICZsdDt4czpncm91cCByZWY9ImxvY2F0aW9uVXNlZCIvJmd0Owog ICAgICAmbHQ7L3hzOnNlcXVlbmNlJmd0OwogICAgJmx0Oy94czpjb21wbGV4VHlwZSZndDsKICAm bHQ7L3hzOmVsZW1lbnQmZ3Q7CgogICZsdDt4czplbGVtZW50IG5hbWU9Imxpc3RTZXJ2aWNlc1Jl c3BvbnNlIiZndDsKICAgICZsdDt4czpjb21wbGV4VHlwZSZndDsKICAgICAgJmx0O3hzOnNlcXVl bmNlJmd0OwogICAgICAgICZsdDt4czplbGVtZW50IHJlZj0ic2VydmljZUxpc3QiLyZndDsKICAg ICAgICAmbHQ7eHM6Z3JvdXAgcmVmPSJjb21tb25SZXNwb25zZVBhdHRlcm4iLyZndDsKICAgICAg Jmx0Oy94czpzZXF1ZW5jZSZndDsKICAgICZsdDsveHM6Y29tcGxleFR5cGUmZ3Q7CiAgJmx0Oy94 czplbGVtZW50Jmd0OwoKICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJsaXN0U2VydmljZXNCeUxvY2F0 aW9uUmVzcG9uc2UiJmd0OwogICAgJmx0O3hzOmNvbXBsZXhUeXBlJmd0OwogICAgICAmbHQ7eHM6 c2VxdWVuY2UmZ3Q7CiAgICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJzZXJ2aWNlTGlzdCIvJmd0 OwogICAgICAgICZsdDt4czpncm91cCByZWY9ImNvbW1vblJlc3BvbnNlUGF0dGVybiIvJmd0Owog ICAgICAgICZsdDt4czpncm91cCByZWY9ImxvY2F0aW9uVXNlZCIvJmd0OwogICAgICAmbHQ7L3hz OnNlcXVlbmNlJmd0OwogICAgJmx0Oy94czpjb21wbGV4VHlwZSZndDsKICAmbHQ7L3hzOmVsZW1l bnQmZ3Q7CgogICZsdDt4czplbGVtZW50IG5hbWU9ImdldFNlcnZpY2VCb3VuZGFyeVJlc3BvbnNl IiZndDsKICAgICZsdDt4czpjb21wbGV4VHlwZSZndDsKICAgICAgJmx0O3hzOnNlcXVlbmNlJmd0 OwogICAgICAgICZsdDt4czpncm91cCByZWY9InNlcnZpY2VCb3VuZGFyeSIvJmd0OwogICAgICAg ICZsdDt4czpncm91cCByZWY9ImNvbW1vblJlc3BvbnNlUGF0dGVybiIvJmd0OwogICAgICAmbHQ7 L3hzOnNlcXVlbmNlJmd0OwogICAgJmx0Oy94czpjb21wbGV4VHlwZSZndDsKICAmbHQ7L3hzOmVs ZW1lbnQmZ3Q7CgogICZsdDt4czpncm91cCBuYW1lPSJjb21tb25SZXF1ZXN0UGF0dGVybiImZ3Q7 CiAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7CiAgICAgICZsdDt4czpncm91cCByZWY9InNlcnZpY2Ui LyZndDsKICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJwYXRoIiBtaW5PY2N1cnM9IjAiLyZndDsK ICAgICAgJmx0O3hzOmdyb3VwIHJlZj0iZXh0ZW5zaW9uUG9pbnQiLyZndDsKICAgICZsdDsveHM6 c2VxdWVuY2UmZ3Q7CiAgJmx0Oy94czpncm91cCZndDsKCiAgJmx0O3hzOmdyb3VwIG5hbWU9ImNv bW1vblJlc3BvbnNlUGF0dGVybiImZ3Q7CiAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7CiAgICAgICZs dDt4czplbGVtZW50IHJlZj0id2FybmluZ3MiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJv dW5kZWQiLyZndDsKICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJwYXRoIi8mZ3Q7CiAgICAgICZs dDt4czpncm91cCByZWY9ImV4dGVuc2lvblBvaW50Ii8mZ3Q7CiAgICAmbHQ7L3hzOnNlcXVlbmNl Jmd0OwogICZsdDsveHM6Z3JvdXAmZ3Q7CgogICZsdDt4czpncm91cCBuYW1lPSJyZXF1ZXN0TG9j YXRpb24iJmd0OwogICAgJmx0O3hzOnNlcXVlbmNlJmd0OwogICAgICAmbHQ7eHM6ZWxlbWVudCBy ZWY9ImxvY2F0aW9uIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvJmd0OwogICAgJmx0Oy94czpzZXF1 ZW5jZSZndDsKICAmbHQ7L3hzOmdyb3VwJmd0OwoKICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJsb2Nh dGlvbiImZ3Q7CiAgICAmbHQ7eHM6Y29tcGxleFR5cGUmZ3Q7CiAgICAgICZsdDt4czpjb21wbGV4 Q29udGVudCZndDsKICAgICAgICAmbHQ7eHM6ZXh0ZW5zaW9uIGJhc2U9ImxvY2F0aW9uSW5mb3Jt YXRpb24iJmd0OwogICAgICAgICAgJmx0O3hzOmF0dHJpYnV0ZSBuYW1lPSJpZCIgdHlwZT0ieHM6 dG9rZW4iIHVzZT0icmVxdWlyZWQiLyZndDsKICAgICAgICAmbHQ7L3hzOmV4dGVuc2lvbiZndDsK ICAgICAgJmx0Oy94czpjb21wbGV4Q29udGVudCZndDsKICAgICZsdDsveHM6Y29tcGxleFR5cGUm Z3Q7CiAgJmx0Oy94czplbGVtZW50Jmd0OwoKICAmbHQ7eHM6Y29tcGxleFR5cGUgbmFtZT0ibG9j YXRpb25JbmZvcm1hdGlvbiImZ3Q7CiAgICAmbHQ7eHM6Z3JvdXAgcmVmPSJleHRlbnNpb25Qb2lu dCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLyZndDsKICAgICZsdDt4czphdHRyaWJ1dGUgbmFtZT0i cHJvZmlsZSIgdHlwZT0ieHM6Tk1UT0tFTiIvJmd0OwogICZsdDsveHM6Y29tcGxleFR5cGUmZ3Q7 CgogICZsdDt4czpncm91cCBuYW1lPSJzZXJ2aWNlQm91bmRhcnkiJmd0OwogICAgJmx0O3hzOnNl cXVlbmNlJmd0OwogICAgICAmbHQ7eHM6ZWxlbWVudCByZWY9InNlcnZpY2VCb3VuZGFyeSIgbWF4 T2NjdXJzPSJ1bmJvdW5kZWQiLyZndDsKICAgICZsdDsveHM6c2VxdWVuY2UmZ3Q7CiAgJmx0Oy94 czpncm91cCZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ic2VydmljZUJvdW5kYXJ5IiB0eXBl PSJsb2NhdGlvbkluZm9ybWF0aW9uIi8mZ3Q7CgogICZsdDt4czplbGVtZW50IG5hbWU9InNlcnZp Y2VCb3VuZGFyeVJlZmVyZW5jZSImZ3Q7CiAgICAmbHQ7eHM6Y29tcGxleFR5cGUmZ3Q7CiAgICAg ICZsdDt4czpncm91cCByZWY9ImV4dGVuc2lvblBvaW50Ii8mZ3Q7CiAgICAgICZsdDt4czphdHRy aWJ1dGVHcm91cCByZWY9InNvdXJjZSIvJmd0OwogICAgICAmbHQ7eHM6YXR0cmlidXRlR3JvdXAg cmVmPSJzZXJ2aWNlQm91bmRhcnlLZXkiLyZndDsKICAgICZsdDsveHM6Y29tcGxleFR5cGUmZ3Q7 CiAgJmx0Oy94czplbGVtZW50Jmd0OwoKICAmbHQ7eHM6YXR0cmlidXRlR3JvdXAgbmFtZT0ic2Vy dmljZUJvdW5kYXJ5S2V5IiZndDsKICAgICZsdDt4czphdHRyaWJ1dGUgbmFtZT0ia2V5IiB0eXBl PSJ4czp0b2tlbiIgdXNlPSJyZXF1aXJlZCIvJmd0OwogICZsdDsveHM6YXR0cmlidXRlR3JvdXAm Z3Q7CgogICZsdDt4czplbGVtZW50IG5hbWU9InBhdGgiJmd0OwogICAgJmx0O3hzOmNvbXBsZXhU eXBlJmd0OwogICAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7CiAgICAgICAgJmx0O3hzOmVsZW1lbnQg cmVmPSJ2aWEiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8mZ3Q7CiAgICAgICZsdDsveHM6c2VxdWVu Y2UmZ3Q7CiAgICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwogICZsdDsveHM6ZWxlbWVudCZndDsK CiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0idmlhIiZndDsKICAgICZsdDt4czpjb21wbGV4VHlwZSZn dDsKICAgICAgJmx0O3hzOmdyb3VwIHJlZj0iZXh0ZW5zaW9uUG9pbnQiLyZndDsKICAgICAgJmx0 O3hzOmF0dHJpYnV0ZUdyb3VwIHJlZj0ic291cmNlIi8mZ3Q7CiAgICAmbHQ7L3hzOmNvbXBsZXhU eXBlJmd0OwogICZsdDsveHM6ZWxlbWVudCZndDsKCiAgJmx0O3hzOmdyb3VwIG5hbWU9ImxvY2F0 aW9uVXNlZCImZ3Q7CiAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7CiAgICAgICZsdDt4czplbGVtZW50 IHJlZj0ibG9jYXRpb25Vc2VkIiBtaW5PY2N1cnM9IjAiLyZndDsKICAgICZsdDsveHM6c2VxdWVu Y2UmZ3Q7CiAgJmx0Oy94czpncm91cCZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ibG9jYXRp b25Vc2VkIiZndDsKICAgICZsdDt4czpjb21wbGV4VHlwZSZndDsKICAgICAgJmx0O3hzOmF0dHJp YnV0ZSBuYW1lPSJpZCIgdHlwZT0ieHM6dG9rZW4iIHVzZT0icmVxdWlyZWQiLyZndDsKICAgICZs dDsveHM6Y29tcGxleFR5cGUmZ3Q7CiAgJmx0Oy94czplbGVtZW50Jmd0OwoKICAmbHQ7eHM6YXR0 cmlidXRlR3JvdXAgbmFtZT0iZXhwaXJlcyImZ3Q7CiAgICAmbHQ7eHM6YXR0cmlidXRlIG5hbWU9 ImV4cGlyZXMiIHVzZT0icmVxdWlyZWQiJmd0OwogICAgICAmbHQ7eHM6c2ltcGxlVHlwZSZndDsK ICAgICAgICAmbHQ7eHM6dW5pb24gbWVtYmVyVHlwZXM9InhzOmRhdGVUaW1lIiZndDsKICAgICAg ICAgICZsdDt4czpzaW1wbGVUeXBlJmd0OwogICAgICAgICAgICAmbHQ7eHM6cmVzdHJpY3Rpb24g YmFzZT0ieHM6dG9rZW4iJmd0OwogICAgICAgICAgICAgICZsdDt4czplbnVtZXJhdGlvbiB2YWx1 ZT0iTk8tQ0FDSEUiLyZndDsKICAgICAgICAgICAgJmx0Oy94czpyZXN0cmljdGlvbiZndDsKICAg ICAgICAgICZsdDsveHM6c2ltcGxlVHlwZSZndDsKICAgICAgICAgICZsdDt4czpzaW1wbGVUeXBl Jmd0OwogICAgICAgICAgICAmbHQ7eHM6cmVzdHJpY3Rpb24gYmFzZT0ieHM6dG9rZW4iJmd0Owog ICAgICAgICAgICAgICZsdDt4czplbnVtZXJhdGlvbiB2YWx1ZT0iTk8tRVhQSVJBVElPTiIvJmd0 OwogICAgICAgICAgICAmbHQ7L3hzOnJlc3RyaWN0aW9uJmd0OwogICAgICAgICAgJmx0Oy94czpz aW1wbGVUeXBlJmd0OwogICAgICAgICZsdDsveHM6dW5pb24mZ3Q7CiAgICAgICZsdDsveHM6c2lt cGxlVHlwZSZndDsKICAgICZsdDsveHM6YXR0cmlidXRlJmd0OwogICZsdDsveHM6YXR0cmlidXRl R3JvdXAmZ3Q7CgogICZsdDt4czpzaW1wbGVUeXBlIG5hbWU9InFuYW1lTGlzdCImZ3Q7CiAgICAm bHQ7eHM6bGlzdCBpdGVtVHlwZT0ieHM6UU5hbWUiLyZndDsKICAmbHQ7L3hzOnNpbXBsZVR5cGUm Z3Q7CgogICZsdDt4czplbGVtZW50IG5hbWU9Im1hcHBpbmciJmd0OwogICAgJmx0O3hzOmNvbXBs ZXhUeXBlJmd0OwogICAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7CiAgICAgICAgJmx0O3hzOmVsZW1l bnQgcmVmPSJkaXNwbGF5TmFtZSIKICAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJz PSJ1bmJvdW5kZWQiLyZndDsKICAgICAgICAmbHQ7eHM6Z3JvdXAgcmVmPSJzZXJ2aWNlIi8mZ3Q7 CiAgICAgICAgJmx0O3hzOmNob2ljZSBtaW5PY2N1cnM9IjAiJmd0OwogICAgICAgICAgJmx0O3hz Omdyb3VwIHJlZj0ic2VydmljZUJvdW5kYXJ5Ii8mZ3Q7CiAgICAgICAgICAmbHQ7eHM6ZWxlbWVu dCByZWY9InNlcnZpY2VCb3VuZGFyeVJlZmVyZW5jZSIvJmd0OwogICAgICAgICZsdDsveHM6Y2hv aWNlJmd0OwogICAgICAgICZsdDt4czplbGVtZW50IHJlZj0idXJpIgogICAgICAgICAgICAgbWlu T2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvJmd0OwogICAgICAgICZsdDt4czplbGVt ZW50IHJlZj0ic2VydmljZU51bWJlciIgbWluT2NjdXJzPSIwIi8mZ3Q7CiAgICAgICAgJmx0O3hz Omdyb3VwIHJlZj0iZXh0ZW5zaW9uUG9pbnQiLyZndDsKICAgICAgJmx0Oy94czpzZXF1ZW5jZSZn dDsKICAgICAgJmx0O3hzOmF0dHJpYnV0ZUdyb3VwIHJlZj0iZXhwaXJlcyIvJmd0OwogICAgICAm bHQ7eHM6YXR0cmlidXRlIG5hbWU9Imxhc3RVcGRhdGVkIiB0eXBlPSJ4czpkYXRlVGltZSIKICAg ICAgICAgICAgdXNlPSJyZXF1aXJlZCIvJmd0OwogICAgICAmbHQ7eHM6YXR0cmlidXRlR3JvdXAg cmVmPSJzb3VyY2UiLyZndDsKICAgICAgJmx0O3hzOmF0dHJpYnV0ZSBuYW1lPSJzb3VyY2VJZCIg dHlwZT0ieHM6dG9rZW4iCiAgICAgICAgICAgIHVzZT0icmVxdWlyZWQiLyZndDsKICAgICAgJmx0 O3hzOmF0dHJpYnV0ZUdyb3VwIHJlZj0ibWVzc2FnZSIvJmd0OwogICAgJmx0Oy94czpjb21wbGV4 VHlwZSZndDsKICAmbHQ7L3hzOmVsZW1lbnQmZ3Q7CgogICZsdDt4czplbGVtZW50IG5hbWU9ImRp c3BsYXlOYW1lIiZndDsKICAgICZsdDt4czpjb21wbGV4VHlwZSZndDsKICAgICAgJmx0O3hzOnNp bXBsZUNvbnRlbnQmZ3Q7CiAgICAgICAgJmx0O3hzOmV4dGVuc2lvbiBiYXNlPSJ4czpzdHJpbmci Jmd0OwogICAgICAgICAgJmx0O3hzOmF0dHJpYnV0ZSByZWY9InhtbDpsYW5nIiB1c2U9InJlcXVp cmVkIi8mZ3Q7CiAgICAgICAgJmx0Oy94czpleHRlbnNpb24mZ3Q7CiAgICAgICZsdDsveHM6c2lt cGxlQ29udGVudCZndDsKICAgICZsdDsveHM6Y29tcGxleFR5cGUmZ3Q7CiAgJmx0Oy94czplbGVt ZW50Jmd0OwoKICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJ1cmkiIHR5cGU9InhzOmFueVVSSSIvJmd0 OwoKICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJzZXJ2aWNlTnVtYmVyIiZndDsKICAgICZsdDt4czpz aW1wbGVUeXBlJmd0OwogICAgICAmbHQ7eHM6cmVzdHJpY3Rpb24gYmFzZT0ieHM6dG9rZW4iJmd0 OwogICAgICAgICZsdDt4czpwYXR0ZXJuIHZhbHVlPSJbMC05KiNdKyIvJmd0OwogICAgICAmbHQ7 L3hzOnJlc3RyaWN0aW9uJmd0OwogICAgJmx0Oy94czpzaW1wbGVUeXBlJmd0OwogICZsdDsveHM6 ZWxlbWVudCZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ibG9jYXRpb25WYWxpZGF0aW9uIiZn dDsKICAgICZsdDt4czpjb21wbGV4VHlwZSZndDsKICAgICAgJmx0O3hzOnNlcXVlbmNlJmd0Owog ICAgICAgICZsdDt4czplbGVtZW50IHJlZj0idmFsaWQiIG1pbk9jY3Vycz0iMCIvJmd0OwogICAg ICAgICZsdDt4czplbGVtZW50IHJlZj0iaW52YWxpZCIgbWluT2NjdXJzPSIwIi8mZ3Q7CiAgICAg ICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJ1bmNoZWNrZWQiIG1pbk9jY3Vycz0iMCIvJmd0OwogICAg ICAgICZsdDt4czpncm91cCByZWY9ImV4dGVuc2lvblBvaW50Ii8mZ3Q7CiAgICAgICZsdDsveHM6 c2VxdWVuY2UmZ3Q7CiAgICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwogICZsdDsveHM6ZWxlbWVu dCZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0idmFsaWQiIHR5cGU9InFuYW1lTGlzdCIvJmd0 OwoKICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJpbnZhbGlkIiB0eXBlPSJxbmFtZUxpc3QiLyZndDsK CiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0idW5jaGVja2VkIiB0eXBlPSJxbmFtZUxpc3QiLyZndDsK CiAgJmx0O3hzOmNvbXBsZXhUeXBlIG5hbWU9ImV4Y2VwdGlvbkNvbnRhaW5lciImZ3Q7CiAgICAm bHQ7eHM6c2VxdWVuY2UmZ3Q7CiAgICAgICZsdDt4czpjaG9pY2UgbWluT2NjdXJzPSIwIiBtYXhP Y2N1cnM9InVuYm91bmRlZCImZ3Q7CiAgICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJiYWRSZXF1 ZXN0Ii8mZ3Q7CiAgICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJpbnRlcm5hbEVycm9yIi8mZ3Q7 CiAgICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJzZXJ2aWNlU3Vic3RpdHV0aW9uIi8mZ3Q7CiAg ICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJkZWZhdWx0TWFwcGluZ1JldHVybmVkIi8mZ3Q7CiAg ICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJmb3JiaWRkZW4iLyZndDsKICAgICAgICAmbHQ7eHM6 ZWxlbWVudCByZWY9Im5vdEZvdW5kIi8mZ3Q7CiAgICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJs b29wIi8mZ3Q7CiAgICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJzZXJ2aWNlTm90SW1wbGVtZW50 ZWQiLyZndDsKICAgICAgICAmbHQ7eHM6ZWxlbWVudCByZWY9InNlcnZlclRpbWVvdXQiLyZndDsK ICAgICAgICAmbHQ7eHM6ZWxlbWVudCByZWY9InNlcnZlckVycm9yIi8mZ3Q7CiAgICAgICAgJmx0 O3hzOmVsZW1lbnQgcmVmPSJsb2NhdGlvbkludmFsaWQiLyZndDsKICAgICAgICAmbHQ7eHM6ZWxl bWVudCByZWY9ImxvY2F0aW9uUHJvZmlsZVVucmVjb2duaXplZCIvJmd0OwogICAgICAmbHQ7L3hz OmNob2ljZSZndDsKICAgICAgJmx0O3hzOmdyb3VwIHJlZj0iZXh0ZW5zaW9uUG9pbnQiLyZndDsK ICAgICZsdDsveHM6c2VxdWVuY2UmZ3Q7CiAgICAmbHQ7eHM6YXR0cmlidXRlR3JvdXAgcmVmPSJz b3VyY2UiLyZndDsKICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwoKICAmbHQ7eHM6ZWxlbWVudCBu YW1lPSJlcnJvcnMiIHR5cGU9ImV4Y2VwdGlvbkNvbnRhaW5lciIvJmd0OwoKICAmbHQ7eHM6ZWxl bWVudCBuYW1lPSJ3YXJuaW5ncyIgdHlwZT0iZXhjZXB0aW9uQ29udGFpbmVyIi8mZ3Q7CgogICZs dDt4czpjb21wbGV4VHlwZSBuYW1lPSJiYXNpY0V4Y2VwdGlvbiImZ3Q7CiAgICAmbHQ7eHM6YW5u b3RhdGlvbiZndDsKICAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgRXhjZXB0 aW9uIHBhdHRlcm4uCiAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICZsdDsveHM6 YW5ub3RhdGlvbiZndDsKICAgICZsdDt4czpncm91cCByZWY9ImV4dGVuc2lvblBvaW50Ii8mZ3Q7 CiAgICAmbHQ7eHM6YXR0cmlidXRlR3JvdXAgcmVmPSJtZXNzYWdlIi8mZ3Q7CiAgJmx0Oy94czpj b21wbGV4VHlwZSZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iYmFkUmVxdWVzdCIgdHlwZT0i YmFzaWNFeGNlcHRpb24iLyZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iaW50ZXJuYWxFcnJv ciIgdHlwZT0iYmFzaWNFeGNlcHRpb24iLyZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ic2Vy dmljZVN1YnN0aXR1dGlvbiIgdHlwZT0iYmFzaWNFeGNlcHRpb24iLyZndDsKCiAgJmx0O3hzOmVs ZW1lbnQgbmFtZT0iZGVmYXVsdE1hcHBpbmdSZXR1cm5lZCIgdHlwZT0iYmFzaWNFeGNlcHRpb24i LyZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iZm9yYmlkZGVuIiB0eXBlPSJiYXNpY0V4Y2Vw dGlvbiIvJmd0OwoKICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJub3RGb3VuZCIgdHlwZT0iYmFzaWNF eGNlcHRpb24iLyZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ibG9vcCIgdHlwZT0iYmFzaWNF eGNlcHRpb24iLyZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ic2VydmljZU5vdEltcGxlbWVu dGVkIiB0eXBlPSJiYXNpY0V4Y2VwdGlvbiIvJmd0OwoKICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJz ZXJ2ZXJUaW1lb3V0IiB0eXBlPSJiYXNpY0V4Y2VwdGlvbiIvJmd0OwoKICAmbHQ7eHM6ZWxlbWVu dCBuYW1lPSJzZXJ2ZXJFcnJvciIgdHlwZT0iYmFzaWNFeGNlcHRpb24iLyZndDsKCiAgJmx0O3hz OmVsZW1lbnQgbmFtZT0iU1JTaW52YWxpZCIgdHlwZT0iYmFzaWNFeGNlcHRpb24iLyZndDsKCiAg Jmx0O3hzOmVsZW1lbnQgbmFtZT0ibG9jYXRpb25JbnZhbGlkIiB0eXBlPSJiYXNpY0V4Y2VwdGlv biIvJmd0OwoKICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJsb2NhdGlvblZhbGlkYXRpb25VbmF2YWls YWJsZSIKICAgICAgICAgIHR5cGU9ImJhc2ljRXhjZXB0aW9uIi8mZ3Q7CgogICZsdDt4czplbGVt ZW50IG5hbWU9ImxvY2F0aW9uUHJvZmlsZVVucmVjb2duaXplZCImZ3Q7CiAgICAgICAgICB0eXBl PSJiYXNpY0V4Y2VwdGlvbiIvJmd0OwoKICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJyZWRpcmVjdCIm Z3Q7CiAgICAmbHQ7eHM6Y29tcGxleFR5cGUmZ3Q7CiAgICAgICZsdDt4czpncm91cCByZWY9ImV4 dGVuc2lvblBvaW50Ii8mZ3Q7CiAgICAgICZsdDt4czphdHRyaWJ1dGUgbmFtZT0idGFyZ2V0IiB0 eXBlPSJhcHBVbmlxdWVTdHJpbmciCiAgICAgICAgICB1c2U9InJlcXVpcmVkIi8mZ3Q7CiAgICAg ICZsdDt4czphdHRyaWJ1dGVHcm91cCByZWY9InNvdXJjZSIvJmd0OwogICAgICAmbHQ7eHM6YXR0 cmlidXRlR3JvdXAgcmVmPSJtZXNzYWdlIi8mZ3Q7CiAgICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0 OwogICZsdDsveHM6ZWxlbWVudCZndDsKCiAgJmx0O3hzOmF0dHJpYnV0ZUdyb3VwIG5hbWU9Im1l c3NhZ2UiJmd0OwogICAgJmx0O3hzOmF0dHJpYnV0ZSBuYW1lPSJtZXNzYWdlIiB0eXBlPSJ4czp0 b2tlbiIvJmd0OwogICAgJmx0O3hzOmF0dHJpYnV0ZSByZWY9InhtbDpsYW5nIi8mZ3Q7CiAgJmx0 Oy94czphdHRyaWJ1dGVHcm91cCZndDsKCiAgJmx0O3hzOmdyb3VwIG5hbWU9InNlcnZpY2UiJmd0 OwogICAgJmx0O3hzOnNlcXVlbmNlJmd0OwogICAgICAmbHQ7eHM6ZWxlbWVudCByZWY9InNlcnZp Y2UiIG1pbk9jY3Vycz0iMCIvJmd0OwogICAgJmx0Oy94czpzZXF1ZW5jZSZndDsKICAmbHQ7L3hz Omdyb3VwJmd0OwoKICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJzZXJ2aWNlIiB0eXBlPSJ4czphbnlV UkkiLyZndDsKCiAgJmx0O3hzOnNpbXBsZVR5cGUgbmFtZT0iYXBwVW5pcXVlU3RyaW5nIiZndDsK ICAgICZsdDt4czpyZXN0cmljdGlvbiBiYXNlPSJ4czp0b2tlbiImZ3Q7CiAgICAgICZsdDt4czpw YXR0ZXJuIHZhbHVlPSIoW2EtekEtWjAtOVwtXStcLikrW2EtekEtWjAtOV0rIi8mZ3Q7CiAgICAm bHQ7L3hzOnJlc3RyaWN0aW9uJmd0OwogICZsdDsveHM6c2ltcGxlVHlwZSZndDsKCiAgJmx0O3hz OmF0dHJpYnV0ZUdyb3VwIG5hbWU9InNvdXJjZSImZ3Q7CiAgICAmbHQ7eHM6YXR0cmlidXRlIG5h bWU9InNvdXJjZSIgdHlwZT0iYXBwVW5pcXVlU3RyaW5nIiB1c2U9InJlcXVpcmVkIi8mZ3Q7CiAg Jmx0Oy94czphdHRyaWJ1dGVHcm91cCZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ic2Vydmlj ZUxpc3QiJmd0OwogICAgJmx0O3hzOnNpbXBsZVR5cGUmZ3Q7CiAgICAgICZsdDt4czpsaXN0IGl0 ZW1UeXBlPSJ4czphbnlVUkkiLyZndDsKICAgICZsdDsveHM6c2ltcGxlVHlwZSZndDsKICAmbHQ7 L3hzOmVsZW1lbnQmZ3Q7CgogICZsdDt4czpncm91cCBuYW1lPSJub3RMb3N0IiZndDsKICAgICZs dDt4czphbm5vdGF0aW9uJmd0OwogICAgICAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAg ICBBbnkgZWxlbWVudCBub3QgaW4gdGhlIExvU1QgbmFtZXNwYWNlLgogICAgICAmbHQ7L3hzOmRv Y3VtZW50YXRpb24mZ3Q7CiAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAmbHQ7eHM6Y2hv aWNlJmd0OwogICAgICAmbHQ7eHM6YW55IG5hbWVzcGFjZT0iIyNvdGhlciIgcHJvY2Vzc0NvbnRl bnRzPSJza2lwIi8mZ3Q7CiAgICAgICZsdDt4czphbnkgbmFtZXNwYWNlPSIjI2xvY2FsIiBwcm9j ZXNzQ29udGVudHM9InNraXAiLyZndDsKICAgICZsdDsveHM6Y2hvaWNlJmd0OwogICZsdDsveHM6 Z3JvdXAmZ3Q7CgogICZsdDt4czpncm91cCBuYW1lPSJhbnlFbGVtZW50IiZndDsKICAgICZsdDt4 czphbm5vdGF0aW9uJmd0OwogICAgICAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICBB IHdpbGRjYXJkIHBhdHRlcm4gZm9yIGluY2x1ZGluZyBhbnkgZWxlbWVudAogICAgICAgIGZyb20g YW55IG90aGVyIG5hbWVzcGFjZS4KICAgICAgJmx0Oy94czpkb2N1bWVudGF0aW9uJmd0OwogICAg Jmx0Oy94czphbm5vdGF0aW9uJmd0OwogICAgJmx0O3hzOnNlcXVlbmNlJmd0OwogICAgICAmbHQ7 eHM6YW55IHByb2Nlc3NDb250ZW50cz0ic2tpcCIKICAgICAgICAgIG1pbk9jY3Vycz0iMCIgbWF4 T2NjdXJzPSJ1bmJvdW5kZWQiLyZndDsKICAgICZsdDsveHM6c2VxdWVuY2UmZ3Q7CiAgJmx0Oy94 czpncm91cCZndDsKCiAgJmx0O3hzOmF0dHJpYnV0ZUdyb3VwIG5hbWU9ImFueUVsZW1lbnQiJmd0 OwogICAgJmx0O3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICZsdDt4czpkb2N1bWVudGF0aW9uJmd0 OwogICAgICAgIEEgd2lsZGNhcmQgcGF0dGVybiBmb3IgaW5jbHVkaW5nIGFueSBlbGVtZW50CiAg ICAgICAgZnJvbSBhbnkgb3RoZXIgbmFtZXNwYWNlLgogICAgICAmbHQ7L3hzOmRvY3VtZW50YXRp b24mZ3Q7CiAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAmbHQ7eHM6YW55QXR0cmlidXRl IHByb2Nlc3NDb250ZW50cz0ic2tpcCIvJmd0OwogICZsdDsveHM6YXR0cmlidXRlR3JvdXAmZ3Q7 CgogICZsdDt4czpncm91cCBuYW1lPSJleHRlbnNpb25Qb2ludCImZ3Q7CiAgICAmbHQ7eHM6YW5u b3RhdGlvbiZndDsKICAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgQSBwb2lu dCB3aGVyZSBmdXR1cmUgZXh0ZW5zaW9ucwogICAgICAgIChlbGVtZW50cyBmcm9tIG90aGVyIG5h bWVzcGFjZXMpCiAgICAgICAgY2FuIGJlIGFkZGVkLgogICAgICAmbHQ7L3hzOmRvY3VtZW50YXRp b24mZ3Q7CiAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7 CiAgICAgICZsdDt4czpncm91cCByZWY9Im5vdExvc3QiCiAgICAgICAgICAgbWluT2NjdXJzPSIw IiBtYXhPY2N1cnM9InVuYm91bmRlZCIvJmd0OwogICAgJmx0Oy94czpzZXF1ZW5jZSZndDsKICAm bHQ7L3hzOmdyb3VwJmd0OwoKJmx0Oy94czpzY2hlbWEmZ3Q7CjwvYXJ0d29yaz48L2ZpZ3VyZT48 L3NlY3Rpb24+CiAgICA8c2VjdGlvbiBhbmNob3I9ImV4dFNjaGVtYSIgdGl0bGU9IkV4dGVuc2lv biBYTUwgU2NoZW1hIj4KPHQ+VGhpcyBzY2hlbWEgcHJvdmlkZXMgdGhlIGV4dGVuc2lvbiB0byB0 aGUgcHJpb3Igc2VjdGlvbiBzY2hlbWEgZm9yIHBsYW5uZWQgY2hhbmdlczo8L3Q+CjxmaWd1cmU+ PGFydHdvcms+CiZsdDs/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8mZ3Q7CiZs dDt4czpzY2hlbWEgeG1sbnM6eHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIgog ICAgICAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmxvc3RQbGFubmVkQ2hhbmdl MSIKICAgICAgICAgICB0YXJnZXROYW1lc3BhY2U9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bG9z dFBsYW5uZWRDaGFuZ2UxIgogICAgICAgICAgIGVsZW1lbnRGb3JtRGVmYXVsdD0icXVhbGlmaWVk IiZndDsKICAgICAmbHQ7IS0tIEltcG9ydCBiYXNlIExvc3QgLS0mZ3Q7CiAgICAgJmx0O3hzOmlt cG9ydCBuYW1lc3BhY2U9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bG9zdDEiLyZndDsKJmx0OyEt LSBleHRlbmQgdGhlIGV4dGVuc2lvblBvaW50IG9mIGNvbW1vblJlcXVlc3RQYXR0ZXJuIG9mIGZp bmRTZXJ2aWNlCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB0byBpbmNsdWRlOiAgLS0mZ3Q7CiAgICAgICAgeHM6Z3JvdXAgcmVmPSJwbGFubmVk Q2hhbmdlIiBtaW5PY2N1cnM9IjEiLyZndDsKCiZsdDshLS0gd2hlcmUgLS0mZ3Q7CiAgICAgICAm bHQ7eHM6Z3JvdXAgbmFtZT0icGxhbm5lZENoYW5nZSImZ3Q7CiAgICAgICAgICAgJmx0O3hzOnNl cXVlbmNlJmd0OwogICAgICAgICAgICAgICZsdDt4czplbGVtZW50IHJlZj0idXJpIiB0eXBlPSJ4 czphbnlVUkkiIC8mZ3Q7CiAgICAgICAgICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJpbnZhbGlk QXNPZiIgdHlwZT0ieHM6ZGF0ZVRpbWUiIC8mZ3Q7CiAgICAgICAgICAgICAgJmx0O3hzOmFueSBu YW1lc3BhY2U9IiMjb3RoZXIiIHByb2Nlc3NDb250ZW50cz0ibGF4IgogICAgICAgICAgICAgICAg IG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLyZndDsKICAgICAgICAgICAmbHQ7 L3hzOnNlcXVlbmNlJmd0OwogICAgICAgICZsdDsveHM6Z3JvdXAmZ3Q7CgombHQ7IS0tIGV4dGVu ZCB0aGUgZXh0ZW5zaW9uUG9pbnQgb2YgY29tbW9uUmVzcG9uc2VQYXR0ZXJuIGluCiAgICAgICAg ICAgICAgICAgICAgICAgICAgZmluZFNlcnZpY2VSZXNwb25zZSB0byBpbmNsdWRlOiAtLSZndDsK ICAgICAgICAgICAmbHQ7eHM6YXR0dHJpYnV0ZSBuYW1lPSJhc09mIiB0eXBlPSJ4czpkYXRlVGlt ZSIgbWluT2NjdXJzPSIwIi8mZ3Q7CiAgICAgICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJ0dGwi IHR5cGU9ImV4cGlyZXMiIG1pbk9jY3Vycz0iMCIgLyZndDsKCiZsdDshLS0gZXh0ZW5kIHRoZSBl eHRlbnNpb25Qb2ludCBvZiBleHRlbnNpb25Db250YWluZXIgdG8gaW5jbHVkZTogLS0mZ3Q7CiAg ICAgICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJ1cmlOb3RTdG9yZWQiLyZndDsKJmx0OyEtLSB3 aGVyZSAtLSZndDsKICAgICAgICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJ1cmlOb3RTdG9yZWQi IHR5cGU9ImJhc2ljRXhjZXB0aW9uIi8mZ3Q7CiAgICAgICAgICAgCgoKJmx0Oy94czpzY2hlbWEm Z3Q7CjwvYXJ0d29yaz48L2ZpZ3VyZT48L3NlY3Rpb24+CiAgICA8c2VjdGlvbiBhbmNob3I9Imxv Y2F0aW9uSW52YWxpZGF0ZWQiIHRpdGxlPSJsb2NhdGlvbkludmFsaWRhdGVkIFNjaGVtYSI+Cjx0 PlRoaXMgc2NoZW1hIGRlZmluZXMgdGhlIG9iamVjdCB1c2VkIGZvciB0aGUgbm90aWZpY2F0aW9u IHRoYXQgYSBsb2NhdGlvbiBpcyBwb3RlbnRpYWxseSBpbnZhbGlkYXRlZCBzZW50IGJ5IGEgTG9T VCBzZXJ2ZXIgdG8gYSBjbGllbnQgdGhhdCByZXF1ZXN0ZWQgaXQuPC90Pgo8ZmlndXJlPjxhcnR3 b3JrPgombHQ7P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/Jmd0OwombHQ7eHM6 c2NoZW1hIHhtbG5zOnhzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIKICAgIHht bG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmxvc3RMb2NhdGlvbkludmFsaWRhdGVkMSIKICAg IHRhcmdldE5hbWVzcGFjZT0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpsb3N0TG9jYXRpb25JbnZh bGlkYXRlZDEiCiAgICBlbGVtZW50Rm9ybURlZmF1bHQ9InF1YWxpZmllZCImZ3Q7CiAmbHQ7eHM6 ZWxlbWVudCBuYW1lPSJsb2NhdGlvbkludmFsaWRhdGVkIiZndDsKICAgJmx0O3hzOmFubm90YXRp b24mZ3Q7CiAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICBBIHBvaW50IHdoZXJl IGZ1dHVyZSBleHRlbnNpb25zCiAgICAgICAoZWxlbWVudHMgZnJvbSBvdGhlciBuYW1lc3BhY2Vz KQogICAgICAgY2FuIGJlIGFkZGVkLgogICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZndDsKICAg Jmx0Oy94czphbm5vdGF0aW9uJmd0OwogICAgICZsdDt4czpjb21wbGV4VHlwZSZndDsKICAgICAg Jmx0O3hzOnNlcXVlbmNlJmd0OwogICAgICAgICZsdDt4czpncm91cCByZWY9Im5vdExvc3QiCiAg ICAgICAgICAgIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLyZndDsKICAgICAg Jmx0Oy94czpzZXF1ZW5jZSZndDsKICAgICAgJmx0O3hzOmF0dHJpYnV0ZSBuYW1lPSJhc09mIiB0 eXBlPSJ4czpkYXRlVGltZSIvJmd0OwoKJmx0Oy94czpzY2hlbWEmZ3Q7CjwvYXJ0d29yaz48L2Zp Z3VyZT48L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gYW5jaG9yPSJzZWN1cml0eSIgdGl0bGU9IlNl Y3VyaXR5IENvbnNpZGVyYXRpb25zIj4KICAgICAgPHQ+QXMgYW4gZXh0ZW5zaW9uIHRvIExvU1Qs IHRoaXMgZG9jdW1lbnQgaW5oZXJpdHMgdGhlIHNlY3VyaXR5IGlzc3VlcyByYWlzZWQgaW4gPHhy ZWYgdGFyZ2V0PSJSRkM1MjIyIi8+LiAgVGhlIHNlcnZlciBjb3VsZCBiZSB0cmlja2VkIGludG8g c3RvcmluZyBhIG1hbGljaW91cyBVUkkgd2hpY2gsIHdoZW4gc2VudCB0aGUgbG9jYXRpb25JbnZh bGlkYXRlZCBvYmplY3QgY291bGQgdHJpZ2dlciBzb21ldGhpbmcgdW50b3dhcmQuICBUaGUgc2Vy dmVyIE1VU1QgTk9UIGFjY2VwdCBhbnkgZGF0YSBmcm9tIHRoZSBjbGllbnQgaW4gcmVzcG9uc2Ug dG8gUE9TVGluZyB0aGUgbG9jYXRpb25JbnZhbGlkYXRlZC48L3Q+CgogICAgICA8dD5UaGUgc2Vy dmVyIGlzIHN1YmplY3QgdG8gYWJ1c2UgYnkgY2xpZW50cyBiZWNhdXNlIGl0IGlzIGJlaW5nIGFz a2VkIHRvIHN0b3JlIHNvbWV0aGluZyBhbmQgbWF5IG5lZWQgdG8gc2VuZCBkYXRhIHRvIGFuIHVu Y29udHJvbGxlZCBVUkkuICBDbGllbnRzIGNvdWxkIHJlcXVlc3QgbWFueSBVUklzIGZvciB0aGUg c2FtZSBsb2NhdGlvbiwgZm9yIGV4YW1wbGUuICBUaGUgc2VydmVyIE1VU1QgaGF2ZSBwb2xpY3kg dGhhdCBsaW1pdHMgdXNlIG9mIHRoaXMgbWVjaGFuaXNtIGJ5IGEgZ2l2ZW4gY2xpZW50LiAgSWYg dGhlIHBvbGljeSBpcyBleGNlZWRlZCwgdGhlIHNlcnZlciByZXR1cm5zIHRoZSAndXJpTm90U3Rv cmVkJyB3YXJuaW5nLiAgVGhlIHNlcnZlciBNVVNUIHZhbGlkYXRlIHRoYXQgdGhlIGNvbnRlbnQg b2YgdGhlICd1cmknIGF0dHJpYnV0ZSBzZW50IGlzIHN5bnRhY3RpY2FsbHkgdmFsaWQgYW5kIG1l ZXRzIHRoZSAyNTYgYnl0ZXMgbGltaXQuICBXaGVuIHNlbmRpbmcgdGhlIGxvY2F0aW9uSW52YWxp ZGF0ZWQgb2JqZWN0IHRvIHRoZSBVUkkgc3RvcmVkLCB0aGUgc2VydmVyIE1VU1QgcHJvdGVjdCBp dHNlbGYgYWdhaW5zdCBjb21tb24gSFRUUCB2dWxuZXJhYmlsaXRpZXMuCiAgICAgIDwvdD4KICAg IDx0PlRoZSBtdXR1YWwgYXV0aGVudGljYXRpb24gYmV0d2VlbiBjbGllbnQgYW5kIHNlcnZlciBp cyBSRUNPTU1FTkRFRCBmb3IgYm90aCB0aGUgaW5pdGlhbCAmbHQ7ZmluZFNlcnZpY2UmZ3Q7IG9w ZXJhdGlvbiB0aGF0IHJlcXVlc3RzIHN0b3JpbmcgdGhlIFVSSSBhbmQgdGhlIHNlbmRpbmcgb2Yg dGhlICdsb2NhdGlvbkludmFsaWRhdGVkJyBvYmplY3QuICBUaGUgc2VydmVyIHNob3VsZCBiZSB3 ZWxsIGtub3duIHRvIHRoZSBjbGllbnQsIGFuZCBpdHMgY3JlZGVudGlhbCBzaG91bGQgYmUgbGVh cm5lZCBpbiBhIHJlbGlhYmxlIHdheS4gIEZvciBleGFtcGxlLCBhIHB1YmxpYyBzYWZldHkgc3lz dGVtIG9wZXJhdGluZyB0aGUgTG9TVCBzZXJ2ZXIgbWF5IGhhdmUgYSBjcmVkZW50aWFsIHRyYWNl YWJsZSB0byBhIHdlbGwga25vd24gQ2VydGlmaWNhdGUgQXV0aG9yaXR5IGtub3duIHRvIHByb3Zp ZGUgY3JlZGVudGlhbHMgZm9yIHB1YmxpYyBzYWZldHkgYWdlbmNpZXMuICBDbGllbnRzIG1heSBi ZSBvcGVyYXRlZCBieSBsb2NhbCBJU1BzIG9yIG90aGVyIHNlcnZpY2UgcHJvdmlkZXJzIHRoYXQg Y2FuIHJlYXNvbmFibHkgb2J0YWluIGEgZ29vZCBjcmVkZW50aWFsIHRvIHVzZSBmb3IgdGhlIHNl cnZlciBzaWRlIG9mIHRoZSBMb1NUIHNlcnZlcidzIFBPU1QgdHJhbnNhY3Rpb24gdXNpbmcgdGhl IFVSSS4gIFdoZXJlIHRoZSBsb1NUIHNlcnZlciBkb2VzIG5vdCByZWNvZ25pemUgdGhlIGNsaWVu dCwgaXRzIHBvbGljeSBNQVkgbGltaXQgdGhlIHVzZSBvZiB0aGlzIGZlYXR1cmUgYmV5b25kIHdo YXQgaXQgd291bGQgbGltaXQgYSBjbGllbnQgaXQgcmVjb2duaXplcy48L3Q+CiAgICA8L3NlY3Rp b24+CiAgICA8c2VjdGlvbiBhbmNob3I9ImlhbmEiIHRpdGxlPSJJQU5BIENvbnNpZGVyYXRpb25z Ij4KICAgIDxzZWN0aW9uIHRpdGxlPSJSZXBsYWNlbWVudCBYTUwgU2NoZW1hIFJlZ2lzdHJhdGlv biI+CiAgICA8ZmlndXJlPjxhcnR3b3JrPjwhW0NEQVRBWwogICBVUkk6ICB1cm46aWV0ZjpwYXJh bXM6eG1sOnNjaGVtYTpsb3N0MwogICBSZWdpc3RyYW50IENvbnRhY3Q6ICBJRVRGIEVDUklUIFdv cmtpbmcgR3JvdXAsIEJyaWFuIFJvc2VuCiAgICAgIChickBicmlhbnJvc2VuLm5ldCkuCiAgIFhN TDoKICAgICAgQkVHSU4KICAgICAgPD94bWwgdmVyc2lvbj0iMi4wIj8+CiAgICAgIDwhRE9DVFlQ RSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgWEhUTUwgQmFzaWMgMS4wLy9FTiIKICAgICAgImh0 dHA6Ly93d3cudzMub3JnL1RSL3hodG1sLWJhc2ljL3hodG1sLWJhc2ljMTAuZHRkIj4KICAgICAg PGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiPgogICAgICA8aGVhZD4K ICAgICAgPG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIgogICAgICAgICAgY29udGVudD0i dGV4dC9odG1sO2NoYXJzZXQ9aXNvLTg4NTktMSIvPgogICAgICA8dGl0bGU+TG9TVCBOYW1lc3Bh Y2U8L3RpdGxlPgogICAgICA8L2hlYWQ+CiAgICAgIDxib2R5PgogICAgICA8aDE+TmFtZXNwYWNl IGZvciBMb1NUPC9oMT4KICAgICAgPGgyPnVybjppZXRmOnBhcmFtczp4bWw6bnM6bG9zdDM8L2gy PgogICAgICA8cD5TZWUgPGEgaHJlZj0iaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZj Pz8/Py50eHQiPgogICAgICBSRkM/Pz8/PC9hPi48L3A+CiAgICAgIDwvYm9keT4KICAgICAgPC9o dG1sPgogICAgICBFTkQKICBdXT48L2FydHdvcms+PC9maWd1cmU+CiAgPHQ+ICBUaGUgWE1MIFNj aGVtYSBpcyBmb3VuZCBpbiA8eHJlZiB0YXJnZXQ9InNjaGVtYSIvPi48L3Q+CiA8L3NlY3Rpb24+ CiAgICA8c2VjdGlvbiB0aXRsZT0iUGxhbm5lZCBDaGFuZ2UgRXh0ZW5zaW9uIFhNTCBTY2hlbWEg UmVnaXN0cmF0aW9uIj4KICAgIDxmaWd1cmU+PGFydHdvcms+PCFbQ0RBVEFbCiAgIFVSSTogIHVy bjppZXRmOnBhcmFtczp4bWw6c2NoZW1hOmxvc3RQbGFubmVkQ2hhbmdlMQogICBSZWdpc3RyYW50 IENvbnRhY3Q6ICBJRVRGIEVDUklUIFdvcmtpbmcgR3JvdXAsIEJyaWFuIFJvc2VuCiAgICAgIChi ckBicmlhbnJvc2VuLm5ldCkuCiAgIFhNTDoKCiAgIEJFR0lOCiAgIDw/eG1sIHZlcnNpb249IjIu MCI/PgogICA8IURPQ1RZUEUgaHRtbCBQVUJMSUMgIi0vL1czQy8vRFREIFhIVE1MIEJhc2ljIDEu MC8vRU4iCiAgICAgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sLWJhc2ljL3hodG1sLWJhc2lj MTAuZHRkIj4KICAgPGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiPgog ICA8aGVhZD4KICAgICA8bWV0YSBodHRwLWVxdWl2PSJjb250ZW50LXR5cGUiCiAgICAgICAgICAg Y29udGVudD0idGV4dC9odG1sO2NoYXJzZXQ9aXNvLTg4NTktMSIvPgogICAgIDx0aXRsZT5Mb1NU IFBsYW5uZWQgQ2hhbmdlIE5hbWVzcGFjZTwvdGl0bGU+CiAgIDwvaGVhZD4KICAgPGJvZHk+CiAg ICAgPGgxPk5hbWVzcGFjZSBmb3IgTG9TVCA8L2gxPgogICAgIDxoMj51cm46aWV0ZjpwYXJhbXM6 eG1sOm5zOmxvc3RQbGFubmVkQ2hhbmdlMTwvaDI+CiAgIDxwPlNlZSA8YSBocmVmPSJodHRwOi8v d3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM/Pz8/LnR4dCI+CiAgICAgIFJGQz8/Pz88L2E+Ljwv cD4KICAgPC9ib2R5PgogICA8L2h0bWw+CiAgIEVORAoKICBdXT48L2FydHdvcms+PC9maWd1cmU+ CiAgPHQ+ICBUaGUgWE1MIFNjaGVtYSBpcyBmb3VuZCBpbiA8eHJlZiB0YXJnZXQ9ImV4dFNjaGVt YSIvPi48L3Q+Cjwvc2VjdGlvbj4KCjxzZWN0aW9uIHRpdGxlPSJsb2NhdGlvbkludmFsaWRhdGVk IFhNTCBTY2hlbWEgUmVnaXN0cmF0aW9uIj4KPGZpZ3VyZT48YXJ0d29yaz48IVtDREFUQVsKVVJJ OiAgdXJuOmlldGY6cGFyYW1zOnhtbDpzY2hlbWE6bG9zdExvY2F0aW9uSW52YWxpZGF0ZWQxClJl Z2lzdHJhbnQgQ29udGFjdDogIElFVEYgRUNSSVQgV29ya2luZyBHcm91cCwgQnJpYW4gUm9zZW4K ICAoYnJAYnJpYW5yb3Nlbi5uZXQpLgpYTUw6CgpCRUdJTgo8P3htbCB2ZXJzaW9uPSIyLjAiPz4K PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCBCYXNpYyAxLjAvL0VOIgoi aHR0cDovL3d3dy53My5vcmcvVFIveGh0bWwtYmFzaWMveGh0bWwtYmFzaWMxMC5kdGQiPgo8aHRt bCB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94aHRtbCI+CjxoZWFkPgo8bWV0YSBodHRw LWVxdWl2PSJjb250ZW50LXR5cGUiCiAgICBjb250ZW50PSJ0ZXh0L2h0bWw7Y2hhcnNldD1pc28t ODg1OS0xIi8+Cjx0aXRsZT5Mb1NUIExvY2F0aW9uIEludmFsaWRlZCBOYW1lc3BhY2U8L3RpdGxl Pgo8L2hlYWQ+Cjxib2R5Pgo8aDE+TmFtZXNwYWNlIGZvciBMb1NUIExvY2F0aW9uIEludmFsaWRh dGVkIG5vdGlmaWNhdGlvbjwvaDE+CjxoMj51cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmxvc3RMb2Nh dGlvbkludmFsaWRhdGVkMTwvaDI+CjxwPlNlZSA8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0 b3Iub3JnL3JmYy9yZmM/Pz8/LnR4dCI+ClJGQz8/Pz88L2E+LjwvcD4KPC9ib2R5Pgo8L2h0bWw+ CkVORApdXT48L2FydHdvcms+PC9maWd1cmU+Cjx0PiAgVGhlIFhNTCBTY2hlbWEgaXMgZm91bmQg aW4gPHhyZWYgdGFyZ2V0PSJsb2NhdGlvbkludmFsaWRhdGVkIi8+LjwvdD4KCjwvc2VjdGlvbj48 L3NlY3Rpb24+CiAgIDwvbWlkZGxlPgoKICA8YmFjaz4KCiAgICA8cmVmZXJlbmNlcyB0aXRsZT0i Tm9ybWF0aXZlIFJlZmVyZW5jZXMiPgogICAgICAmUkZDMjExOTsKICAgICAgJlJGQzUyMjI7CiAg ICA8L3JlZmVyZW5jZXM+CiAgPC9iYWNrPgo8L3JmYz4K --=_MailMate_321F8108-A8BB-4A6C-AC31-1622E59E899C_= Content-Disposition: attachment; filename=Diff-xml.html Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = = = = = = = = = = Diff: draft-ietf-ecrit-lost-planned-changes-04.xml - draft-ietf-= ecrit-lost-planned-changes-04-rg.xml = = = = = = = = = = change date, and a date that al= lows the LoST client to request that the <= td class=3D"rblock">optional Time-To-Live element to the response, which = informs clients of<= td class=3D"rblock">the current expected lifetime of a validation. This document also <= td class=3D"rblock">provides a conventional XML schema for LoST, as a backwards compatible <= td class=3D"rblock">alternative to the RelaxNG schema in RFC5222<= /tr> <= td class=3D"lineno"><= td class=3D"rblock">future date, and new locations= may become valid after the date. If <= td class=3D"rblock">specified, the URI may be retained by the LoST server and may be <= /td><= td class=3D"rblock">associated with the data record that was validated, a= nd used to notify <= td class=3D"rblock">the the LoST client (e.g., a Location Information Server [LIS]) wh= en a <= td class=3D"rblock">location which was previously valid will become inval= id. The date may <= td class=3D"rblock">be used by a client to ask a server to= perform validation as of a <= td class=3D"rblock">future date. In addition to this mechanism, the = = <= td class=3D"rblock">part of the county/province. This kind of annexation= has an effective <= td class=3D"rblock">date and time (typically 00:00 on the first or last d= ay of a month), <= td class=3D"rblock">known in advance. Other kinds= of changes may also occur, and these <= td class=3D"rblock">will almost always also have a= n effective date that is known in <= /tr> <= td class=3D"rblock">advance.</t>= <= td class=3D"rblock">revalidation.</t>= circumstance where the location = in the original request may become = = = <= td class=3D"rblock">the location may become invalid.</t><= td class=3D"rblock"><= td class=3D"rblock"><t>In situations where it is not practical or advisable for the LIS to <= td class=3D"rblock">maintain a stable URI for each of it= s records, periodic revalidation <= td class=3D"rblock">can still be used to ma= intain the data in the LIS. However, the LoST <= td class=3D"rblock">server should be able to influ= ence the rate of such revalidation. For <= td class=3D"rblock">this purpose, this extension a= dds a Time to Live (TTL) element to the <= td class=3D"rblock">&lt;findServiceResponse&am= p;gt; which provides advice from the server to <= td class=3D"rblock">the LIS of when validation is suggested.</t><t>There are quite a few implementations of LoST. = Experience with <section anchor=3D"conventions" title=3D"Conventi= ons used in this = = <= td class=3D"lineno">= If the server receives a 'uri' for the same location from the same = = operation fails, the server MAY retry the operation imm= ediately, and if <= td class=3D"right"><t>The LoST server is NOT REQUIRED to store the = Location Information server that do not affect validation of the client's specific Location <= td class=3D"rblock"><t>The &lt;locationI= nvalidated&gt; object does not contain information <= td class=3D"rblock">about the location, as the URI= to which it is sent is determined by the <= td class=3D"rblock">requesting client and can be u= nique for each of the client's location <= td class=3D"rblock">records.</t>= policy at the server limits how many URIs will be stor= ed against a server has some other restriction on the feature.</t= ><= td> <= /tr> = = <= td> = <= td class=3D"rblock">advisable to revalidate data eventually.</t>= &lt;xs:import namespace=3D"urn:ietf:params:xml= :ns:lost1"/&gt;= = &lt;xs:element ref=3D"uri" type=3D"xs:= anyURI" /&gt; &lt;xs:any namespace=3D"##other" proc= essContents=3D"lax" = = <section anchor=3D"security" title=3D"Security Co= nsiderations">= = safety system operating the LoST server may have a cred= ential traceable =
< dra= ft-ietf-ecrit-lost-planned-changes-04.xml  &nb= sp;draft-ietf-ecrit-lost-planned-chan= ges-04-rg.xml >= ;
skipping to= change at line 44 &= para; skipping to change at line 44
<email&= gt;br@brianrosen.net</email> = <email>br@brianrosen.net</email>
</address= > </address>
</author>= ; </author>
<date year=3D= "2021"/> <date year=3D"2021"/= >
<area>AR= T</area> <area>ART</= area>
<workgroup&= gt;=C3=A9crit</workgroup> <= ;workgroup>=C3=A9crit</workgroup>
<keyword>= ;Internet-Draft</keyword> <= ;keyword>Internet-Draft</keyword>
<abstract&g= t; <abstract>
<t>T= his document defines an extension to LoST (= RFC5222) that <t>This doc= ument defines an extension to the Location to Serv= ice
allows a planned= change to the data = in the LoST server to occur. Translation (LoST) protocol (RFC5222) that allows a LoST server to
Records that previously were valid w= ill become invalid at a date in the = notify a clien= t of planned changes to the data. This extension is only
future, and new locations will become valid after the date. The useful with th= e validation function of LoST. It is beneficial f= or LoST
extension adds t= wo elements to the &lt;findservice&gt; request: A URI validation clients to be aware of plan= ned changes, as records that
to be used to inform the LIS = that previously valid locations will be previously were valid may become invalid= at a known future date, and
invalid after the planned change date, and add a date which requests new locations may= become valid after the date. This = extension adds two
the server to perform validation as of the date specified. I= t also elements to the &lt;findService&gt; request: A URI that the LoST server
adds an optional= Time-To-Live element to the response, which informs can use to inform the LoST client (e.g., a Location Information Server
clients about the current expected lifetime of the validation. This [LIS]) that previously valid locations wil= l be invalid after a planned
document also pr= ovides a conventional XML schema for LoST, as backwards
compatible alter= native to the RelaxNG schema in RFC5222 server perform validation as of the date = specified. It also adds an
</t> </t>
</abstract&= gt; </abstract>
</front> </front>
<middle> <middle>
<section ti= tle=3D"Introduction"> <sectio= n title=3D"Introduction">
<t>T= his document describes an update to the LoST protocol + which <t>This document describes an extension to the Location to
allows a &lt;findservice&gt; request to optionally add a URI and a date Service Translation (LoST) protocol = <xref target=3D"RFC5222"/> to assist<= /span>
to be used with planned changes to the underlying location i= nformation with planned changes to th= e underlying location information in the
in the server. = The URI is retained by the LoST server, associated with server. The extension allows a &lt;find= Service&gt; request to
the data record = that was validated, and used to notify the LIS (th= e optio= nally contain a URI, and optionally a date. This extension is
LoST client) when a location which was previously valid wil= l become usefu= l in the context of the validation function of LoST. It is
invalid. The da= te is used by the client to ask the server to perform beneficial for L= oST validation clients to be aware of planned changes,
validation as of= a future date. In addition to this mechanism, the as records that previously were vali= d may become invalid at a known
&lt;findservic= eResponse&gt; is also extended to provide a Time-To-Live &lt;findserviceResponse&gt; is also extend= ed to provide a Time-To-Live
(TTL) for validati= on, after which the client should revalidate the (TTL) for validation, after which the client should revalidate= the
location.= location.
</t> </t>
<t>Val= idation of civic locations involves dealing with data that <t>Validation of civic locations involve= s dealing with data that
changes over time. A typical example is a portion of a cou= nty or may cha= nge over time. A typical example is when a portion of a county
province that wa= s not part of a municipality is =E2=80=9Cannexed=E2= =80=9D to a or province that w= as not part of a municipality is "annexed" = to a
municipality. P= rior to the change, the content of the PIDF-LO A3 = municipality. Prior to the ch= ange, a Presence Information Data Format
element would be blank, or represent some other v= alue and after the Location Object (PIDF-LO) specifying a civic location in the affected <= /td>
change would be the municipal= ity that annexed that part of the area would have a blank= A3 element, or would contain some o= ther value;
county/province.= This kind of annexation has an effective date and after the change, a PIDF-LO specify= ing the same location would contain =
time (typically = 00:00 on the first or last day of a month).</t&= gt; an A= 3 element set to the name of the municipality that annexed that
<= /td>
<t>Records i= n a LIS must change around these kinds of events. The old <t>Records in a LIS must change around these k= inds of events. The old
record must be dis= carded, and a new, validated record must be loaded record must be discarded, and a new, validated record must b= e loaded
into the LIS. It = is often difficult for the LIS operator to know that into the LIS. It is often difficult for the LIS operator = to know that
records must be ch= anged around such events. There are other records must be changed around such events. There are other
circumstances wher= e locations that were previously valid become circumstances where locations that were previously valid become <= /td>
invalid, such as= a street renaming or renumbering event. As RFC52= 22 invalid, such as a street r= enaming or renumbering event. Using <xref
defines validation, the only way for a LIS to discover such= changes was target=3D"RFC5222"/> validation, t= he only way for a LIS to discover such
to periodically = revalidate its entire database. Of course, this w= ould changes is to periodically revalidate its entire database. Of cours= e,
not facilitate t= imely changes, is not coordinated with the actual this does not facilitate timel= y changes, is not coordinated with the
change event, an= d also adds significant load to the LoST server. Even actual change event, and = also adds significant load to the LoST server
if re-validation= is contemplated, the server has no mechanism to as well as the LIS. Even if re= -validation is contemplated, the server
control, or even= suggest the time period for revalidation</t>= ; has no mechanism to control, = or even suggest the time period for
<t>This ex= tension allows the client to provide a stab= le URI that is <t>This extension allows a LoST client to provide a stable URI that the
retained by the server associated with the location information used in LoST server ma= y retain and may associate with the location information
the request. In= the event of a planned change, or any other used in the request. In the event of a planned change, or any ot= her
circumstance whe= re the location may become invalid, the server sends a
notification to = the URI informing it of a change. The noti= fication invalid, the server sends a = notification to the URI to inform the
contains the dat= e and time when the location may become invalid.</t> client of a change. T= he notification contains the date and time when
<t>Ideally, following such a notification, the LIS will prepare a new <t>When a LIS receives such = a notification, it may prepare a new record=
record to be inserted in its active database, that becomes active<= /span> at so t= hat, at the precise planned event date and time, it may insert the
the precise plan= ned event date and time, at which point it = would also new record into in its active database and delete the old record. As
delete the old r= ecord. However, the new record has to be valid, and part of preparing the new record, the LIS may use the= "as of" date
the LIS would like to validate it prior to the planned change event. component of this extension to perform a LoST validation of the new
If it requests validation before the planned event, the server (wi= thout r= ecord as of the effective date.</t>
this extension) would inform the client that the location was inva= lid.
This extension includes an optional = =E2=80=9Cas of=E2=80=9D date and time in the
request that allows the LoST server to provide validation as of the
date and time specified, as opposed = to the =E2=80=9Cas of now=E2=80=9D implied = in <= /td>
the current LoST protocol.</t>
<t>When it is not practical or advisable for the LIS = to maintain stable <t>The notification URI and "as of" date components of this ex= tension
URIs for all of its records, = periodic revalidation can be still used to = allow a LIS to= be prepared for and smoothly transition to planned
maintain the dat= a in the LIS. However, the server should be able to changes, without the overhead and = delay inherent in performing periodic
control the rate of such revalidation. For this purpose, a= new TTL revalidation of each location. The notification= URI allows a LIS to be
element is included in the &lt;f= indserviceResponse&gt; which provides alerted to planned changes, while the = "as of" date allows the LIS to
advice from the = server to the LIS of when revalidation is s= uggested.</t> verify the validity of locations before they become active.</t>= ;
<t>There are= quite a few implementations of LoST. Experience with
these implementati= ons indicates that the RelaxNG schema is very these implementations indicates that the RelaxNG schema is very <= /td>
difficult to dea= l with, because the tools that the implementors use difficult to deal with, both because many commonly used development
don=E2=80=99t support it, and their<= /span> staff is unfamiliar with it. Alternative tools do= n't support it, and development staf= f is often unfamiliar with
schemas have bee= n circulated, which is undesirable, as they= may not be it. Informal alternative schemas have been circulated, which is
in conformance <= span class=3D"delete">to the RelaxNG schema in <xref target=3D"= RFC5222"/>. This undesirable as they may not be in conformance with the RelaxNG schema
document provide= s an XML schema that replaces the RelaxNG schema. It in <xref target=3D"RFC5222"/>. This document prov= ides an XML schema that
can be used by a= ny implementation interchangeably with the RelaxNG replaces the RelaxNG schema. It can be used by any impleme= ntation
schema. </t&g= t; interchangeably with the RelaxNG sc= hema. </t>
</section&g= t; </section>
<section an= chor=3D"conventions" title=3D"Conventions used in this
document"> document">
<t>The= key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>The key words "MUST", "MUST NOT", "RE= QUIRED", "SHALL", "SHALL
NOT", "SHOULD", "S= HOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OP= TIONAL" in
this document are = to be interpreted as described in <xref this document are to be interpreted as described in <xref
target=3D"RFC2119"= />. target=3D"RFC2119"/>.
</t> </t>
<t>=E2=80=9DServer=E2=80=9D in this document re= fers to the LoST server and <t>"Server" in this document refers to t= he LoST server and
=E2=80=9CClient=E2=80=9D is the LoST client, even when the = server is performing an "Client" is the LoST client, even when the server is perf= orming an
operation on the c= lient.</t> operation on the clien= t.</t>
</section&g= t; </section>
<section ti= tle=3D"&lt;plannedChange&gt; element"> <section title=3D"&lt;plannedChange&gt; element= ">
<t>T= his document defines a new element to &= lt;findService&gt; <t>= ;This document defines a new element in the= &lt;findService&gt;
called =E2=80=9CplannedChange=E2=80=9D. This element conta= ins two attributes: request called "plannedChange". This element contains two optional
=E2=80=98uri=E2=80=99 and =E2=80=98a= sOf=E2=80=99. The =E2=80=98uri=E2=80=99 attribute MUST be a URI w= ith a attributes: 'uri' and 'asOf'. When present, the 'u= ri' attribute MUST
scheme of HTTPS.= The URI will be stored by the server against the = be a URI with a scheme of HTTPS. If the ser= ver supports this extension,
location in the = request for subsequent use with the notific= ation it may s= tore the URI and may associate it with the location in the
function defined= below. To minimize storage requirements of at the reque= st. The server uses the URI with the notification function
server, the leng= th of the URI MUST be 256 bytes or less. Each client defined below. To minimize storage requirements at the server, the <= /td>
of the server ma= y only store one URI against a location, where length of the URI MUST not exceed = 256 bytes. Each client of the server
=E2=80=9Clocation=E2=80=9D is defined by policy at the serv= er, since a given unique may only sto= re one URI against a location, where "location" is defined
location may hav= e many combinations of location elements that resolve by policy at the server, since a given unique location m= ay have many
to the same loca= tion. If the server receives a =E2=80=98uri=E2=80= =99 for the same combinations = of location elements that resolve to the same location.
location from th= e same client, the URI in the request replaces the URI
it previously re= tained. Policy at the server may limit how many URIs client, the URI in the request replaces the URI it previ= ously retained.
it retains for a= given location. A new warning is defined below to be Policy at the server may = limit how many URIs it retains for a given
used to indicate that the URI has not been stored. If the = location in location. A new warning i= s defined below to indicate that the URI has
the request is i= nvalid, the URI will not be stored and the warning will = not been stored. If the location in = the request is invalid, the URI is
be returned. not stored = and the warning is returned.
</t> </t>
<t>The =E2=80=98asOf=E2=80=99 attribute contains a da= te and time. The server will <t>The 'asOf' = attribute contains a date and time. The server va= lidates
validate the location in the request as of the date specifi= ed, taking the location in the reques= t as of the date and time specified, taking=
into account pla= nned changes. This allows the client to ve= rify that it into account planned cha= nges. This allows a client to verify that = it
can make changes i= n the LIS commensurate with changes in the LoST can make changes in the LIS commensurate with changes in the LoST=
server by validati= ng locations in advance of a change.</t> server by validating locations in advance of a change.</t><= /td>
</section&g= t; </section>
<section tit= le=3D"&lt;locationInvalidated&gt; object"> <section title=3D"&lt;locationInvalidated&gt= ; object">
<t>When the server needs to invalidate a location where the client <t>When a server needs to inva= lidate a location that has one or more
provided a URI in &lt;plannedCha= nge&gt;, associated client-supplied URIs (provided in a &lt;plannedChange&gt; <= /td>
the server executes an HTTPS POST co= ntaining element),
&lt;locationInvalidated&gt;, with a Content-Type of= 'application/xml' it transmits an HTTPS POST with a Content-Type of 'applicatio= n/xml'
to the URI previously provided. containing a &lt;locationInvalidated&am= p;gt; object to each associated URI.=
This is the notice= from the server to the client that the location may This is the notice from the server to the client that the = location may
be invalid and sho= uld be revalidated. be invalid and shou= ld be revalidated.
&lt;location= Invalidated&gt; contains an =E2=80=98invalidAsOf=E2=80=98 attribute The &lt;locationInvalidated&gt; object contains an =E2=80=98invalidAsOf=E2=80=98
that specifies when the location may become invalid.attribute, which specifies a date and time when the locat= ion may become
If the date/time in =E2=80=98invalidAsOf=E2=80=98 is earlier= than the time the invalid.
&lt;locationInvalidated&gt; was If this is earlier than the= current time, the location may already be =
sent, the location may already be invalid and the LIS shoul= d take invalid and the LIS should tak= e immediate action. If the POST
immediate action= =2E If the POST operation fails, the server MAY retry
the operation im= mediately, and if it fails again, retry the operation it fails again, retry the operation later. Retry timing and duration
at a later time.</t> or number of attempts is determined by the serv= er.</t>
<t>The LoST = server is NOT REQUIRED to store the Location Information
supplied in the or= iginal findService request. This means the server supplied in the original findService request. This means th= e server
may not know if a = planned change will in fact invalidate the location may not know if a planned change will in fact invalidate th= e location
stored in the LoST= client, because changes could be made in the LoST stored in the LoST client, because changes could be made in = the LoST
server that do n= ot affect validation of the Location Information. The <= /td>
LoST client may = find that upon revalidation with the changed server Information. The LoST client may find that upon revalidat= ion with the
state, the valid= ation data is the same as it was before the changed server state, the validation data is the same as it was be= fore
notification was= received. </t> the notification= was received. </t>
=
</section>= ; </section>
<section title=3D= "URI Not Stored Warning"> <sectio= n title=3D"URI Not Stored Warning">
<t>A new warning is added to the exceptionContainer, <t>This extension adds a new warning to the = exceptionContainer,
=E2=80=99uriNotStored=E2=80=99. This warning MUST NOT be r= eturned unless the 'uriNotStored'. This warning MUST NOT be returned unless the= request
&lt;plannedC= hange&gt; element was found in the correspondi= ng request. contains a &lt;plannedChange&gt; element with a 'uri' attribute. The
The warning is r= eturned when the server decides not to store the U= RI warning is returned when th= e server decides not to store the URI. As =
found in the &lt;plannedChange&gt; element. As dis= cussed above, this discussed above, t= his may occur because, among other reasons, the
may occur becaus= e, among other reasons, the policy at the server limits
how many URIs wi= ll be stored against a specific location, the URI is specific location, the URI is not well formed or the poli= cy at the
not well formed = or the policy at the server has some other restriction
on the feature.&= lt;/t>
</section>= ; </section>
<section title=3D= "Time-To-Live (TTL) in Response"> &l= t;section title=3D"Time-To-Live (TTL) in Response">
<t>A new &lt;ttl&gt; element is added to the <t>This extension adds the &lt;ttl&g= t; element to the
&lt;findserviceResponse&gt;. The &lt;ttl&g= t; element &= ;lt;findServiceResponse&gt;. The &lt;ttl&gt; element<= /td>
contains a date an= d time after which the client may wish to revalidate contains a date and time after which the client may wish t= o revalidate
the locationthe location
at the server. = This element MAY be = added by the server if validation at the server. = A server MAY add this element to the= response if
is requested validation i= s requested. This element takes the form o= f the 'expires' <= /td>
in the response. The form of= the element is the =E2=80=98expires=E2=80=99 attribute p= attern of <xref target=3D"RFC5222"/>, which allows
attribute pattern, which allows the values '= NO CACHE' or 'NO EXPIRATION' to be returned instead of a
explicit =E2=80=98NO CACHE=E2=80=99 and =E2=80=98NO EXPIRATION=E2=80= =99 values to be returned dateTime value. However, for the &lt;ttl&a= mp;gt; element 'NO CACHE' has no
in the &lt;ttl&gt; element. = =E2=80=98NO CACHE=E2=80=99 has no meaning and MUST NOT be returned. 'NO EXPIRAT= ION' means the server does
meaning and MUST= NOT be returned in TTL. =E2=80=98NO EXPIRATION=E2= =80=99 means the not have a suggested revalidation period.</t>
server does
not have any suggested revalidation period.</t>
<t>Selecting= a revalidation interval is a complex balancing of <t>Selecting a revalidation interval is a complex bala= ncing of
timeliness, server= load, stability of the underlying data, and policy timeliness, server load, stability of the underlying data, = and policy
of the LoST server= =2E Too short, and load on the server may overwhelm of the LoST server. Too short, and load on the server may= overwhelm
it. Too long an= d invalid data may persist in the server for too l= ong. it. Too long and invali= d data may persist in the server for
The URI mechanis= m provides timely notice to coordinate changes, but unacceptable lengths of time. The URI notification mechanism provides =
even with it, it= is often advisable to revalidate data eventually.</t> timely notice to coordinate changes, but even with= it, it is often
<t>In areas = that have little change in data, such as fully built out, <t>In areas that have little change in data, su= ch as fully built out,
stable communities= already part of a municipality, it may be reasonable stable communities already part of a municipality, it may= be reasonable
to set revalidatio= n periods of 6 months or longer, especially if the to set revalidation periods of 6 months or longer, especiall= y if the
URI mechanism is w= idely deployed at both the server and the clients. URI mechanism is widely deployed at both the server and the= clients.
In areas that are = quickly growing, 20-30 day revalidation may be more In areas that are quickly growing, 20-30 day revalidation m= ay be more
appropriate even t= hough such revalidation would be the majority of the appropriate even though such revalidation would be the maj= ority of the
traffic on the LoS= T server.</t> traffic on the LoST= server.</t>
<t>When a pl= anned change is made, typically the TTL value for the <t>When a planned change is made, typically the TTL= value for the
affected records i= s lowered, so that revalidation is forced soon after affected records is lowered, so that revalidation is force= d soon after
the change is impl= emented. It is not advisable to set the expiration the change is implemented. It is not advisable to set th= e expiration
skipping to= change at line 679 = ¶ skipping to change at line 702<= /em>
&lt;xs:im= port namespace=3D"urn:ietf:params:xml:ns:lost1"/&gt;
&lt;!-- extend= the extensionPoint of commonRequestPattern of findService &lt;!-- extend the extensionPoint of commonReques= tPattern of findService
= to include: to inc= lude:
--&gt;--&gt;
xs:group r= ef=3D"plannedChange" minOccurs=3D"1"/&gt; xs:group ref=3D"plannedChange" minOccurs=3D"1"/&gt;
&lt;!-- where = --&gt; &lt;!-- where --&gt;=
&lt;xs:= group name=3D"plannedChange"&gt; = &lt;xs:group name=3D"plannedChange"&gt;
&lt= ;xs:sequence&gt; &lt= ;xs:sequence&gt;
&= ;lt;xs:element ref=3D"uri" type=3D"xs:anyURI" /&gt;
&a= mp;lt;xs:element ref=3D=E2=80=9CinvalidAsOf" type=3D"xs:dateTime" = &lt;xs:element ref=3D"invalidAsOf" type= =3D"xs:dateTime" /&gt;
/&gt;
&= ;lt;xs:any namespace=3D"##other" processContents=3D"lax"
m= inOccurs=3D"0" maxOccurs=3D"unbounded"/&gt; minOccurs=3D"0" maxOccurs=3D"unbounded"/&gt;=
&lt= ;/xs:sequence&gt; &l= t;/xs:sequence&gt;
&lt;/x= s:group&gt; &lt;/xs:gro= up&gt;
&lt;!-- extend= the extensionPoint of commonResponsePattern in &lt;!-- extend the extensionPoint of commonResponsePattern in=
= findServiceResponse to include: --&gt; findServiceResponse to include: --&= amp;gt;
&lt= ;xs:atttribute name=3D"asOf" type=3D"xs:dateTime" &lt;xs:atttribute name=3D"asOf" type=3D"xs:dat= eTime"
minOccurs=3D"0"/&a= mp;gt; minOccurs=3D"0"/&gt;
&lt= ;xs:element ref=3D"ttl" type=3D"expires" minOccurs=3D"0" /&gt; &lt;xs:element ref=3D"ttl" typ= e=3D"expires" minOccurs=3D"0" /&gt;
skipping to= change at line 702 = ¶ skipping to change at line 724<= /em>
&lt;!-- extend= the extensionPoint of extensionContainer to include: &lt;!-- extend the extensionPoint of extensionContain= er to include:
--&gt;--&gt;
&lt= ;xs:element ref=3D"uriNotStored"/&gt; &lt;xs:element ref=3D"uriNotStored"/&gt;
&lt;!-- where = --&gt; &lt;!-- where --&gt;=
&lt= ;xs:element name=3D"uriNotStored" type=3D"basicException"/&gt; &lt;xs:element name=3D"uriNotS= tored" type=3D"basicException"/&gt;
&lt;/xs:schema= &gt; &lt;/xs:schema&gt;
</artwork>&l= t;/figure></section> </artw= ork></figure></section>
<section an= chor=3D"locationInvalidated" title=3D"locationInvalidated <section anchor=3D"locationInvalidated" title=3D= "locationInvalidated
Schema">Schema">
<t>This sc= hema defines the object used for the notification = of <t>This schema define= s the object used for the notification that a
(potential) invalidated location by = the LoST server to a client that location is potentially invalidated sent= by a LoST server to a client
requested it.<= ;/t> that requested it.</t>
<figure><= artwork> <figure><artwork&g= t;
&lt;?xml versi= on=3D"1.0" encoding=3D"UTF-8"?&gt; = &lt;?xml version=3D"1.0" encoding=3D"UTF-8"?&gt;
&lt;xs:schema = xmlns:xs=3D"http://www.w3.org/2001/XMLSchema" &lt;xs:schema xmlns:xs=3D"http://www.w3.org/2001/XMLSchema"
xmlns=3D"urn:i= etf:params:xml:ns:lostLocationInvalidated1" xmlns=3D"urn:ietf:params:xml:ns:lostLocationInvalidated1"
targetNamespac= e=3D"urn:ietf:params:xml:ns:lostLocationInvalidated1" targetNamespace=3D"urn:ietf:params:xml:ns:lostLocation= Invalidated1"
elementFormDef= ault=3D"qualified"&gt; elementF= ormDefault=3D"qualified"&gt;
&lt;xs:elemen= t name=3D"locationInvalidated"&gt; = &lt;xs:element name=3D"locationInvalidated"&gt;
&lt;xs:anno= tation&gt; &lt;xs:annotation= &gt;
&lt;xs:do= cumentation&gt; &lt;xs:doc= umentation&gt;
A point whe= re future extensions A point whe= re future extensions
skipping to= change at line 739 = ¶ skipping to change at line 761<= /em>
<section an= chor=3D"security" title=3D"Security Considerations">
<t>As = an extension to LoST, this document inherits the security <t>As an extension to LoST, this document= inherits the security
issues raised in &= lt;xref target=3D"RFC5222"/>. The server could be tricked <= /td>issues raised in <xref target=3D"RFC5222"/>= =2E The server could be tricked
into storing a mal= icious URI which, when sent the locationInvalidated into storing a malicious URI which, when sent the locationI= nvalidated
object could trigg= er something untoward. The server MUST NOT accept object could trigger something untoward. The server MUST NO= T accept
any data from the = client in response to POSTing the any = data from the client in response to POSTing the
locationInvalidate= d.</t> locationInvalidated.</t= >
<t>The= server is subject to abuse by clients because it is being <t>The server is subject to abuse by cli= ents because it is being
asked to store som= ething and may need to send data to an uncontrolled asked to store something and may need to send data to an un= controlled
URI. Clients co= uld request many URIs for the same location for URI. Clients could request many URIs for the same location, for
example. The serv= er MUST have policy that limits use of this mechanism example. The server MUST have policy that limits use of = this mechanism
by a given client.= If the policy is exceeded, the server returns the by a given client. If the policy is exceeded, the server r= eturns the
=E2=80=98uriNotStored=E2=80=98 warning. The server MUST va= lidate that the content 'uriNotStored' warning. The server MUST validate that th= e content of
of the =E2=80=98uri=E2=80=98 attribute sent is syntacticall= y valid and meets the the 'uri' attribute sent is syntactically valid and meets = the 256 bytes
256 bytes limit.= When sending the locationInvalidated object to the limit. When sending the locationInvalidated object to th= e URI stored,
URI stored, the = server MUST protect itself against common HTTP the server MUST protect itself against common HTTP vulnerabiliti= es.
vulnerabilities.=
</t> </t>
<t>The m= utual authentication between client and server is <t>The mutual authentication between client and ser= ver is
RECOMMENDED for bo= th the initial &lt;findService&gt; operation that RECOMMENDED for both the initial &lt;findService&= amp;gt; operation that
requests storing= the URI and the sending of the reque= sts storing the URI and the sending of the 'locati= onInvalidated'
=E2=80=98locationInvalidated=E2=80=98 object. The server s= hould be well known to object. The s= erver should be well known to the client, and its
the client, and = its credential should be learned in a reliable way. credential should be learned in a reliable way. For exam= ple, a public
For example, a p= ublic safety system operating the LoST server may have
a credential tra= ceable to a well known Certificate Authority known to to a well known Certificate Authority known to provide c= redentials for
provide credenti= als for public safety agencies. Many of the clien= ts public safety agencies. Clients may be operated by local ISPs or othe= r
will be operated by local ISPs or other service providers <= span class=3D"delete">where the service providers that can reasonably obt= ain a good credential to use
server operator can reasonably obtain a good credential to = use for the for the server side of the LoST server's POST transaction using the =
URI. Where the = server does not recognize the client, its policy MAY URI. Where the loST server= does not recognize the client, its policy
limit the use of= this feature beyond what it would limit a client it MAY limit the use of this feature beyond what it would li= mit a client
recognized.</t> it= recognizes.</t>
</section&g= t; </section>
<section an= chor=3D"iana" title=3D"IANA Considerations"> <section anchor=3D"iana" title=3D"IANA Considerations">=
<section ti= tle=3D"Replacement XML Schema Registration"> <section title=3D"Replacement XML Schema Registration">=
<figure>= <artwork><![CDATA[ <fig= ure><artwork><![CDATA[
URI: urn:ietf:= params:xml:schema:lost3 URI: urn:ie= tf:params:xml:schema:lost3
Registrant Cont= act: IETF ECRIT Working Group, Brian Rosen Registrant Contact: IETF ECRIT Working Group, Brian Rosen
(br@brianros= en.net). (br@brianrosen.net).
XML: <= /td> XML:
BEGIN BEGIN
<?xml ver= sion=3D"2.0"?> <?xml versio= n=3D"2.0"?>
<= /td>
&= nbsp;End of changes. 23 change blocks. 
148 lines changed or deleted= 169 lines changed or added

This htm= l diff was produced by rfcdiff 1.48. The latest version is available from= http://tools.ietf.= org/tools/rfcdiff/
--=_MailMate_321F8108-A8BB-4A6C-AC31-1622E59E899C_= Content-Disposition: attachment; filename=Diff-txt.html Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = = = = = = = = = = Diff: draft-ietf-ecrit-lost-planned-changes-04.txt - draft-ietf-= ecrit-lost-planned-changes-04-rg.txt = = = = = = = <= td class=3D"lineno"> the LoST server can use to inform the LoST client (e.g., a Location<= td class=3D"rblock"> specified. It also adds an optional Time-To-Live = element to the<= td class=3D"rblock"> response, which informs clients of the current expected lifetime of a<= /span><= td class=3D"rblock"> validation. This document also provides a convent= ional XML schema<= td class=3D"rblock"> for LoST, as a backw= ards compatible alternative to the RelaxNG schema<= td class=3D"rblock"> in RFC5222 publication of this document. Please review these = documents to this document. Code Components extracted from t= his document must the Trust Legal Provisions and are provided without= warranty as<= td class=3D"rblock"> described in the Simplified BSD License.<= td class=3D"rblock"> locations may become valid = after the date. If specified, the URI may<= td class=3D"rblock"> (e.g., a Location Informati= on Server [LIS]) when a location which was<= td class=3D"rblock"> previously valid will become invalid. The date may be used by a<= td class=3D"rblock"> client to ask a serv= er to perform validation as of a future date. In<= td class=3D"rblock"> addition to this mechanism, the <findserviceRes= ponse> is also<= td class=3D"rblock"> extended to provide a Time-To-Live (TTL) for valid= ation, after which<= td class=3D"rblock"> the client should revalidate the location.<= td class=3D"rblock"> Format Location Object (PID= F-LO) specifying a civic location in the affected area would <= span class=3D"insert">have a blank A3 element, or would contain some other value; after th= e change, a PIDF-LO specifying the same location= <= td class=3D"rblock"> annexed that part of the county/province. This ki= nd of annexation<= td class=3D"rblock"> has an effective date and time (typically 00:00 on= the first or last<= td class=3D"rblock"> day of a month), known in a= dvance. Other kinds of changes may also<= td class=3D"rblock"> occur, and these will almos= t always also have an effective date that<= td class=3D"rblock"> is known in advance.= or any other circumstance where the location in the original request<= td class=3D"rblock"> and time when the location may become invalid. changes, without the overhead= and delay inherent in performing<= td class=3D"rblock"> active.<= td class=3D"rblock"><= td class=3D"rblock"> In situations where = it is not practical or advisable for the LIS to<= td class=3D"rblock"> maintain a stable URI for each of= its records, periodic revalidation<= td class=3D"rblock"> can still be used to= maintain the data in the LIS. However, the LoST<= /span><= td class=3D"rblock"> server should be able to in= fluence the rate of such revalidation.<= td class=3D"rblock"> For this purpose, this exte= nsion adds a Time to Live (TTL) elem= ent to<= td class=3D"rblock"> the <findServiceResponse= > which provides advice from the server to<= td class=3D"rblock"> the LIS of when validation<= /span> is suggested.<= td class=3D"rblock"> with the RelaxNG schema.<= td class=3D"lineno"> requirements at the server, the length of the URI M= UST not exceed 256<= /tr> location, where "location" is defined by policy at t= he server, since<= td class=3D"rblock"> stored and the warning is returned. can make changes in the LIS commensurate with change= s in the LoST<= td class=3D"lineno"><= /tr> <= td class=3D"rblock"> duration or number of attem= pts is determined by the server.<= td class=3D"rblock"> = <= td class=3D"rblock"> The <locationInvalidated= > object does not contain information about<= td class=3D"rblock"> the location, as the URI to= which it is sent is determined by the<= td class=3D"rblock"> requesting client and can b= e unique for each of the client's location<= td class=3D"rblock"> records. policy at the server limits how many URIs will be s= tored against a specific location, the URI is not well formed or th= e policy at the= = to include: --><= td class=3D"lineno"> = = <!-- extend the extensionPoint of extensionContainer= to include: -->= <= td class=3D"rblock"> = = targetNamespace=3D"urn:ietf:params:xml:ns:lostLo= cationInvalidated1"<= td class=3D"right"> for both the initial <findService> operation = that requests storing<= /tr> = <= td class=3D"rblock"> it recognizes.<= td class=3D"lineno"> = <= td class=3D"lineno">= =
< dra= ft-ietf-ecrit-lost-planned-changes-04.txt  &nb= sp;draft-ietf-ecrit-lost-planned-chan= ges-04-rg.txt >= ;
ecrit = B. Rosen ecrit = B. Rosen
Internet-Draft = 19 Augus= t 2021 Internet-Draft = August 23,= 2021
Updates: RFC5222 (= if approved) Updates: RFC5222 (if appro= ved)
Intended status: S= tandards Track Intended status: Standar= ds Track
Expires: 20 February 2022 Expires: February 24, 2022
Valida= tion of Locations Around a Planned Change Validation of Locations Around a Planned Change
dr= aft-ietf-ecrit-lost-planned-changes-04 = draft-ietf-ecrit-lost-planned-changes-04
Abstract = Abstract
This document= defines an extension to LoST (RFC5222) tha= t allows a This document defines an= extension to the Location to Service
planned change to the data in the LoST server to occur. Records that Translation (LoST) protocol (RFC5222) that allo= ws a LoST server to
previously we= re valid will become invalid at a date in the future, notify a client of planned changes to the data. This ext= ension is
and new locat= ions will become valid after the date. The extension only useful with the validation function of LoST. It is beneficial
adds two elem= ents to the <findservice> request: A = URI to be used to for LoST validation clients to be aware of planned = changes, as
inform the LIS that previously valid locations will be i= nvalid after = records that previously were valid may become invalid at a known
the planned change date, and add a date which requests the server to future date, and new locations may become valid after the date. This=
perform valid= ation as of the date specified. It also adds an extension adds two elements to the <= ;findService> request: A URI that=
optional Time= -To-Live element to the response, which informs clients
about the current expected lifetime of the validation. This document Information Server [LIS]) that prev= iously valid locations will be
also provides= a conventional XML schema for LoST, as backwards invalid after a planned chan= ge date, and a date that allows the LoST
compatible al= ternative to the RelaxNG schema in RFC5222 client to re= quest that the server perform validation as of the date
Status of This Mem= o Status of This Memo
This Internet-D= raft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the<= /td>
provisions of B= CP 78 and BCP 79. provisions of BCP = 78 and BCP 79.
Internet-Drafts= are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engi= neering
Task Force (IET= F). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute=
working documen= ts as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of curr= ent Internet-
Drafts is at = https://datatracker.ietf.org/drafts/current= /. Drafts is at http://datatracker.= ietf.org/drafts/current/.
Internet-Drafts= are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximu= m of six months
and may be upda= ted, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other doc= uments at any
time. It is in= appropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference=
material or to = cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet= -Draft will expire on 20 February 2022. This Internet-Draft will expire on February 24, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2= 021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as th= e
document author= s. All rights reserved. document au= thors. All rights reserved.
This document i= s subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal<= /td>
Provisions Re= lating to IETF Documents (https://trustee.ietf.org= / Provisions Relating to IET= F Documents
license-info) in effect on the date of publication of th= is document. (http://trustee.ietf.org/license-info) in effect on the date of
Please review= these documents carefully, as they describe your rights
and restricti= ons with respect to this document. Code Components carefully, as they describe your rights and restrictions= with respect
extracted fro= m this document must include Simplified BSD License text
as described = in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Sec= tion 4.e of
provided with= out warranty as described in the Simplified BSD License.
Table of Contents<= /td> Table of Contents
1. Introductio= n . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . = =2E . . . . . 2
2. Conventions= used in this document . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . = =2E . . . . . 4
3. <planned= Change> element . . . . . . . . . . . . . . . . . . . 4 3. <plannedChange> element . . . . . . . = =2E . . . . . . . . . . . 4
4. <locatio= nInvalidated> object . . . . . . . . . . . . . . . . 5 4. <locationInvalidated> object . . . . = =2E . . . . . . . . . . . 5
5. URI Not S= tored Warning . . . . . . . . . . . . . . . . . . . 5 5. URI Not Stored Wa= rning . . . . . . . . . . . . . . . . . . . 6
6. Time-To-L= ive (TTL) in Response . . . . . . . . . . . . . . . 5 6. Time-To-Live (TTL= ) in Response . . . . . . . . . . . . . . . 6
7. Replaceme= nt XML schema . . . . . . . . . . . . . . . . . . . 6 7. Replacement XML s= chema . . . . . . . . . . . . . . . . . . . 7
8. Extension X= ML Schema . . . . . . . . . . . . . . . . . . . . 15 8. Extension XML Schema . . . . . . . . . . . . . . = =2E . . . . . 15
9. locationInv= alidated Schema . . . . . . . . . . . . . . . . . 16 9. locationInvalidated Schema . . . . . . . . . . . = =2E . . . . . 16
10. Security = Considerations . . . . . . . . . . . . . . . . . . . 16 10. Security Consider= ations . . . . . . . . . . . . . . . . . . . 17
11. IANA Cons= iderations . . . . . . . . . . . . . . . . . . . . . 17 11. IANA Consideratio= ns . . . . . . . . . . . . . . . . . . . . . 18
11.1. Repl= acement XML Schema Registration . . . . . . . . . . 17 11.1. Replacement = XML Schema Registration . . . . . . . . . . 18
11.2. Plan= ned Change Extension XML Schema Registration . . . . 17 11.2. Planned Chan= ge Extension XML Schema Registration . . . . 18
11.3. loca= tionInvalidated XML Schema Registration . . . . . . 18 11.3. locationInva= lidated XML Schema Registration . . . . . . 19
12. Normative= References . . . . . . . . . . . . . . . . . . . . 19 12. Normative Referen= ces . . . . . . . . . . . . . . . . . . . . 20
Author's Addr= ess . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . .= . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
This document= describes an update to the LoST protocol + which allows This document describes an extension to the Location to Service
a <findservice> request to = optionally add a URI and a date to be used<= /span> Trans= lation (LoST) protocol [RFC5222] to assist<= /span> with planned changes
with planned = changes to the underlying location information in the to the underlying location information in the server. = The extension
server. The = URI is retained by the LoST server, associated with the allows a <findService> request to op= tionally contain a URI, and
data record t= hat was validated, and used to notify the LIS (the= LoST = optionally a date. This extension is useful in the context of the
client) when a location which was previously valid will b= ecome valida= tion function of LoST. It is beneficial fo= r LoST validation
invalid. The= date is used by the= client to ask the server to perform= clients to = be aware of planned changes, as records that previously
validation as= of a future date. In addition to this mechanism, the were valid may become invalid = at a known future date, and new
<findservi= ceResponse> is also extended to provide a Time-To-Live
(TTL) for val= idation, after which the client should revalidate the be retained by the LoST = server and may be associated with the data<= /td>
location. record that was validated, and used to= notify the the LoST client
Validation of= civic locations involves dealing with data that c= hanges Validation of civic l= ocations involves dealing with data that may
over time. A= typical example is a portion of a county or province change over time. A typ= ical example is when a portion of a county = or
that was not = part of a municipality is "annexed" to a municipality. province that was not part of a municipality is "anne= xed" to a
Prior to the = change, the content of the PIDF-LO A3 element would be municipality. Prior to the change, a Prese= nce Information Data
blank, or represent some o= ther value and after the change would be =
the municipal= ity that annexed that part of the county/province. This
kind of annex= ation has an effective date and time (typically 00:00 on
the first or = last day of a month). would contain an A3 element set t= o the name of the municipality that
=
Records in a LI= S must change around these kinds of events. The old Records in a LIS must change around these kinds of event= s. The old
record must be = discarded, and a new, validated record must be loaded record must be discarded, and a new, validated record m= ust be loaded
into the LIS. = It is often difficult for the LIS operator to know into the LIS. It is often difficult for the LIS operator = to know
that records mu= st be changed around such events. There are other that records must be changed around such events. There ar= e other
circumstances w= here locations that were previously valid become circumstances where locations that were previously valid becom= e
invalid, such= as a street renaming or renumbering event. As RF= C5222 invalid, such as a str= eet renaming or renumbering event. Using
defines validation, the only way for a LIS to discover s= uch changes = [RFC5222] validation, the only way for a LIS to discover such chan= ges
was to periodically revalidate its entire database. Of c= ourse, this = is to periodically revalidate its entire database. Of course, thi= s
would not facilitate timely changes, is not coordinated w= ith the does= not facilitate timely changes, is not coordinated with the
actual change e= vent, and also adds significant load to the LoST actual change event, and also adds significant load to the LoS= T
server. Even if re-validation is contemplated, the serve= r has no ser= ver as well as the LIS. Even if re-validation is contemplated,
mechanism to = control, or even suggest the time period for the server has no mechanism to control, or even suggest the tim= e
revalidation period= for revalidation.
This extensio= n allows the client to provide a stable URI= that is This extension allows a LoST client to = provide a stable URI that the
retained by the server associated= with the location information used LoST server = may retain and may associate with the location
in the reques= t. In the event of a planned change, or any other information used in the request. In the event of a plann= ed change,
circumstance = where the location may become invalid, the server sends <= /td>
a notificatio= n to the URI informing it of a change. The= notification may become invalid, t= he server sends a notification to the URI to
contains the = date and time when the location may become invalid. inform the client of a cha= nge. The notification contains the date
Ideally, following such a notification, the LIS will prepare a new When a LIS receives such a notificatio= n, it may prepare a new record
record to be inserted in its active database, that becomes acti= ve at so that, at the precise planned event date and time, it may insert
the precise p= lanned event date and time, at which point = it would also the new record into in its active databas= e and delete the old record.
delete the ol= d record. However, the new record has to be valid, and As part of preparing the new record, the LIS may use the "as of" date
the LIS would like to validate it prior to the planned change event. component of this extension to perform a LoST validation of the new
If it requests validation before the planned event, the server<= /span> recor= d as of the effective date.
(without this extension) would inform the client that the locat= ion <= /td>
was invalid. This extension includes an optional "as of= " date and
time in the request that allows the LoST server to provide validation
as of the date and time specified,= as opposed to the "as of now"
implied in the current LoST proto= col. =
When it is not practical or advisable for the LIS to main= tain stable = The notification URI and "as of" date components of this extension=
URIs for all of its records= , periodic revalidation can be still used allow a LIS t= o be prepared for and smoothly transition to planned
to maintain t= he data in the LIS. However, the server should be able
to control the rate of such revalidation. For this purp= ose, a new periodic revalidation of each location. The= notification URI allows
TTL element is included in= the <findserviceResponse> which prov= ides a LIS t= o be alerted to planned changes, while the "as of" date allows
advice from t= he server to the LIS of when revalidation i= s suggested. = the LIS to verify the validity of locations before they become
=
There are quite= a few implementations of LoST. Experience with these There are quite a few implementations of LoST. Experi= ence with these
implementations= indicates that the RelaxNG schema is very difficult implementations indicates that the RelaxNG schema is ver= y difficult
to deal with,= because the tools t= hat the implementors use don't = to deal with, both because many commonly used development tools don't
support it, a= nd their staff is unfamiliar with it. Alternative = support it, and development staff is often unfamiliar with it.
schemas have = been circulated, which is undesirable, as t= hey may not = Informal alternative schemas have been circulated, which is
be in conform= ance to the RelaxNG schema in [RFC5222]. T= his document undesirable as they may not be in conformance with the RelaxNG schema
provides an X= ML schema that replaces the RelaxNG schema. It can be in [RFC5222]. This document provides an XML schema t= hat replaces the
used by any i= mplementation interchangeably with the RelaxNG schema. RelaxNG schema. It can be used by any implementation= interchangeably
=
2. Conventions us= ed in this document 2. Conventions use= d in this document
The key words "= MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "= SHALL NOT",
"SHOULD", "SHOU= LD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTI= ONAL" in this
document are to= be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
"Server" in thi= s document refers to the LoST server and "Client" is "Server" in this document refers to the LoST server and = "Client" is
the LoST client= , even when the server is performing an operation on the LoST client, even when the server is performing an o= peration on
the client. the client.
3. <plannedCha= nge> element 3. <plannedChange&g= t; element
This document= defines a new element to <findService&g= t; called This document defines a n= ew element in the <findService> request
"plannedChang= e". This element contains two attributes: 'uri' and called "plannedChange". This element contains two optional
'asOf'. The 'uri' attribute MUST be a URI with a scheme= of HTTPS. attributes: 'uri' and 'a= sOf'. When present, the 'uri' attribute MU= ST
The URI will be stored by the server against the location in the = be a URI with a scheme of HTTPS. If the= server supports this
request for subsequent use with the notification function= defined ext= ension, it may store the URI and may associate it with the
below. To mi= nimize storage requirements of at the serve= r, the length location in the request. The server uses the URI with the
of the URI MU= ST be 256 bytes or l= ess. Each client of the server may notification function defined below. To minimize storage
only store on= e URI against a location, where "location" is defined by
policy at the= server, since a given unique location may have many bytes. Each client of th= e server may only store one URI against a
combinations = of location elements that resolve to the same location.
If the server= receives a 'uri' for the same location from the same a given unique location may have many combinations of = location
client, the U= RI in the request replaces the URI it previously elements that resolve to the same location. If the server re= ceives a
retained. Po= licy at the server may limit how many URIs it retains 'uri' for the same location from the same client, the = URI in the
for a given l= ocation. A new warning is defined below to be use= d to request replaces the UR= I it previously retained. Policy at the
indicate that= the URI has not been stored. If the location in the server may limit how many URIs it retains for a given = location. A
request is in= valid, the URI will not be stored and the warning will new warning is defined below to indi= cate that the URI has not been
be returned. store= d. If the location in the request is invalid, the URI is not
The 'asOf' at= tribute contains a date and time. The server will= The 'asOf' attribute contai= ns a date and time. The server validates
validate the location in the request as of the date spec= ified, taking the location in the r= equest as of the date and time specified, t= aking
into account = planned changes. This allows the client to= verify that into account planned c= hanges. This allows a client to verify tha= t it
it can make c= hanges in the LIS commensurate with changes in the LoST
server by valid= ating locations in advance of a change. server by validating locations in advance of a change.
4. <locationIn= validated> object 4. <locationIn= validated> object
When the server needs to invalidate a location where the client = When a server needs to invalidate a loca= tion that has one or more
provided a URI in <plannedChan= ge>, the server executes an HTTPS POST associated client-supplied URIs (provi= ded in a <plannedChange>
containing <locationInvalidated>, with a Content-Ty= pe of elemen= t), it transmits an HTTPS POST with a Content-Type of
'application/= xml' to the URI previously provided. This = is the notice 'application/xml' containing a <locationInvalidated> object to each
from the serv= er to the client that the location may be invalid and associated URI. This is= the notice from the server to the client
should be rev= alidated. <locationInvalidated> contains an that the location may be invalid and should be revalidated= =2E The
'invalidAsOf'= attribute that specifies when the location= may become <locationInvalidated= > object contains an 'invalidAsOf' attribute,
invalid. If = the date/time in 'invalidAsOf' is earlier t= han the time which specifies a date and time when the location may become invalid.
the <locationInvalidated> was sent, the location m= ay already be If this is earlier than the current time,= the location may already be
invalid and the= LIS should take immediate action. If the POST invalid and the LIS should take immediate action. If the POST=
operation fails= , the server MAY retry the operation immediately, and operation fails, the server MAY retry the operation imm= ediately, and
if it fails a= gain, retry the operation at a later time.<= /td> if it fails again, retry the operat= ion later. Retry timing and
The LoST server= is NOT REQUIRED to store the Location Information The LoST server is NOT REQUIRED to store the Location Info= rmation
supplied in the= original findService request. This means the server supplied in the original findService request. This mea= ns the server
may not know if= a planned change will in fact invalidate the location may not know if a planned change will in fact invalida= te the location
stored in the L= oST client, because changes could be made in the LoST stored in the LoST client, because changes could be mad= e in the LoST
server that d= o not affect validation of the Location Information. server that do not affect validation of the client's specific
The LoST clie= nt may find that upon revalidation with the changed Location Information. The LoST client may find that upo= n
server state,= the validation data is the same as it was before the revalidation with the changed server state, the valida= tion data is
notification = was received. the same as it was be= fore the notification was received.
5. URI Not Stored= Warning 5. URI Not Stored Warning
A new warning is added to t= he exceptionContainer, 'uriNotStored'. This extension adds a new warning to th= e exceptionContainer,
This warning = MUST NOT be returned unless the <plannedChange> element 'uriNotStored'. This warning MUST NOT be retu= rned unless the request
was found in the corresponding request. The warning is r= eturned when = contains a <plannedChange> element w= ith a 'uri' attribute. The
the server de= cides not to store the URI found in the <planne= dChange> warning is retur= ned when the server decides not to store the URI.<= /span> As
element. As discussed above, this may occur because, am= ong other discussed above, this may= occur because, among other reasons, the
reasons, the = policy at the server limits how many URIs will be stored
against a spe= cific location, the URI is not well formed or the policy
at the server= has some other restriction on the feature. server has some other restriction on the feature.
6. Time-To-Live (= TTL) in Response 6. Time-To-Live (TTL)= in Response
A new <ttl> element is added= to the <findserviceResponse>.= The <ttl> This extension adds the <ttl> element to the <findServiceResponse>.
element conta= ins a date and time after which the client may wish to The <ttl> element contains a date and time afte= r which the client may
revalidate th= e location at the server. This element MAY= be added by wish to revalidate the location at the server. A server MAY add this
the server if validation is reque= sted in the response. The form of element to the response if validation is requested. This element<= /td>
the element is the 'expires' attribute pattern, which allows explicit= takes the form of the 'expires' attribute pattern of [= RFC5222], which
'NO CACHE' and 'NO EXPIRATION' va= lues to be returned in the <ttl&g= t; allows th= e values 'NO CACHE' or 'NO EXPIRATIO= N' to be returned
element. 'NO CACHE' has no meaning and MUST NOT be returned in TTL. instead of a dateTime value. However, for<= /span> the <ttl> element 'NO
'NO EXPIRATIO= N' means the server does not have any sugge= sted CACHE' has no meaning and MUST= NOT be returned. 'NO EXPIRATION'
revalidation = period. means the server does not h= ave a suggested revalidation period.
Selecting a rev= alidation interval is a complex balancing of Selecting a revalidation interval is a complex balancing of
timeliness, ser= ver load, stability of the underlying data, and policy timeliness, server load, stability of the underlying d= ata, and policy
of the LoST ser= ver. Too short, and load on the server may overwhelm of the LoST server. Too short, and load on the server = may overwhelm
it. Too long= and invalid data may persist in the server for to= o it. Too long and invalid = data may persist in the server for
long. The URI mechanism provides timely notice to coord= inate unacce= ptable lengths of time. The URI notificati= on mechanism
changes, but = even with it, it is often advisable to revalidate data provides timely notice to coordinate changes, but eve= n with it, it is
eventually. often advisable to revalidate data e= ventually.
In areas that h= ave little change in data, such as fully built out, In areas that have little change in data, such as fully b= uilt out,
stable communit= ies already part of a municipality, it may be stable communities already part of a municipality, it may be
reasonable to s= et revalidation periods of 6 months or longer, reasonable to set revalidation periods of 6 months or longer,<= /td>
especially if t= he URI mechanism is widely deployed at both the server especially if the URI mechanism is widely deployed at = both the server
and the clients= =2E In areas that are quickly growing, 20-30 day and the clients. In areas that are quickly growing, 20-30 = day
revalidation ma= y be more appropriate even though such revalidation revalidation may be more appropriate even though such rev= alidation
would be the ma= jority of the traffic on the LoST server. would be the majority of the traffic on the LoST server.
When a planned = change is made, typically the TTL value for the When a planned change is made, typically the TTL value for the=
skipping to= change at page 15, line 30 skipping to chang= e at page 16, line 20
<!-- Impor= t base Lost --> <!-- Import = base Lost -->
<xs:import= namespace=3D"urn:ietf:params:xml:ns:lost1"/> <xs:import namespace=3D"urn:ietf:params:xml:ns:lost1"/>= ;
<!-- extend the= extensionPoint of commonRequestPattern of findService <!-- extend the extensionPoint of commonRequestPattern= of findService
= to include: -->
xs:group r= ef=3D"plannedChange" minOccurs=3D"1"/> xs:group ref=3D"plannedChange" minOccurs=3D"1"/>
<!-- where --&g= t; <!-- where -->
<xs:grou= p name=3D"plannedChange"> <= ;xs:group name=3D"plannedChange">
<xs:= sequence> <xs:sequence= >
<= xs:element ref=3D"uri" type=3D"xs:anyURI" /> <xs:element ref=3D"uri" type=3D"xs:anyURI" />=
&l= t;xs:element ref=3D=E2=80=9CinvalidAsOf" ty= pe=3D"xs:dateTime" /> = <xs:element ref=3D"invalidAsOf" type=3D= "xs:dateTime" />
<= xs:any namespace=3D"##other" processContents=3D"lax" <xs:any namespace=3D"##other" processConte= nts=3D"lax"
m= inOccurs=3D"0" maxOccurs=3D"unbounded"/> minOccurs=3D"0" maxOccurs=3D"unbounded"/>
</xs= :sequence> </xs:sequen= ce>
</xs:gr= oup> </xs:group>
<!-- extend the= extensionPoint of commonResponsePattern in <!-- extend the extensionPoint of commonResponsePattern in
= findServiceResponse to include: --> findServiceResponse to include: --><= /td>
<xs:= atttribute name=3D"asOf" type=3D"xs:dateTime" minOccurs=3D"0"/> <xs:atttribute name=3D"asOf" ty= pe=3D"xs:dateTime" minOccurs=3D"0"/>
<xs:= element ref=3D"ttl" type=3D"expires" minOccurs=3D"0" /> <xs:element ref=3D"ttl" type=3D"expires= " minOccurs=3D"0" />
skipping to= change at page 16, line 4 skipping to change= at page 16, line 37= ¶
= findServiceResponse to include: --> findServiceResponse to include: --><= /td>
<xs:= atttribute name=3D"asOf" type=3D"xs:dateTime" minOccurs=3D"0"/> <xs:atttribute name=3D"asOf" ty= pe=3D"xs:dateTime" minOccurs=3D"0"/>
<xs:= element ref=3D"ttl" type=3D"expires" minOccurs=3D"0" /> <xs:element ref=3D"ttl" type=3D"expires= " minOccurs=3D"0" />
<!-- extend the= extensionPoint of extensionContainer to include: -->
<xs:= element ref=3D"uriNotStored"/> = <xs:element ref=3D"uriNotStored"/><= /td>
<!-- where --&g= t; <!-- where -->
<xs:= element name=3D"uriNotStored" type=3D"basicException"/> <xs:element name=3D"uriNotStored" type=3D= "basicException"/>
</xs:schema>= </xs:schema>
9. locationInvali= dated Schema 9. locationInvalidated Sc= hema
This schema d= efines the object used for the notification of This schema defines the object = used for the notification that a
(potential) invalidated location by the LoST server to a client that location is potentially invalidated sent by a LoST server to a client
requested it.= that requested it.
<?xml versio= n=3D"1.0" encoding=3D"UTF-8"?> &l= t;?xml version=3D"1.0" encoding=3D"UTF-8"?><= /td>
<xs:schema x= mlns:xs=3D"http://www.w3.org/2001/XMLSchema" <xs:schema xmlns:xs=3D"http://www.w3.org/2001/XMLSchema"
xmlns=3D"ur= n:ietf:params:xml:ns:lostLocationInvalidated1" xmlns=3D"urn:ietf:params:xml:ns:lostLocationInvalidated1"<= /td>
targetNames= pace=3D"urn:ietf:params:xml:ns:lostLocationInvalidated1"
elementForm= Default=3D"qualified"> elemen= tFormDefault=3D"qualified">
<xs:element= name=3D"locationInvalidated"> &= lt;xs:element name=3D"locationInvalidated"><= /td>
<xs:annot= ation> <xs:annotation>
<xs:doc= umentation> <xs:documenta= tion>
A point = where future extensions A poi= nt where future extensions
skipping to= change at page 16, line 42 skipping to chang= e at page 17, line 37
10. Security Cons= iderations 10. Security Considerations=
As an extension= to LoST, this document inherits the security issues As an extension to LoST, this document inherits the secu= rity issues
raised in [RFC5= 222]. The server could be tricked into storing a raised in [RFC5222]. The server could be tricked into stor= ing a
malicious URI w= hich, when sent the locationInvalidated object could malicious URI which, when sent the locationInvalidated o= bject could
trigger somethi= ng untoward. The server MUST NOT accept any data from trigger something untoward. The server MUST NOT accep= t any data from
the client in r= esponse to POSTing the locationInvalidated. the client in response to POSTing the locationInvalidated.
The server is s= ubject to abuse by clients because it is being asked The server is subject to abuse by clients because it is = being asked
to store someth= ing and may need to send data to an uncontrolled URI. to store something and may need to send data to an unco= ntrolled URI.
Clients could= request many URIs for the same location for example. Clients could request many URIs for the same location<= span class=3D"insert">, for example.
The server MUST= have policy that limits use of this mechanism by a The server MUST have policy that limits use of this mecha= nism by a
given client. = If the policy is exceeded, the server returns the given client. If the policy is exceeded, the server return= s the
'uriNotStored' = warning. The server MUST validate that the content of 'uriNotStored' warning. The server MUST validate that= the content of
the 'uri' attri= bute sent is syntactically valid and meets the 256 the 'uri' attribute sent is syntactically valid and meets = the 256
bytes limit. W= hen sending the locationInvalidated object to the URI bytes limit. When sending the locationInvalidated obje= ct to the URI
stored, the ser= ver MUST protect itself against common HTTP stored, the server MUST protect itself against common HTTP
vulnerabilities= =2E vulnerabilities.
The mutual auth= entication between client and server is RECOMMENDED The mutual authentication between client and server is RE= COMMENDED
for both the in= itial <findService> operation that requests storing
the URI and the= sending of the 'locationInvalidated' object. The the URI and the sending of the 'locationInvalidated' objec= t. The
server should b= e well known to the client, and its credential should server should be well known to the client, and its cred= ential should
be learned in a= reliable way. For example, a public safety system be learned in a reliable way. For example, a public safe= ty system
operating the L= oST server may have a credential traceable to a well operating the LoST server may have a credential traceabl= e to a well
known Certifica= te Authority known to provide credentials for public known Certificate Authority known to provide credentials= for public
safety agenci= es. Many of the clients will be operated b= y local ISPs safety agencies. Clients may be operated by local ISPs or other<= /td>
or other serv= ice providers where the server operator can= reasonably service providers that can reasonably obtain a good credential to = use
obtain a good= credential to use for the URI. Where the server does for the server side of the LoS= T server's POST transaction using the
not recognize= the client, its policy MAY limit the use of this URI. Where the loST server = does not recognize the client, its policy
feature beyon= d what it would limit a client it recognized. MAY limit the use of this featur= e beyond what it would limit a client
11. IANA Consider= ations 11. IANA Considerations
11.1. Replacement= XML Schema Registration 11.1. Replace= ment XML Schema Registration
URI: urn:ie= tf:params:xml:schema:lost3 URI: = urn:ietf:params:xml:schema:lost3
Registrant C= ontact: IETF ECRIT Working Group, Brian Rosen Registrant Contact: IETF ECRIT Working Group, Brian Rosen<= /td>
(br@brian= rosen.net). (br@brianrosen.net= ).
XML: XML:
BEGIN BEGIN
skipping to= change at page 19, line 34 skipping to chang= e at page 20, line 34
</body> </body>
</html> </html>
END END
The XML Schema = is found in Section 9. The XML Schem= a is found in Section 9.
12. Normative Ref= erences 12. Normative References
[RFC2119] Brad= ner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=
Requ= irement Levels", BCP 14, RFC 2119, = Requirement Levels", BCP 14, RFC 2119,
DO= I 10.17487/RFC2119, March 1997, = DOI 10.17487/RFC2119, March 1997, <http= s://www.rfc-
<https://www.rfc-editor.org/info/rfc2119>. = editor.org/info/rfc2119>.
[RFC5222] Hard= ie, T., Newton, A., Schulzrinne, H., and H. [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tsch= ofenig, "LoST: A Location-to-Service Translation Tschofenig, "LoST: A Location-to-Service Translatio= n
Prot= ocol", RFC 5222, DOI 10.17487/RFC5222, August 2008, Protocol", RFC 5222, DOI 10.17487/RFC5222, Aug= ust 2008,
<= https://www.rfc-editor.org/info/rfc5222>. <https://www.rfc-editor.org/info/rfc5222>.
Author's Address Author's Address
Brian Rosen Brian Rosen
470 Conrad Dr 470 Conrad Dr
Mars, PA 1604= 6 Mars, PA 16046
United States of America US
Email: br@brianrosen.net EMail: br@brianrosen.net
<= /td>
&= nbsp;End of changes. 32 change blocks. 
158 lines changed or deleted= 190 lines changed or added

This htm= l diff was produced by rfcdiff 1.48. The latest version is available from= http://tools.ietf.= org/tools/rfcdiff/
--=_MailMate_321F8108-A8BB-4A6C-AC31-1622E59E899C_=-- From nobody Mon Aug 23 14:42:00 2021 Return-Path: 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 CE7AB3A1C90 for ; Mon, 23 Aug 2021 14:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 iTmheKLjXrVN for ; Mon, 23 Aug 2021 14:41:39 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0DF3A1C95 for ; Mon, 23 Aug 2021 14:41:39 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 23 Aug 2021 14:41:38 -0700 From: "Randall Gellens" To: "Caron, Guy" Cc: "Brian Rosen" , ecrit@ietf.org Date: Mon, 23 Aug 2021 14:41:38 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <8508C216-7FF5-41D2-A78D-EBF475F83C7F@randy.pensive.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_359E529D-0D01-45A0-A802-BE4590A4F4BD_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[735, 2339], "plain":[404, 309], "uuid":"923ED4C2-6F72-4ACC-965E-331D4B45467D"}] Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: Locations are not always invalidated X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 21:41:59 -0000 --=_MailMate_359E529D-0D01-45A0-A802-BE4590A4F4BD_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Using 'impacted' is not really better, because a location may or may not actually be impacted. If we go down the path of precise names we should use something such as 'locationPotentiallyInvalidated', which seems silly. I think the draft makes it clear (especially with my suggested edits) that a notified location is potentially invalidated. --Randall On 23 Aug 2021, at 14:24, Caron, Guy wrote: > This new version introduces variability in whether a location is > indeed invalidated or not by a change, which I agree with. > > Given this, the names “locationInvalidated†and > “invalidatedAsOf†seem misleading. Should “invalidated†be > changed to something like “Impacted� > > Thanks, > > Guy > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --=_MailMate_359E529D-0D01-45A0-A802-BE4590A4F4BD_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Using 'impacted' is not really better, because a location = may or may not actually be impacted. If we go down the path of precise n= ames we should use something such as 'locationPotentiallyInvalidated', wh= ich seems silly. I think the draft makes it clear (especially with my su= ggested edits) that a notified location is potentially invalidated.

--Randall

On 23 Aug 2021, at 14:24, Caron, Guy wrote:

This new version introduces variability in whether a location is indee= d invalidated or not by a change, which I agree with.

=C2=A0

Given this, the names =E2=80=9ClocationInvalidated=E2=80=9D and =E2=80= =9CinvalidatedAsOf=E2=80=9D seem misleading. Should =E2=80=9Cinvalidated=E2= =80=9D be changed to something like =E2=80=9CImpacted=E2=80=9D?

=C2=A0

Thanks,

=C2=A0

Guy

=C2=A0

=C2=A0

______________________= _________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

--=_MailMate_359E529D-0D01-45A0-A802-BE4590A4F4BD_=-- From nobody Mon Aug 23 14:44:18 2021 Return-Path: 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 9C0DE3A1CC1 for ; Mon, 23 Aug 2021 14:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=bell.ca 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 1Yag8YfUhcDR for ; Mon, 23 Aug 2021 14:44:10 -0700 (PDT) Received: from ESA2-Wyn.bell.ca (esa2-wyn.bell.ca [67.69.243.180]) (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 9DEC93A1CBC for ; Mon, 23 Aug 2021 14:44:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1629755050; x=1661291050; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=dWXWpa4iwQC2Mxg/JrDbobX+JTkOMDNQSs9tszXrPOI=; b=auUoyIUoJB9GhFg3km58xPNvx1Npvn0T8FIKOWC3ZDKHSL6VkhrTzarM C/Nnca1iRxGjv6YyKucK+Dc25wpSnqM3h1Lr65gJPIS8DsUft+Ml6ME3o ewNOkkM+H+cid+zngjusNeuVbbvXjFXqjrkzK3FyUZ+W6qCa3JsuWL0mH SgeQmAN+o9Mnpg31urrF8wuqgKAWJD/UTbbpmUrfXmoDAHh5L/PLymcMj dSkw6SJg7Rc7KBxB9C4Rs6HrJgKW0hHKdsup630gd+EDpjUxWPGGMHFLo LX9zDToF6esYsZ9yv+jqZK8JJQE7L2DyUtoTOXE/72oGBNAcpD76Uol7x A==; IronPort-SDR: 0Nsh2GeOP1sqgpWGUapVylkmvgem9bzWviKK0aTO0hlbwhpdgNRxquOixjkAEVnE2dSf99Hwfe nIIT55dHsnKA== Received: from dm5czo-d01.bellca.int.bell.ca (HELO DG1MBX03-WYN.bell.corp.bce.ca) ([198.235.102.33]) by esa02corp-wyn.bell.corp.bce.ca with ESMTP; 23 Aug 2021 17:44:09 -0400 Received: from DG12MBX03-WYN.bell.corp.bce.ca (142.182.18.48) by DG1MBX03-WYN.bell.corp.bce.ca (142.182.18.13) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 23 Aug 2021 17:44:09 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX03-WYN.bell.corp.bce.ca (142.182.18.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Mon, 23 Aug 2021 17:44:09 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Mon, 23 Aug 2021 17:44:09 -0400 From: "Caron, Guy" To: Brian Rosen CC: "ecrit@ietf.org" Thread-Topic: [EXT]Re: lost-planned-changes-04: plannedChange bound to validateLocation? Thread-Index: AdeYYhykIa0/cXEHQDGV6seRBYfoOQAJEtyAAAfVt2A= Date: Mon, 23 Aug 2021 21:44:08 +0000 Message-ID: <791ea34f628d48d3addeb04613d5721a@bell.ca> References: <8bdda7ea7d004b4591ff715526d93a73@bell.ca> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.79] Content-Type: multipart/alternative; boundary="_000_791ea34f628d48d3addeb04613d5721abellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 21:44:17 -0000 --_000_791ea34f628d48d3addeb04613d5721abellca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB0aGF0IGFjY29tbW9kYXRpbmcgdGhpcyBjb21tZW50IHdvdWxkIHJlcXVpcmUgZGVl cGVyIFhNTCBjaGFuZ2VzLg0KDQpJZiB3ZSBkbyBub3Qgd2FudCB0byBnbyB0aGVyZSwgSSB0aGlu ayB0aGUgZHJhZnQgc2hvdWxkIGJlIGNsZWFyIHRoYXQgdGhlcmUgaXMgbm8gdXNlY2FzZSBmb3Ig c2VuZGluZyA8cGxhbm5lZENoYW5nZT4gb3V0c2lkZSBvZiBhIGxvY2F0aW9uIHZhbGlkYXRpb24g cmVxdWVzdCBhbmQgYXMgc3VjaCwgc2hvdWxkIG5vcm1hdGl2ZWx5IHJlY29tbWVuZCBub3QgZG9p bmcgc28uDQoNCkkgZG8gbm90IGFncmVlIHRoYXQgYSBMb1NUIHNlcnZlciByZWNlaXZpbmcgPHBs YW5uZWRDaGFuZ2U+IG91dHNpZGUgb2YgYSBsb2NhdGlvbiB2YWxpZGF0aW9uIHJlcXVlc3Qgd291 bGQgcmV0YWluIHRoZSBVUkkgYW5kIHNlbmQgbm90aWZpY2F0aW9uIGlmIHRoZSByZWNvcmQgY2hh bmdlZCBhZnRlcndhcmQuIEkgdGhpbmsgdGhpcyB3b3VsZCBjcmVhdGUgaGF2b2Mgb24gdGhlIGNs aWVudOKAmSBzaWRlLg0KDQpUaGFua3MsDQoNCkd1eQ0KDQpEZSA6IEJyaWFuIFJvc2VuIDxickBi cmlhbnJvc2VuLm5ldD4NCkVudm95w6kgOiAyMyBhb8O7dCAyMDIxIDE3OjIyDQrDgCA6IENhcm9u LCBHdXkgPGcuY2Fyb25AYmVsbC5jYT4NCkNjIDogZWNyaXRAaWV0Zi5vcmcNCk9iamV0IDogW0VY VF1SZTogbG9zdC1wbGFubmVkLWNoYW5nZXMtMDQ6IHBsYW5uZWRDaGFuZ2UgYm91bmQgdG8gdmFs aWRhdGVMb2NhdGlvbj8NCg0KdmFsaWRhdGVMb2NhdGlvbiBpcyBhbiBhdHRyaWJ1dGUsIG5vdCBh biBlbGVtZW50LCBzbyBJIGNhbuKAmXQgZXh0ZW5kIGl0Lg0KDQpUaGVyZSBpc27igJl0IGFuIGFj dHVhbCByZXF1aXJlbWVudCB0byB0aWUgcGxhbm5lZENoYW5nZSB0byB2YWxpZGF0ZUxvY2F0aW9u LiAgSXQgbWF5IG5vdCBtYWtlIGEgbG90IG9mIHNlbnNlLCBidXQgaWYgeW91IGRpZCBpdCwgdGhl IExvU1Qgc2VydmVyIHdvdWxkIG5vdCByZXR1cm4gdmFsaWRhdGlvbiBkYXRhLCB3b3VsZCByZXRh aW4gdGhlIFVSSSBhbmQgd291bGQgc2VuZCB0aGUgbm90aWZpY2F0aW9uIGlmIHRoZSByZWNvcmQg Y2hhbmdlZC4gIE5vdGUgbXkgdGV4dCB0aGF0IHRoZSBMb1NUIHNlcnZlciBkb2VzbuKAmXQgc3Rv cmUgdGhlIExJIC0gdGhlIG5vdGlmaWNhdGlvbiBpcyDigJxzb21ldGhpbmcgY2hhbmdlZOKAnSBu b3Qg4oCcd2hhdCB5b3Ugc2VudCBpcyBndWFyYW50ZWVkIHRvIGJlIGludmFsaWTigJ0gb3IgZXZl biDigJxvbmUgb3IgbW9yZSBvZiB0aGUgZWxlbWVudHMgeW91IHNlbnQgY2hhbmdlZCIuICBJIHRo b3VnaHQgYWJvdXQgY2hhbmdpbmcgdGhlIG5hbWUgb2YgdGhlIG5vdGlmaWNhdGlvbiwgYnV0IEkg ZGlkbuKAmXQgZG8gdGhhdC4gIFRoZSBwcmFjdGljYWwgdXNlIGNhc2UgcmVtYWlucyB0aGUgc2Ft ZS4NCg0KQnJpYW4NCg0KDQpPbiBBdWcgMjMsIDIwMjEsIGF0IDU6MDcgUE0sIENhcm9uLCBHdXkg PGcuY2Fyb25AYmVsbC5jYTxtYWlsdG86Zy5jYXJvbkBiZWxsLmNhPj4gd3JvdGU6DQoNCk5vdCBh bGwgTG9TVCBzZXJ2ZXIgaW1wbGVtZW50YXRpb25zIHBlcmZvcm0gbG9jYXRpb24gdmFsaWRhdGlv bnMuIFdoZW4gbG9jYXRpb24gdmFsaWRhdGlvbiBpcyByZXF1ZXN0ZWQgYnkgdGhlIGNsaWVudCwg aXQgYWRkcyB0aGUg4oCcdmFsaWRhdGVMb2NhdGlvbuKAnSBhdHRyaWJ1dGUgdG8gdGhlIDxmaW5k U2VydmljZT4gZWxlbWVudC4NCg0KU28gdGhlIHF1ZXN0aW9uIGlzOiBTaG91bGQg4oCccGxhbm5l ZENoYW5nZeKAnSBiZSBib3VuZCB0byDigJx2YWxpZGF0ZUxvY2F0aW9u4oCdPw0KDQpJZiB5b3Ug YmVsaWV2ZSBub3QsIHdoYXQgd291bGQgYmUgdGhlIGV4cGVjdGVkIGJlaGF2aW91ciBvZiBhIExv U1Qgc2VydmVyIHJlY2VpdmluZyBhIDxwbGFubmVkQ2hhbmdlPiBlbGVtZW50IG91dHNpZGUgb2Yg YSB2YWxpZGF0aW9uIHJlcXVlc3Q/DQoNClRoYW5rcywNCg0KR3V5DQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpFeHRlcm5hbCBFbWFpbDogUGxlYXNlIHVzZSBjYXV0aW9uIHdo ZW4gb3BlbmluZyBsaW5rcyBhbmQgYXR0YWNobWVudHMgLyBDb3VycmllbCBleHRlcm5lOiBTb3ll eiBwcnVkZW50IGF2ZWMgbGVzIGxpZW5zIGV0IGRvY3VtZW50cyBqb2ludHMNCg== --_000_791ea34f628d48d3addeb04613d5721abellca_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5t c29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFt ZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUi1DQSIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGFncmVlIHRoYXQgYWNjb21tb2RhdGluZyB0aGlzIGNv bW1lbnQgd291bGQgcmVxdWlyZSBkZWVwZXIgWE1MIGNoYW5nZXMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPklmIHdlIGRv IG5vdCB3YW50IHRvIGdvIHRoZXJlLCBJIHRoaW5rIHRoZSBkcmFmdCBzaG91bGQgYmUgY2xlYXIg dGhhdCB0aGVyZSBpcyBubyB1c2VjYXNlIGZvciBzZW5kaW5nICZsdDtwbGFubmVkQ2hhbmdlJmd0 Ow0KIG91dHNpZGUgb2YgYSBsb2NhdGlvbiB2YWxpZGF0aW9uIHJlcXVlc3QgYW5kIGFzIHN1Y2gs IHNob3VsZCBub3JtYXRpdmVseSByZWNvbW1lbmQgbm90IGRvaW5nIHNvLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGRv IG5vdCBhZ3JlZSB0aGF0IGEgTG9TVCBzZXJ2ZXIgcmVjZWl2aW5nICZsdDtwbGFubmVkQ2hhbmdl Jmd0OyBvdXRzaWRlIG9mIGEgbG9jYXRpb24gdmFsaWRhdGlvbiByZXF1ZXN0IHdvdWxkIHJldGFp biB0aGUNCiBVUkkgYW5kIHNlbmQgbm90aWZpY2F0aW9uIGlmIHRoZSByZWNvcmQgY2hhbmdlZCBh ZnRlcndhcmQuIEkgdGhpbmsgdGhpcyB3b3VsZCBjcmVhdGUgaGF2b2Mgb24gdGhlIGNsaWVudOKA mSBzaWRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkd1eTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkZS IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiBCcmlhbiBSb3NlbiAmbHQ7YnJAYnJpYW5yb3Nlbi5uZXQmZ3Q7DQo8YnI+ DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gMjMgYW/Du3QgMjAyMSAxNzoyMjxicj4NCjxiPsOAJm5i c3A7OjwvYj4gQ2Fyb24sIEd1eSAmbHQ7Zy5jYXJvbkBiZWxsLmNhJmd0Ozxicj4NCjxiPkNjJm5i c3A7OjwvYj4gZWNyaXRAaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFtFWFRdUmU6 IGxvc3QtcGxhbm5lZC1jaGFuZ2VzLTA0OiBwbGFubmVkQ2hhbmdlIGJvdW5kIHRvIHZhbGlkYXRl TG9jYXRpb24/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ dmFsaWRhdGVMb2NhdGlvbiBpcyBhbiBhdHRyaWJ1dGUsIG5vdCBhbiBlbGVtZW50LCBzbyBJIGNh buKAmXQgZXh0ZW5kIGl0LiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoZXJlIGlzbuKAmXQgYW4gYWN0dWFsIHJlcXVpcmVtZW50IHRvIHRpZSBw bGFubmVkQ2hhbmdlIHRvIHZhbGlkYXRlTG9jYXRpb24uICZuYnNwO0l0IG1heSBub3QgbWFrZSBh IGxvdCBvZiBzZW5zZSwgYnV0IGlmIHlvdSBkaWQgaXQsIHRoZSBMb1NUIHNlcnZlciB3b3VsZCBu b3QgcmV0dXJuIHZhbGlkYXRpb24gZGF0YSwgd291bGQgcmV0YWluIHRoZSBVUkkgYW5kIHdvdWxk IHNlbmQgdGhlIG5vdGlmaWNhdGlvbiBpZiB0aGUNCiByZWNvcmQgY2hhbmdlZC4gJm5ic3A7Tm90 ZSBteSB0ZXh0IHRoYXQgdGhlIExvU1Qgc2VydmVyIGRvZXNu4oCZdCBzdG9yZSB0aGUgTEkgLSB0 aGUgbm90aWZpY2F0aW9uIGlzIOKAnHNvbWV0aGluZyBjaGFuZ2Vk4oCdIG5vdCDigJx3aGF0IHlv dSBzZW50IGlzIGd1YXJhbnRlZWQgdG8gYmUgaW52YWxpZOKAnSBvciBldmVuIOKAnG9uZSBvciBt b3JlIG9mIHRoZSBlbGVtZW50cyB5b3Ugc2VudCBjaGFuZ2VkJnF1b3Q7LiAmbmJzcDtJIHRob3Vn aHQgYWJvdXQgY2hhbmdpbmcgdGhlIG5hbWUgb2YNCiB0aGUgbm90aWZpY2F0aW9uLCBidXQgSSBk aWRu4oCZdCBkbyB0aGF0LiAmbmJzcDtUaGUgcHJhY3RpY2FsIHVzZSBjYXNlIHJlbWFpbnMgdGhl IHNhbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkJyaWFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBBdWcgMjMsIDIwMjEsIGF0IDU6MDcgUE0sIENhcm9uLCBHdXkgJmx0 OzxhIGhyZWY9Im1haWx0bzpnLmNhcm9uQGJlbGwuY2EiPmcuY2Fyb25AYmVsbC5jYTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ob3QgYWxsIExvU1Qgc2Vy dmVyIGltcGxlbWVudGF0aW9ucyBwZXJmb3JtIGxvY2F0aW9uIHZhbGlkYXRpb25zLiBXaGVuIGxv Y2F0aW9uIHZhbGlkYXRpb24gaXMgcmVxdWVzdGVkIGJ5IHRoZSBjbGllbnQsIGl0IGFkZHMgdGhl IOKAnHZhbGlkYXRlTG9jYXRpb27igJ0NCiBhdHRyaWJ1dGUgdG8gdGhlICZsdDtmaW5kU2Vydmlj ZSZndDsgZWxlbWVudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ U28gdGhlIHF1ZXN0aW9uIGlzOiBTaG91bGQg4oCccGxhbm5lZENoYW5nZeKAnSBiZSBib3VuZCB0 byDigJx2YWxpZGF0ZUxvY2F0aW9u4oCdPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5JZiB5b3UgYmVsaWV2ZSBub3QsIHdoYXQgd291bGQgYmUgdGhlIGV4cGVjdGVk IGJlaGF2aW91ciBvZiBhIExvU1Qgc2VydmVyIHJlY2VpdmluZyBhICZsdDtwbGFubmVkQ2hhbmdl Jmd0OyBlbGVtZW50IG91dHNpZGUgb2YgYSB2YWxpZGF0aW9uIHJlcXVlc3Q/PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+R3V5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0i MTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzdHJv bmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj5FeHRlcm5hbCBF bWFpbDo8L3NwYW4+PC9pPjwvc3Ryb25nPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2NvbG9yOmJsdWUiPiBQbGVhc2UgdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxpbmtzIGFuZCBh dHRhY2htZW50cyAvDQo8L3NwYW4+PC9lbT48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Y29sb3I6Ymx1ZSI+Q291cnJpZWwgZXh0ZXJuZTo8L3NwYW4+PC9pPjwvc3Ryb25n PjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPiBTb3lleiBwcnVk ZW50IGF2ZWMgbGVzIGxpZW5zIGV0IGRvY3VtZW50cyBqb2ludHMNCjwvc3Bhbj48L2VtPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_791ea34f628d48d3addeb04613d5721abellca_-- From nobody Mon Aug 23 14:47:39 2021 Return-Path: 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 6D9C53A1D03 for ; Mon, 23 Aug 2021 14:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 bl0oHNs0gORW for ; Mon, 23 Aug 2021 14:47:31 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id C993B3A1D08 for ; Mon, 23 Aug 2021 14:47:30 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 23 Aug 2021 14:47:30 -0700 From: "Randall Gellens" To: "Caron, Guy" Cc: "Brian Rosen" , ecrit@ietf.org Date: Mon, 23 Aug 2021 14:47:29 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <2C9BD286-3868-4717-8A1E-972259FA758E@randy.pensive.org> In-Reply-To: <791ea34f628d48d3addeb04613d5721a@bell.ca> References: <8bdda7ea7d004b4591ff715526d93a73@bell.ca> <791ea34f628d48d3addeb04613d5721a@bell.ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_6CA935C8-472A-424C-8C04-AE82872D61A1_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[503, 8622], "plain":[172, 2174], "uuid":"387C7E54-EB14-4AA8-8B35-463012C8D162"}] Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 21:47:37 -0000 --=_MailMate_6CA935C8-472A-424C-8C04-AE82872D61A1_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit As I mentioned, my suggested edits make it clear that the extension is only useful in the context of validation. --Randall On 23 Aug 2021, at 14:44, Caron, Guy wrote: > I agree that accommodating this comment would require deeper XML > changes. > > If we do not want to go there, I think the draft should be clear that > there is no usecase for sending outside of a location > validation request and as such, should normatively recommend not doing > so. > > I do not agree that a LoST server receiving outside of > a location validation request would retain the URI and send > notification if the record changed afterward. I think this would > create havoc on the client’ side. > > Thanks, > > Guy > > De : Brian Rosen > Envoyé : 23 août 2021 17:22 > À : Caron, Guy > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to > validateLocation? > > validateLocation is an attribute, not an element, so I can’t extend > it. > > There isn’t an actual requirement to tie plannedChange to > validateLocation. It may not make a lot of sense, but if you did it, > the LoST server would not return validation data, would retain the URI > and would send the notification if the record changed. Note my text > that the LoST server doesn’t store the LI - the notification is > “something changed†not “what you sent is guaranteed to be > invalid†or even “one or more of the elements you sent changed". > I thought about changing the name of the notification, but I didn’t > do that. The practical use case remains the same. > > Brian > > > On Aug 23, 2021, at 5:07 PM, Caron, Guy > > wrote: > > Not all LoST server implementations perform location validations. When > location validation is requested by the client, it adds the > “validateLocation†attribute to the element. > > So the question is: Should “plannedChange†be bound to > “validateLocation� > > If you believe not, what would be the expected behaviour of a LoST > server receiving a element outside of a validation > request? > > Thanks, > > Guy > > ________________________________ > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --=_MailMate_6CA935C8-472A-424C-8C04-AE82872D61A1_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">As I mentioned, my suggested edits make it clear that the = extension is only useful in the context of validation.

--Randall

On 23 Aug 2021, at 14:44, Caron, Guy wrote:

I agree that accommodating this comment would require deeper XML chang= es.

=C2=A0

If we do not want to go there, I think the draft should be clear that = there is no usecase for sending <plannedChange> outside of a location validation request and as such, should normatively= recommend not doing so.

=C2=A0

I do not agree that a LoST server receiving <plannedChange> outs= ide of a location validation request would retain the URI and send notification if the record changed afterward. I think this = would create havoc on the client=E2=80=99 side.

=C2=A0

Thanks,

=C2=A0

Guy

=C2=A0

De=C2=A0: Brian Rosen = <br@brianrosen.net>
Envoy=C3=A9=C2=A0: 23 ao=C3=BBt 2021 17:22
=C3=80=C2=A0: Caron, Guy <g.caron@bell.ca>
Cc=C2=A0: ecrit@ietf.org
Objet=C2=A0: [EXT]Re: lost-planned-changes-04: plannedChange bound= to validateLocation?

=C2=A0

validateLocation is an attribute, not an eleme= nt, so I can=E2=80=99t extend it. =C2=A0

=C2=A0

There isn=E2=80=99t an actual requirement to t= ie plannedChange to validateLocation. =C2=A0It may not make a lot of sens= e, but if you did it, the LoST server would not return validation data, w= ould retain the URI and would send the notification if the record changed. =C2=A0Note my text that the LoST server doesn=E2=80=99t = store the LI - the notification is =E2=80=9Csomething changed=E2=80=9D no= t =E2=80=9Cwhat you sent is guaranteed to be invalid=E2=80=9D or even =E2= =80=9Cone or more of the elements you sent changed". =C2=A0I thought abou= t changing the name of the notification, but I didn=E2=80=99t do that. =C2=A0The practical use = case remains the same.

=C2=A0

Brian



On Aug 23, 2021, at 5:07 PM, Caron, Guy <g.caron@bell.ca> wrote:

=C2=A0

Not all LoST server impl= ementations perform location validations. When location validation is req= uested by the client, it adds the =E2=80=9CvalidateLocation=E2=80=9D attribute to the <findService> element.

=C2=A0

So the question is: Shou= ld =E2=80=9CplannedChange=E2=80=9D be bound to =E2=80=9CvalidateLocation=E2= =80=9D?

=C2=A0

If you believe not, what= would be the expected behaviour of a LoST server receiving a <planned= Change> element outside of a validation request?

=C2=A0

Thanks,

=C2=A0

Guy

=C2=A0

External Email: Please use caution when opening links and attachments= / Courrie= l externe: Soyez prudent avec les liens et documents joints

______________________= _________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

--=_MailMate_6CA935C8-472A-424C-8C04-AE82872D61A1_=-- From nobody Mon Aug 23 14:48:44 2021 Return-Path: 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 1EE853A1D1D for ; Mon, 23 Aug 2021 14:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=bell.ca 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 ELUcgCE31ms2 for ; Mon, 23 Aug 2021 14:48:35 -0700 (PDT) Received: from ESA2-Dor.bell.ca (esa2-dor.bell.ca [204.101.223.59]) (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 4BF3B3A1D20 for ; Mon, 23 Aug 2021 14:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1629755315; x=1661291315; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=OI8nrmMgb0qSegm20huxcb5thCInyCsFvHlLFKTz9G8=; b=JNFkqZXkMLa3j36+60HEUxVZAyF0GFnOizLI2NT8Y/yfcNSYGrA+gEMc wxlIkPUItC7rlhEiVwQK9ylM/mP9X9V+XmxX8sLPi07+J79zVBpuiFRw0 grb7CtkU3W9LBvQwkhZqkjFtMAWYRc8R8ngcGcCbtjmrGUGdy8fQQALNm 1PNtv3xYGYNrWMqKN/im7WHpAfWvXfdfOD9rhv7SlIaIxKYm+egC0Wds/ 0EiEuwRJuNK6zhc1f9cm0OopAn25LbA9pt9aDsoZ1Pw5gFp2/MtY4A8m/ ujRYazVigc5PEgP4ZMeBwGfdvpUSpvLZqZAOuWUHMuM2B/qdEP8VlbSUj g==; IronPort-SDR: d7bVXub3d+rMiO6d3nqQ86cqVm65mwLQgd/uUfKNIiRN+BDwK5yF4+WllE9XjUuXHhmlfW8EBx dVn25QbAKrVQ== Received: from dc5cmy-d01.bellca.int.bell.ca (HELO DG4MBX01-WYN.bell.corp.bce.ca) ([198.235.121.230]) by esa02corp-dor.bell.corp.bce.ca with ESMTP; 23 Aug 2021 17:48:33 -0400 Received: from DG12MBX02-WYN.bell.corp.bce.ca (142.182.18.47) by DG4MBX01-WYN.bell.corp.bce.ca (142.182.18.27) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 23 Aug 2021 17:48:33 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX02-WYN.bell.corp.bce.ca (142.182.18.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Mon, 23 Aug 2021 17:48:33 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Mon, 23 Aug 2021 17:48:33 -0400 From: "Caron, Guy" To: Randall Gellens CC: Brian Rosen , "ecrit@ietf.org" Thread-Topic: [EXT]Re: [Ecrit] lost-planned-changes-04: Locations are not always invalidated Thread-Index: AdeYZFeQ2SDl+s67TUyTfs68kd40mwAJNZoAAAhHdZA= Date: Mon, 23 Aug 2021 21:48:33 +0000 Message-ID: References: <8508C216-7FF5-41D2-A78D-EBF475F83C7F@randy.pensive.org> In-Reply-To: <8508C216-7FF5-41D2-A78D-EBF475F83C7F@randy.pensive.org> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.79] Content-Type: multipart/alternative; boundary="_000_f31a4b66d3ee4a7587991181705948d1bellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: Locations are not always invalidated X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 21:48:42 -0000 --_000_f31a4b66d3ee4a7587991181705948d1bellca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGVzZSBsb2NhdGlvbnMgYXJlIGltcGFjdGVkIGluIG9uZSB3YXkgb3IgdGhlIG90 aGVyIG90aGVyd2lzZSwgdGhlIExvU1Qgc2VydmVyIHdvdWxkIG5vdCBiZSBhYmxlIHRvIGRldGVy bWluZSB0aGF0IGl0IHNob3VsZCBzZW5kIG5vdGlmaWNhdGlvbnM7IHRoZXkgbWF5IGp1c3Qgbm90 IGJlY29tZSBpbnZhbGlkIGluIHRoZSBMb1NUIHNlbnNlLg0KDQpUaGFua3MsDQoNCkd1eQ0KDQoN Cg0KRGUgOiBSYW5kYWxsIEdlbGxlbnMgPHJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmc+DQpFbnZv ecOpIDogMjMgYW/Du3QgMjAyMSAxNzo0Mg0Kw4AgOiBDYXJvbiwgR3V5IDxnLmNhcm9uQGJlbGwu Y2E+DQpDYyA6IEJyaWFuIFJvc2VuIDxickBicmlhbnJvc2VuLm5ldD47IGVjcml0QGlldGYub3Jn DQpPYmpldCA6IFtFWFRdUmU6IFtFY3JpdF0gbG9zdC1wbGFubmVkLWNoYW5nZXMtMDQ6IExvY2F0 aW9ucyBhcmUgbm90IGFsd2F5cyBpbnZhbGlkYXRlZA0KDQoNClVzaW5nICdpbXBhY3RlZCcgaXMg bm90IHJlYWxseSBiZXR0ZXIsIGJlY2F1c2UgYSBsb2NhdGlvbiBtYXkgb3IgbWF5IG5vdCBhY3R1 YWxseSBiZSBpbXBhY3RlZC4gSWYgd2UgZ28gZG93biB0aGUgcGF0aCBvZiBwcmVjaXNlIG5hbWVz IHdlIHNob3VsZCB1c2Ugc29tZXRoaW5nIHN1Y2ggYXMgJ2xvY2F0aW9uUG90ZW50aWFsbHlJbnZh bGlkYXRlZCcsIHdoaWNoIHNlZW1zIHNpbGx5LiBJIHRoaW5rIHRoZSBkcmFmdCBtYWtlcyBpdCBj bGVhciAoZXNwZWNpYWxseSB3aXRoIG15IHN1Z2dlc3RlZCBlZGl0cykgdGhhdCBhIG5vdGlmaWVk IGxvY2F0aW9uIGlzIHBvdGVudGlhbGx5IGludmFsaWRhdGVkLg0KDQotLVJhbmRhbGwNCg0KT24g MjMgQXVnIDIwMjEsIGF0IDE0OjI0LCBDYXJvbiwgR3V5IHdyb3RlOg0KDQpUaGlzIG5ldyB2ZXJz aW9uIGludHJvZHVjZXMgdmFyaWFiaWxpdHkgaW4gd2hldGhlciBhIGxvY2F0aW9uIGlzIGluZGVl ZCBpbnZhbGlkYXRlZCBvciBub3QgYnkgYSBjaGFuZ2UsIHdoaWNoIEkgYWdyZWUgd2l0aC4NCg0K DQoNCkdpdmVuIHRoaXMsIHRoZSBuYW1lcyDigJxsb2NhdGlvbkludmFsaWRhdGVk4oCdIGFuZCDi gJxpbnZhbGlkYXRlZEFzT2bigJ0gc2VlbSBtaXNsZWFkaW5nLiBTaG91bGQg4oCcaW52YWxpZGF0 ZWTigJ0gYmUgY2hhbmdlZCB0byBzb21ldGhpbmcgbGlrZSDigJxJbXBhY3RlZOKAnT8NCg0KDQoN ClRoYW5rcywNCg0KDQoNCkd1eQ0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpFY3JpdCBtYWlsaW5nIGxpc3QNCkVjcml0QGlldGYub3Jn PG1haWx0bzpFY3JpdEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZWNyaXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkV4dGVybmFs IEVtYWlsOiBQbGVhc2UgdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxpbmtzIGFuZCBhdHRhY2ht ZW50cyAvIENvdXJyaWVsIGV4dGVybmU6IFNveWV6IHBydWRlbnQgYXZlYyBsZXMgbGllbnMgZXQg ZG9jdW1lbnRzIGpvaW50cw0K --_000_f31a4b66d3ee4a7587991181705948d1bellca_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJ e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSLUNB IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgdGhpbmsgdGhlc2UgbG9jYXRp b25zIGFyZSBpbXBhY3RlZCBpbiBvbmUgd2F5IG9yIHRoZSBvdGhlciBvdGhlcndpc2UsIHRoZSBM b1NUIHNlcnZlciB3b3VsZCBub3QgYmUgYWJsZSB0byBkZXRlcm1pbmUNCiB0aGF0IGl0IHNob3Vs ZCBzZW5kIG5vdGlmaWNhdGlvbnM7IHRoZXkgbWF5IGp1c3Qgbm90IGJlY29tZSBpbnZhbGlkIGlu IHRoZSBMb1NUIHNlbnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkd1eTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RGUmbmJzcDs6 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUmFuZGFsbCBHZWxsZW5zICZs dDtyZyYjNDM7aWV0ZkByYW5keS5wZW5zaXZlLm9yZyZndDsNCjxicj4NCjxiPkVudm95w6kmbmJz cDs6PC9iPiAyMyBhb8O7dCAyMDIxIDE3OjQyPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBDYXJvbiwg R3V5ICZsdDtnLmNhcm9uQGJlbGwuY2EmZ3Q7PGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBCcmlhbiBS b3NlbiAmbHQ7YnJAYnJpYW5yb3Nlbi5uZXQmZ3Q7OyBlY3JpdEBpZXRmLm9yZzxicj4NCjxiPk9i amV0Jm5ic3A7OjwvYj4gW0VYVF1SZTogW0Vjcml0XSBsb3N0LXBsYW5uZWQtY2hhbmdlcy0wNDog TG9jYXRpb25zIGFyZSBub3QgYWx3YXlzIGludmFsaWRhdGVkPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+VXNpbmcgJ2ltcGFjdGVkJyBpcyBub3QgcmVhbGx5IGJldHRl ciwgYmVjYXVzZSBhIGxvY2F0aW9uIG1heSBvciBtYXkgbm90IGFjdHVhbGx5IGJlIGltcGFjdGVk LiBJZiB3ZSBnbyBkb3duIHRoZSBwYXRoIG9mIHByZWNpc2UgbmFtZXMgd2Ugc2hvdWxkIHVzZSBz b21ldGhpbmcgc3VjaCBhcyAnbG9jYXRpb25Qb3RlbnRpYWxseUludmFsaWRhdGVkJywgd2hpY2gg c2VlbXMNCiBzaWxseS4gSSB0aGluayB0aGUgZHJhZnQgbWFrZXMgaXQgY2xlYXIgKGVzcGVjaWFs bHkgd2l0aCBteSBzdWdnZXN0ZWQgZWRpdHMpIHRoYXQgYSBub3RpZmllZCBsb2NhdGlvbiBpcyBw b3RlbnRpYWxseSBpbnZhbGlkYXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+LS1SYW5kYWxs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIDIzIEF1ZyAyMDIxLCBhdCAxNDoyNCwgQ2Fyb24s IEd1eSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjNzc3Nzc3IDEuNXB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNC4wcHQ7bWFyZ2luLWxlZnQ6MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2lu LWJvdHRvbTozLjc1cHQiPg0KPGRpdiBpZD0iOTIzRUQ0QzItNkY3Mi00QUNDLTk2NUUtMzMxRDRC NDU0NjdEIj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+VGhpcyBuZXcgdmVyc2lvbiBpbnRyb2R1Y2VzIHZhcmlhYmlsaXR5 IGluIHdoZXRoZXIgYSBsb2NhdGlvbiBpcyBpbmRlZWQgaW52YWxpZGF0ZWQgb3Igbm90IGJ5IGEN CiBjaGFuZ2UsIHdoaWNoIEkgYWdyZWUgd2l0aC48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3 Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5HaXZlbiB0aGlzLCB0aGUg bmFtZXMg4oCcbG9jYXRpb25JbnZhbGlkYXRlZOKAnSBhbmQg4oCcaW52YWxpZGF0ZWRBc09m4oCd IHNlZW0gbWlzbGVhZGluZy4gU2hvdWxkIOKAnGludmFsaWRhdGVk4oCdDQogYmUgY2hhbmdlZCB0 byBzb21ldGhpbmcgbGlrZSDigJxJbXBhY3RlZOKAnT88L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21h cmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJn aW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MsPC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBz dHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+R3V5PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6Izc3Nzc3Nzttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjNzc3Nzc3IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNC4wcHQ7bWFyZ2luLWxlZnQ6MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbToz Ljc1cHQiPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpFY3JpdCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86RWNyaXRAaWV0Zi5vcmciPkVjcml0QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQiPjxzcGFuIHN0eWxlPSJjb2xv cjojNzc3Nzc3Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0PC9z cGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1h bGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPkV4dGVybmFsIEVtYWlsOjwvc3Bhbj48L2k+PC9zdHJv bmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+IFBsZWFzZSB1 c2UgY2F1dGlvbiB3aGVuIG9wZW5pbmcgbGlua3MgYW5kIGF0dGFjaG1lbnRzIC8NCjwvc3Bhbj48 L2VtPjxzdHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj5D b3VycmllbCBleHRlcm5lOjwvc3Bhbj48L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+IFNveWV6IHBydWRlbnQgYXZlYyBsZXMgbGllbnMgZXQg ZG9jdW1lbnRzIGpvaW50cw0KPC9zcGFuPjwvZW0+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_f31a4b66d3ee4a7587991181705948d1bellca_-- From nobody Mon Aug 23 14:50:44 2021 Return-Path: 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 B8E2D3A1D48 for ; Mon, 23 Aug 2021 14:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=bell.ca 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 oVeHIa8Ugzv0 for ; Mon, 23 Aug 2021 14:50:36 -0700 (PDT) Received: from ESA4-Dor.bell.ca (esa4-dor.bell.ca [204.101.223.61]) (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 3B78D3A1D3B for ; Mon, 23 Aug 2021 14:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1629755436; x=1661291436; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=Kwgdz+n+7xViQdTMuNtaGVkl4ApM1G+d6u1RZK80BXQ=; b=XQcIqd6XVlf3azqUD5zbU4F/pEP1g9ljxM7aqI8375lO8QBfLeCmUCW9 /5jAeDaEk55cpPLtbKq5Fx9yS9srtTLHcwDjo1DZWSKF12v2UaIDLrRJn Tr4oQ2C2XNBa1wkC6NF9OKS9cVE4ZpZBsiWQrRE3N3T8WRXzI4H/3We+i jzp01KzVM9Ov0hOdMR1GZDMhVbAUyo0ctOTV3MJDAgkISssf9JLpUa21K LZWxMUh8SsMsnTXo1ifGPZukK7fVsy7+DI/mTlUvrhQKDvgKoWNx9geqY 2JOlsP6ftkdz/Paxi/ifu+dh1RQf1zEqb4kPbGmAKhloJu3XDYBgdFpLh g==; IronPort-SDR: OkDEKYiIiqECvzQBWUwD16ofDe5LGQiqIlVy13uj/gkAsh4z4ZzRO6Q75n8AfWUec8ArSl+QRf P5sfgIzkpu1A== Received: from dc5cmz-d01.bellca.int.bell.ca (HELO DG1MBX02-WYN.bell.corp.bce.ca) ([198.235.121.232]) by esa04corp-dor.bell.corp.bce.ca with ESMTP; 23 Aug 2021 17:50:34 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG1MBX02-WYN.bell.corp.bce.ca (142.182.18.12) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 23 Aug 2021 17:50:34 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Mon, 23 Aug 2021 17:50:34 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Mon, 23 Aug 2021 17:50:34 -0400 From: "Caron, Guy" To: Randall Gellens CC: Brian Rosen , "ecrit@ietf.org" Thread-Topic: [EXT]Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation? Thread-Index: AQHXmGh+YLFzWlV3v0+/P+QgQ43+B6uBoKUQ Date: Mon, 23 Aug 2021 21:50:34 +0000 Message-ID: References: <8bdda7ea7d004b4591ff715526d93a73@bell.ca> <791ea34f628d48d3addeb04613d5721a@bell.ca> <2C9BD286-3868-4717-8A1E-972259FA758E@randy.pensive.org> In-Reply-To: <2C9BD286-3868-4717-8A1E-972259FA758E@randy.pensive.org> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.79] Content-Type: multipart/alternative; boundary="_000_d13697a2c06142fe953983dbdfac0297bellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 21:50:43 -0000 --_000_d13697a2c06142fe953983dbdfac0297bellca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlbuKAmXQgc2VlbiB5b3VyIGVkaXRzIHNpbmNlIHRoZXkgYXJlIG5vdCBwb3N0ZWQgb24g dGhlIGxpc3QgYnV0IHdoYXQgeW91IHN1Z2dlc3RlZCBzZWVtcyBub3Qgc3Ryb25nIGVub3VnaCBs YW5ndWFnZSB0byBtZS4NCg0KVGhhbmtzLA0KDQpHdXkNCg0KRGUgOiBSYW5kYWxsIEdlbGxlbnMg PHJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmc+DQpFbnZvecOpIDogMjMgYW/Du3QgMjAyMSAxNzo0 Nw0Kw4AgOiBDYXJvbiwgR3V5IDxnLmNhcm9uQGJlbGwuY2E+DQpDYyA6IEJyaWFuIFJvc2VuIDxi ckBicmlhbnJvc2VuLm5ldD47IGVjcml0QGlldGYub3JnDQpPYmpldCA6IFtFWFRdUmU6IFtFY3Jp dF0gbG9zdC1wbGFubmVkLWNoYW5nZXMtMDQ6IHBsYW5uZWRDaGFuZ2UgYm91bmQgdG8gdmFsaWRh dGVMb2NhdGlvbj8NCg0KDQpBcyBJIG1lbnRpb25lZCwgbXkgc3VnZ2VzdGVkIGVkaXRzIG1ha2Ug aXQgY2xlYXIgdGhhdCB0aGUgZXh0ZW5zaW9uIGlzIG9ubHkgdXNlZnVsIGluIHRoZSBjb250ZXh0 IG9mIHZhbGlkYXRpb24uDQoNCi0tUmFuZGFsbA0KDQpPbiAyMyBBdWcgMjAyMSwgYXQgMTQ6NDQs IENhcm9uLCBHdXkgd3JvdGU6DQoNCkkgYWdyZWUgdGhhdCBhY2NvbW1vZGF0aW5nIHRoaXMgY29t bWVudCB3b3VsZCByZXF1aXJlIGRlZXBlciBYTUwgY2hhbmdlcy4NCg0KDQoNCklmIHdlIGRvIG5v dCB3YW50IHRvIGdvIHRoZXJlLCBJIHRoaW5rIHRoZSBkcmFmdCBzaG91bGQgYmUgY2xlYXIgdGhh dCB0aGVyZSBpcyBubyB1c2VjYXNlIGZvciBzZW5kaW5nIDxwbGFubmVkQ2hhbmdlPiBvdXRzaWRl IG9mIGEgbG9jYXRpb24gdmFsaWRhdGlvbiByZXF1ZXN0IGFuZCBhcyBzdWNoLCBzaG91bGQgbm9y bWF0aXZlbHkgcmVjb21tZW5kIG5vdCBkb2luZyBzby4NCg0KDQoNCkkgZG8gbm90IGFncmVlIHRo YXQgYSBMb1NUIHNlcnZlciByZWNlaXZpbmcgPHBsYW5uZWRDaGFuZ2U+IG91dHNpZGUgb2YgYSBs b2NhdGlvbiB2YWxpZGF0aW9uIHJlcXVlc3Qgd291bGQgcmV0YWluIHRoZSBVUkkgYW5kIHNlbmQg bm90aWZpY2F0aW9uIGlmIHRoZSByZWNvcmQgY2hhbmdlZCBhZnRlcndhcmQuIEkgdGhpbmsgdGhp cyB3b3VsZCBjcmVhdGUgaGF2b2Mgb24gdGhlIGNsaWVudOKAmSBzaWRlLg0KDQoNCg0KVGhhbmtz LA0KDQoNCg0KR3V5DQoNCg0KDQpEZSA6IEJyaWFuIFJvc2VuIDxickBicmlhbnJvc2VuLm5ldDxt YWlsdG86YnJAYnJpYW5yb3Nlbi5uZXQ+Pg0KRW52b3nDqSA6IDIzIGFvw7t0IDIwMjEgMTc6MjIN CsOAIDogQ2Fyb24sIEd1eSA8Zy5jYXJvbkBiZWxsLmNhPG1haWx0bzpnLmNhcm9uQGJlbGwuY2E+ Pg0KQ2MgOiBlY3JpdEBpZXRmLm9yZzxtYWlsdG86ZWNyaXRAaWV0Zi5vcmc+DQpPYmpldCA6IFtF WFRdUmU6IGxvc3QtcGxhbm5lZC1jaGFuZ2VzLTA0OiBwbGFubmVkQ2hhbmdlIGJvdW5kIHRvIHZh bGlkYXRlTG9jYXRpb24/DQoNCg0KDQp2YWxpZGF0ZUxvY2F0aW9uIGlzIGFuIGF0dHJpYnV0ZSwg bm90IGFuIGVsZW1lbnQsIHNvIEkgY2Fu4oCZdCBleHRlbmQgaXQuDQoNCg0KDQpUaGVyZSBpc27i gJl0IGFuIGFjdHVhbCByZXF1aXJlbWVudCB0byB0aWUgcGxhbm5lZENoYW5nZSB0byB2YWxpZGF0 ZUxvY2F0aW9uLiAgSXQgbWF5IG5vdCBtYWtlIGEgbG90IG9mIHNlbnNlLCBidXQgaWYgeW91IGRp ZCBpdCwgdGhlIExvU1Qgc2VydmVyIHdvdWxkIG5vdCByZXR1cm4gdmFsaWRhdGlvbiBkYXRhLCB3 b3VsZCByZXRhaW4gdGhlIFVSSSBhbmQgd291bGQgc2VuZCB0aGUgbm90aWZpY2F0aW9uIGlmIHRo ZSByZWNvcmQgY2hhbmdlZC4gIE5vdGUgbXkgdGV4dCB0aGF0IHRoZSBMb1NUIHNlcnZlciBkb2Vz buKAmXQgc3RvcmUgdGhlIExJIC0gdGhlIG5vdGlmaWNhdGlvbiBpcyDigJxzb21ldGhpbmcgY2hh bmdlZOKAnSBub3Qg4oCcd2hhdCB5b3Ugc2VudCBpcyBndWFyYW50ZWVkIHRvIGJlIGludmFsaWTi gJ0gb3IgZXZlbiDigJxvbmUgb3IgbW9yZSBvZiB0aGUgZWxlbWVudHMgeW91IHNlbnQgY2hhbmdl ZCIuICBJIHRob3VnaHQgYWJvdXQgY2hhbmdpbmcgdGhlIG5hbWUgb2YgdGhlIG5vdGlmaWNhdGlv biwgYnV0IEkgZGlkbuKAmXQgZG8gdGhhdC4gIFRoZSBwcmFjdGljYWwgdXNlIGNhc2UgcmVtYWlu cyB0aGUgc2FtZS4NCg0KDQoNCkJyaWFuDQoNCg0KDQpPbiBBdWcgMjMsIDIwMjEsIGF0IDU6MDcg UE0sIENhcm9uLCBHdXkgPGcuY2Fyb25AYmVsbC5jYTxtYWlsdG86Zy5jYXJvbkBiZWxsLmNhPj4g d3JvdGU6DQoNCg0KDQpOb3QgYWxsIExvU1Qgc2VydmVyIGltcGxlbWVudGF0aW9ucyBwZXJmb3Jt IGxvY2F0aW9uIHZhbGlkYXRpb25zLiBXaGVuIGxvY2F0aW9uIHZhbGlkYXRpb24gaXMgcmVxdWVz dGVkIGJ5IHRoZSBjbGllbnQsIGl0IGFkZHMgdGhlIOKAnHZhbGlkYXRlTG9jYXRpb27igJ0gYXR0 cmlidXRlIHRvIHRoZSA8ZmluZFNlcnZpY2U+IGVsZW1lbnQuDQoNCg0KDQpTbyB0aGUgcXVlc3Rp b24gaXM6IFNob3VsZCDigJxwbGFubmVkQ2hhbmdl4oCdIGJlIGJvdW5kIHRvIOKAnHZhbGlkYXRl TG9jYXRpb27igJ0/DQoNCg0KDQpJZiB5b3UgYmVsaWV2ZSBub3QsIHdoYXQgd291bGQgYmUgdGhl IGV4cGVjdGVkIGJlaGF2aW91ciBvZiBhIExvU1Qgc2VydmVyIHJlY2VpdmluZyBhIDxwbGFubmVk Q2hhbmdlPiBlbGVtZW50IG91dHNpZGUgb2YgYSB2YWxpZGF0aW9uIHJlcXVlc3Q/DQoNCg0KDQpU aGFua3MsDQoNCg0KDQpHdXkNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoNCkV4dGVybmFsIEVtYWlsOiBQbGVhc2UgdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxpbmtz IGFuZCBhdHRhY2htZW50cyAvIENvdXJyaWVsIGV4dGVybmU6IFNveWV6IHBydWRlbnQgYXZlYyBs ZXMgbGllbnMgZXQgZG9jdW1lbnRzIGpvaW50cw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KRWNyaXQgbWFpbGluZyBsaXN0DQpFY3JpdEBpZXRmLm9y ZzxtYWlsdG86RWNyaXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2Vjcml0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpFeHRlcm5h bCBFbWFpbDogUGxlYXNlIHVzZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQgYXR0YWNo bWVudHMgLyBDb3VycmllbCBleHRlcm5lOiBTb3lleiBwcnVkZW50IGF2ZWMgbGVzIGxpZW5zIGV0 IGRvY3VtZW50cyBqb2ludHMNCg== --_000_d13697a2c06142fe953983dbdfac0297bellca_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJ e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBw dCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUi1DQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5JIGhhdmVu4oCZdCBzZWVuIHlvdXIgZWRpdHMgc2luY2UgdGhleSBhcmUgbm90IHBvc3Rl ZCBvbiB0aGUgbGlzdCBidXQgd2hhdCB5b3Ugc3VnZ2VzdGVkIHNlZW1zIG5vdCBzdHJvbmcgZW5v dWdoIGxhbmd1YWdlDQogdG8gbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+R3V5PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFJhbmRhbGwgR2VsbGVucyAmbHQ7cmcmIzQzO2ll dGZAcmFuZHkucGVuc2l2ZS5vcmcmZ3Q7DQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gMjMg YW/Du3QgMjAyMSAxNzo0Nzxicj4NCjxiPsOAJm5ic3A7OjwvYj4gQ2Fyb24sIEd1eSAmbHQ7Zy5j YXJvbkBiZWxsLmNhJmd0Ozxicj4NCjxiPkNjJm5ic3A7OjwvYj4gQnJpYW4gUm9zZW4gJmx0O2Jy QGJyaWFucm9zZW4ubmV0Jmd0OzsgZWNyaXRAaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8 L2I+IFtFWFRdUmU6IFtFY3JpdF0gbG9zdC1wbGFubmVkLWNoYW5nZXMtMDQ6IHBsYW5uZWRDaGFu Z2UgYm91bmQgdG8gdmFsaWRhdGVMb2NhdGlvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj5BcyBJIG1lbnRpb25lZCwgbXkgc3VnZ2VzdGVkIGVkaXRzIG1ha2UgaXQg Y2xlYXIgdGhhdCB0aGUgZXh0ZW5zaW9uIGlzIG9ubHkgdXNlZnVsIGluIHRoZSBjb250ZXh0IG9m IHZhbGlkYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPi0tUmFuZGFsbDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj5PbiAyMyBBdWcgMjAyMSwgYXQgMTQ6NDQsIENhcm9uLCBHdXkgd3JvdGU6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgIzc3Nzc3NyAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDQuMHB0O21hcmdpbi1sZWZ0OjBjbTttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207 bWFyZ2luLWJvdHRvbTozLjc1cHQiPg0KPGRpdiBpZD0iMzg3QzdFNTQtRUIxNC00QUE4LThCMzUt NDYzMDEyQzhEMTYyIj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9t Oi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBhZ3JlZSB0aGF0IGFjY29tbW9kYXRpbmcgdGhpcyBj b21tZW50IHdvdWxkIHJlcXVpcmUgZGVlcGVyIFhNTCBjaGFuZ2VzLjwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPklmIHdl IGRvIG5vdCB3YW50IHRvIGdvIHRoZXJlLCBJIHRoaW5rIHRoZSBkcmFmdCBzaG91bGQgYmUgY2xl YXIgdGhhdCB0aGVyZSBpcyBubyB1c2VjYXNlIGZvciBzZW5kaW5nDQogJmx0O3BsYW5uZWRDaGFu Z2UmZ3Q7IG91dHNpZGUgb2YgYSBsb2NhdGlvbiB2YWxpZGF0aW9uIHJlcXVlc3QgYW5kIGFzIHN1 Y2gsIHNob3VsZCBub3JtYXRpdmVseSByZWNvbW1lbmQgbm90IGRvaW5nIHNvLjwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PkkgZG8gbm90IGFncmVlIHRoYXQgYSBMb1NUIHNlcnZlciByZWNlaXZpbmcgJmx0O3BsYW5uZWRD aGFuZ2UmZ3Q7IG91dHNpZGUgb2YgYSBsb2NhdGlvbiB2YWxpZGF0aW9uIHJlcXVlc3QNCiB3b3Vs ZCByZXRhaW4gdGhlIFVSSSBhbmQgc2VuZCBub3RpZmljYXRpb24gaWYgdGhlIHJlY29yZCBjaGFu Z2VkIGFmdGVyd2FyZC4gSSB0aGluayB0aGlzIHdvdWxkIGNyZWF0ZSBoYXZvYyBvbiB0aGUgY2xp ZW504oCZIHNpZGUuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQi PjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9t Oi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhhbmtzLDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFy Z2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkd1eTwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImNvbG9yOiM3Nzc3Nzc7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PGI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3 Nzc3Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 Izc3Nzc3NyI+IEJyaWFuIFJvc2VuICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmJyQGJyaWFu cm9zZW4ubmV0Ij48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5ickBicmlhbnJvc2VuLm5ldDwv c3Bhbj48L2E+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij4mZ3Q7DQo8 YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gMjMgYW/Du3QgMjAyMSAxNzoyMjxicj4NCjxiPsOA Jm5ic3A7OjwvYj4gQ2Fyb24sIEd1eSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpnLmNhcm9u QGJlbGwuY2EiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmcuY2Fyb25AYmVsbC5jYTwvc3Bh bj48L2E+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij4mZ3Q7PGJyPg0K PGI+Q2MmbmJzcDs6PC9iPiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmVjcml0QGlldGYub3JnIj48 c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5lY3JpdEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4g bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij48YnI+DQo8Yj5PYmpldCZuYnNwOzo8 L2I+IFtFWFRdUmU6IGxvc3QtcGxhbm5lZC1jaGFuZ2VzLTA0OiBwbGFubmVkQ2hhbmdlIGJvdW5k IHRvIHZhbGlkYXRlTG9jYXRpb24/PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjow Y207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJv dHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+dmFsaWRhdGVMb2NhdGlv biBpcyBhbiBhdHRyaWJ1dGUsIG5vdCBhbiBlbGVtZW50LCBzbyBJIGNhbuKAmXQgZXh0ZW5kIGl0 LiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjow Y207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdp bjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+ VGhlcmUgaXNu4oCZdCBhbiBhY3R1YWwgcmVxdWlyZW1lbnQgdG8gdGllIHBsYW5uZWRDaGFuZ2Ug dG8gdmFsaWRhdGVMb2NhdGlvbi4gJm5ic3A7SXQgbWF5IG5vdCBtYWtlIGEgbG90IG9mIHNlbnNl LCBidXQgaWYgeW91IGRpZCBpdCwgdGhlIExvU1Qgc2VydmVyIHdvdWxkIG5vdCByZXR1cm4gdmFs aWRhdGlvbiBkYXRhLCB3b3VsZCByZXRhaW4NCiB0aGUgVVJJIGFuZCB3b3VsZCBzZW5kIHRoZSBu b3RpZmljYXRpb24gaWYgdGhlIHJlY29yZCBjaGFuZ2VkLiAmbmJzcDtOb3RlIG15IHRleHQgdGhh dCB0aGUgTG9TVCBzZXJ2ZXIgZG9lc27igJl0IHN0b3JlIHRoZSBMSSAtIHRoZSBub3RpZmljYXRp b24gaXMg4oCcc29tZXRoaW5nIGNoYW5nZWTigJ0gbm90IOKAnHdoYXQgeW91IHNlbnQgaXMgZ3Vh cmFudGVlZCB0byBiZSBpbnZhbGlk4oCdIG9yIGV2ZW4g4oCcb25lIG9yIG1vcmUgb2YgdGhlIGVs ZW1lbnRzIHlvdSBzZW50IGNoYW5nZWQmcXVvdDsuDQogJm5ic3A7SSB0aG91Z2h0IGFib3V0IGNo YW5naW5nIHRoZSBuYW1lIG9mIHRoZSBub3RpZmljYXRpb24sIGJ1dCBJIGRpZG7igJl0IGRvIHRo YXQuICZuYnNwO1RoZSBwcmFjdGljYWwgdXNlIGNhc2UgcmVtYWlucyB0aGUgc2FtZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJn aW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTtt YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij5Ccmlhbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTIuMHB0 O21hcmdpbi1sZWZ0OjBjbSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+T24gQXVnIDIzLCAy MDIxLCBhdCA1OjA3IFBNLCBDYXJvbiwgR3V5ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmcu Y2Fyb25AYmVsbC5jYSI+Zy5jYXJvbkBiZWxsLmNhPC9hPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3 Nzc3Ij4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgc3R5bGU9 Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6Izc3 Nzc3NyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBzdHls ZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Tm90IGFsbCBMb1NUIHNlcnZlciBpbXBsZW1lbnRhdGlv bnMgcGVyZm9ybSBsb2NhdGlvbiB2YWxpZGF0aW9ucy4gV2hlbiBsb2NhdGlvbiB2YWxpZGF0aW9u IGlzIHJlcXVlc3RlZCBieSB0aGUgY2xpZW50LCBpdA0KIGFkZHMgdGhlIOKAnHZhbGlkYXRlTG9j YXRpb27igJ0gYXR0cmlidXRlIHRvIHRoZSAmbHQ7ZmluZFNlcnZpY2UmZ3Q7IGVsZW1lbnQuPC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQi PjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U28gdGhlIHF1ZXN0aW9u IGlzOiBTaG91bGQg4oCccGxhbm5lZENoYW5nZeKAnSBiZSBib3VuZCB0byDigJx2YWxpZGF0ZUxv Y2F0aW9u4oCdPzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJv dHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRv bTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklm IHlvdSBiZWxpZXZlIG5vdCwgd2hhdCB3b3VsZCBiZSB0aGUgZXhwZWN0ZWQgYmVoYXZpb3VyIG9m IGEgTG9TVCBzZXJ2ZXIgcmVjZWl2aW5nIGEgJmx0O3BsYW5uZWRDaGFuZ2UmZ3Q7IGVsZW1lbnQg b3V0c2lkZSBvZiBhDQogdmFsaWRhdGlvbiByZXF1ZXN0Pzwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5 bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9 Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3 Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJt YXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3 NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJn aW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5HdXk8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiM3Nzc3NzciPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpj ZW50ZXIiPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij4NCjxociBzaXplPSIyIiB3aWR0aD0i MTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBj bTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzdHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtjb2xvcjpibHVlIj5FeHRlcm5hbCBFbWFpbDo8L3NwYW4+PC9pPjwvc3Ryb25nPjxl bT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPiBQbGVhc2UgdXNlIGNh dXRpb24gd2hlbiBvcGVuaW5nIGxpbmtzIGFuZCBhdHRhY2htZW50cyAvDQo8L3NwYW4+PC9lbT48 c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+Q291cnJp ZWwgZXh0ZXJuZTo8L3NwYW4+PC9pPjwvc3Ryb25nPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2NvbG9yOmJsdWUiPiBTb3lleiBwcnVkZW50IGF2ZWMgbGVzIGxpZW5zIGV0IGRvY3Vt ZW50cyBqb2ludHMNCjwvc3Bhbj48L2VtPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjNzc3Nzc3 IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQ7bWFyZ2luLWxlZnQ6MGNtO21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjMuNzVwdCI+DQo8cD48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj Nzc3Nzc3Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCkVjcml0IG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86RWNyaXRA aWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmIj5FY3JpdEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+PGJyPg0KPC9zcGFu PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM3Nzc3NzciPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQ8L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0 eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWdu PSJjZW50ZXIiPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Ryb25nPjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+RXh0ZXJuYWwgRW1haWw6PC9zcGFu PjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVl Ij4gUGxlYXNlIHVzZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQgYXR0YWNobWVudHMg Lw0KPC9zcGFuPjwvZW0+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Nv bG9yOmJsdWUiPkNvdXJyaWVsIGV4dGVybmU6PC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj4gU295ZXogcHJ1ZGVudCBhdmVjIGxl cyBsaWVucyBldCBkb2N1bWVudHMgam9pbnRzDQo8L3NwYW4+PC9lbT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_d13697a2c06142fe953983dbdfac0297bellca_-- From nobody Mon Aug 23 14:51:21 2021 Return-Path: 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 3B1CD3A1D46 for ; Mon, 23 Aug 2021 14:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, 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 AMOmQ1Ds9fkN for ; Mon, 23 Aug 2021 14:51:14 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id B31AD3A1D59 for ; Mon, 23 Aug 2021 14:51:13 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 23 Aug 2021 14:51:13 -0700 From: "Randall Gellens" To: "Caron, Guy" Cc: "Brian Rosen" , ecrit@ietf.org Date: Mon, 23 Aug 2021 14:51:12 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: References: <8508C216-7FF5-41D2-A78D-EBF475F83C7F@randy.pensive.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_4C2BE536-4DBE-4C0C-AFB0-A8B0FB1C1BBC_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[714, 10312], "plain":[383, 1576], "uuid":"A9B3596D-4769-4D0B-9698-6CA576D0581D"}] Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: Locations are not always invalidated X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 21:51:20 -0000 --=_MailMate_4C2BE536-4DBE-4C0C-AFB0-A8B0FB1C1BBC_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit I don't know that that's true. My interpretation is that a LoST server might maintain a list of URIs but not associate each with specific location records, and when there is a change, it would then send a notification to each stored URI. The location that was used for the original validation query might not be impacted. --Randall On 23 Aug 2021, at 14:48, Caron, Guy wrote: > I think these locations are impacted in one way or the other > otherwise, the LoST server would not be able to determine that it > should send notifications; they may just not become invalid in the > LoST sense. > > Thanks, > > Guy > > > > De : Randall Gellens > Envoyé : 23 août 2021 17:42 > À : Caron, Guy > Cc : Brian Rosen ; ecrit@ietf.org > Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: Locations are not > always invalidated > > > Using 'impacted' is not really better, because a location may or may > not actually be impacted. If we go down the path of precise names we > should use something such as 'locationPotentiallyInvalidated', which > seems silly. I think the draft makes it clear (especially with my > suggested edits) that a notified location is potentially invalidated. > > --Randall > > On 23 Aug 2021, at 14:24, Caron, Guy wrote: > > This new version introduces variability in whether a location is > indeed invalidated or not by a change, which I agree with. > > > > Given this, the names “locationInvalidated†and > “invalidatedAsOf†seem misleading. Should “invalidated†be > changed to something like “Impacted� > > > > Thanks, > > > > Guy > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > ________________________________ > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints --=_MailMate_4C2BE536-4DBE-4C0C-AFB0-A8B0FB1C1BBC_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">I don't know that that's true. My interpretation is that = a LoST server might maintain a list of URIs but not associate each with s= pecific location records, and when there is a change, it would then send = a notification to each stored URI. The location that was used for the or= iginal validation query might not be impacted.

--Randall

On 23 Aug 2021, at 14:48, Caron, Guy wrote:

I think these locations are impacted = in one way or the other otherwise, the LoST server would not be able to d= etermine that it should send notifications; they may just not become invalid in t= he LoST sense.

=C2=A0

Thanks,

=C2=A0

Guy

=C2=A0

=C2=A0

=C2=A0

De=C2= =A0: Randall Gellens <rg+ietf@randy.pensive.org>
Envoy=C3=A9=C2=A0: 23 ao=C3=BBt 2021 17:42
=C3=80=C2=A0: Caron, Guy <g.caron@bell.ca>
Cc=C2=A0: Brian Rosen <br@brianrosen.net>; ecrit@ietf.org Objet=C2=A0: [EXT]Re: [Ecrit] lost-planned-changes-04: Locations a= re not always invalidated

=C2=A0

Using 'impacted' is not really better, because a location may or may not= actually be impacted. If we go down the path of precise names we should = use something such as 'locationPotentiallyInvalidated', which seems silly. I think the draft makes it clear (especially with my suggested ed= its) that a notified location is potentially invalidated.

--Randall

On 23 Aug 2021, at 14:24, Caron, Guy wrote:

=

This new version introduces variabili= ty in whether a location is indeed invalidated or not by a change, which I agree with.<= /p>

=C2=A0

Given this, the names =E2=80=9Clocati= onInvalidated=E2=80=9D and =E2=80=9CinvalidatedAsOf=E2=80=9D seem mislead= ing. Should =E2=80=9Cinvalidated=E2=80=9D be changed to something like =E2=80=9CImpacted=E2=80=9D?

=C2=A0

Thanks,

=C2=A0

Guy

=C2=A0<= span style=3D"color:#777777">

=C2=A0

=

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

<= span style=3D"font-size:9.0pt;color:blue">External Email: Please use caution wh= en opening links and attachments / Courrie= l externe: Soyez prudent avec les liens et documents joints

--=_MailMate_4C2BE536-4DBE-4C0C-AFB0-A8B0FB1C1BBC_=-- From nobody Mon Aug 23 14:53:27 2021 Return-Path: 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 E951A3A1D78 for ; Mon, 23 Aug 2021 14:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, 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 v-ACMNn9xJwI for ; Mon, 23 Aug 2021 14:53:18 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id A87893A1D76 for ; Mon, 23 Aug 2021 14:53:18 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 23 Aug 2021 14:53:18 -0700 From: "Randall Gellens" To: "Caron, Guy" Cc: "Brian Rosen" , ecrit@ietf.org Date: Mon, 23 Aug 2021 14:53:17 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: References: <8bdda7ea7d004b4591ff715526d93a73@bell.ca> <791ea34f628d48d3addeb04613d5721a@bell.ca> <2C9BD286-3868-4717-8A1E-972259FA758E@randy.pensive.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_47BC319C-9233-4DAF-87E2-599D37A1657F_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[548, 19683], "plain":[217, 3247], "uuid":"4EEE36A2-3886-43E9-9B52-54DC614E21E4"}] Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 21:53:25 -0000 --=_MailMate_47BC319C-9233-4DAF-87E2-599D37A1657F_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit I think the list is slow. The message was stuck but Roger released it. Once you see the changes, if you want to make the language stronger, we can do that. --Randall On 23 Aug 2021, at 14:50, Caron, Guy wrote: > I haven’t seen your edits since they are not posted on the list but > what you suggested seems not strong enough language to me. > > Thanks, > > Guy > > De : Randall Gellens > Envoyé : 23 août 2021 17:47 > À : Caron, Guy > Cc : Brian Rosen ; ecrit@ietf.org > Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: plannedChange bound > to validateLocation? > > > As I mentioned, my suggested edits make it clear that the extension is > only useful in the context of validation. > > --Randall > > On 23 Aug 2021, at 14:44, Caron, Guy wrote: > > I agree that accommodating this comment would require deeper XML > changes. > > > > If we do not want to go there, I think the draft should be clear that > there is no usecase for sending outside of a location > validation request and as such, should normatively recommend not doing > so. > > > > I do not agree that a LoST server receiving outside of > a location validation request would retain the URI and send > notification if the record changed afterward. I think this would > create havoc on the client’ side. > > > > Thanks, > > > > Guy > > > > De : Brian Rosen > > Envoyé : 23 août 2021 17:22 > À : Caron, Guy > > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to > validateLocation? > > > > validateLocation is an attribute, not an element, so I can’t extend > it. > > > > There isn’t an actual requirement to tie plannedChange to > validateLocation. It may not make a lot of sense, but if you did it, > the LoST server would not return validation data, would retain the URI > and would send the notification if the record changed. Note my text > that the LoST server doesn’t store the LI - the notification is > “something changed†not “what you sent is guaranteed to be > invalid†or even “one or more of the elements you sent changed". > I thought about changing the name of the notification, but I didn’t > do that. The practical use case remains the same. > > > > Brian > > > > On Aug 23, 2021, at 5:07 PM, Caron, Guy > > wrote: > > > > Not all LoST server implementations perform location validations. When > location validation is requested by the client, it adds the > “validateLocation†attribute to the element. > > > > So the question is: Should “plannedChange†be bound to > “validateLocation� > > > > If you believe not, what would be the expected behaviour of a LoST > server receiving a element outside of a validation > request? > > > > Thanks, > > > > Guy > > > > ________________________________ > > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > ________________________________ > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints --=_MailMate_47BC319C-9233-4DAF-87E2-599D37A1657F_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">I think the list is slow. The message was stuck but Roger= released it. Once you see the changes, if you want to make the language= stronger, we can do that.

--Randall

On 23 Aug 2021, at 14:50, Caron, Guy wrote:

I haven=E2=80=99t seen your edits sin= ce they are not posted on the list but what you suggested seems not stron= g enough language to me.

=C2=A0

Thanks,

=C2=A0

Guy

=C2=A0

De=C2= =A0: Randall Gellens <rg+ietf@randy.pensive.org>
Envoy=C3=A9=C2=A0: 23 ao=C3=BBt 2021 17:47
=C3=80=C2=A0: Caron, Guy <g.caron@bell.ca>
Cc=C2=A0: Brian Rosen <br@brianrosen.net>; ecrit@ietf.org Objet=C2=A0: [EXT]Re: [Ecrit] lost-planned-changes-04: plannedChan= ge bound to validateLocation?

=C2=A0

As I mentioned, my suggested edits make it clear that the extension is o= nly useful in the context of validation.

--Randall

On 23 Aug 2021, at 14:44, Caron, Guy wrote:

I agree that accommodating this comme= nt would require deeper XML changes.=

=C2=A0

If we do not want to go there, I thin= k the draft should be clear that there is no usecase for sending <plannedChange> outside of a location validation request and as su= ch, should normatively recommend not doing so.

=C2=A0

I do not agree that a LoST server rec= eiving <plannedChange> outside of a location validation request would retain the URI and send notification if the record changed afterwa= rd. I think this would create havoc on the client=E2=80=99 side.

=C2=A0

Thanks,

=C2=A0

Guy

=C2=A0<= span style=3D"color:#777777">

De=C2=A0: Brian Rosen <= br@brianrosen.net>
Envoy=C3=A9=C2=A0: 23 ao=C3=BBt 2021 17:22
=C3=80=C2=A0: Caron, Guy <g.caron@bell.ca>
Cc=C2=A0: ecrit@ietf= =2Eorg
Objet=C2=A0: [EXT]Re: lost-planned-changes-04: plannedChange bound= to validateLocation?

=C2=A0

validateLocation is an attribute, not an element, so I ca= n=E2=80=99t extend it. =C2=A0

=C2=A0

There isn=E2=80=99t an actual requirement to tie plannedC= hange to validateLocation. =C2=A0It may not make a lot of sense, but if y= ou did it, the LoST server would not return validation data, would retain= the URI and would send the notification if the record changed. =C2=A0Not= e my text that the LoST server doesn=E2=80=99t store the LI - the notific= ation is =E2=80=9Csomething changed=E2=80=9D not =E2=80=9Cwhat you sent i= s guaranteed to be invalid=E2=80=9D or even =E2=80=9Cone or more of the e= lements you sent changed". =C2=A0I thought about changing the name of the notification, but I didn=E2= =80=99t do that. =C2=A0The practical use case remains the same.

=C2=A0

Brian

=C2=A0

On Aug 23, 2021, at 5:07 PM, Caron, Guy <g.caron@bell.ca> wrote:

=C2=A0

Not all LoST server implementations perform location validations= =2E When location validation is requested by the client, it adds the =E2=80=9CvalidateLocation=E2=80=9D attribute to the <findSer= vice> element.

=C2=A0

So the question is: Should =E2=80=9CplannedChange=E2=80=9D be bo= und to =E2=80=9CvalidateLocation=E2=80=9D?

=C2=A0

If you believe not, what would be the expected behaviour of a Lo= ST server receiving a <plannedChange> element outside of a validation request?

=C2=A0

Thanks,

=C2=A0

Guy

=C2=A0

<= span style=3D"font-size:9.0pt;color:blue">External Email: Please use caution wh= en opening links and attachments / Courrie= l externe: Soyez prudent avec les liens et documents joints

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/m= ailman/listinfo/ecrit

<= span style=3D"font-size:9.0pt;color:blue">External Email: Please use caution wh= en opening links and attachments / Courrie= l externe: Soyez prudent avec les liens et documents joints

--=_MailMate_47BC319C-9233-4DAF-87E2-599D37A1657F_=-- From nobody Mon Aug 23 14:55:24 2021 Return-Path: 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 020483A1DA3 for ; Mon, 23 Aug 2021 14:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, 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.20150623.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 Aw3wHvIicJox for ; Mon, 23 Aug 2021 14:55:17 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 05BB73A1D9B for ; Mon, 23 Aug 2021 14:55:17 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id b7so23758690iob.4 for ; Mon, 23 Aug 2021 14:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=au5FAmzgNXG/QE18Y2rokjz1otiuzwb8Bev7nEbk8U4=; b=SikQCumafLHyXaZgzc6pEsug/XYrzxyx1VBQNcmCGskLJPo59nD9Maax+e5P7V33jM zhgeaK974r8g0k1+m6VKO2YA7kPGbihznKFnkDCvIL1wMcHfr6sF3pYH2S3dJQbRcNoB yxfnh/DUS/kAYHUb7aI0SVaOiQf/SoAjf0cZXey0DE9JXbsVb3dySJmgQaiwlgggE+uC G3IjZ3VyTaXCaej4r4D682NRJLjG99PCGXjeMZUIN0Bx8PIRluEa/A3WOy2YdNSPpuLd HRzFrvMwPv6POofJQAVS2HJwYk75P+1jOisy+NXZsnE+EYGwp8Lo0VAH/5RuLdvYndua 66fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=au5FAmzgNXG/QE18Y2rokjz1otiuzwb8Bev7nEbk8U4=; b=ay0c+aLovDMBbnYkip0zPCqpi2h1hrgwfpnF8AnlFCsM8RZX3ROU0tevOjrWVtZMLx isAtHBpJ3mSEwf7+H2xnR9JzeC1AjxACqlPJkbyRKtB9fGF+HjkuPlgFfr/UIx/JC/b5 08BbpEZkC2Oaqk2if0IChjst8KseyvHWvmOKbOkgG/6uET9SlQPIUgX4HLmTPjoV1rjD F97iHZwFJEIdzTv5PlU1GcCbVAphZqj8pPn4QwDFkfLiU+7qsm1pNToVjsBSb7Qv3P9B /AHBs2wSpZ07u1TkmwSp8qC2o2RFkeCTkEP2u0j5s4+0ymkLC5oiQximrfrHbrxiuM1O o69Q== X-Gm-Message-State: AOAM533iUl0bAdO1A2bMwa/lwV8zfYin1QlRc+UyzOvt4WENdz+1e+zz AYfJP6tcqc8rtgFqoYvAtO+82g== X-Google-Smtp-Source: ABdhPJw8W8EkV+ri4Y7DEPn6jx5f2/EyMW8T5tZNInX1EyqmwtfS5qwUq77fP1WDNivksh4mAcKlng== X-Received: by 2002:a5d:8e11:: with SMTP id e17mr28762932iod.138.1629755715359; Mon, 23 Aug 2021 14:55:15 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id o11sm8824812ilf.86.2021.08.23.14.55.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Aug 2021 14:55:14 -0700 (PDT) From: Brian Rosen Message-Id: <9158D09E-770E-4E65-BE46-E39060EAC884@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_A37AF8E8-66DF-447A-BC63-C8E624F333EA" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Mon, 23 Aug 2021 17:55:13 -0400 In-Reply-To: <791ea34f628d48d3addeb04613d5721a@bell.ca> Cc: "ecrit@ietf.org" To: "Caron, Guy" References: <8bdda7ea7d004b4591ff715526d93a73@bell.ca> <791ea34f628d48d3addeb04613d5721a@bell.ca> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 21:55:23 -0000 --Apple-Mail=_A37AF8E8-66DF-447A-BC63-C8E624F333EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I don=E2=80=99t understand the reasoning on =E2=80=9Ccreating havoc=E2=80=9D= . I don=E2=80=99t know why a client would ever do it, but it = =E2=80=9Cworks=E2=80=9D in that the server doesn=E2=80=99t have to = validate to save the URI. If I client sends the URI and doesn=E2=80=99t = validate, it=E2=80=99s weird, but not wrong. We can decide to prohibit it. But we don=E2=80=99t really have a = justification. Brian > On Aug 23, 2021, at 5:44 PM, Caron, Guy wrote: >=20 > I agree that accommodating this comment would require deeper XML = changes. > =20 > If we do not want to go there, I think the draft should be clear that = there is no usecase for sending outside of a location = validation request and as such, should normatively recommend not doing = so. > =20 > I do not agree that a LoST server receiving outside of = a location validation request would retain the URI and send notification = if the record changed afterward. I think this would create havoc on the = client=E2=80=99 side. > =20 > Thanks, > =20 > Guy > =20 > De : Brian Rosen =20 > Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:22 > =C3=80 : Caron, Guy > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to = validateLocation? > =20 > validateLocation is an attribute, not an element, so I can=E2=80=99t = extend it. =20 > =20 > There isn=E2=80=99t an actual requirement to tie plannedChange to = validateLocation. It may not make a lot of sense, but if you did it, = the LoST server would not return validation data, would retain the URI = and would send the notification if the record changed. Note my text = that the LoST server doesn=E2=80=99t store the LI - the notification is = =E2=80=9Csomething changed=E2=80=9D not =E2=80=9Cwhat you sent is = guaranteed to be invalid=E2=80=9D or even =E2=80=9Cone or more of the = elements you sent changed". I thought about changing the name of the = notification, but I didn=E2=80=99t do that. The practical use case = remains the same. > =20 > Brian >=20 >=20 > On Aug 23, 2021, at 5:07 PM, Caron, Guy > wrote: > =20 > Not all LoST server implementations perform location validations. When = location validation is requested by the client, it adds the = =E2=80=9CvalidateLocation=E2=80=9D attribute to the = element. > =20 > So the question is: Should =E2=80=9CplannedChange=E2=80=9D be bound to = =E2=80=9CvalidateLocation=E2=80=9D? > =20 > If you believe not, what would be the expected behaviour of a LoST = server receiving a element outside of a validation = request? > =20 > Thanks, > =20 > Guy > =20 > External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints --Apple-Mail=_A37AF8E8-66DF-447A-BC63-C8E624F333EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = don=E2=80=99t understand the reasoning on =E2=80=9Ccreating havoc=E2=80=9D= .  I don=E2=80=99t know why a client would ever do it, but it = =E2=80=9Cworks=E2=80=9D in that the server doesn=E2=80=99t have to = validate to save the URI.  If I client sends the URI and doesn=E2=80=99= t validate, it=E2=80=99s weird, but not wrong.

We can decide to prohibit it.  But = we don=E2=80=99t really have a justification.

Brian

On Aug 23, 2021, at 5:44 PM, Caron, Guy <g.caron@bell.ca> = wrote:

I agree that = accommodating this comment would require deeper XML changes.
 
If = we do not want to go there, I think the draft should be clear that there = is no usecase for sending <plannedChange> outside of a location = validation request and as such, should normatively recommend not doing = so.
 
I do not agree that a LoST server receiving = <plannedChange> outside of a location validation request would = retain the URI and send notification if the record changed afterward. I = think this would create havoc on the client=E2=80=99 side.
 
Thanks,
 
Guy
 
De : Brian = Rosen <br@brianrosen.net> 
Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:22
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : ecrit@ietf.org
Objet : [EXT]Re: = lost-planned-changes-04: plannedChange bound to validateLocation?
 
validateLocation is an attribute, not an = element, so I can=E2=80=99t extend it.  
 
There = isn=E2=80=99t an actual requirement to tie plannedChange to = validateLocation.  It may not make a lot of sense, but if you did = it, the LoST server would not return validation data, would retain the = URI and would send the notification if the record changed.  Note my = text that the LoST server doesn=E2=80=99t store the LI - the = notification is =E2=80=9Csomething changed=E2=80=9D not =E2=80=9Cwhat = you sent is guaranteed to be invalid=E2=80=9D or even =E2=80=9Cone or = more of the elements you sent changed".  I thought about changing = the name of the notification, but I didn=E2=80=99t do that.  The = practical use case remains the same.
 
Brian


On Aug 23, 2021, at 5:07 PM, Caron, Guy = <g.caron@bell.ca> = wrote:
 
Not all LoST server = implementations perform location validations. When location validation = is requested by the client, it adds the =E2=80=9CvalidateLocation=E2=80=9D= attribute to the <findService> element.
 
So the question is: = Should =E2=80=9CplannedChange=E2=80=9D be bound to = =E2=80=9CvalidateLocation=E2=80=9D?
 
If you believe not, = what would be the expected behaviour of a LoST server receiving a = <plannedChange> element outside of a validation = request?
 
Thanks,
 
Guy
 
External Email: Please use caution when = opening links and attachments / Courriel externe: Soyez prudent avec les = liens et documents = joints

= --Apple-Mail=_A37AF8E8-66DF-447A-BC63-C8E624F333EA-- From nobody Mon Aug 23 15:01:29 2021 Return-Path: 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 086CA3A1E0A for ; Mon, 23 Aug 2021 15:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=bell.ca 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 Y3Lr2UkK6-ty for ; Mon, 23 Aug 2021 15:01:17 -0700 (PDT) Received: from ESA2-Wyn.bell.ca (esa2-wyn.bell.ca [67.69.243.180]) (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 54CBE3A1E0C for ; Mon, 23 Aug 2021 15:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1629756077; x=1661292077; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=p6gEi5OpeuLV/xtlW/AuheICmDPMna+hLP6nVdPnznQ=; b=IEGsGcbDW0OmEoEQyw8FLmURSrEsZb/KZbvQt/4+H58MoTcceGBk6P/l cnSzcCs2CelrA+XUo7olCnfaJXBCl2yn/ap/AoTkxl5qGXhJtWVtRLy/8 Bh1Wj2+7eAWXAANA2T30Md7RwzsBzrWexJMD51+kXFXbe7J7poTEsqWwD 2u3LIelzgoEaj1in0Thy73cqdRzbJ//TnrpqAbd+x5hqoVqHu2dPDnv+g N9otGuUfyzYBMK/tOUsugcE06fcK04wvDee6ae5Pj10k1UnTCd6FxvSgO 5UZt99kQnENG1CXugIgKpOshtr+WNqMsUm2ZZ1VW0GfW2D/xsmnzIYaD2 g==; IronPort-SDR: uxp+6H8C92sZ8THLCGWxwRcU3h0hfLt83XO/CZdSMSUlxiYRDzQbJ2+IBqIaWGCMFkORdtVFAz Uuqz/zuMlXJw== Received: from dm5cch-d01.bellca.int.bell.ca (HELO DG4MBX03-WYN.bell.corp.bce.ca) ([198.235.102.31]) by esa02corp-wyn.bell.corp.bce.ca with ESMTP; 23 Aug 2021 18:01:16 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG4MBX03-WYN.bell.corp.bce.ca (142.182.18.29) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 23 Aug 2021 18:01:15 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Mon, 23 Aug 2021 18:01:15 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Mon, 23 Aug 2021 18:01:15 -0400 From: "Caron, Guy" To: Brian Rosen CC: "ecrit@ietf.org" Thread-Topic: [EXT]Re: lost-planned-changes-04: plannedChange bound to validateLocation? Thread-Index: AdeYYhykIa0/cXEHQDGV6seRBYfoOQAJEtyAAAfVt2D//8qpgIAAQotw Date: Mon, 23 Aug 2021 22:01:15 +0000 Message-ID: <0b81d439e4824aec8a3476906ce5cbc1@bell.ca> References: <8bdda7ea7d004b4591ff715526d93a73@bell.ca> <791ea34f628d48d3addeb04613d5721a@bell.ca> <9158D09E-770E-4E65-BE46-E39060EAC884@brianrosen.net> In-Reply-To: <9158D09E-770E-4E65-BE46-E39060EAC884@brianrosen.net> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.79] Content-Type: multipart/alternative; boundary="_000_0b81d439e4824aec8a3476906ce5cbc1bellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 22:01:24 -0000 --_000_0b81d439e4824aec8a3476906ce5cbc1bellca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSBMb1NUIGNsaWVudCB0aGF0IHNlbmRzIHJvdXRpbmcgcmVxdWVzdHMgdG8gdGhlIHNlcnZlciB3 b3VsZCByZWNlaXZlLCB3YXkgYWZ0ZXIgY2FsbHMgaGF2ZSBiZWVuIGRlbGl2ZXJlZCwgYSBub3Rp ZmljYXRpb24gd2l0aCBhIDxsb2NhdGlvbkludmFsaWQ+IGJvZHkuIFdoYXQgd291bGQgaXQgZG8g d2l0aCB0aGlzPw0KDQpNYWtlcyBubyBzZW5zZSB0byBtZS4NCg0KR3V5DQoNCkRlIDogQnJpYW4g Um9zZW4gPGJyQGJyaWFucm9zZW4ubmV0Pg0KRW52b3nDqSA6IDIzIGFvw7t0IDIwMjEgMTc6NTUN CsOAIDogQ2Fyb24sIEd1eSA8Zy5jYXJvbkBiZWxsLmNhPg0KQ2MgOiBlY3JpdEBpZXRmLm9yZw0K T2JqZXQgOiBbRVhUXVJlOiBsb3N0LXBsYW5uZWQtY2hhbmdlcy0wNDogcGxhbm5lZENoYW5nZSBi b3VuZCB0byB2YWxpZGF0ZUxvY2F0aW9uPw0KDQpJIGRvbuKAmXQgdW5kZXJzdGFuZCB0aGUgcmVh c29uaW5nIG9uIOKAnGNyZWF0aW5nIGhhdm9j4oCdLiAgSSBkb27igJl0IGtub3cgd2h5IGEgY2xp ZW50IHdvdWxkIGV2ZXIgZG8gaXQsIGJ1dCBpdCDigJx3b3Jrc+KAnSBpbiB0aGF0IHRoZSBzZXJ2 ZXIgZG9lc27igJl0IGhhdmUgdG8gdmFsaWRhdGUgdG8gc2F2ZSB0aGUgVVJJLiAgSWYgSSBjbGll bnQgc2VuZHMgdGhlIFVSSSBhbmQgZG9lc27igJl0IHZhbGlkYXRlLCBpdOKAmXMgd2VpcmQsIGJ1 dCBub3Qgd3JvbmcuDQoNCldlIGNhbiBkZWNpZGUgdG8gcHJvaGliaXQgaXQuICBCdXQgd2UgZG9u 4oCZdCByZWFsbHkgaGF2ZSBhIGp1c3RpZmljYXRpb24uDQoNCkJyaWFuDQoNCg0KT24gQXVnIDIz LCAyMDIxLCBhdCA1OjQ0IFBNLCBDYXJvbiwgR3V5IDxnLmNhcm9uQGJlbGwuY2E8bWFpbHRvOmcu Y2Fyb25AYmVsbC5jYT4+IHdyb3RlOg0KDQpJIGFncmVlIHRoYXQgYWNjb21tb2RhdGluZyB0aGlz IGNvbW1lbnQgd291bGQgcmVxdWlyZSBkZWVwZXIgWE1MIGNoYW5nZXMuDQoNCklmIHdlIGRvIG5v dCB3YW50IHRvIGdvIHRoZXJlLCBJIHRoaW5rIHRoZSBkcmFmdCBzaG91bGQgYmUgY2xlYXIgdGhh dCB0aGVyZSBpcyBubyB1c2VjYXNlIGZvciBzZW5kaW5nIDxwbGFubmVkQ2hhbmdlPiBvdXRzaWRl IG9mIGEgbG9jYXRpb24gdmFsaWRhdGlvbiByZXF1ZXN0IGFuZCBhcyBzdWNoLCBzaG91bGQgbm9y bWF0aXZlbHkgcmVjb21tZW5kIG5vdCBkb2luZyBzby4NCg0KSSBkbyBub3QgYWdyZWUgdGhhdCBh IExvU1Qgc2VydmVyIHJlY2VpdmluZyA8cGxhbm5lZENoYW5nZT4gb3V0c2lkZSBvZiBhIGxvY2F0 aW9uIHZhbGlkYXRpb24gcmVxdWVzdCB3b3VsZCByZXRhaW4gdGhlIFVSSSBhbmQgc2VuZCBub3Rp ZmljYXRpb24gaWYgdGhlIHJlY29yZCBjaGFuZ2VkIGFmdGVyd2FyZC4gSSB0aGluayB0aGlzIHdv dWxkIGNyZWF0ZSBoYXZvYyBvbiB0aGUgY2xpZW504oCZIHNpZGUuDQoNClRoYW5rcywNCg0KR3V5 DQoNCkRlIDogQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0PG1haWx0bzpickBicmlhbnJv c2VuLm5ldD4+DQpFbnZvecOpIDogMjMgYW/Du3QgMjAyMSAxNzoyMg0Kw4AgOiBDYXJvbiwgR3V5 IDxnLmNhcm9uQGJlbGwuY2E8bWFpbHRvOmcuY2Fyb25AYmVsbC5jYT4+DQpDYyA6IGVjcml0QGll dGYub3JnPG1haWx0bzplY3JpdEBpZXRmLm9yZz4NCk9iamV0IDogW0VYVF1SZTogbG9zdC1wbGFu bmVkLWNoYW5nZXMtMDQ6IHBsYW5uZWRDaGFuZ2UgYm91bmQgdG8gdmFsaWRhdGVMb2NhdGlvbj8N Cg0KdmFsaWRhdGVMb2NhdGlvbiBpcyBhbiBhdHRyaWJ1dGUsIG5vdCBhbiBlbGVtZW50LCBzbyBJ IGNhbuKAmXQgZXh0ZW5kIGl0Lg0KDQpUaGVyZSBpc27igJl0IGFuIGFjdHVhbCByZXF1aXJlbWVu dCB0byB0aWUgcGxhbm5lZENoYW5nZSB0byB2YWxpZGF0ZUxvY2F0aW9uLiAgSXQgbWF5IG5vdCBt YWtlIGEgbG90IG9mIHNlbnNlLCBidXQgaWYgeW91IGRpZCBpdCwgdGhlIExvU1Qgc2VydmVyIHdv dWxkIG5vdCByZXR1cm4gdmFsaWRhdGlvbiBkYXRhLCB3b3VsZCByZXRhaW4gdGhlIFVSSSBhbmQg d291bGQgc2VuZCB0aGUgbm90aWZpY2F0aW9uIGlmIHRoZSByZWNvcmQgY2hhbmdlZC4gIE5vdGUg bXkgdGV4dCB0aGF0IHRoZSBMb1NUIHNlcnZlciBkb2VzbuKAmXQgc3RvcmUgdGhlIExJIC0gdGhl IG5vdGlmaWNhdGlvbiBpcyDigJxzb21ldGhpbmcgY2hhbmdlZOKAnSBub3Qg4oCcd2hhdCB5b3Ug c2VudCBpcyBndWFyYW50ZWVkIHRvIGJlIGludmFsaWTigJ0gb3IgZXZlbiDigJxvbmUgb3IgbW9y ZSBvZiB0aGUgZWxlbWVudHMgeW91IHNlbnQgY2hhbmdlZCIuICBJIHRob3VnaHQgYWJvdXQgY2hh bmdpbmcgdGhlIG5hbWUgb2YgdGhlIG5vdGlmaWNhdGlvbiwgYnV0IEkgZGlkbuKAmXQgZG8gdGhh dC4gIFRoZSBwcmFjdGljYWwgdXNlIGNhc2UgcmVtYWlucyB0aGUgc2FtZS4NCg0KQnJpYW4NCg0K DQoNCk9uIEF1ZyAyMywgMjAyMSwgYXQgNTowNyBQTSwgQ2Fyb24sIEd1eSA8Zy5jYXJvbkBiZWxs LmNhPG1haWx0bzpnLmNhcm9uQGJlbGwuY2E+PiB3cm90ZToNCg0KTm90IGFsbCBMb1NUIHNlcnZl ciBpbXBsZW1lbnRhdGlvbnMgcGVyZm9ybSBsb2NhdGlvbiB2YWxpZGF0aW9ucy4gV2hlbiBsb2Nh dGlvbiB2YWxpZGF0aW9uIGlzIHJlcXVlc3RlZCBieSB0aGUgY2xpZW50LCBpdCBhZGRzIHRoZSDi gJx2YWxpZGF0ZUxvY2F0aW9u4oCdIGF0dHJpYnV0ZSB0byB0aGUgPGZpbmRTZXJ2aWNlPiBlbGVt ZW50Lg0KDQpTbyB0aGUgcXVlc3Rpb24gaXM6IFNob3VsZCDigJxwbGFubmVkQ2hhbmdl4oCdIGJl IGJvdW5kIHRvIOKAnHZhbGlkYXRlTG9jYXRpb27igJ0/DQoNCklmIHlvdSBiZWxpZXZlIG5vdCwg d2hhdCB3b3VsZCBiZSB0aGUgZXhwZWN0ZWQgYmVoYXZpb3VyIG9mIGEgTG9TVCBzZXJ2ZXIgcmVj ZWl2aW5nIGEgPHBsYW5uZWRDaGFuZ2U+IGVsZW1lbnQgb3V0c2lkZSBvZiBhIHZhbGlkYXRpb24g cmVxdWVzdD8NCg0KVGhhbmtzLA0KDQpHdXkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkV4dGVybmFsIEVtYWlsOiBQbGVhc2UgdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxp bmtzIGFuZCBhdHRhY2htZW50cyAvIENvdXJyaWVsIGV4dGVybmU6IFNveWV6IHBydWRlbnQgYXZl YyBsZXMgbGllbnMgZXQgZG9jdW1lbnRzIGpvaW50cw0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KRXh0ZXJuYWwgRW1haWw6IFBsZWFzZSB1c2UgY2F1dGlvbiB3aGVuIG9wZW5p bmcgbGlua3MgYW5kIGF0dGFjaG1lbnRzIC8gQ291cnJpZWwgZXh0ZXJuZTogU295ZXogcHJ1ZGVu dCBhdmVjIGxlcyBsaWVucyBldCBkb2N1bWVudHMgam9pbnRzDQo= --_000_0b81d439e4824aec8a3476906ce5cbc1bellca_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5t c29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFt ZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpz cGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0 ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlItQ0Ei IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QSBMb1NUIGNsaWVudCB0aGF0IHNl bmRzIHJvdXRpbmcgcmVxdWVzdHMgdG8gdGhlIHNlcnZlciB3b3VsZCByZWNlaXZlLCB3YXkgYWZ0 ZXIgY2FsbHMgaGF2ZSBiZWVuIGRlbGl2ZXJlZCwgYSBub3RpZmljYXRpb24NCiB3aXRoIGEgJmx0 O2xvY2F0aW9uSW52YWxpZCZndDsgYm9keS4gV2hhdCB3b3VsZCBpdCBkbyB3aXRoIHRoaXM/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPk1ha2VzIG5vIHNlbnNlIHRvIG1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5HdXk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4gQnJpYW4gUm9zZW4gJmx0O2JyQGJyaWFucm9zZW4ubmV0Jmd0Ow0K PGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IDIzIGFvw7t0IDIwMjEgMTc6NTU8YnI+DQo8Yj7D gCZuYnNwOzo8L2I+IENhcm9uLCBHdXkgJmx0O2cuY2Fyb25AYmVsbC5jYSZndDs8YnI+DQo8Yj5D YyZuYnNwOzo8L2I+IGVjcml0QGlldGYub3JnPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBbRVhU XVJlOiBsb3N0LXBsYW5uZWQtY2hhbmdlcy0wNDogcGxhbm5lZENoYW5nZSBib3VuZCB0byB2YWxp ZGF0ZUxvY2F0aW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSByZWFzb25pbmcgb24g4oCcY3JlYXRpbmcgaGF2 b2PigJ0uICZuYnNwO0kgZG9u4oCZdCBrbm93IHdoeSBhIGNsaWVudCB3b3VsZCBldmVyIGRvIGl0 LCBidXQgaXQg4oCcd29ya3PigJ0gaW4gdGhhdCB0aGUgc2VydmVyIGRvZXNu4oCZdCBoYXZlIHRv IHZhbGlkYXRlIHRvIHNhdmUgdGhlIFVSSS4gJm5ic3A7SWYgSSBjbGllbnQgc2VuZHMgdGhlIFVS SSBhbmQgZG9lc27igJl0IHZhbGlkYXRlLCBpdOKAmXMgd2VpcmQsDQogYnV0IG5vdCB3cm9uZy48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGNhbiBkZWNp ZGUgdG8gcHJvaGliaXQgaXQuICZuYnNwO0J1dCB3ZSBkb27igJl0IHJlYWxseSBoYXZlIGEganVz dGlmaWNhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QnJpYW48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gQXVnIDIzLCAyMDIxLCBhdCA1OjQ0IFBNLCBDYXJvbiwgR3V5 ICZsdDs8YSBocmVmPSJtYWlsdG86Zy5jYXJvbkBiZWxsLmNhIj5nLmNhcm9uQGJlbGwuY2E8L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB0aGF0 IGFjY29tbW9kYXRpbmcgdGhpcyBjb21tZW50IHdvdWxkIHJlcXVpcmUgZGVlcGVyIFhNTCBjaGFu Z2VzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JZiB3ZSBkbyBu b3Qgd2FudCB0byBnbyB0aGVyZSwgSSB0aGluayB0aGUgZHJhZnQgc2hvdWxkIGJlIGNsZWFyIHRo YXQgdGhlcmUgaXMgbm8gdXNlY2FzZSBmb3Igc2VuZGluZyAmbHQ7cGxhbm5lZENoYW5nZSZndDsg b3V0c2lkZSBvZiBhIGxvY2F0aW9uIHZhbGlkYXRpb24NCiByZXF1ZXN0IGFuZCBhcyBzdWNoLCBz aG91bGQgbm9ybWF0aXZlbHkgcmVjb21tZW5kIG5vdCBkb2luZyBzby48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBkbyBub3QgYWdyZWUgdGhhdCBhIExvU1Qgc2Vy dmVyIHJlY2VpdmluZyAmbHQ7cGxhbm5lZENoYW5nZSZndDsgb3V0c2lkZSBvZiBhIGxvY2F0aW9u IHZhbGlkYXRpb24gcmVxdWVzdCB3b3VsZCByZXRhaW4gdGhlIFVSSSBhbmQgc2VuZCBub3RpZmlj YXRpb24gaWYNCiB0aGUgcmVjb3JkIGNoYW5nZWQgYWZ0ZXJ3YXJkLiBJIHRoaW5rIHRoaXMgd291 bGQgY3JlYXRlIGhhdm9jIG9uIHRoZSBjbGllbnTigJkgc2lkZS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5HdXk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5n PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5Ccmlhbg0KIFJvc2VuICZsdDs8YSBocmVmPSJtYWlsdG86YnJAYnJp YW5yb3Nlbi5uZXQiPmJyQGJyaWFucm9zZW4ubmV0PC9hPiZndDs8c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+ PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjIzIGFvw7t0 IDIwMjEgMTc6MjI8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkNhcm9uLCBHdXkgJmx0OzxhIGhyZWY9Im1haWx0bzpn LmNhcm9uQGJlbGwuY2EiPmcuY2Fyb25AYmVsbC5jYTwvYT4mZ3Q7PGJyPg0KPGI+Q2MmbmJzcDs6 PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBo cmVmPSJtYWlsdG86ZWNyaXRAaWV0Zi5vcmciPmVjcml0QGlldGYub3JnPC9hPjxicj4NCjxiPk9i amV0Jm5ic3A7OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+W0VYVF1SZTogbG9zdC1wbGFubmVkLWNoYW5nZXMtMDQ6IHBsYW5uZWRDaGFuZ2UgYm91 bmQgdG8gdmFsaWRhdGVMb2NhdGlvbj88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj52YWxpZGF0ZUxvY2F0 aW9uIGlzIGFuIGF0dHJpYnV0ZSwgbm90IGFuIGVsZW1lbnQsIHNvIEkgY2Fu4oCZdCBleHRlbmQg aXQuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgaXNu4oCZdCBhbiBhY3R1YWwgcmVx dWlyZW1lbnQgdG8gdGllIHBsYW5uZWRDaGFuZ2UgdG8gdmFsaWRhdGVMb2NhdGlvbi4gJm5ic3A7 SXQgbWF5IG5vdCBtYWtlIGEgbG90IG9mIHNlbnNlLCBidXQgaWYgeW91IGRpZCBpdCwgdGhlIExv U1Qgc2VydmVyIHdvdWxkIG5vdCByZXR1cm4gdmFsaWRhdGlvbiBkYXRhLCB3b3VsZCByZXRhaW4g dGhlIFVSSSBhbmQgd291bGQgc2VuZCB0aGUgbm90aWZpY2F0aW9uIGlmIHRoZQ0KIHJlY29yZCBj aGFuZ2VkLiAmbmJzcDtOb3RlIG15IHRleHQgdGhhdCB0aGUgTG9TVCBzZXJ2ZXIgZG9lc27igJl0 IHN0b3JlIHRoZSBMSSAtIHRoZSBub3RpZmljYXRpb24gaXMg4oCcc29tZXRoaW5nIGNoYW5nZWTi gJ0gbm90IOKAnHdoYXQgeW91IHNlbnQgaXMgZ3VhcmFudGVlZCB0byBiZSBpbnZhbGlk4oCdIG9y IGV2ZW4g4oCcb25lIG9yIG1vcmUgb2YgdGhlIGVsZW1lbnRzIHlvdSBzZW50IGNoYW5nZWQmcXVv dDsuICZuYnNwO0kgdGhvdWdodCBhYm91dCBjaGFuZ2luZyB0aGUgbmFtZSBvZg0KIHRoZSBub3Rp ZmljYXRpb24sIGJ1dCBJIGRpZG7igJl0IGRvIHRoYXQuICZuYnNwO1RoZSBwcmFjdGljYWwgdXNl IGNhc2UgcmVtYWlucyB0aGUgc2FtZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnJpYW48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEF1ZyAyMywgMjAyMSwg YXQgNTowNyBQTSwgQ2Fyb24sIEd1eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmcuY2Fyb25AYmVsbC5j YSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Zy5jYXJvbkBiZWxsLmNhPC9zcGFuPjwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5Ob3QgYWxsIExvU1Qgc2VydmVyIGltcGxlbWVudGF0aW9ucyBwZXJm b3JtIGxvY2F0aW9uIHZhbGlkYXRpb25zLiBXaGVuIGxvY2F0aW9uIHZhbGlkYXRpb24gaXMgcmVx dWVzdGVkIGJ5IHRoZSBjbGllbnQsIGl0IGFkZHMgdGhlIOKAnHZhbGlkYXRlTG9jYXRpb27igJ0N CiBhdHRyaWJ1dGUgdG8gdGhlICZsdDtmaW5kU2VydmljZSZndDsgZWxlbWVudC48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+U28gdGhlIHF1ZXN0aW9uIGlzOiBTaG91bGQg4oCccGxhbm5lZENoYW5nZeKAnSBiZSBi b3VuZCB0byDigJx2YWxpZGF0ZUxvY2F0aW9u4oCdPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JZiB5b3UgYmVs aWV2ZSBub3QsIHdoYXQgd291bGQgYmUgdGhlIGV4cGVjdGVkIGJlaGF2aW91ciBvZiBhIExvU1Qg c2VydmVyIHJlY2VpdmluZyBhICZsdDtwbGFubmVkQ2hhbmdlJmd0OyBlbGVtZW50IG91dHNpZGUg b2YgYSB2YWxpZGF0aW9uIHJlcXVlc3Q/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+R3V5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdp ZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzdHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVl Ij5FeHRlcm5hbCBFbWFpbDo8L3NwYW4+PC9pPjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1 ZSI+Jm5ic3A7PC9zcGFuPjwvaT48L3NwYW4+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Y29sb3I6Ymx1ZSI+UGxlYXNlDQogdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxpbmtzIGFu ZCBhdHRhY2htZW50cyAvPC9zcGFuPjwvZW0+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj4mbmJzcDs8 L3NwYW4+PC9pPjwvc3Bhbj48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Y29sb3I6Ymx1ZSI+Q291cnJpZWwgZXh0ZXJuZTo8L3NwYW4+PC9pPjwvc3Ryb25nPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjwvaT48L3NwYW4+PGVtPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+U295ZXoNCiBwcnVkZW50IGF2ZWMgbGVzIGxpZW5z IGV0IGRvY3VtZW50cyBqb2ludHM8L3NwYW4+PC9lbT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNv Tm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNp emU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJs dWUiPkV4dGVybmFsIEVtYWlsOjwvc3Bhbj48L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+IFBsZWFzZSB1c2UgY2F1dGlvbiB3aGVuIG9wZW5p bmcgbGlua3MgYW5kIGF0dGFjaG1lbnRzIC8NCjwvc3Bhbj48L2VtPjxzdHJvbmc+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj5Db3VycmllbCBleHRlcm5lOjwvc3Bh bj48L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1 ZSI+IFNveWV6IHBydWRlbnQgYXZlYyBsZXMgbGllbnMgZXQgZG9jdW1lbnRzIGpvaW50cw0KPC9z cGFuPjwvZW0+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_0b81d439e4824aec8a3476906ce5cbc1bellca_-- From nobody Mon Aug 23 15:06:14 2021 Return-Path: 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 D85443A1E8D for ; Mon, 23 Aug 2021 15:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=bell.ca 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 V_0m9-eDZNxA for ; Mon, 23 Aug 2021 15:06:07 -0700 (PDT) Received: from ESA1-Dor.bell.ca (esa1-dor.bell.ca [204.101.223.58]) (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 37D1B3A1E8F for ; Mon, 23 Aug 2021 15:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1629756367; x=1661292367; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=1TH4heSDbmLeOZ039MZwjuj9YlgPhD82qbxipAys6S4=; b=d3X9ZGxnFOHj1lqgwdyM7fD48xe9nrCdpMiCHL8bhoM7gK2RqlUaU068 BXuU7O3d4tZ9t9PHdIEBw4PGmhT6/UZq7+eC8swaU45IHm9z6zGC3lFH2 mYh7/MtXBtvsWNJeT9rSwqbpNDTeiPrTTPUwTx7VJvt3JXRLTfK+iTi6C J/2KpbpUmA2OGcVeKsClqTl7cklA5UpR0C8CDBaTJSO7MgzO/OdMeXKaf jWzIkPqPZtRVH59gQea9JvLI/wabIE+AjujUifkulkZc24vM1Z1oOvGU8 PlTRDJMTQHYr590GL7dNM04HTZGRVYByPKOtqA4IeL6hqsFv4Ps99GpD6 g==; IronPort-SDR: A7d53VI0Mdb9TgaElLrqpm5x8VTL9r1aBOIZoBxUazCmF8YyjbnQUayaYZSSA/nbpQCfNJzoIX nLyKS6ntO6lQ== Received: from dc5cmy-d00.bellca.int.bell.ca (HELO DG3MBX02-WYN.bell.corp.bce.ca) ([198.235.121.229]) by esa01corp-dor.bell.corp.bce.ca with ESMTP; 23 Aug 2021 18:06:05 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG3MBX02-WYN.bell.corp.bce.ca (142.182.18.24) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 23 Aug 2021 18:06:05 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Mon, 23 Aug 2021 18:06:04 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Mon, 23 Aug 2021 18:06:04 -0400 From: "Caron, Guy" To: Brian Rosen CC: "ecrit@ietf.org" Thread-Topic: [EXT]Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation? Thread-Index: AQHXmGsRlOgBMfP5wky7OvP/cPKU3Q== Date: Mon, 23 Aug 2021 22:06:04 +0000 Message-ID: References: <8bdda7ea7d004b4591ff715526d93a73@bell.ca> <791ea34f628d48d3addeb04613d5721a@bell.ca> <9158D09E-770E-4E65-BE46-E39060EAC884@brianrosen.net> <0b81d439e4824aec8a3476906ce5cbc1@bell.ca> In-Reply-To: <0b81d439e4824aec8a3476906ce5cbc1@bell.ca> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.79] Content-Type: multipart/alternative; boundary="_000_c3f5a623984e4bef9ddf14b1ae2ba273bellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 22:06:13 -0000 --_000_c3f5a623984e4bef9ddf14b1ae2ba273bellca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBmdXJ0aGVyIHRoaW5rIHRoYXQgYSBzZXJ2ZXIgc2hvdWxkIGlnbm9yZSA8cGxhbm5lZENoYW5n ZT4gaWYgc2VudCBvdXRzaWRlIGEgbG9jYXRpb24gdmFsaWRhdGlvbiByZXF1ZXN0IG9yLCBhdCB0 aGUgbWluaW11bSwgc2VuZCBhIOKAnHVyaU5vdFN0b3JlZOKAnSBpbiB0aGUgcmVzcG9uc2UuDQoN ClRoYW5rcywNCg0KR3V5DQoNCkRlIDogRWNyaXQgPGVjcml0LWJvdW5jZXNAaWV0Zi5vcmc+IERl IGxhIHBhcnQgZGUgQ2Fyb24sIEd1eQ0KRW52b3nDqSA6IDIzIGFvw7t0IDIwMjEgMTg6MDENCsOA IDogQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0Pg0KQ2MgOiBlY3JpdEBpZXRmLm9yZw0K T2JqZXQgOiBbRVhUXVJlOiBbRWNyaXRdIGxvc3QtcGxhbm5lZC1jaGFuZ2VzLTA0OiBwbGFubmVk Q2hhbmdlIGJvdW5kIHRvIHZhbGlkYXRlTG9jYXRpb24/DQoNCkEgTG9TVCBjbGllbnQgdGhhdCBz ZW5kcyByb3V0aW5nIHJlcXVlc3RzIHRvIHRoZSBzZXJ2ZXIgd291bGQgcmVjZWl2ZSwgd2F5IGFm dGVyIGNhbGxzIGhhdmUgYmVlbiBkZWxpdmVyZWQsIGEgbm90aWZpY2F0aW9uIHdpdGggYSA8bG9j YXRpb25JbnZhbGlkPiBib2R5LiBXaGF0IHdvdWxkIGl0IGRvIHdpdGggdGhpcz8NCg0KTWFrZXMg bm8gc2Vuc2UgdG8gbWUuDQoNCkd1eQ0KDQpEZSA6IEJyaWFuIFJvc2VuIDxickBicmlhbnJvc2Vu Lm5ldDxtYWlsdG86YnJAYnJpYW5yb3Nlbi5uZXQ+Pg0KRW52b3nDqSA6IDIzIGFvw7t0IDIwMjEg MTc6NTUNCsOAIDogQ2Fyb24sIEd1eSA8Zy5jYXJvbkBiZWxsLmNhPG1haWx0bzpnLmNhcm9uQGJl bGwuY2E+Pg0KQ2MgOiBlY3JpdEBpZXRmLm9yZzxtYWlsdG86ZWNyaXRAaWV0Zi5vcmc+DQpPYmpl dCA6IFtFWFRdUmU6IGxvc3QtcGxhbm5lZC1jaGFuZ2VzLTA0OiBwbGFubmVkQ2hhbmdlIGJvdW5k IHRvIHZhbGlkYXRlTG9jYXRpb24/DQoNCkkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSByZWFzb25p bmcgb24g4oCcY3JlYXRpbmcgaGF2b2PigJ0uICBJIGRvbuKAmXQga25vdyB3aHkgYSBjbGllbnQg d291bGQgZXZlciBkbyBpdCwgYnV0IGl0IOKAnHdvcmtz4oCdIGluIHRoYXQgdGhlIHNlcnZlciBk b2VzbuKAmXQgaGF2ZSB0byB2YWxpZGF0ZSB0byBzYXZlIHRoZSBVUkkuICBJZiBJIGNsaWVudCBz ZW5kcyB0aGUgVVJJIGFuZCBkb2VzbuKAmXQgdmFsaWRhdGUsIGl04oCZcyB3ZWlyZCwgYnV0IG5v dCB3cm9uZy4NCg0KV2UgY2FuIGRlY2lkZSB0byBwcm9oaWJpdCBpdC4gIEJ1dCB3ZSBkb27igJl0 IHJlYWxseSBoYXZlIGEganVzdGlmaWNhdGlvbi4NCg0KQnJpYW4NCg0KT24gQXVnIDIzLCAyMDIx LCBhdCA1OjQ0IFBNLCBDYXJvbiwgR3V5IDxnLmNhcm9uQGJlbGwuY2E8bWFpbHRvOmcuY2Fyb25A YmVsbC5jYT4+IHdyb3RlOg0KDQpJIGFncmVlIHRoYXQgYWNjb21tb2RhdGluZyB0aGlzIGNvbW1l bnQgd291bGQgcmVxdWlyZSBkZWVwZXIgWE1MIGNoYW5nZXMuDQoNCklmIHdlIGRvIG5vdCB3YW50 IHRvIGdvIHRoZXJlLCBJIHRoaW5rIHRoZSBkcmFmdCBzaG91bGQgYmUgY2xlYXIgdGhhdCB0aGVy ZSBpcyBubyB1c2VjYXNlIGZvciBzZW5kaW5nIDxwbGFubmVkQ2hhbmdlPiBvdXRzaWRlIG9mIGEg bG9jYXRpb24gdmFsaWRhdGlvbiByZXF1ZXN0IGFuZCBhcyBzdWNoLCBzaG91bGQgbm9ybWF0aXZl bHkgcmVjb21tZW5kIG5vdCBkb2luZyBzby4NCg0KSSBkbyBub3QgYWdyZWUgdGhhdCBhIExvU1Qg c2VydmVyIHJlY2VpdmluZyA8cGxhbm5lZENoYW5nZT4gb3V0c2lkZSBvZiBhIGxvY2F0aW9uIHZh bGlkYXRpb24gcmVxdWVzdCB3b3VsZCByZXRhaW4gdGhlIFVSSSBhbmQgc2VuZCBub3RpZmljYXRp b24gaWYgdGhlIHJlY29yZCBjaGFuZ2VkIGFmdGVyd2FyZC4gSSB0aGluayB0aGlzIHdvdWxkIGNy ZWF0ZSBoYXZvYyBvbiB0aGUgY2xpZW504oCZIHNpZGUuDQoNClRoYW5rcywNCg0KR3V5DQoNCkRl IDogQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0PG1haWx0bzpickBicmlhbnJvc2VuLm5l dD4+DQpFbnZvecOpIDogMjMgYW/Du3QgMjAyMSAxNzoyMg0Kw4AgOiBDYXJvbiwgR3V5IDxnLmNh cm9uQGJlbGwuY2E8bWFpbHRvOmcuY2Fyb25AYmVsbC5jYT4+DQpDYyA6IGVjcml0QGlldGYub3Jn PG1haWx0bzplY3JpdEBpZXRmLm9yZz4NCk9iamV0IDogW0VYVF1SZTogbG9zdC1wbGFubmVkLWNo YW5nZXMtMDQ6IHBsYW5uZWRDaGFuZ2UgYm91bmQgdG8gdmFsaWRhdGVMb2NhdGlvbj8NCg0KdmFs aWRhdGVMb2NhdGlvbiBpcyBhbiBhdHRyaWJ1dGUsIG5vdCBhbiBlbGVtZW50LCBzbyBJIGNhbuKA mXQgZXh0ZW5kIGl0Lg0KDQpUaGVyZSBpc27igJl0IGFuIGFjdHVhbCByZXF1aXJlbWVudCB0byB0 aWUgcGxhbm5lZENoYW5nZSB0byB2YWxpZGF0ZUxvY2F0aW9uLiAgSXQgbWF5IG5vdCBtYWtlIGEg bG90IG9mIHNlbnNlLCBidXQgaWYgeW91IGRpZCBpdCwgdGhlIExvU1Qgc2VydmVyIHdvdWxkIG5v dCByZXR1cm4gdmFsaWRhdGlvbiBkYXRhLCB3b3VsZCByZXRhaW4gdGhlIFVSSSBhbmQgd291bGQg c2VuZCB0aGUgbm90aWZpY2F0aW9uIGlmIHRoZSByZWNvcmQgY2hhbmdlZC4gIE5vdGUgbXkgdGV4 dCB0aGF0IHRoZSBMb1NUIHNlcnZlciBkb2VzbuKAmXQgc3RvcmUgdGhlIExJIC0gdGhlIG5vdGlm aWNhdGlvbiBpcyDigJxzb21ldGhpbmcgY2hhbmdlZOKAnSBub3Qg4oCcd2hhdCB5b3Ugc2VudCBp cyBndWFyYW50ZWVkIHRvIGJlIGludmFsaWTigJ0gb3IgZXZlbiDigJxvbmUgb3IgbW9yZSBvZiB0 aGUgZWxlbWVudHMgeW91IHNlbnQgY2hhbmdlZCIuICBJIHRob3VnaHQgYWJvdXQgY2hhbmdpbmcg dGhlIG5hbWUgb2YgdGhlIG5vdGlmaWNhdGlvbiwgYnV0IEkgZGlkbuKAmXQgZG8gdGhhdC4gIFRo ZSBwcmFjdGljYWwgdXNlIGNhc2UgcmVtYWlucyB0aGUgc2FtZS4NCg0KQnJpYW4NCg0KDQpPbiBB dWcgMjMsIDIwMjEsIGF0IDU6MDcgUE0sIENhcm9uLCBHdXkgPGcuY2Fyb25AYmVsbC5jYTxtYWls dG86Zy5jYXJvbkBiZWxsLmNhPj4gd3JvdGU6DQoNCk5vdCBhbGwgTG9TVCBzZXJ2ZXIgaW1wbGVt ZW50YXRpb25zIHBlcmZvcm0gbG9jYXRpb24gdmFsaWRhdGlvbnMuIFdoZW4gbG9jYXRpb24gdmFs aWRhdGlvbiBpcyByZXF1ZXN0ZWQgYnkgdGhlIGNsaWVudCwgaXQgYWRkcyB0aGUg4oCcdmFsaWRh dGVMb2NhdGlvbuKAnSBhdHRyaWJ1dGUgdG8gdGhlIDxmaW5kU2VydmljZT4gZWxlbWVudC4NCg0K U28gdGhlIHF1ZXN0aW9uIGlzOiBTaG91bGQg4oCccGxhbm5lZENoYW5nZeKAnSBiZSBib3VuZCB0 byDigJx2YWxpZGF0ZUxvY2F0aW9u4oCdPw0KDQpJZiB5b3UgYmVsaWV2ZSBub3QsIHdoYXQgd291 bGQgYmUgdGhlIGV4cGVjdGVkIGJlaGF2aW91ciBvZiBhIExvU1Qgc2VydmVyIHJlY2VpdmluZyBh IDxwbGFubmVkQ2hhbmdlPiBlbGVtZW50IG91dHNpZGUgb2YgYSB2YWxpZGF0aW9uIHJlcXVlc3Q/ DQoNClRoYW5rcywNCg0KR3V5DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpF eHRlcm5hbCBFbWFpbDogUGxlYXNlIHVzZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQg YXR0YWNobWVudHMgLyBDb3VycmllbCBleHRlcm5lOiBTb3lleiBwcnVkZW50IGF2ZWMgbGVzIGxp ZW5zIGV0IGRvY3VtZW50cyBqb2ludHMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkV4dGVybmFsIEVtYWlsOiBQbGVhc2UgdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxpbmtz IGFuZCBhdHRhY2htZW50cyAvIENvdXJyaWVsIGV4dGVybmU6IFNveWV6IHBydWRlbnQgYXZlYyBs ZXMgbGllbnMgZXQgZG9jdW1lbnRzIGpvaW50cw0K --_000_c3f5a623984e4bef9ddf14b1ae2ba273bellca_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5t c29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFt ZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpz cGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0 ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUi1DQSIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGZ1cnRoZXIgdGhpbmsgdGhhdCBhIHNlcnZlciBzaG91 bGQgaWdub3JlICZsdDtwbGFubmVkQ2hhbmdlJmd0OyBpZiBzZW50IG91dHNpZGUgYSBsb2NhdGlv biB2YWxpZGF0aW9uIHJlcXVlc3Qgb3IsIGF0IHRoZSBtaW5pbXVtLA0KIHNlbmQgYSDigJx1cmlO b3RTdG9yZWTigJ0gaW4gdGhlIHJlc3BvbnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkd1 eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5EZSZuYnNwOzo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBFY3JpdCAmbHQ7ZWNyaXQtYm91bmNl c0BpZXRmLm9yZyZndDsNCjxiPkRlIGxhIHBhcnQgZGU8L2I+IENhcm9uLCBHdXk8YnI+DQo8Yj5F bnZvecOpJm5ic3A7OjwvYj4gMjMgYW/Du3QgMjAyMSAxODowMTxicj4NCjxiPsOAJm5ic3A7Ojwv Yj4gQnJpYW4gUm9zZW4gJmx0O2JyQGJyaWFucm9zZW4ubmV0Jmd0Ozxicj4NCjxiPkNjJm5ic3A7 OjwvYj4gZWNyaXRAaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFtFWFRdUmU6IFtF Y3JpdF0gbG9zdC1wbGFubmVkLWNoYW5nZXMtMDQ6IHBsYW5uZWRDaGFuZ2UgYm91bmQgdG8gdmFs aWRhdGVMb2NhdGlvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkEgTG9TVCBjbGllbnQgdGhhdCBzZW5kcyByb3V0aW5nIHJlcXVl c3RzIHRvIHRoZSBzZXJ2ZXIgd291bGQgcmVjZWl2ZSwgd2F5IGFmdGVyIGNhbGxzIGhhdmUgYmVl biBkZWxpdmVyZWQsIGEgbm90aWZpY2F0aW9uDQogd2l0aCBhICZsdDtsb2NhdGlvbkludmFsaWQm Z3Q7IGJvZHkuIFdoYXQgd291bGQgaXQgZG8gd2l0aCB0aGlzPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5NYWtlcyBubyBz ZW5zZSB0byBtZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+R3V5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkZSIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ IEJyaWFuIFJvc2VuICZsdDs8YSBocmVmPSJtYWlsdG86YnJAYnJpYW5yb3Nlbi5uZXQiPmJyQGJy aWFucm9zZW4ubmV0PC9hPiZndDsNCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiAyMyBhb8O7 dCAyMDIxIDE3OjU1PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBDYXJvbiwgR3V5ICZsdDs8YSBocmVm PSJtYWlsdG86Zy5jYXJvbkBiZWxsLmNhIj5nLmNhcm9uQGJlbGwuY2E8L2E+Jmd0Ozxicj4NCjxi PkNjJm5ic3A7OjwvYj4gPGEgaHJlZj0ibWFpbHRvOmVjcml0QGlldGYub3JnIj5lY3JpdEBpZXRm Lm9yZzwvYT48YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFtFWFRdUmU6IGxvc3QtcGxhbm5lZC1j aGFuZ2VzLTA0OiBwbGFubmVkQ2hhbmdlIGJvdW5kIHRvIHZhbGlkYXRlTG9jYXRpb24/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb27igJl0IHVuZGVy c3RhbmQgdGhlIHJlYXNvbmluZyBvbiDigJxjcmVhdGluZyBoYXZvY+KAnS4gJm5ic3A7SSBkb27i gJl0IGtub3cgd2h5IGEgY2xpZW50IHdvdWxkIGV2ZXIgZG8gaXQsIGJ1dCBpdCDigJx3b3Jrc+KA nSBpbiB0aGF0IHRoZSBzZXJ2ZXIgZG9lc27igJl0IGhhdmUgdG8gdmFsaWRhdGUgdG8gc2F2ZSB0 aGUgVVJJLiAmbmJzcDtJZiBJIGNsaWVudCBzZW5kcyB0aGUgVVJJIGFuZCBkb2VzbuKAmXQgdmFs aWRhdGUsIGl04oCZcyB3ZWlyZCwNCiBidXQgbm90IHdyb25nLjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgY2FuIGRlY2lkZSB0byBwcm9oaWJpdCBpdC4g Jm5ic3A7QnV0IHdlIGRvbuKAmXQgcmVhbGx5IGhhdmUgYSBqdXN0aWZpY2F0aW9uLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CcmlhbjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEF1ZyAyMywgMjAyMSwgYXQgNTo0NCBQTSwgQ2Fyb24s IEd1eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmcuY2Fyb25AYmVsbC5jYSI+Zy5jYXJvbkBiZWxsLmNh PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUg dGhhdCBhY2NvbW1vZGF0aW5nIHRoaXMgY29tbWVudCB3b3VsZCByZXF1aXJlIGRlZXBlciBYTUwg Y2hhbmdlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SWYgd2Ug ZG8gbm90IHdhbnQgdG8gZ28gdGhlcmUsIEkgdGhpbmsgdGhlIGRyYWZ0IHNob3VsZCBiZSBjbGVh ciB0aGF0IHRoZXJlIGlzIG5vIHVzZWNhc2UgZm9yIHNlbmRpbmcgJmx0O3BsYW5uZWRDaGFuZ2Um Z3Q7IG91dHNpZGUgb2YgYSBsb2NhdGlvbiB2YWxpZGF0aW9uDQogcmVxdWVzdCBhbmQgYXMgc3Vj aCwgc2hvdWxkIG5vcm1hdGl2ZWx5IHJlY29tbWVuZCBub3QgZG9pbmcgc28uPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgZG8gbm90IGFncmVlIHRoYXQgYSBMb1NU IHNlcnZlciByZWNlaXZpbmcgJmx0O3BsYW5uZWRDaGFuZ2UmZ3Q7IG91dHNpZGUgb2YgYSBsb2Nh dGlvbiB2YWxpZGF0aW9uIHJlcXVlc3Qgd291bGQgcmV0YWluIHRoZSBVUkkgYW5kIHNlbmQgbm90 aWZpY2F0aW9uIGlmDQogdGhlIHJlY29yZCBjaGFuZ2VkIGFmdGVyd2FyZC4gSSB0aGluayB0aGlz IHdvdWxkIGNyZWF0ZSBoYXZvYyBvbiB0aGUgY2xpZW504oCZIHNpZGUuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+R3V5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4g bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+QnJpYW4NCiBSb3NlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJy QGJyaWFucm9zZW4ubmV0Ij5ickBicmlhbnJvc2VuLm5ldDwvYT4mZ3Q7PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPkVudm95w6kmbmJzcDs6 PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4yMyBh b8O7dCAyMDIxIDE3OjIyPGJyPg0KPGI+w4AmbmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5DYXJvbiwgR3V5ICZsdDs8YSBocmVmPSJtYWls dG86Zy5jYXJvbkBiZWxsLmNhIj5nLmNhcm9uQGJlbGwuY2E8L2E+Jmd0Ozxicj4NCjxiPkNjJm5i c3A7OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOmVjcml0QGlldGYub3JnIj5lY3JpdEBpZXRmLm9yZzwvYT48YnI+DQo8 Yj5PYmpldCZuYnNwOzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPltFWFRdUmU6IGxvc3QtcGxhbm5lZC1jaGFuZ2VzLTA0OiBwbGFubmVkQ2hhbmdl IGJvdW5kIHRvIHZhbGlkYXRlTG9jYXRpb24/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dmFsaWRhdGVM b2NhdGlvbiBpcyBhbiBhdHRyaWJ1dGUsIG5vdCBhbiBlbGVtZW50LCBzbyBJIGNhbuKAmXQgZXh0 ZW5kIGl0LiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGlzbuKAmXQgYW4gYWN0dWFs IHJlcXVpcmVtZW50IHRvIHRpZSBwbGFubmVkQ2hhbmdlIHRvIHZhbGlkYXRlTG9jYXRpb24uICZu YnNwO0l0IG1heSBub3QgbWFrZSBhIGxvdCBvZiBzZW5zZSwgYnV0IGlmIHlvdSBkaWQgaXQsIHRo ZSBMb1NUIHNlcnZlciB3b3VsZCBub3QgcmV0dXJuIHZhbGlkYXRpb24gZGF0YSwgd291bGQgcmV0 YWluIHRoZSBVUkkgYW5kIHdvdWxkIHNlbmQgdGhlIG5vdGlmaWNhdGlvbiBpZiB0aGUNCiByZWNv cmQgY2hhbmdlZC4gJm5ic3A7Tm90ZSBteSB0ZXh0IHRoYXQgdGhlIExvU1Qgc2VydmVyIGRvZXNu 4oCZdCBzdG9yZSB0aGUgTEkgLSB0aGUgbm90aWZpY2F0aW9uIGlzIOKAnHNvbWV0aGluZyBjaGFu Z2Vk4oCdIG5vdCDigJx3aGF0IHlvdSBzZW50IGlzIGd1YXJhbnRlZWQgdG8gYmUgaW52YWxpZOKA nSBvciBldmVuIOKAnG9uZSBvciBtb3JlIG9mIHRoZSBlbGVtZW50cyB5b3Ugc2VudCBjaGFuZ2Vk JnF1b3Q7LiAmbmJzcDtJIHRob3VnaHQgYWJvdXQgY2hhbmdpbmcgdGhlIG5hbWUgb2YNCiB0aGUg bm90aWZpY2F0aW9uLCBidXQgSSBkaWRu4oCZdCBkbyB0aGF0LiAmbmJzcDtUaGUgcHJhY3RpY2Fs IHVzZSBjYXNlIHJlbWFpbnMgdGhlIHNhbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJy aWFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIEF1ZyAyMywgMjAyMSwgYXQgNTowNyBQTSwgQ2Fyb24sIEd1eSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmcuY2Fyb25AYmVsbC5jYSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ Zy5jYXJvbkBiZWxsLmNhPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ob3QgYWxsIExvU1Qg c2VydmVyIGltcGxlbWVudGF0aW9ucyBwZXJmb3JtIGxvY2F0aW9uIHZhbGlkYXRpb25zLiBXaGVu IGxvY2F0aW9uIHZhbGlkYXRpb24gaXMgcmVxdWVzdGVkIGJ5IHRoZSBjbGllbnQsIGl0IGFkZHMg dGhlIOKAnHZhbGlkYXRlTG9jYXRpb27igJ0NCiBhdHRyaWJ1dGUgdG8gdGhlICZsdDtmaW5kU2Vy dmljZSZndDsgZWxlbWVudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U28gdGhlIHF1ZXN0aW9uIGlzOiBTaG91 bGQg4oCccGxhbm5lZENoYW5nZeKAnSBiZSBib3VuZCB0byDigJx2YWxpZGF0ZUxvY2F0aW9u4oCd Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5JZiB5b3UgYmVsaWV2ZSBub3QsIHdoYXQgd291bGQgYmUgdGhlIGV4 cGVjdGVkIGJlaGF2aW91ciBvZiBhIExvU1Qgc2VydmVyIHJlY2VpdmluZyBhICZsdDtwbGFubmVk Q2hhbmdlJmd0OyBlbGVtZW50IG91dHNpZGUgb2YgYSB2YWxpZGF0aW9uIHJlcXVlc3Q/PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+R3V5PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGln bjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzdHJvbmc+PGk+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj5FeHRlcm5hbCBFbWFpbDo8L3NwYW4+PC9pPjwv c3Ryb25nPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxpPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjwvaT48L3NwYW4+PGVt PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+UGxlYXNlDQogdXNlIGNh dXRpb24gd2hlbiBvcGVuaW5nIGxpbmtzIGFuZCBhdHRhY2htZW50cyAvPC9zcGFuPjwvZW0+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PC9pPjwvc3Bhbj48c3Ryb25nPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+Q291cnJpZWwgZXh0ZXJuZTo8 L3NwYW4+PC9pPjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxp PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjwv aT48L3NwYW4+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+U295 ZXoNCiBwcnVkZW50IGF2ZWMgbGVzIGxpZW5zIGV0IGRvY3VtZW50cyBqb2ludHM8L3NwYW4+PC9l bT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0i dGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2Vu dGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHN0cm9uZz48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPkV4dGVybmFsIEVtYWlsOjwvc3Bhbj48L2k+ PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+IFBs ZWFzZSB1c2UgY2F1dGlvbiB3aGVuIG9wZW5pbmcgbGlua3MgYW5kIGF0dGFjaG1lbnRzIC8NCjwv c3Bhbj48L2VtPjxzdHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpi bHVlIj5Db3VycmllbCBleHRlcm5lOjwvc3Bhbj48L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+IFNveWV6IHBydWRlbnQgYXZlYyBsZXMgbGll bnMgZXQgZG9jdW1lbnRzIGpvaW50cw0KPC9zcGFuPjwvZW0+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_c3f5a623984e4bef9ddf14b1ae2ba273bellca_-- From nobody Mon Aug 23 15:06:46 2021 Return-Path: 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 602803A1EB1 for ; Mon, 23 Aug 2021 15:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, 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.20150623.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 Y2qocKkFnAWN for ; Mon, 23 Aug 2021 15:06:27 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 E0ABC3A1E95 for ; Mon, 23 Aug 2021 15:06:26 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id b200so23776761iof.13 for ; Mon, 23 Aug 2021 15:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=9w1LBBCJof8ZxsCkYswLpHtjfHrclPO2OyB7U0mc50s=; b=NgwGKh6Bd077DPVFKtujTocX1kiAqi6JXDVR1e9aJSZpm02QRzNUi/6u2NkRGyv0Rb EF5Mu5Xy93MGFHXi0UfkPmTO6r4+pXWtNRcCSd1ue8xS7l++bfrcKpeJoUEvIwEOv5SV /BNw4quQKPxfd9e+/aAbGXEkNJjo9z29DUj2PtJP8LQ2jNpFvnS2ujTBHJu1MGySSeEi qnGXM5oVlGJu0AHkj4vDYhZfJqZgY3Pd4IYJAdKpBjEP5/H0/3gOglxxtLiDSGhIUm5u ZK8qtHMrKdppyirY48I8f37PNbkwHF6CaHE8jNjHmYEgpkB95YD7jE9sQmuhpPx0TnMg Hp/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=9w1LBBCJof8ZxsCkYswLpHtjfHrclPO2OyB7U0mc50s=; b=o/tuoubVdy0YjHtDY3BhcQBmYVgAFfJzDKCiNQ8lbspiYgDxm8LzT4tmps/G7qXTL7 X3IH9+eT2yeoS7FcTH37ooq2h3j651JzZuUS7CybG8jxTswSBDoC1SPDApMF+VmJUQoP 4/jUmjh0rbw118dPYOcL1PH6TgqCcrbgQ34MeHlJltKaX8PJ2Z5UYf/gvrPheH1HtoN5 rPLOilgAcEHL/W6kV9rfjkTbMIOl2nnENaRlf49LgZn3j5Ea8kuqSU+jrY83mKNli6zi DZhcQCdriJs/jUXHyT5dYl2cYzuzdS2Li/DRjZ2V8nKUOkkuonE+6bdcvtwz5CrVQHns 2jMA== X-Gm-Message-State: AOAM532cuMszDCfxl/eO4ckyjQFbdHjXuIeHsBpji0vBmmfB8/AzdUwn A9cAmOgHrG05WRF93IDhKU3ZIg== X-Google-Smtp-Source: ABdhPJzMLxfm/DC+U8YNc47kwgmZcqzK8OClno2QZpExmZNp6PQNKQ288JDwo/QOmJZjws0Ry8rNYQ== X-Received: by 2002:a6b:f817:: with SMTP id o23mr28341213ioh.205.1629756385473; Mon, 23 Aug 2021 15:06:25 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id l15sm9494243ilt.45.2021.08.23.15.06.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Aug 2021 15:06:24 -0700 (PDT) From: Brian Rosen Message-Id: <7C21F96F-E238-4DA2-82BB-D7C731A84D53@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_0D83DEC3-AF9A-400A-83C3-9F46FED93AD0" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Mon, 23 Aug 2021 18:06:23 -0400 In-Reply-To: <0b81d439e4824aec8a3476906ce5cbc1@bell.ca> Cc: "ecrit@ietf.org" To: "Caron, Guy" References: <8bdda7ea7d004b4591ff715526d93a73@bell.ca> <791ea34f628d48d3addeb04613d5721a@bell.ca> <9158D09E-770E-4E65-BE46-E39060EAC884@brianrosen.net> <0b81d439e4824aec8a3476906ce5cbc1@bell.ca> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 22:06:43 -0000 --Apple-Mail=_0D83DEC3-AF9A-400A-83C3-9F46FED93AD0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Only if it asked for it, per location. It asked for it, it got it. It has NOTHING to do with actual calls. It=E2=80=99s just an = alternative to periodic revalidation for records in the LIS. A more interesting issue is what does a LIS do when it deletes a record = for which a URI is stored in the server. Probably it marks that URI is = OBE. Another possibility is that it stores a new URI that is a catch-all = =E2=80=9Cignore me=E2=80=9D Hmmm. I wonder if we should have an explicit delete. Null URI =3D = delete. Brian > On Aug 23, 2021, at 6:01 PM, Caron, Guy wrote: >=20 > A LoST client that sends routing requests to the server would receive, = way after calls have been delivered, a notification with a = body. What would it do with this? > =20 > Makes no sense to me. > =20 > Guy > =20 > De : Brian Rosen =20 > Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:55 > =C3=80 : Caron, Guy > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to = validateLocation? > =20 > I don=E2=80=99t understand the reasoning on =E2=80=9Ccreating = havoc=E2=80=9D. I don=E2=80=99t know why a client would ever do it, but = it =E2=80=9Cworks=E2=80=9D in that the server doesn=E2=80=99t have to = validate to save the URI. If I client sends the URI and doesn=E2=80=99t = validate, it=E2=80=99s weird, but not wrong. > =20 > We can decide to prohibit it. But we don=E2=80=99t really have a = justification. > =20 > Brian >=20 >=20 > On Aug 23, 2021, at 5:44 PM, Caron, Guy > wrote: > =20 > I agree that accommodating this comment would require deeper XML = changes. > =20 > If we do not want to go there, I think the draft should be clear that = there is no usecase for sending outside of a location = validation request and as such, should normatively recommend not doing = so. > =20 > I do not agree that a LoST server receiving outside of = a location validation request would retain the URI and send notification = if the record changed afterward. I think this would create havoc on the = client=E2=80=99 side. > =20 > Thanks, > =20 > Guy > =20 > De : Brian Rosen >=20 > Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:22 > =C3=80 : Caron, Guy > > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to = validateLocation? > =20 > validateLocation is an attribute, not an element, so I can=E2=80=99t = extend it. =20 > =20 > There isn=E2=80=99t an actual requirement to tie plannedChange to = validateLocation. It may not make a lot of sense, but if you did it, = the LoST server would not return validation data, would retain the URI = and would send the notification if the record changed. Note my text = that the LoST server doesn=E2=80=99t store the LI - the notification is = =E2=80=9Csomething changed=E2=80=9D not =E2=80=9Cwhat you sent is = guaranteed to be invalid=E2=80=9D or even =E2=80=9Cone or more of the = elements you sent changed". I thought about changing the name of the = notification, but I didn=E2=80=99t do that. The practical use case = remains the same. > =20 > Brian >=20 >=20 >=20 > On Aug 23, 2021, at 5:07 PM, Caron, Guy > wrote: > =20 > Not all LoST server implementations perform location validations. When = location validation is requested by the client, it adds the = =E2=80=9CvalidateLocation=E2=80=9D attribute to the = element. > =20 > So the question is: Should =E2=80=9CplannedChange=E2=80=9D be bound to = =E2=80=9CvalidateLocation=E2=80=9D? > =20 > If you believe not, what would be the expected behaviour of a LoST = server receiving a element outside of a validation = request? > =20 > Thanks, > =20 > Guy > =20 > External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints > =20 > External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints --Apple-Mail=_0D83DEC3-AF9A-400A-83C3-9F46FED93AD0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Only = if it asked for it, per location.  It asked for it, it got it.

It has NOTHING to do = with actual calls.  It=E2=80=99s just an alternative to periodic = revalidation for records in the LIS.

A more interesting issue is what does a = LIS do when it deletes a record for which a URI is stored in the server. =  Probably it marks that URI is OBE. Another possibility is that it = stores a new URI that is a catch-all =E2=80=9Cignore me=E2=80=9D

Hmmm.  I wonder if = we should have an explicit delete.  Null URI =3D delete.

Brian


On Aug 23, 2021, at 6:01 PM, Caron, Guy = <g.caron@bell.ca> = wrote:

A LoST client that = sends routing requests to the server would receive, way after calls have = been delivered, a notification with a <locationInvalid> body. What = would it do with this?
 
Makes no sense to me.
 
Guy
 
De : Brian = Rosen <br@brianrosen.net> 
Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:55
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : ecrit@ietf.org
Objet : [EXT]Re: = lost-planned-changes-04: plannedChange bound to validateLocation?
 
I don=E2=80=99t understand the reasoning = on =E2=80=9Ccreating havoc=E2=80=9D.  I don=E2=80=99t know why a = client would ever do it, but it =E2=80=9Cworks=E2=80=9D in that the = server doesn=E2=80=99t have to validate to save the URI.  If I = client sends the URI and doesn=E2=80=99t validate, it=E2=80=99s weird, = but not wrong.
 
We can decide to prohibit it.  But = we don=E2=80=99t really have a justification.
 
Brian


On Aug 23, = 2021, at 5:44 PM, Caron, Guy <g.caron@bell.ca> wrote:
 
I agree that = accommodating this comment would require deeper XML changes.
 
If we do not want to go = there, I think the draft should be clear that there is no usecase for = sending <plannedChange> outside of a location validation request = and as such, should normatively recommend not doing so.
 
I do not agree that a = LoST server receiving <plannedChange> outside of a location = validation request would retain the URI and send notification if the = record changed afterward. I think this would create havoc on the = client=E2=80=99 side.
 
Thanks,
 
Guy
 
De : Brian Rosen <br@brianrosen.net> 
Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:22
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : ecrit@ietf.org
Objet : [EXT]Re: = lost-planned-changes-04: plannedChange bound to = validateLocation?
 
validateLocation is an attribute, not an element, so = I can=E2=80=99t extend it.  
 
There isn=E2=80=99t an actual requirement to tie = plannedChange to validateLocation.  It may not make a lot of sense, = but if you did it, the LoST server would not return validation data, = would retain the URI and would send the notification if the record = changed.  Note my text that the LoST server doesn=E2=80=99t store = the LI - the notification is =E2=80=9Csomething changed=E2=80=9D not = =E2=80=9Cwhat you sent is guaranteed to be invalid=E2=80=9D or even = =E2=80=9Cone or more of the elements you sent changed".  I thought = about changing the name of the notification, but I didn=E2=80=99t do = that.  The practical use case remains the same.
 
Brian



On Aug 23, 2021, at 5:07 = PM, Caron, Guy <g.caron@bell.ca> wrote:
 
Not all LoST server = implementations perform location validations. When location validation = is requested by the client, it adds the =E2=80=9CvalidateLocation=E2=80=9D= attribute to the <findService> element.
 
So the question is: Should = =E2=80=9CplannedChange=E2=80=9D be bound to = =E2=80=9CvalidateLocation=E2=80=9D?
 
If you believe not, what would be the = expected behaviour of a LoST server receiving a <plannedChange> = element outside of a validation request?
 
Thanks,
 
Guy
 
External Email: Please use caution = when opening links and attachments / Courriel externe: Soyez prudent avec = les liens et documents joints
 
External Email: Please use caution when = opening links and attachments / Courriel externe: Soyez prudent avec les = liens et documents = joints

= --Apple-Mail=_0D83DEC3-AF9A-400A-83C3-9F46FED93AD0-- From nobody Mon Aug 23 15:08:40 2021 Return-Path: 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 298573A1E90 for ; Mon, 23 Aug 2021 15:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=bell.ca 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 DD2Go2DSXNen for ; Mon, 23 Aug 2021 15:08:31 -0700 (PDT) Received: from ESA2-Wyn.bell.ca (esa2-wyn.bell.ca [67.69.243.180]) (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 ADDC23A1E9F for ; Mon, 23 Aug 2021 15:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1629756511; x=1661292511; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=Re/vl2l2D9N5OJ3/TCopgX9DbsXPtLLZ964ylnNxA4A=; b=RNu/f/PWnub1h3RdxWhb9ZAWs6N8BbEPYc+e2cD+5KwsiiCGoOEX8GOd RLKzS8mKGPWjd7NmxFspsYYVffPW3XalGfpn9qnIsqPLk4QtJvvafP87Z oFvMFY+sHryIWTV2UtuHanaywUfrgNBzIfSSFAf4k4sjuxQHjqsTV4SB3 V23jpeFZyziFpwhew5dot7QuAWerY11oWIrR0IhhxtlCab+bkRcMS9Ze4 CLqEQk8nZaWHfbEyQrxjX0qssLlzbYlfQG51iaEcr8I1P+W0vQA2W23y9 8sJ2zz18s2DGZ0SR4XWjhHPxl/pFipVSrGzuZaYHArxF+2VaZpk5ytG4q A==; IronPort-SDR: U5cj5K3eTgUI4dVC1UMQVprSnaR4NWqQ+GY4eBybtI4tYKqYA0hpjv4ZK0AonMXRFSjpgy/I5s Jd3iF7cEoqpw== Received: from dm5cch-d01.bellca.int.bell.ca (HELO DG4MBX03-WYN.bell.corp.bce.ca) ([198.235.102.31]) by esa02corp-wyn.bell.corp.bce.ca with ESMTP; 23 Aug 2021 18:08:30 -0400 Received: from DG12MBX03-WYN.bell.corp.bce.ca (142.182.18.48) by DG4MBX03-WYN.bell.corp.bce.ca (142.182.18.29) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 23 Aug 2021 18:08:30 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX03-WYN.bell.corp.bce.ca (142.182.18.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Mon, 23 Aug 2021 18:08:30 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Mon, 23 Aug 2021 18:08:30 -0400 From: "Caron, Guy" To: Randall Gellens CC: Brian Rosen , "ecrit@ietf.org" Thread-Topic: [EXT]Re: [Ecrit] lost-planned-changes-04: Locations are not always invalidated Thread-Index: AdeYZFeQ2SDl+s67TUyTfs68kd40mwAJNZoAAAhHdZD//8BwAIAAPtdg Date: Mon, 23 Aug 2021 22:08:29 +0000 Message-ID: References: <8508C216-7FF5-41D2-A78D-EBF475F83C7F@randy.pensive.org> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.79] Content-Type: multipart/alternative; boundary="_000_e93fdfffe6614bd2897f77bb3b5b6d2dbellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: Locations are not always invalidated X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 22:08:38 -0000 --_000_e93fdfffe6614bd2897f77bb3b5b6d2dbellca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGFrZW4gZnJvbSBzZWN0aW9uIDM6DQoNClRoZSBVUkkgd2lsbCBiZSBzdG9yZWQgYnkgdGhlIHNl cnZlciBhZ2FpbnN0IHRoZSBsb2NhdGlvbiBpbiB0aGUgcmVxdWVzdCBmb3Igc3Vic2VxdWVudCB1 c2Ugd2l0aCB0aGUgbm90aWZpY2F0aW9uIGZ1bmN0aW9uIGRlZmluZWQgIGJlbG93Lg0KDQpHdXkN Cg0KRGUgOiBSYW5kYWxsIEdlbGxlbnMgPHJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmc+DQpFbnZv ecOpIDogMjMgYW/Du3QgMjAyMSAxNzo1MQ0Kw4AgOiBDYXJvbiwgR3V5IDxnLmNhcm9uQGJlbGwu Y2E+DQpDYyA6IEJyaWFuIFJvc2VuIDxickBicmlhbnJvc2VuLm5ldD47IGVjcml0QGlldGYub3Jn DQpPYmpldCA6IFtFWFRdUmU6IFtFY3JpdF0gbG9zdC1wbGFubmVkLWNoYW5nZXMtMDQ6IExvY2F0 aW9ucyBhcmUgbm90IGFsd2F5cyBpbnZhbGlkYXRlZA0KDQoNCkkgZG9uJ3Qga25vdyB0aGF0IHRo YXQncyB0cnVlLiBNeSBpbnRlcnByZXRhdGlvbiBpcyB0aGF0IGEgTG9TVCBzZXJ2ZXIgbWlnaHQg bWFpbnRhaW4gYSBsaXN0IG9mIFVSSXMgYnV0IG5vdCBhc3NvY2lhdGUgZWFjaCB3aXRoIHNwZWNp ZmljIGxvY2F0aW9uIHJlY29yZHMsIGFuZCB3aGVuIHRoZXJlIGlzIGEgY2hhbmdlLCBpdCB3b3Vs ZCB0aGVuIHNlbmQgYSBub3RpZmljYXRpb24gdG8gZWFjaCBzdG9yZWQgVVJJLiBUaGUgbG9jYXRp b24gdGhhdCB3YXMgdXNlZCBmb3IgdGhlIG9yaWdpbmFsIHZhbGlkYXRpb24gcXVlcnkgbWlnaHQg bm90IGJlIGltcGFjdGVkLg0KDQotLVJhbmRhbGwNCg0KT24gMjMgQXVnIDIwMjEsIGF0IDE0OjQ4 LCBDYXJvbiwgR3V5IHdyb3RlOg0KDQpJIHRoaW5rIHRoZXNlIGxvY2F0aW9ucyBhcmUgaW1wYWN0 ZWQgaW4gb25lIHdheSBvciB0aGUgb3RoZXIgb3RoZXJ3aXNlLCB0aGUgTG9TVCBzZXJ2ZXIgd291 bGQgbm90IGJlIGFibGUgdG8gZGV0ZXJtaW5lIHRoYXQgaXQgc2hvdWxkIHNlbmQgbm90aWZpY2F0 aW9uczsgdGhleSBtYXkganVzdCBub3QgYmVjb21lIGludmFsaWQgaW4gdGhlIExvU1Qgc2Vuc2Uu DQoNCg0KDQpUaGFua3MsDQoNCg0KDQpHdXkNCg0KDQoNCg0KDQoNCg0KRGUgOiBSYW5kYWxsIEdl bGxlbnMgPHJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmc8bWFpbHRvOnJnK2lldGZAcmFuZHkucGVu c2l2ZS5vcmc+Pg0KRW52b3nDqSA6IDIzIGFvw7t0IDIwMjEgMTc6NDINCsOAIDogQ2Fyb24sIEd1 eSA8Zy5jYXJvbkBiZWxsLmNhPG1haWx0bzpnLmNhcm9uQGJlbGwuY2E+Pg0KQ2MgOiBCcmlhbiBS b3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ8bWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0Pj47IGVjcml0 QGlldGYub3JnPG1haWx0bzplY3JpdEBpZXRmLm9yZz4NCk9iamV0IDogW0VYVF1SZTogW0Vjcml0 XSBsb3N0LXBsYW5uZWQtY2hhbmdlcy0wNDogTG9jYXRpb25zIGFyZSBub3QgYWx3YXlzIGludmFs aWRhdGVkDQoNCg0KDQpVc2luZyAnaW1wYWN0ZWQnIGlzIG5vdCByZWFsbHkgYmV0dGVyLCBiZWNh dXNlIGEgbG9jYXRpb24gbWF5IG9yIG1heSBub3QgYWN0dWFsbHkgYmUgaW1wYWN0ZWQuIElmIHdl IGdvIGRvd24gdGhlIHBhdGggb2YgcHJlY2lzZSBuYW1lcyB3ZSBzaG91bGQgdXNlIHNvbWV0aGlu ZyBzdWNoIGFzICdsb2NhdGlvblBvdGVudGlhbGx5SW52YWxpZGF0ZWQnLCB3aGljaCBzZWVtcyBz aWxseS4gSSB0aGluayB0aGUgZHJhZnQgbWFrZXMgaXQgY2xlYXIgKGVzcGVjaWFsbHkgd2l0aCBt eSBzdWdnZXN0ZWQgZWRpdHMpIHRoYXQgYSBub3RpZmllZCBsb2NhdGlvbiBpcyBwb3RlbnRpYWxs eSBpbnZhbGlkYXRlZC4NCg0KLS1SYW5kYWxsDQoNCk9uIDIzIEF1ZyAyMDIxLCBhdCAxNDoyNCwg Q2Fyb24sIEd1eSB3cm90ZToNCg0KVGhpcyBuZXcgdmVyc2lvbiBpbnRyb2R1Y2VzIHZhcmlhYmls aXR5IGluIHdoZXRoZXIgYSBsb2NhdGlvbiBpcyBpbmRlZWQgaW52YWxpZGF0ZWQgb3Igbm90IGJ5 IGEgY2hhbmdlLCB3aGljaCBJIGFncmVlIHdpdGguDQoNCg0KDQpHaXZlbiB0aGlzLCB0aGUgbmFt ZXMg4oCcbG9jYXRpb25JbnZhbGlkYXRlZOKAnSBhbmQg4oCcaW52YWxpZGF0ZWRBc09m4oCdIHNl ZW0gbWlzbGVhZGluZy4gU2hvdWxkIOKAnGludmFsaWRhdGVk4oCdIGJlIGNoYW5nZWQgdG8gc29t ZXRoaW5nIGxpa2Ug4oCcSW1wYWN0ZWTigJ0/DQoNCg0KDQpUaGFua3MsDQoNCg0KDQpHdXkNCg0K DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K RWNyaXQgbWFpbGluZyBsaXN0DQpFY3JpdEBpZXRmLm9yZzxtYWlsdG86RWNyaXRAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoNCkV4dGVybmFsIEVtYWlsOiBQbGVhc2UgdXNlIGNh dXRpb24gd2hlbiBvcGVuaW5nIGxpbmtzIGFuZCBhdHRhY2htZW50cyAvIENvdXJyaWVsIGV4dGVy bmU6IFNveWV6IHBydWRlbnQgYXZlYyBsZXMgbGllbnMgZXQgZG9jdW1lbnRzIGpvaW50cw0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRXh0ZXJuYWwgRW1haWw6IFBsZWFzZSB1 c2UgY2F1dGlvbiB3aGVuIG9wZW5pbmcgbGlua3MgYW5kIGF0dGFjaG1lbnRzIC8gQ291cnJpZWwg ZXh0ZXJuZTogU295ZXogcHJ1ZGVudCBhdmVjIGxlcyBsaWVucyBldCBkb2N1bWVudHMgam9pbnRz DQo= --_000_e93fdfffe6614bd2897f77bb3b5b6d2dbellca_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJ e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBw dCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUi1DQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5UYWtlbiBmcm9tIHNlY3Rpb24gMzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5UaGUgVVJJIHdpbGwgYmUg c3RvcmVkIGJ5IHRoZSBzZXJ2ZXIgYWdhaW5zdCB0aGUgbG9jYXRpb24gaW4gdGhlIHJlcXVlc3Qg Zm9yIHN1YnNlcXVlbnQgdXNlIHdpdGggdGhlIG5vdGlmaWNhdGlvbiBmdW5jdGlvbiBkZWZpbmVk Jm5ic3A7IGJlbG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+R3V5 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkRlJm5ic3A7Ojwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFJhbmRhbGwgR2VsbGVucyAmbHQ7cmcm IzQzO2lldGZAcmFuZHkucGVuc2l2ZS5vcmcmZ3Q7DQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7Ojwv Yj4gMjMgYW/Du3QgMjAyMSAxNzo1MTxicj4NCjxiPsOAJm5ic3A7OjwvYj4gQ2Fyb24sIEd1eSAm bHQ7Zy5jYXJvbkBiZWxsLmNhJmd0Ozxicj4NCjxiPkNjJm5ic3A7OjwvYj4gQnJpYW4gUm9zZW4g Jmx0O2JyQGJyaWFucm9zZW4ubmV0Jmd0OzsgZWNyaXRAaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZu YnNwOzo8L2I+IFtFWFRdUmU6IFtFY3JpdF0gbG9zdC1wbGFubmVkLWNoYW5nZXMtMDQ6IExvY2F0 aW9ucyBhcmUgbm90IGFsd2F5cyBpbnZhbGlkYXRlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPkkgZG9uJ3Qga25vdyB0aGF0IHRoYXQncyB0cnVlLiBNeSBpbnRlcnBy ZXRhdGlvbiBpcyB0aGF0IGEgTG9TVCBzZXJ2ZXIgbWlnaHQgbWFpbnRhaW4gYSBsaXN0IG9mIFVS SXMgYnV0IG5vdCBhc3NvY2lhdGUgZWFjaCB3aXRoIHNwZWNpZmljIGxvY2F0aW9uIHJlY29yZHMs IGFuZCB3aGVuIHRoZXJlIGlzIGEgY2hhbmdlLCBpdCB3b3VsZCB0aGVuIHNlbmQgYSBub3RpZmlj YXRpb24NCiB0byBlYWNoIHN0b3JlZCBVUkkuIFRoZSBsb2NhdGlvbiB0aGF0IHdhcyB1c2VkIGZv ciB0aGUgb3JpZ2luYWwgdmFsaWRhdGlvbiBxdWVyeSBtaWdodCBub3QgYmUgaW1wYWN0ZWQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPi0tUmFuZGFsbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5P biAyMyBBdWcgMjAyMSwgYXQgMTQ6NDgsIENhcm9uLCBHdXkgd3JvdGU6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgIzc3Nzc3NyAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0O21hcmdpbi1s ZWZ0OjBjbTttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbToz Ljc1cHQiPg0KPGRpdiBpZD0iQTlCMzU5NkQtNDc2OS00RDBCLTk2OTgtNkNBNTc2RDA1ODFEIj4N CjxkaXY+DQo8cD48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgdGhpbmsgdGhlc2UgbG9jYXRpb25zIGFyZSBpbXBh Y3RlZCBpbiBvbmUgd2F5IG9yIHRoZSBvdGhlciBvdGhlcndpc2UsIHRoZSBMb1NUIHNlcnZlciB3 b3VsZCBub3QgYmUgYWJsZSB0byBkZXRlcm1pbmUgdGhhdCBpdCBzaG91bGQgc2VuZA0KIG5vdGlm aWNhdGlvbnM7IHRoZXkgbWF5IGp1c3Qgbm90IGJlY29tZSBpbnZhbGlkIGluIHRoZSBMb1NUIHNl bnNlLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3 Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhhbmtzLDwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3Nzci PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+R3V5PC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iY29sb3I6Izc3Nzc3Nzttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHA+PGI+PHNwYW4gbGFuZz0i RlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+IFJhbmRhbGwgR2VsbGVucyAmbHQ7PC9z cGFuPjxhIGhyZWY9Im1haWx0bzpyZyYjNDM7aWV0ZkByYW5keS5wZW5zaXZlLm9yZyI+PHNwYW4g bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+cmcmIzQzO2lldGZAcmFuZHkucGVuc2l2ZS5vcmc8L3NwYW4+ PC9hPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+Jmd0Ow0KPGJyPg0K PGI+RW52b3nDqSZuYnNwOzo8L2I+IDIzIGFvw7t0IDIwMjEgMTc6NDI8YnI+DQo8Yj7DgCZuYnNw Ozo8L2I+IENhcm9uLCBHdXkgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86Zy5jYXJvbkBiZWxs LmNhIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5nLmNhcm9uQGJlbGwuY2E8L3NwYW4+PC9h PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+Jmd0Ozxicj4NCjxiPkNj Jm5ic3A7OjwvYj4gQnJpYW4gUm9zZW4gJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86YnJAYnJp YW5yb3Nlbi5uZXQiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmJyQGJyaWFucm9zZW4ubmV0 PC9zcGFuPjwvYT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPiZndDs7 DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmVjcml0QGlldGYub3JnIj48c3BhbiBsYW5nPSJGUiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5lY3JpdEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRlIiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNzc3Nzc3Ij48YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFtFWFRdUmU6IFtF Y3JpdF0gbG9zdC1wbGFubmVkLWNoYW5nZXMtMDQ6IExvY2F0aW9ucyBhcmUgbm90IGFsd2F5cyBp bnZhbGlkYXRlZDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3 NzciPlVzaW5nICdpbXBhY3RlZCcgaXMgbm90IHJlYWxseSBiZXR0ZXIsIGJlY2F1c2UgYSBsb2Nh dGlvbiBtYXkgb3IgbWF5IG5vdCBhY3R1YWxseSBiZSBpbXBhY3RlZC4gSWYgd2UgZ28gZG93biB0 aGUgcGF0aCBvZiBwcmVjaXNlIG5hbWVzIHdlIHNob3VsZCB1c2Ugc29tZXRoaW5nIHN1Y2ggYXMg J2xvY2F0aW9uUG90ZW50aWFsbHlJbnZhbGlkYXRlZCcsDQogd2hpY2ggc2VlbXMgc2lsbHkuIEkg dGhpbmsgdGhlIGRyYWZ0IG1ha2VzIGl0IGNsZWFyIChlc3BlY2lhbGx5IHdpdGggbXkgc3VnZ2Vz dGVkIGVkaXRzKSB0aGF0IGEgbm90aWZpZWQgbG9jYXRpb24gaXMgcG90ZW50aWFsbHkgaW52YWxp ZGF0ZWQuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij4tLVJhbmRhbGw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPk9uIDIzIEF1 ZyAyMDIxLCBhdCAxNDoyNCwgQ2Fyb24sIEd1eSB3cm90ZTo8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICM3Nzc3NzcgMS41cHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA0LjBwdDttYXJnaW4tbGVmdDowY207bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206My43NXB0Ij4NCjxkaXYgaWQ9IjkyM0VENEMyLTZG NzItNEFDQy05NjVFLTMzMUQ0QjQ1NDY3RCI+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGlz IG5ldyB2ZXJzaW9uIGludHJvZHVjZXMgdmFyaWFiaWxpdHkgaW4gd2hldGhlciBhIGxvY2F0aW9u IGlzIGluZGVlZCBpbnZhbGlkYXRlZCBvciBub3QgYnkgYSBjaGFuZ2UsIHdoaWNoIEkgYWdyZWUg d2l0aC48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjoj Nzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkdpdmVuIHRo aXMsIHRoZSBuYW1lcyDigJxsb2NhdGlvbkludmFsaWRhdGVk4oCdIGFuZCDigJxpbnZhbGlkYXRl ZEFzT2bigJ0gc2VlbSBtaXNsZWFkaW5nLiBTaG91bGQg4oCcaW52YWxpZGF0ZWTigJ0gYmUgY2hh bmdlZCB0byBzb21ldGhpbmcgbGlrZSDigJxJbXBhY3RlZOKAnT88L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rcyw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkd1eTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xv cjojNzc3Nzc3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjNzc3Nzc3IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQ7bWFy Z2luLWxlZnQ6MGNtO21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjMuNzVwdCI+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCkVjcml0IG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48 YSBocmVmPSJtYWlsdG86RWNyaXRAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5FY3JpdEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 Izc3Nzc3NyI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZWNyaXQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZWNyaXQ8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50 ZXIiPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAw JSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cD48c3Ryb25nPjxpPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+RXh0ZXJuYWwgRW1haWw6PC9zcGFuPjwv aT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj4g UGxlYXNlIHVzZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQgYXR0YWNobWVudHMgLw0K PC9zcGFuPjwvZW0+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9y OmJsdWUiPkNvdXJyaWVsIGV4dGVybmU6PC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj4gU295ZXogcHJ1ZGVudCBhdmVjIGxlcyBs aWVucyBldCBkb2N1bWVudHMgam9pbnRzDQo8L3NwYW4+PC9lbT48c3BhbiBzdHlsZT0iY29sb3I6 Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHls ZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0i Y2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHN0cm9uZz48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPkV4dGVybmFsIEVtYWlsOjwvc3Bhbj48 L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+ IFBsZWFzZSB1c2UgY2F1dGlvbiB3aGVuIG9wZW5pbmcgbGlua3MgYW5kIGF0dGFjaG1lbnRzIC8N Cjwvc3Bhbj48L2VtPjxzdHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xv cjpibHVlIj5Db3VycmllbCBleHRlcm5lOjwvc3Bhbj48L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+IFNveWV6IHBydWRlbnQgYXZlYyBsZXMg bGllbnMgZXQgZG9jdW1lbnRzIGpvaW50cw0KPC9zcGFuPjwvZW0+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_e93fdfffe6614bd2897f77bb3b5b6d2dbellca_-- From nobody Mon Aug 23 15:10:43 2021 Return-Path: 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 474163A1EB0 for ; Mon, 23 Aug 2021 15:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=bell.ca 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 yuTF3WbhH0Ty for ; Mon, 23 Aug 2021 15:10:35 -0700 (PDT) Received: from ESA1-Dor.bell.ca (esa1-dor.bell.ca [204.101.223.58]) (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 EE7BA3A1EFD for ; Mon, 23 Aug 2021 15:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1629756632; x=1661292632; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=RilOZ527ONh6Gq2Tsdaq8MZAfmdFnqEvs0GQvZQKLgU=; b=YRKS5ykV35X3Q5OSSbWZriG0HORTay4qN+DeB3pYfnaK2ajl58EgQG7v h5q7qrFwt19uowAy47kw5ENz6JW5HjMeMuhYnaSurJhNYjvmIkn2R12ti Ms3xD87B9UaJB9+1jcr39MqNQdvDL3PNLq5T9U2wwlasfpm3iyf1o5w91 fc8qV6GtMeeqsoonBINB9a2br/6Dy8tN5ToZW5k3GpgJ4bO9rrtqQVeH6 VI6UUKc2NK6EHOQamxm07YBl0j0xvh7EEhm/KVdMlxw0JFGeaSNafMFoE kZRLr9hqTizPyLoQgNEN/D83aih8Ncmd3SCFHy0zAVK6m8WZp2f7dU3ln w==; IronPort-SDR: y6thxgCCKbs7fzRe6ljhmfDueanm/P/JHghv+dOPLS/UsghR+vXvuwkL6HfBUj+WpT7Zzz3pbg ovLDD3Zj8/aQ== Received: from dc5cmy-d00.bellca.int.bell.ca (HELO DG6MBX01-WYN.bell.corp.bce.ca) ([198.235.121.229]) by esa01corp-dor.bell.corp.bce.ca with ESMTP; 23 Aug 2021 18:10:30 -0400 Received: from DG12MBX04-WYN.bell.corp.bce.ca (142.182.18.49) by DG6MBX01-WYN.bell.corp.bce.ca (142.182.18.36) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 23 Aug 2021 18:10:30 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX04-WYN.bell.corp.bce.ca (142.182.18.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Mon, 23 Aug 2021 18:10:30 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Mon, 23 Aug 2021 18:10:30 -0400 From: "Caron, Guy" To: Brian Rosen CC: "ecrit@ietf.org" Thread-Topic: [EXT]Re: lost-planned-changes-04: plannedChange bound to validateLocation? Thread-Index: AdeYYhykIa0/cXEHQDGV6seRBYfoOQAJEtyAAAfVt2D//8qpgIAAQotw///AlICAAEJzIA== Date: Mon, 23 Aug 2021 22:10:30 +0000 Message-ID: <038dcfc4405d4ebe8930d6225f09ea83@bell.ca> References: <8bdda7ea7d004b4591ff715526d93a73@bell.ca> <791ea34f628d48d3addeb04613d5721a@bell.ca> <9158D09E-770E-4E65-BE46-E39060EAC884@brianrosen.net> <0b81d439e4824aec8a3476906ce5cbc1@bell.ca> <7C21F96F-E238-4DA2-82BB-D7C731A84D53@brianrosen.net> In-Reply-To: <7C21F96F-E238-4DA2-82BB-D7C731A84D53@brianrosen.net> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.79] Content-Type: multipart/alternative; boundary="_000_038dcfc4405d4ebe8930d6225f09ea83bellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 22:10:42 -0000 --_000_038dcfc4405d4ebe8930d6225f09ea83bellca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IG1pc3MgbXkgcG9pbnQuIFRoZSBMb1NUIGNsaWVudCBtYXkgbm90IGJlIGEgTElTLiBJZiB3 ZSBtYWtlIGl0IGV4cGxpY2l0IHRoYXQgb25seSBMSVNlcyBhcmUgTG9TVCBjbGllbnRzIGluIHRo ZSBjb250ZXh0IG9mIHRoaXMgZHJhZnQsIEkgbWF5IG5vdCBoYXZlIGFzIHN0cm9uZyBvYmplY3Rp b25zLg0KDQpHdXkNCg0KRGUgOiBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ+DQpFbnZv ecOpIDogMjMgYW/Du3QgMjAyMSAxODowNg0Kw4AgOiBDYXJvbiwgR3V5IDxnLmNhcm9uQGJlbGwu Y2E+DQpDYyA6IGVjcml0QGlldGYub3JnDQpPYmpldCA6IFtFWFRdUmU6IGxvc3QtcGxhbm5lZC1j aGFuZ2VzLTA0OiBwbGFubmVkQ2hhbmdlIGJvdW5kIHRvIHZhbGlkYXRlTG9jYXRpb24/DQoNCk9u bHkgaWYgaXQgYXNrZWQgZm9yIGl0LCBwZXIgbG9jYXRpb24uICBJdCBhc2tlZCBmb3IgaXQsIGl0 IGdvdCBpdC4NCg0KSXQgaGFzIE5PVEhJTkcgdG8gZG8gd2l0aCBhY3R1YWwgY2FsbHMuICBJdOKA mXMganVzdCBhbiBhbHRlcm5hdGl2ZSB0byBwZXJpb2RpYyByZXZhbGlkYXRpb24gZm9yIHJlY29y ZHMgaW4gdGhlIExJUy4NCg0KQSBtb3JlIGludGVyZXN0aW5nIGlzc3VlIGlzIHdoYXQgZG9lcyBh IExJUyBkbyB3aGVuIGl0IGRlbGV0ZXMgYSByZWNvcmQgZm9yIHdoaWNoIGEgVVJJIGlzIHN0b3Jl ZCBpbiB0aGUgc2VydmVyLiAgUHJvYmFibHkgaXQgbWFya3MgdGhhdCBVUkkgaXMgT0JFLiBBbm90 aGVyIHBvc3NpYmlsaXR5IGlzIHRoYXQgaXQgc3RvcmVzIGEgbmV3IFVSSSB0aGF0IGlzIGEgY2F0 Y2gtYWxsIOKAnGlnbm9yZSBtZeKAnQ0KDQpIbW1tLiAgSSB3b25kZXIgaWYgd2Ugc2hvdWxkIGhh dmUgYW4gZXhwbGljaXQgZGVsZXRlLiAgTnVsbCBVUkkgPSBkZWxldGUuDQoNCkJyaWFuDQoNCg0K DQpPbiBBdWcgMjMsIDIwMjEsIGF0IDY6MDEgUE0sIENhcm9uLCBHdXkgPGcuY2Fyb25AYmVsbC5j YTxtYWlsdG86Zy5jYXJvbkBiZWxsLmNhPj4gd3JvdGU6DQoNCkEgTG9TVCBjbGllbnQgdGhhdCBz ZW5kcyByb3V0aW5nIHJlcXVlc3RzIHRvIHRoZSBzZXJ2ZXIgd291bGQgcmVjZWl2ZSwgd2F5IGFm dGVyIGNhbGxzIGhhdmUgYmVlbiBkZWxpdmVyZWQsIGEgbm90aWZpY2F0aW9uIHdpdGggYSA8bG9j YXRpb25JbnZhbGlkPiBib2R5LiBXaGF0IHdvdWxkIGl0IGRvIHdpdGggdGhpcz8NCg0KTWFrZXMg bm8gc2Vuc2UgdG8gbWUuDQoNCkd1eQ0KDQpEZSA6IEJyaWFuIFJvc2VuIDxickBicmlhbnJvc2Vu Lm5ldDxtYWlsdG86YnJAYnJpYW5yb3Nlbi5uZXQ+Pg0KRW52b3nDqSA6IDIzIGFvw7t0IDIwMjEg MTc6NTUNCsOAIDogQ2Fyb24sIEd1eSA8Zy5jYXJvbkBiZWxsLmNhPG1haWx0bzpnLmNhcm9uQGJl bGwuY2E+Pg0KQ2MgOiBlY3JpdEBpZXRmLm9yZzxtYWlsdG86ZWNyaXRAaWV0Zi5vcmc+DQpPYmpl dCA6IFtFWFRdUmU6IGxvc3QtcGxhbm5lZC1jaGFuZ2VzLTA0OiBwbGFubmVkQ2hhbmdlIGJvdW5k IHRvIHZhbGlkYXRlTG9jYXRpb24/DQoNCkkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSByZWFzb25p bmcgb24g4oCcY3JlYXRpbmcgaGF2b2PigJ0uICBJIGRvbuKAmXQga25vdyB3aHkgYSBjbGllbnQg d291bGQgZXZlciBkbyBpdCwgYnV0IGl0IOKAnHdvcmtz4oCdIGluIHRoYXQgdGhlIHNlcnZlciBk b2VzbuKAmXQgaGF2ZSB0byB2YWxpZGF0ZSB0byBzYXZlIHRoZSBVUkkuICBJZiBJIGNsaWVudCBz ZW5kcyB0aGUgVVJJIGFuZCBkb2VzbuKAmXQgdmFsaWRhdGUsIGl04oCZcyB3ZWlyZCwgYnV0IG5v dCB3cm9uZy4NCg0KV2UgY2FuIGRlY2lkZSB0byBwcm9oaWJpdCBpdC4gIEJ1dCB3ZSBkb27igJl0 IHJlYWxseSBoYXZlIGEganVzdGlmaWNhdGlvbi4NCg0KQnJpYW4NCg0KDQoNCk9uIEF1ZyAyMywg MjAyMSwgYXQgNTo0NCBQTSwgQ2Fyb24sIEd1eSA8Zy5jYXJvbkBiZWxsLmNhPG1haWx0bzpnLmNh cm9uQGJlbGwuY2E+PiB3cm90ZToNCg0KSSBhZ3JlZSB0aGF0IGFjY29tbW9kYXRpbmcgdGhpcyBj b21tZW50IHdvdWxkIHJlcXVpcmUgZGVlcGVyIFhNTCBjaGFuZ2VzLg0KDQpJZiB3ZSBkbyBub3Qg d2FudCB0byBnbyB0aGVyZSwgSSB0aGluayB0aGUgZHJhZnQgc2hvdWxkIGJlIGNsZWFyIHRoYXQg dGhlcmUgaXMgbm8gdXNlY2FzZSBmb3Igc2VuZGluZyA8cGxhbm5lZENoYW5nZT4gb3V0c2lkZSBv ZiBhIGxvY2F0aW9uIHZhbGlkYXRpb24gcmVxdWVzdCBhbmQgYXMgc3VjaCwgc2hvdWxkIG5vcm1h dGl2ZWx5IHJlY29tbWVuZCBub3QgZG9pbmcgc28uDQoNCkkgZG8gbm90IGFncmVlIHRoYXQgYSBM b1NUIHNlcnZlciByZWNlaXZpbmcgPHBsYW5uZWRDaGFuZ2U+IG91dHNpZGUgb2YgYSBsb2NhdGlv biB2YWxpZGF0aW9uIHJlcXVlc3Qgd291bGQgcmV0YWluIHRoZSBVUkkgYW5kIHNlbmQgbm90aWZp Y2F0aW9uIGlmIHRoZSByZWNvcmQgY2hhbmdlZCBhZnRlcndhcmQuIEkgdGhpbmsgdGhpcyB3b3Vs ZCBjcmVhdGUgaGF2b2Mgb24gdGhlIGNsaWVudOKAmSBzaWRlLg0KDQpUaGFua3MsDQoNCkd1eQ0K DQpEZSA6IEJyaWFuIFJvc2VuIDxickBicmlhbnJvc2VuLm5ldDxtYWlsdG86YnJAYnJpYW5yb3Nl bi5uZXQ+Pg0KRW52b3nDqSA6IDIzIGFvw7t0IDIwMjEgMTc6MjINCsOAIDogQ2Fyb24sIEd1eSA8 Zy5jYXJvbkBiZWxsLmNhPG1haWx0bzpnLmNhcm9uQGJlbGwuY2E+Pg0KQ2MgOiBlY3JpdEBpZXRm Lm9yZzxtYWlsdG86ZWNyaXRAaWV0Zi5vcmc+DQpPYmpldCA6IFtFWFRdUmU6IGxvc3QtcGxhbm5l ZC1jaGFuZ2VzLTA0OiBwbGFubmVkQ2hhbmdlIGJvdW5kIHRvIHZhbGlkYXRlTG9jYXRpb24/DQoN CnZhbGlkYXRlTG9jYXRpb24gaXMgYW4gYXR0cmlidXRlLCBub3QgYW4gZWxlbWVudCwgc28gSSBj YW7igJl0IGV4dGVuZCBpdC4NCg0KVGhlcmUgaXNu4oCZdCBhbiBhY3R1YWwgcmVxdWlyZW1lbnQg dG8gdGllIHBsYW5uZWRDaGFuZ2UgdG8gdmFsaWRhdGVMb2NhdGlvbi4gIEl0IG1heSBub3QgbWFr ZSBhIGxvdCBvZiBzZW5zZSwgYnV0IGlmIHlvdSBkaWQgaXQsIHRoZSBMb1NUIHNlcnZlciB3b3Vs ZCBub3QgcmV0dXJuIHZhbGlkYXRpb24gZGF0YSwgd291bGQgcmV0YWluIHRoZSBVUkkgYW5kIHdv dWxkIHNlbmQgdGhlIG5vdGlmaWNhdGlvbiBpZiB0aGUgcmVjb3JkIGNoYW5nZWQuICBOb3RlIG15 IHRleHQgdGhhdCB0aGUgTG9TVCBzZXJ2ZXIgZG9lc27igJl0IHN0b3JlIHRoZSBMSSAtIHRoZSBu b3RpZmljYXRpb24gaXMg4oCcc29tZXRoaW5nIGNoYW5nZWTigJ0gbm90IOKAnHdoYXQgeW91IHNl bnQgaXMgZ3VhcmFudGVlZCB0byBiZSBpbnZhbGlk4oCdIG9yIGV2ZW4g4oCcb25lIG9yIG1vcmUg b2YgdGhlIGVsZW1lbnRzIHlvdSBzZW50IGNoYW5nZWQiLiAgSSB0aG91Z2h0IGFib3V0IGNoYW5n aW5nIHRoZSBuYW1lIG9mIHRoZSBub3RpZmljYXRpb24sIGJ1dCBJIGRpZG7igJl0IGRvIHRoYXQu ICBUaGUgcHJhY3RpY2FsIHVzZSBjYXNlIHJlbWFpbnMgdGhlIHNhbWUuDQoNCkJyaWFuDQoNCg0K DQoNCk9uIEF1ZyAyMywgMjAyMSwgYXQgNTowNyBQTSwgQ2Fyb24sIEd1eSA8Zy5jYXJvbkBiZWxs LmNhPG1haWx0bzpnLmNhcm9uQGJlbGwuY2E+PiB3cm90ZToNCg0KTm90IGFsbCBMb1NUIHNlcnZl ciBpbXBsZW1lbnRhdGlvbnMgcGVyZm9ybSBsb2NhdGlvbiB2YWxpZGF0aW9ucy4gV2hlbiBsb2Nh dGlvbiB2YWxpZGF0aW9uIGlzIHJlcXVlc3RlZCBieSB0aGUgY2xpZW50LCBpdCBhZGRzIHRoZSDi gJx2YWxpZGF0ZUxvY2F0aW9u4oCdIGF0dHJpYnV0ZSB0byB0aGUgPGZpbmRTZXJ2aWNlPiBlbGVt ZW50Lg0KDQpTbyB0aGUgcXVlc3Rpb24gaXM6IFNob3VsZCDigJxwbGFubmVkQ2hhbmdl4oCdIGJl IGJvdW5kIHRvIOKAnHZhbGlkYXRlTG9jYXRpb27igJ0/DQoNCklmIHlvdSBiZWxpZXZlIG5vdCwg d2hhdCB3b3VsZCBiZSB0aGUgZXhwZWN0ZWQgYmVoYXZpb3VyIG9mIGEgTG9TVCBzZXJ2ZXIgcmVj ZWl2aW5nIGEgPHBsYW5uZWRDaGFuZ2U+IGVsZW1lbnQgb3V0c2lkZSBvZiBhIHZhbGlkYXRpb24g cmVxdWVzdD8NCg0KVGhhbmtzLA0KDQpHdXkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkV4dGVybmFsIEVtYWlsOiBQbGVhc2UgdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxp bmtzIGFuZCBhdHRhY2htZW50cyAvIENvdXJyaWVsIGV4dGVybmU6IFNveWV6IHBydWRlbnQgYXZl YyBsZXMgbGllbnMgZXQgZG9jdW1lbnRzIGpvaW50cw0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KRXh0ZXJuYWwgRW1haWw6IFBsZWFzZSB1c2UgY2F1dGlvbiB3aGVuIG9wZW5p bmcgbGlua3MgYW5kIGF0dGFjaG1lbnRzIC8gQ291cnJpZWwgZXh0ZXJuZTogU295ZXogcHJ1ZGVu dCBhdmVjIGxlcyBsaWVucyBldCBkb2N1bWVudHMgam9pbnRzDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpFeHRlcm5hbCBFbWFpbDogUGxlYXNlIHVzZSBjYXV0aW9uIHdoZW4g b3BlbmluZyBsaW5rcyBhbmQgYXR0YWNobWVudHMgLyBDb3VycmllbCBleHRlcm5lOiBTb3lleiBw cnVkZW50IGF2ZWMgbGVzIGxpZW5zIGV0IGRvY3VtZW50cyBqb2ludHMNCg== --_000_038dcfc4405d4ebe8930d6225f09ea83bellca_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5t c29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFt ZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpz cGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0 ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlItQ0Ei IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+WW91IG1pc3MgbXkgcG9pbnQuIFRo ZSBMb1NUIGNsaWVudCBtYXkgbm90IGJlIGEgTElTLiBJZiB3ZSBtYWtlIGl0IGV4cGxpY2l0IHRo YXQgb25seSBMSVNlcyBhcmUgTG9TVCBjbGllbnRzIGluIHRoZSBjb250ZXh0DQogb2YgdGhpcyBk cmFmdCwgSSBtYXkgbm90IGhhdmUgYXMgc3Ryb25nIG9iamVjdGlvbnMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkd1eTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5EZSZuYnNwOzo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBCcmlhbiBSb3NlbiAmbHQ7YnJAYnJpYW5y b3Nlbi5uZXQmZ3Q7DQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gMjMgYW/Du3QgMjAyMSAx ODowNjxicj4NCjxiPsOAJm5ic3A7OjwvYj4gQ2Fyb24sIEd1eSAmbHQ7Zy5jYXJvbkBiZWxsLmNh Jmd0Ozxicj4NCjxiPkNjJm5ic3A7OjwvYj4gZWNyaXRAaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZu YnNwOzo8L2I+IFtFWFRdUmU6IGxvc3QtcGxhbm5lZC1jaGFuZ2VzLTA0OiBwbGFubmVkQ2hhbmdl IGJvdW5kIHRvIHZhbGlkYXRlTG9jYXRpb24/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T25seSBpZiBpdCBhc2tlZCBmb3IgaXQsIHBlciBsb2NhdGlvbi4g Jm5ic3A7SXQgYXNrZWQgZm9yIGl0LCBpdCBnb3QgaXQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBoYXMgTk9USElORyB0byBkbyB3aXRoIGFjdHVhbCBj YWxscy4gJm5ic3A7SXTigJlzIGp1c3QgYW4gYWx0ZXJuYXRpdmUgdG8gcGVyaW9kaWMgcmV2YWxp ZGF0aW9uIGZvciByZWNvcmRzIGluIHRoZSBMSVMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgbW9yZSBpbnRlcmVzdGluZyBpc3N1ZSBpcyB3 aGF0IGRvZXMgYSBMSVMgZG8gd2hlbiBpdCBkZWxldGVzIGEgcmVjb3JkIGZvciB3aGljaCBhIFVS SSBpcyBzdG9yZWQgaW4gdGhlIHNlcnZlci4gJm5ic3A7UHJvYmFibHkgaXQgbWFya3MgdGhhdCBV UkkgaXMgT0JFLiBBbm90aGVyIHBvc3NpYmlsaXR5IGlzIHRoYXQgaXQgc3RvcmVzIGEgbmV3IFVS SSB0aGF0IGlzIGEgY2F0Y2gtYWxsIOKAnGlnbm9yZSBtZeKAnTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IbW1tLiAmbmJzcDtJIHdvbmRlciBp ZiB3ZSBzaG91bGQgaGF2ZSBhbiBleHBsaWNpdCBkZWxldGUuICZuYnNwO051bGwgVVJJID0gZGVs ZXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5CcmlhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBBdWcgMjMsIDIwMjEsIGF0IDY6MDEgUE0sIENhcm9uLCBHdXkgJmx0OzxhIGhyZWY9Im1haWx0 bzpnLmNhcm9uQGJlbGwuY2EiPmcuY2Fyb25AYmVsbC5jYTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BIExvU1QgY2xpZW50IHRoYXQgc2VuZHMgcm91dGlu ZyByZXF1ZXN0cyB0byB0aGUgc2VydmVyIHdvdWxkIHJlY2VpdmUsIHdheSBhZnRlciBjYWxscyBo YXZlIGJlZW4gZGVsaXZlcmVkLCBhIG5vdGlmaWNhdGlvbiB3aXRoIGEgJmx0O2xvY2F0aW9uSW52 YWxpZCZndDsNCiBib2R5LiBXaGF0IHdvdWxkIGl0IGRvIHdpdGggdGhpcz88L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TWFrZXMgbm8gc2Vuc2UgdG8gbWUuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkd1eTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw YW4+PC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkJyaWFuDQogUm9zZW4gJmx0Ozxh IGhyZWY9Im1haWx0bzpickBicmlhbnJvc2VuLm5ldCI+YnJAYnJpYW5yb3Nlbi5uZXQ8L2E+Jmd0 OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8 Yj5FbnZvecOpJm5ic3A7OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+MjMgYW/Du3QgMjAyMSAxNzo1NTxicj4NCjxiPsOAJm5ic3A7OjwvYj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Q2Fyb24sIEd1eSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmcuY2Fyb25AYmVsbC5jYSI+Zy5jYXJvbkBiZWxsLmNhPC9hPiZn dDs8YnI+DQo8Yj5DYyZuYnNwOzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzplY3JpdEBpZXRmLm9yZyI+ZWNyaXRAaWV0 Zi5vcmc8L2E+PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5bRVhUXVJlOiBsb3N0LXBsYW5uZWQtY2hhbmdlcy0w NDogcGxhbm5lZENoYW5nZSBib3VuZCB0byB2YWxpZGF0ZUxvY2F0aW9uPzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSByZWFzb25pbmcgb24g4oCcY3JlYXRpbmcg aGF2b2PigJ0uICZuYnNwO0kgZG9u4oCZdCBrbm93IHdoeSBhIGNsaWVudCB3b3VsZCBldmVyIGRv IGl0LCBidXQgaXQg4oCcd29ya3PigJ0gaW4gdGhhdCB0aGUgc2VydmVyIGRvZXNu4oCZdCBoYXZl IHRvIHZhbGlkYXRlIHRvIHNhdmUgdGhlIFVSSS4gJm5ic3A7SWYgSSBjbGllbnQgc2VuZHMgdGhl IFVSSSBhbmQgZG9lc27igJl0IHZhbGlkYXRlLCBpdOKAmXMgd2VpcmQsDQogYnV0IG5vdCB3cm9u Zy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGNhbiBkZWNpZGUgdG8gcHJvaGliaXQgaXQuICZuYnNw O0J1dCB3ZSBkb27igJl0IHJlYWxseSBoYXZlIGEganVzdGlmaWNhdGlvbi48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QnJpYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gQXVnIDIzLCAyMDIxLCBhdCA1OjQ0IFBNLCBDYXJvbiwgR3V5ICZsdDs8YSBocmVmPSJt YWlsdG86Zy5jYXJvbkBiZWxsLmNhIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5nLmNhcm9u QGJlbGwuY2E8L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUgdGhhdCBhY2NvbW1v ZGF0aW5nIHRoaXMgY29tbWVudCB3b3VsZCByZXF1aXJlIGRlZXBlciBYTUwgY2hhbmdlcy48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+SWYgd2UgZG8gbm90IHdhbnQgdG8gZ28gdGhlcmUsIEkgdGhpbmsgdGhlIGRy YWZ0IHNob3VsZCBiZSBjbGVhciB0aGF0IHRoZXJlIGlzIG5vIHVzZWNhc2UgZm9yIHNlbmRpbmcg Jmx0O3BsYW5uZWRDaGFuZ2UmZ3Q7IG91dHNpZGUgb2YgYSBsb2NhdGlvbiB2YWxpZGF0aW9uDQog cmVxdWVzdCBhbmQgYXMgc3VjaCwgc2hvdWxkIG5vcm1hdGl2ZWx5IHJlY29tbWVuZCBub3QgZG9p bmcgc28uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgZG8gbm90IGFncmVlIHRoYXQgYSBMb1NUIHNlcnZlciBy ZWNlaXZpbmcgJmx0O3BsYW5uZWRDaGFuZ2UmZ3Q7IG91dHNpZGUgb2YgYSBsb2NhdGlvbiB2YWxp ZGF0aW9uIHJlcXVlc3Qgd291bGQgcmV0YWluIHRoZSBVUkkgYW5kIHNlbmQgbm90aWZpY2F0aW9u IGlmDQogdGhlIHJlY29yZCBjaGFuZ2VkIGFmdGVyd2FyZC4gSSB0aGluayB0aGlzIHdvdWxkIGNy ZWF0ZSBoYXZvYyBvbiB0aGUgY2xpZW504oCZIHNpZGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+R3V5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QnJpYW4NCiBSb3Nl biAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0Ij48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5ickBicmlhbnJvc2VuLm5ldDwvc3Bhbj48L2E+Jmd0OzxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5FbnZvecOpJm5ic3A7 OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+MjMg YW/Du3QgMjAyMSAxNzoyMjxicj4NCjxiPsOAJm5ic3A7OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Q2Fyb24sIEd1eSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmcuY2Fyb25AYmVsbC5jYSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Zy5jYXJvbkBi ZWxsLmNhPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+Q2MmbmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZWNyaXRA aWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmVjcml0QGlldGYub3JnPC9zcGFu PjwvYT48YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPltFWFRdUmU6IGxvc3QtcGxhbm5lZC1jaGFuZ2VzLTA0OiBw bGFubmVkQ2hhbmdlIGJvdW5kIHRvIHZhbGlkYXRlTG9jYXRpb24/PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dmFsaWRhdGVMb2NhdGlvbiBpcyBhbiBh dHRyaWJ1dGUsIG5vdCBhbiBlbGVtZW50LCBzbyBJIGNhbuKAmXQgZXh0ZW5kIGl0LiAmbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGlz buKAmXQgYW4gYWN0dWFsIHJlcXVpcmVtZW50IHRvIHRpZSBwbGFubmVkQ2hhbmdlIHRvIHZhbGlk YXRlTG9jYXRpb24uICZuYnNwO0l0IG1heSBub3QgbWFrZSBhIGxvdCBvZiBzZW5zZSwgYnV0IGlm IHlvdSBkaWQgaXQsIHRoZSBMb1NUIHNlcnZlciB3b3VsZCBub3QgcmV0dXJuIHZhbGlkYXRpb24g ZGF0YSwgd291bGQgcmV0YWluIHRoZSBVUkkgYW5kIHdvdWxkIHNlbmQgdGhlIG5vdGlmaWNhdGlv biBpZiB0aGUNCiByZWNvcmQgY2hhbmdlZC4gJm5ic3A7Tm90ZSBteSB0ZXh0IHRoYXQgdGhlIExv U1Qgc2VydmVyIGRvZXNu4oCZdCBzdG9yZSB0aGUgTEkgLSB0aGUgbm90aWZpY2F0aW9uIGlzIOKA nHNvbWV0aGluZyBjaGFuZ2Vk4oCdIG5vdCDigJx3aGF0IHlvdSBzZW50IGlzIGd1YXJhbnRlZWQg dG8gYmUgaW52YWxpZOKAnSBvciBldmVuIOKAnG9uZSBvciBtb3JlIG9mIHRoZSBlbGVtZW50cyB5 b3Ugc2VudCBjaGFuZ2VkJnF1b3Q7LiAmbmJzcDtJIHRob3VnaHQgYWJvdXQgY2hhbmdpbmcgdGhl IG5hbWUgb2YNCiB0aGUgbm90aWZpY2F0aW9uLCBidXQgSSBkaWRu4oCZdCBkbyB0aGF0LiAmbmJz cDtUaGUgcHJhY3RpY2FsIHVzZSBjYXNlIHJlbWFpbnMgdGhlIHNhbWUuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJyaWFuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBBdWcgMjMsIDIwMjEsIGF0IDU6MDcgUE0sIENhcm9uLCBHdXkgJmx0Ozxh IGhyZWY9Im1haWx0bzpnLmNhcm9uQGJlbGwuY2EiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi PmcuY2Fyb25AYmVsbC5jYTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Tm90IGFsbCBMb1NUIHNlcnZlciBpbXBsZW1lbnRhdGlvbnMgcGVy Zm9ybSBsb2NhdGlvbiB2YWxpZGF0aW9ucy4gV2hlbiBsb2NhdGlvbiB2YWxpZGF0aW9uIGlzIHJl cXVlc3RlZCBieSB0aGUgY2xpZW50LCBpdCBhZGRzIHRoZSDigJx2YWxpZGF0ZUxvY2F0aW9u4oCd DQogYXR0cmlidXRlIHRvIHRoZSAmbHQ7ZmluZFNlcnZpY2UmZ3Q7IGVsZW1lbnQuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNvIHRoZSBxdWVzdGlvbiBpczog U2hvdWxkIOKAnHBsYW5uZWRDaGFuZ2XigJ0gYmUgYm91bmQgdG8g4oCcdmFsaWRhdGVMb2NhdGlv buKAnT88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SWYgeW91 IGJlbGlldmUgbm90LCB3aGF0IHdvdWxkIGJlIHRoZSBleHBlY3RlZCBiZWhhdmlvdXIgb2YgYSBM b1NUIHNlcnZlciByZWNlaXZpbmcgYSAmbHQ7cGxhbm5lZENoYW5nZSZndDsgZWxlbWVudCBvdXRz aWRlIG9mIGEgdmFsaWRhdGlvbiByZXF1ZXN0Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkd1eTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1h bGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Ryb25nPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+RXh0ZXJuYWwgRW1haWw6PC9z cGFuPjwvaT48L3N0cm9uZz48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48L2k+ PC9zcGFuPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPlBsZWFz ZQ0KIHVzZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQgYXR0YWNobWVudHMgLzwvc3Bh bj48L2VtPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxpPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjwvaT48L3NwYW4+PHN0 cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPkNvdXJyaWVs IGV4dGVybmU6PC9zcGFuPjwvaT48L3N0cm9uZz48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPiZuYnNw Ozwvc3Bhbj48L2k+PC9zcGFuPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9y OmJsdWUiPlNveWV6DQogcHJ1ZGVudCBhdmVjIGxlcyBsaWVucyBldCBkb2N1bWVudHMgam9pbnRz PC9zcGFuPjwvZW0+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhy IHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzdHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtjb2xvcjpibHVlIj5FeHRlcm5hbCBFbWFpbDo8L3NwYW4+PC9pPjwvc3Ryb25nPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjwvaT48L3NwYW4+PGVtPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+UGxlYXNlDQogdXNlIGNhdXRpb24gd2hlbiBvcGVu aW5nIGxpbmtzIGFuZCBhdHRhY2htZW50cyAvPC9zcGFuPjwvZW0+PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpi bHVlIj4mbmJzcDs8L3NwYW4+PC9pPjwvc3Bhbj48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+Q291cnJpZWwgZXh0ZXJuZTo8L3NwYW4+PC9pPjwvc3Ry b25nPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxpPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjwvaT48L3NwYW4+PGVtPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+U295ZXoNCiBwcnVkZW50IGF2 ZWMgbGVzIGxpZW5zIGV0IGRvY3VtZW50cyBqb2ludHM8L3NwYW4+PC9lbT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0i MiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+ RXh0ZXJuYWwgRW1haWw6PC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtjb2xvcjpibHVlIj4gUGxlYXNlIHVzZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBs aW5rcyBhbmQgYXR0YWNobWVudHMgLw0KPC9zcGFuPjwvZW0+PHN0cm9uZz48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPkNvdXJyaWVsIGV4dGVybmU6PC9zcGFuPjwv aT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj4g U295ZXogcHJ1ZGVudCBhdmVjIGxlcyBsaWVucyBldCBkb2N1bWVudHMgam9pbnRzDQo8L3NwYW4+ PC9lbT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_038dcfc4405d4ebe8930d6225f09ea83bellca_-- From nobody Mon Aug 23 15:12:30 2021 Return-Path: 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 DACB03A1F45 for ; Mon, 23 Aug 2021 15:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, 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 ck2QmRM8IirL for ; Mon, 23 Aug 2021 15:12:10 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D02E73A1F15 for ; Mon, 23 Aug 2021 15:12:09 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 23 Aug 2021 15:12:09 -0700 From: "Randall Gellens" To: "Caron, Guy" Cc: "Brian Rosen" , ecrit@ietf.org Date: Mon, 23 Aug 2021 15:12:09 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <9FA8CD6B-0DF0-4D30-A182-1AF77A155871@randy.pensive.org> In-Reply-To: References: <8508C216-7FF5-41D2-A78D-EBF475F83C7F@randy.pensive.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_E0652897-09F9-4E62-AE2F-EDEB9559E97E_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[441, 16443], "plain":[110, 2713], "uuid":"79858B46-01D2-4961-8667-883AA3E52214"}] Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: Locations are not always invalidated X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 22:12:29 -0000 --=_MailMate_E0652897-09F9-4E62-AE2F-EDEB9559E97E_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit In my suggested edits I changed this to add "may". --Randall On 23 Aug 2021, at 15:08, Caron, Guy wrote: > Taken from section 3: > > The URI will be stored by the server against the location in the > request for subsequent use with the notification function defined > below. > > Guy > > De : Randall Gellens > Envoyé : 23 août 2021 17:51 > À : Caron, Guy > Cc : Brian Rosen ; ecrit@ietf.org > Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: Locations are not > always invalidated > > > I don't know that that's true. My interpretation is that a LoST server > might maintain a list of URIs but not associate each with specific > location records, and when there is a change, it would then send a > notification to each stored URI. The location that was used for the > original validation query might not be impacted. > > --Randall > > On 23 Aug 2021, at 14:48, Caron, Guy wrote: > > I think these locations are impacted in one way or the other > otherwise, the LoST server would not be able to determine that it > should send notifications; they may just not become invalid in the > LoST sense. > > > > Thanks, > > > > Guy > > > > > > > > De : Randall Gellens > > > Envoyé : 23 août 2021 17:42 > À : Caron, Guy > > Cc : Brian Rosen >; > ecrit@ietf.org > Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: Locations are not > always invalidated > > > > Using 'impacted' is not really better, because a location may or may > not actually be impacted. If we go down the path of precise names we > should use something such as 'locationPotentiallyInvalidated', which > seems silly. I think the draft makes it clear (especially with my > suggested edits) that a notified location is potentially invalidated. > > --Randall > > On 23 Aug 2021, at 14:24, Caron, Guy wrote: > > This new version introduces variability in whether a location is > indeed invalidated or not by a change, which I agree with. > > > > Given this, the names “locationInvalidated†and > “invalidatedAsOf†seem misleading. Should “invalidated†be > changed to something like “Impacted� > > > > Thanks, > > > > Guy > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > ________________________________ > > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints > > ________________________________ > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints --=_MailMate_E0652897-09F9-4E62-AE2F-EDEB9559E97E_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">In my suggested edits I changed this to add "may".

--Randall

On 23 Aug 2021, at 15:08, Caron, Guy wrote:

Taken from section 3:

=C2=A0

The URI will be stored by the server against the location in the = request for subsequent use with the notification function defined=C2=A0 b= elow.

=C2=A0

Guy

=C2=A0

De=C2= =A0: Randall Gellens <rg+ietf@randy.pensive.org>
Envoy=C3=A9=C2=A0: 23 ao=C3=BBt 2021 17:51
=C3=80=C2=A0: Caron, Guy <g.caron@bell.ca>
Cc=C2=A0: Brian Rosen <br@brianrosen.net>; ecrit@ietf.org Objet=C2=A0: [EXT]Re: [Ecrit] lost-planned-changes-04: Locations a= re not always invalidated

=C2=A0

I don't know that that's true. My interpretation is that a LoST server m= ight maintain a list of URIs but not associate each with specific locatio= n records, and when there is a change, it would then send a notification to each stored URI. The location that was used for the original validati= on query might not be impacted.

--Randall

On 23 Aug 2021, at 14:48, Caron, Guy wrote:

I think these locations are impacted in one way or the other otherwise= , the LoST server would not be able to determine that it should send notifications; they may just not become invalid in the LoST sense.

=C2=A0

Thanks,

=C2=A0

Guy

=C2=A0

=C2=A0

=C2=A0

De=C2=A0: Randall Gellens <rg+ietf@randy.pensive.org>
Envoy=C3=A9=C2=A0: 23 ao=C3=BBt 2021 17:42
=C3=80=C2=A0: Caron, Guy <g.caron@bell.ca>
Cc=C2=A0: Brian Rosen <br@brianrosen.net>; ecrit@ietf.org
Objet=C2=A0: [EXT]Re: [Ecrit] lost-planned-changes-04: Locations a= re not always invalidated

=

=C2=A0

Using 'impacted' is not really better, because a location = may or may not actually be impacted. If we go down the path of precise na= mes we should use something such as 'locationPotentiallyInvalidated', which seems silly. I think the draft makes it clear (especially with my = suggested edits) that a notified location is potentially invalidated.

--Randall

On 23 Aug 2021, at 14:24, Caron, Guy wrote:

This new version introduces variability in whether a location is indee= d invalidated or not by a change, which I agree with.

=C2=A0

Given this, the names =E2=80=9ClocationInvalidated=E2=80=9D and =E2=80= =9CinvalidatedAsOf=E2=80=9D seem misleading. Should =E2=80=9Cinvalidated=E2= =80=9D be changed to something like =E2=80=9CImpacted=E2=80=9D?

=C2=A0

Thanks,

=C2=A0

Guy

=C2=A0

=C2= =A0

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/m= ailman/listinfo/ecrit

=

External Email: Please use caution when opening links and attachments= / Courrie= l externe: Soyez prudent avec les liens et documents joints

<= span style=3D"font-size:9.0pt;color:blue">External Email: Please use caution wh= en opening links and attachments / Courrie= l externe: Soyez prudent avec les liens et documents joints

--=_MailMate_E0652897-09F9-4E62-AE2F-EDEB9559E97E_=-- From nobody Mon Aug 23 15:13:29 2021 Return-Path: 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 2C7393A1F34 for ; Mon, 23 Aug 2021 15:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, 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 jbXloJmX-afD for ; Mon, 23 Aug 2021 15:13:12 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 731353A1F06 for ; Mon, 23 Aug 2021 15:13:12 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 23 Aug 2021 15:13:12 -0700 From: "Randall Gellens" To: ecrit@ietf.org Date: Mon, 23 Aug 2021 15:13:00 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <82C4B705-5044-493E-9969-B75D060A95B9@randy.pensive.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Ecrit] [EDIT] Review of draft-ietf-ecrit-lost-planned-changes-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 22:13:27 -0000 The list server has too aggressive editing, so I'm resending this = message with the attachments changed to links. (1) Should the Time to Live information in a validation response be an = attribute rather than an element? Logically, it seems more an attribute = of the response, and also it mirrors the 'expires' attribute on which it = is modeled. (2) In the extension schema, are 'invalidAsOf' and 'asOf' swapped? = ('AsOf' should be part of the element but looks like = maybe it is part of the response, while 'invalidAsOf' is part of = ). (3) I'm not sure that "The server MUST have policy that limits use of = this mechanism by a given client" is warranted; I think using "SHOULD" = is more easily justified. I have a number of suggested edits for clarification or language. = Linked are four files: The XML uploaded by Brian, with my edits. draft-ietf-ecrit-lost-planned-changes-04-rg.xml https://turing.pensive.org/ecrit/draft-ietf-ecrit-lost-planned-changes-04= -rg.xml The TXT generated from the XML with my edits. draft-ietf-ecrit-lost-planned-changes-04-rg.txt https://turing.pensive.org/ecrit/draft-ietf-ecrit-lost-planned-changes-04= -rg.txt An IETF tools diff showing my edits to the TXT, side by side. Diff-txt.html https://turing.pensive.org/ecrit/Diff-txt.html An IETF tools diff showing my edits to the XML, side by side. Diff-xml.html https://turing.pensive.org/ecrit/Diff-xml.html --Randall From nobody Mon Aug 23 15:13:53 2021 Return-Path: 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 8CA463A1F11 for ; Mon, 23 Aug 2021 15:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, 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.20150623.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 iN094RAKo6yi for ; Mon, 23 Aug 2021 15:13:45 -0700 (PDT) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 286C53A1F09 for ; Mon, 23 Aug 2021 15:13:45 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id r6so18558475ilt.13 for ; Mon, 23 Aug 2021 15:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ZcKLLCiIlLWAyoiGb9uBet2wegpYVp6s6brcxKGsj1U=; b=cRIDfL3YRpjvG441eoXI2X5DY8S43/8YUDjXQfMrFfuLQPL8on1xfh2RMf6/mE3ToS Vvuaqqb2C+NvKORHNrR2w+PAwiQUi16ZkRFH6nRrqsnCpV5JD2anOng974rsbDKLe+Up uHWd0/8024P32lidPH9jAgzJWqmeRdaAqHdaYd1I91zVy+3ioLGuLp0NS/2w5ODMSmE0 UmBIUjaKZIkb7DU2Czee6auFRgWG6ry9daLAEpRgBs0HYerWGY0yuIoS4oiCItYFkKlM FpfeDzHMJpC3D02iuPjdkgXZDIYSz9IVGOvjpPVuCyEPpfHF4rWb2KQ1lDUdoUQVtU2A ORKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ZcKLLCiIlLWAyoiGb9uBet2wegpYVp6s6brcxKGsj1U=; b=F9U4ewJCp6x2AFSP1aVnzVg1EwFt9lWWY1rzjnJ20oi6PqVw07itVy7Wls5QukRlZv VAzJO78axre7OGihAjvbFiAEXhexK0XKsVqSLOCHRFNohtaIek1lkfOhO5+sJmemmpPH vErWm09uPyqoduSwqR0OVrmTwznoANugE6Fo7t9O1ITGu6V53h7jvzFS86uwmFLenYpx D4+3AdmRPQu+AIz9gkvjtpZo05AMyiZRqfZhfcg6vpgKD6Jh7rGdLueI1W08iGGkK6sj 7VyV8nuEl5O3Sc+Nf6UFw4zChmdMSPLjv9gWwkmv4rJgHz+UG1Q879iAMxpV7VMXBYCo pOiA== X-Gm-Message-State: AOAM530/rpLQ9v+6N+sRu71R50FYJRZeCJDONkGGkgrYcaPKg0DTWQw2 FZwTG5h/RiZpKfYM5qdNHzedgA== X-Google-Smtp-Source: ABdhPJwElL/r+VkUTahw4i1Qa6dzOdgJqQLM7mNlg8ga6TZhYaf7SPt3EaVw1abo/Nm5PG5f16ZfQA== X-Received: by 2002:a05:6e02:c8b:: with SMTP id b11mr23905423ile.90.1629756823467; Mon, 23 Aug 2021 15:13:43 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id z7sm8972958ilz.25.2021.08.23.15.13.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Aug 2021 15:13:43 -0700 (PDT) From: Brian Rosen Message-Id: <6EC6E0D3-B9E8-476D-A6F7-E1D20817B58E@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_30E93F02-320C-45E9-A5B7-2DB4EA9FDD0D" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Mon, 23 Aug 2021 18:13:40 -0400 In-Reply-To: <038dcfc4405d4ebe8930d6225f09ea83@bell.ca> Cc: "ecrit@ietf.org" To: "Caron, Guy" References: <8bdda7ea7d004b4591ff715526d93a73@bell.ca> <791ea34f628d48d3addeb04613d5721a@bell.ca> <9158D09E-770E-4E65-BE46-E39060EAC884@brianrosen.net> <0b81d439e4824aec8a3476906ce5cbc1@bell.ca> <7C21F96F-E238-4DA2-82BB-D7C731A84D53@brianrosen.net> <038dcfc4405d4ebe8930d6225f09ea83@bell.ca> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 22:13:52 -0000 --Apple-Mail=_30E93F02-320C-45E9-A5B7-2DB4EA9FDD0D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sure, PSAPs could be a LoST client for example. A routing proxy can be = a LoST client. But they wouldn=E2=80=99t ask to store the URI. You = have to ask for it to get the notification.=20 Brian > On Aug 23, 2021, at 6:10 PM, Caron, Guy wrote: >=20 > You miss my point. The LoST client may not be a LIS. If we make it = explicit that only LISes are LoST clients in the context of this draft, = I may not have as strong objections. > =20 > Guy > =20 > De : Brian Rosen =20 > Envoy=C3=A9 : 23 ao=C3=BBt 2021 18:06 > =C3=80 : Caron, Guy > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to = validateLocation? > =20 > Only if it asked for it, per location. It asked for it, it got it. > =20 > It has NOTHING to do with actual calls. It=E2=80=99s just an = alternative to periodic revalidation for records in the LIS. > =20 > A more interesting issue is what does a LIS do when it deletes a = record for which a URI is stored in the server. Probably it marks that = URI is OBE. Another possibility is that it stores a new URI that is a = catch-all =E2=80=9Cignore me=E2=80=9D > =20 > Hmmm. I wonder if we should have an explicit delete. Null URI =3D = delete. > =20 > Brian > =20 >=20 >=20 > On Aug 23, 2021, at 6:01 PM, Caron, Guy > wrote: > =20 > A LoST client that sends routing requests to the server would receive, = way after calls have been delivered, a notification with a = body. What would it do with this? > =20 > Makes no sense to me. > =20 > Guy > =20 > De : Brian Rosen >=20 > Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:55 > =C3=80 : Caron, Guy > > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to = validateLocation? > =20 > I don=E2=80=99t understand the reasoning on =E2=80=9Ccreating = havoc=E2=80=9D. I don=E2=80=99t know why a client would ever do it, but = it =E2=80=9Cworks=E2=80=9D in that the server doesn=E2=80=99t have to = validate to save the URI. If I client sends the URI and doesn=E2=80=99t = validate, it=E2=80=99s weird, but not wrong. > =20 > We can decide to prohibit it. But we don=E2=80=99t really have a = justification. > =20 > Brian >=20 >=20 >=20 > On Aug 23, 2021, at 5:44 PM, Caron, Guy > wrote: > =20 > I agree that accommodating this comment would require deeper XML = changes. > =20 > If we do not want to go there, I think the draft should be clear that = there is no usecase for sending outside of a location = validation request and as such, should normatively recommend not doing = so. > =20 > I do not agree that a LoST server receiving outside of = a location validation request would retain the URI and send notification = if the record changed afterward. I think this would create havoc on the = client=E2=80=99 side. > =20 > Thanks, > =20 > Guy > =20 > De : Brian Rosen >=20 > Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:22 > =C3=80 : Caron, Guy > > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to = validateLocation? > =20 > validateLocation is an attribute, not an element, so I can=E2=80=99t = extend it. =20 > =20 > There isn=E2=80=99t an actual requirement to tie plannedChange to = validateLocation. It may not make a lot of sense, but if you did it, = the LoST server would not return validation data, would retain the URI = and would send the notification if the record changed. Note my text = that the LoST server doesn=E2=80=99t store the LI - the notification is = =E2=80=9Csomething changed=E2=80=9D not =E2=80=9Cwhat you sent is = guaranteed to be invalid=E2=80=9D or even =E2=80=9Cone or more of the = elements you sent changed". I thought about changing the name of the = notification, but I didn=E2=80=99t do that. The practical use case = remains the same. > =20 > Brian >=20 >=20 >=20 >=20 > On Aug 23, 2021, at 5:07 PM, Caron, Guy > wrote: > =20 > Not all LoST server implementations perform location validations. When = location validation is requested by the client, it adds the = =E2=80=9CvalidateLocation=E2=80=9D attribute to the = element. > =20 > So the question is: Should =E2=80=9CplannedChange=E2=80=9D be bound to = =E2=80=9CvalidateLocation=E2=80=9D? > =20 > If you believe not, what would be the expected behaviour of a LoST = server receiving a element outside of a validation = request? > =20 > Thanks, > =20 > Guy > =20 > External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints > =20 > External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints > =20 > External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints --Apple-Mail=_30E93F02-320C-45E9-A5B7-2DB4EA9FDD0D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Sure,= PSAPs could be a LoST client for example.  A routing proxy can be = a LoST client.  But they wouldn=E2=80=99t ask to store the URI. =  You have to ask for it to get the notification. 

Brian

On Aug 23, 2021, at 6:10 PM, Caron, Guy <g.caron@bell.ca> = wrote:

You miss my point. The = LoST client may not be a LIS. If we make it explicit that only LISes are = LoST clients in the context of this draft, I may not have as strong = objections.
 
Guy
 
De : Brian = Rosen <br@brianrosen.net> 
Envoy=C3=A9 : 23 ao=C3=BBt 2021 18:06
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : ecrit@ietf.org
Objet : [EXT]Re: = lost-planned-changes-04: plannedChange bound to validateLocation?
 
Only if it asked for it, per location. =  It asked for it, it got it.
 
It has NOTHING to do with actual calls. =  It=E2=80=99s just an alternative to periodic revalidation for = records in the LIS.
 
A more interesting issue is what does a = LIS do when it deletes a record for which a URI is stored in the server. =  Probably it marks that URI is OBE. Another possibility is that it = stores a new URI that is a catch-all =E2=80=9Cignore me=E2=80=9D
 
Hmmm. =  I wonder if we should have an explicit delete.  Null URI =3D = delete.
 
Brian
 


On Aug 23, 2021, at 6:01 PM, Caron, Guy = <g.caron@bell.ca> = wrote:
 
A LoST client that = sends routing requests to the server would receive, way after calls have = been delivered, a notification with a <locationInvalid> body. What = would it do with this?
 
Makes no sense to me.
 
Guy
 
De : Brian Rosen <br@brianrosen.net> 
Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:55
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : ecrit@ietf.org
Objet : [EXT]Re: = lost-planned-changes-04: plannedChange bound to = validateLocation?
 
I don=E2=80=99t understand the reasoning on = =E2=80=9Ccreating havoc=E2=80=9D.  I don=E2=80=99t know why a = client would ever do it, but it =E2=80=9Cworks=E2=80=9D in that the = server doesn=E2=80=99t have to validate to save the URI.  If I = client sends the URI and doesn=E2=80=99t validate, it=E2=80=99s weird, = but not wrong.
 
We can decide to = prohibit it.  But we don=E2=80=99t really have a justification.
 
Brian



On Aug 23, 2021, at 5:44 = PM, Caron, Guy <g.caron@bell.ca> wrote:
 
I agree that = accommodating this comment would require deeper XML changes.
 
If we do not want to go there, I think the = draft should be clear that there is no usecase for sending = <plannedChange> outside of a location validation request and as = such, should normatively recommend not doing so.
 
I do not agree that a LoST server = receiving <plannedChange> outside of a location validation request = would retain the URI and send notification if the record changed = afterward. I think this would create havoc on the client=E2=80=99 = side.
 
Thanks,
 
Guy
 
De : Brian Rosen <br@brianrosen.net> 
Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:22
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : ecrit@ietf.org
Objet : [EXT]Re: = lost-planned-changes-04: plannedChange bound to = validateLocation?
 
validateLocation is an = attribute, not an element, so I can=E2=80=99t extend it.  
 
There isn=E2=80=99t an actual requirement to tie = plannedChange to validateLocation.  It may not make a lot of sense, = but if you did it, the LoST server would not return validation data, = would retain the URI and would send the notification if the record = changed.  Note my text that the LoST server doesn=E2=80=99t store = the LI - the notification is =E2=80=9Csomething changed=E2=80=9D not = =E2=80=9Cwhat you sent is guaranteed to be invalid=E2=80=9D or even = =E2=80=9Cone or more of the elements you sent changed".  I thought = about changing the name of the notification, but I didn=E2=80=99t do = that.  The practical use case remains the same.
 
Brian




On Aug 23, = 2021, at 5:07 PM, Caron, Guy <g.caron@bell.ca> = wrote:
 
Not all LoST = server implementations perform location validations. When location = validation is requested by the client, it adds the = =E2=80=9CvalidateLocation=E2=80=9D attribute to the <findService> = element.
 
So = the question is: Should =E2=80=9CplannedChange=E2=80=9D be bound to = =E2=80=9CvalidateLocation=E2=80=9D?
 
If = you believe not, what would be the expected behaviour of a LoST server = receiving a <plannedChange> element outside of a validation = request?
 
Thanks,
 
Guy
 
External = Email: Please use caution = when opening links and attachments / Courriel externe: Soyez prudent avec = les liens et documents joints
 
External Email: Please use caution = when opening links and attachments / Courriel externe: Soyez prudent avec = les liens et documents joints
 
External Email: Please use caution when = opening links and attachments / Courriel externe: Soyez prudent avec les = liens et documents = joints

= --Apple-Mail=_30E93F02-320C-45E9-A5B7-2DB4EA9FDD0D-- From nobody Mon Aug 23 15:14:51 2021 Return-Path: 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 AAC243A1F30 for ; Mon, 23 Aug 2021 15:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, 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 gyD93SZw0i1I for ; Mon, 23 Aug 2021 15:14:43 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id B8C013A1F27 for ; Mon, 23 Aug 2021 15:14:43 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 23 Aug 2021 15:14:43 -0700 From: "Randall Gellens" To: "Caron, Guy" Cc: "Brian Rosen" , ecrit@ietf.org Date: Mon, 23 Aug 2021 15:14:43 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <4270BC8E-F7B5-4634-85A4-A705318A88CB@randy.pensive.org> In-Reply-To: <0b81d439e4824aec8a3476906ce5cbc1@bell.ca> References: <8bdda7ea7d004b4591ff715526d93a73@bell.ca> <791ea34f628d48d3addeb04613d5721a@bell.ca> <9158D09E-770E-4E65-BE46-E39060EAC884@brianrosen.net> <0b81d439e4824aec8a3476906ce5cbc1@bell.ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_EDF531D8-9830-460D-9ED8-F69C840171BB_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[472, 14220], "plain":[141, 3320], "uuid":"C0A2F207-6C36-4AB1-A61E-8F2E0157CFFE"}] Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 22:14:50 -0000 --=_MailMate_EDF531D8-9830-460D-9ED8-F69C840171BB_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit It would only receive a notification if it asked for one. Normally, it wouldn't. --Randall On 23 Aug 2021, at 15:01, Caron, Guy wrote: > A LoST client that sends routing requests to the server would receive, > way after calls have been delivered, a notification with a > body. What would it do with this? > > Makes no sense to me. > > Guy > > De : Brian Rosen > Envoyé : 23 août 2021 17:55 > À : Caron, Guy > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to > validateLocation? > > I don’t understand the reasoning on “creating havocâ€. I don’t > know why a client would ever do it, but it “works†in that the > server doesn’t have to validate to save the URI. If I client sends > the URI and doesn’t validate, it’s weird, but not wrong. > > We can decide to prohibit it. But we don’t really have a > justification. > > Brian > > > On Aug 23, 2021, at 5:44 PM, Caron, Guy > > wrote: > > I agree that accommodating this comment would require deeper XML > changes. > > If we do not want to go there, I think the draft should be clear that > there is no usecase for sending outside of a location > validation request and as such, should normatively recommend not doing > so. > > I do not agree that a LoST server receiving outside of > a location validation request would retain the URI and send > notification if the record changed afterward. I think this would > create havoc on the client’ side. > > Thanks, > > Guy > > De : Brian Rosen > > Envoyé : 23 août 2021 17:22 > À : Caron, Guy > > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to > validateLocation? > > validateLocation is an attribute, not an element, so I can’t extend > it. > > There isn’t an actual requirement to tie plannedChange to > validateLocation. It may not make a lot of sense, but if you did it, > the LoST server would not return validation data, would retain the URI > and would send the notification if the record changed. Note my text > that the LoST server doesn’t store the LI - the notification is > “something changed†not “what you sent is guaranteed to be > invalid†or even “one or more of the elements you sent changed". > I thought about changing the name of the notification, but I didn’t > do that. The practical use case remains the same. > > Brian > > > > On Aug 23, 2021, at 5:07 PM, Caron, Guy > > wrote: > > Not all LoST server implementations perform location validations. When > location validation is requested by the client, it adds the > “validateLocation†attribute to the element. > > So the question is: Should “plannedChange†be bound to > “validateLocationâ€? > > If you believe not, what would be the expected behaviour of a LoST > server receiving a element outside of a validation > request? > > Thanks, > > Guy > > ________________________________ > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints > > ________________________________ > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --=_MailMate_EDF531D8-9830-460D-9ED8-F69C840171BB_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">It would only receive a notification if it asked for one. = Normally, it wouldn't.

--Randall

On 23 Aug 2021, at 15:01, Caron, Guy wrote:

A LoST client that sends routing requests to the server would receive,= way after calls have been delivered, a notification with a <locationInvalid> body. What would it do with this?<= /p>

=C2=A0

Makes no sense to me.

=C2=A0

Guy

=C2=A0

De=C2=A0: Brian Rosen = <br@brianrosen.net>
Envoy=C3=A9=C2=A0: 23 ao=C3=BBt 2021 17:55
=C3=80=C2=A0: Caron, Guy <g.caron@bell.ca>
Cc=C2=A0: ecrit@ietf.org
Objet=C2=A0: [EXT]Re: lost-planned-changes-04: plannedChange bound= to validateLocation?

=C2=A0

I don=E2=80=99t understand the reasoning on =E2= =80=9Ccreating havoc=E2=80=9D. =C2=A0I don=E2=80=99t know why a client wo= uld ever do it, but it =E2=80=9Cworks=E2=80=9D in that the server doesn=E2= =80=99t have to validate to save the URI. =C2=A0If I client sends the URI= and doesn=E2=80=99t validate, it=E2=80=99s weird, but not wrong.

=C2=A0

We can decide to prohibit it. =C2=A0But we don= =E2=80=99t really have a justification.

=C2=A0

Brian



On Aug 23, 2021, at 5:44 PM, Caron, Guy <g.caron@bell.ca> wrote:

=C2=A0

I agree that accommodati= ng this comment would require deeper XML changes.

=C2=A0

If we do not want to go = there, I think the draft should be clear that there is no usecase for sen= ding <plannedChange> outside of a location validation request and as such, should normatively recommend not doing so.

=C2=A0

I do not agree that a Lo= ST server receiving <plannedChange> outside of a location validatio= n request would retain the URI and send notification if the record changed afterward. I think this would create havoc on the cli= ent=E2=80=99 side.

=C2=A0

Thanks,

=C2=A0

Guy

=C2=A0

De=C2=A0:=C2=A0Brian Rosen <br@brianrosen.net>= =C2=A0
Envoy=C3=A9=C2=A0:=C2=A023 ao=C3=BBt 2021 17:22
=C3=80=C2=A0:= =C2=A0Caron, Guy <g.caron@be= ll.ca>
Cc=C2=A0:=C2=A0= ecrit@ietf.org
Objet=C2=A0:=C2= =A0[EXT]Re: lost-planned-changes-04: plannedChange bound to valida= teLocation?

=C2=A0

validateLocation is an attribute, not an eleme= nt, so I can=E2=80=99t extend it. =C2=A0

=C2=A0

There isn=E2=80=99t an actual requirement to t= ie plannedChange to validateLocation. =C2=A0It may not make a lot of sens= e, but if you did it, the LoST server would not return validation data, w= ould retain the URI and would send the notification if the record changed. =C2=A0Note my text that the LoST server doesn=E2=80=99t = store the LI - the notification is =E2=80=9Csomething changed=E2=80=9D no= t =E2=80=9Cwhat you sent is guaranteed to be invalid=E2=80=9D or even =E2= =80=9Cone or more of the elements you sent changed". =C2=A0I thought abou= t changing the name of the notification, but I didn=E2=80=99t do that. =C2=A0The practical use = case remains the same.

=C2=A0

Brian




On Aug 23, 2021, at 5:07 PM, Caron, Guy <g.caron@bel= l.ca> wrote:

=C2=A0

Not all LoST server impl= ementations perform location validations. When location validation is req= uested by the client, it adds the =E2=80=9CvalidateLocation=E2=80=9D attribute to the <findService> element.

=C2=A0

So the question is: Shou= ld =E2=80=9CplannedChange=E2=80=9D be bound to =E2=80=9CvalidateLocation=E2= =80=9D?

=C2=A0

If you believe not, what= would be the expected behaviour of a LoST server receiving a <planned= Change> element outside of a validation request?

=C2=A0

Thanks,

=C2=A0

Guy

=C2=A0

External Email:=C2=A0= Please use caution when opening links and attachments /=C2=A0Courriel externe:=C2=A0Soyez prudent avec les liens et documents joints

=C2=A0

External Email: Please use caution when opening links and attachments= / Courrie= l externe: Soyez prudent avec les liens et documents joints

______________________= _________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

--=_MailMate_EDF531D8-9830-460D-9ED8-F69C840171BB_=-- From nobody Mon Aug 23 15:17:12 2021 Return-Path: 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 A4D933A1F7C for ; Mon, 23 Aug 2021 15:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, 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 7pAKxGz-DsNf for ; Mon, 23 Aug 2021 15:17:05 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id C69EF3A1F78 for ; Mon, 23 Aug 2021 15:17:03 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 23 Aug 2021 15:17:03 -0700 From: "Randall Gellens" To: "Brian Rosen" Cc: "Caron, Guy" , ecrit@ietf.org Date: Mon, 23 Aug 2021 15:17:03 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <67B98146-3601-42B7-AA07-81E6EC55599D@randy.pensive.org> In-Reply-To: <7C21F96F-E238-4DA2-82BB-D7C731A84D53@brianrosen.net> References: <8bdda7ea7d004b4591ff715526d93a73@bell.ca> <791ea34f628d48d3addeb04613d5721a@bell.ca> <9158D09E-770E-4E65-BE46-E39060EAC884@brianrosen.net> <0b81d439e4824aec8a3476906ce5cbc1@bell.ca> <7C21F96F-E238-4DA2-82BB-D7C731A84D53@brianrosen.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_2021BC80-E074-4115-A40D-3C9DD7F784A2_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[569, 19828], "plain":[238, 3906], "uuid":"F286DFBD-716A-4F1E-84D5-E6FFBFF3F8C0"}] Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 22:17:11 -0000 --=_MailMate_2021BC80-E074-4115-A40D-3C9DD7F784A2_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit If the attribute exists but with an empty value, it means delete? That could work. We could also add an explicit "delete" value as an alternative, but that's more schema work. --Randall On 23 Aug 2021, at 15:06, Brian Rosen wrote: > Only if it asked for it, per location. It asked for it, it got it. > > It has NOTHING to do with actual calls. It’s just an alternative to > periodic revalidation for records in the LIS. > > A more interesting issue is what does a LIS do when it deletes a > record for which a URI is stored in the server. Probably it marks > that URI is OBE. Another possibility is that it stores a new URI that > is a catch-all “ignore me†> > Hmmm. I wonder if we should have an explicit delete. Null URI = > delete. > > Brian > > >> On Aug 23, 2021, at 6:01 PM, Caron, Guy wrote: >> >> A LoST client that sends routing requests to the server would >> receive, way after calls have been delivered, a notification with a >> body. What would it do with this? >> >> Makes no sense to me. >> >> Guy >> >> De : Brian Rosen >> Envoyé : 23 août 2021 17:55 >> À : Caron, Guy >> Cc : ecrit@ietf.org >> Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to >> validateLocation? >> >> I don’t understand the reasoning on “creating havocâ€. I >> don’t know why a client would ever do it, but it “works†in >> that the server doesn’t have to validate to save the URI. If I >> client sends the URI and doesn’t validate, it’s weird, but not >> wrong. >> >> We can decide to prohibit it. But we don’t really have a >> justification. >> >> Brian >> >> >> On Aug 23, 2021, at 5:44 PM, Caron, Guy > > wrote: >> >> I agree that accommodating this comment would require deeper XML >> changes. >> >> If we do not want to go there, I think the draft should be clear that >> there is no usecase for sending outside of a location >> validation request and as such, should normatively recommend not >> doing so. >> >> I do not agree that a LoST server receiving outside >> of a location validation request would retain the URI and send >> notification if the record changed afterward. I think this would >> create havoc on the client’ side. >> >> Thanks, >> >> Guy >> >> De : Brian Rosen > >> Envoyé : 23 août 2021 17:22 >> À : Caron, Guy > >> Cc : ecrit@ietf.org >> Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to >> validateLocation? >> >> validateLocation is an attribute, not an element, so I can’t extend >> it. >> >> There isn’t an actual requirement to tie plannedChange to >> validateLocation. It may not make a lot of sense, but if you did it, >> the LoST server would not return validation data, would retain the >> URI and would send the notification if the record changed. Note my >> text that the LoST server doesn’t store the LI - the notification >> is “something changed†not “what you sent is guaranteed to be >> invalid†or even “one or more of the elements you sent changed". >> I thought about changing the name of the notification, but I didn’t >> do that. The practical use case remains the same. >> >> Brian >> >> >> >> On Aug 23, 2021, at 5:07 PM, Caron, Guy > > wrote: >> >> Not all LoST server implementations perform location validations. >> When location validation is requested by the client, it adds the >> “validateLocation†attribute to the element. >> >> So the question is: Should “plannedChange†be bound to >> “validateLocationâ€? >> >> If you believe not, what would be the expected behaviour of a LoST >> server receiving a element outside of a validation >> request? >> >> Thanks, >> >> Guy >> >> External Email: Please use caution when opening links and attachments >> / Courriel externe: Soyez prudent avec les liens et documents joints >> >> External Email: Please use caution when opening links and attachments >> / Courriel externe: Soyez prudent avec les liens et documents joints > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --=_MailMate_2021BC80-E074-4115-A40D-3C9DD7F784A2_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">If the attribute exists but with an empty value, it means = delete? That could work. We could also add an explicit "delete" value a= s an alternative, but that's more schema work.

--Randall

On 23 Aug 2021, at 15:06, Brian Rosen wrote:

Only if it asked for it, per location. &nb= sp;It asked for it, it got it.

It has NOTHING to do with actual calls.  It=E2=80=99s just= an alternative to periodic revalidation for records in the LIS.

A more interesting issu= e is what does a LIS do when it deletes a record for which a URI is store= d in the server.  Probably it marks that URI is OBE. Another possibi= lity is that it stores a new URI that is a catch-all =E2=80=9Cignore me=E2= =80=9D

Hmmm. &n= bsp;I wonder if we should have an explicit delete.  Null URI =3D del= ete.

Brian


On Aug 23, 2021, at 6:01 PM, Caron, Guy &= lt;g.caron@bell.ca> = wrote:

A LoST client that = sends routing requests to the server would receive, way after calls have = been delivered, a notification with a <locationInvalid> body. What = would it do with this?
 
Makes no sen= se to me.
 
= Guy
 
De&nb= sp;:&nb= sp;Brian Rosen <br@brianrosen.net> 
Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:55
=C3=80 : = Caron, Guy <g.car= on@bell.ca>
Cc : ecrit@ietf.org
Objet :<= span class=3D"Apple-converted-space"> [EXT]Re: lost-planned-c= hanges-04: plannedChange bound to validateLocation?=
 
I don=E2=80=99t understand the reasoning on =E2=80=9Ccreating havoc=E2= =80=9D.  I don=E2=80=99t know why a client would ever do it, but it = =E2=80=9Cworks=E2=80=9D in that the server doesn=E2=80=99t have to valida= te to save the URI.  If I client sends the URI and doesn=E2=80=99t v= alidate, it=E2=80=99s weird, but not wrong.
 
We can decide to prohibit it.  But we don=E2=80=99t = really have a justification.
 
Brian

On Aug 23, 2021, at 5:44 PM, Caron, Guy <g.caron@bell.ca> wrote:
 
I ag= ree that accommodating this comment would require deeper XML changes.
&nb= sp;
If we do not want to go there, I think the draft should be clear that = there is no usecase for sending <plannedChange> outside of a locati= on validation request and as such, should normatively recommend not doing= so.
 
I do not agree that a LoST server receiving <plannedChange&g= t; outside of a location validation request would retain the URI and send= notification if the record changed afterward. I think this would create = havoc on the client=E2=80=99 side.
 
Thanks,<= /o:p>
 
Guy
 
De : Brian Rosen <br@brianrosen.net= > 
Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:22
=C3=80=  : Caron, Guy = <g.caron@bell.ca>
Cc : = ecrit@ietf.org
O= bjet : [EXT]Re= : lost-planned-changes-04: plannedChange bound to validateLocation?
 
validateLo= cation is an attribute, not an element, so I can=E2=80=99t extend it. &nb= sp;
 
There isn=E2=80=99t an actual requirement to tie planne= dChange to validateLocation.  It may not make a lot of sense, but if= you did it, the LoST server would not return validation data, would reta= in the URI and would send the notification if the record changed.  N= ote my text that the LoST server doesn=E2=80=99t store the LI - the notif= ication is =E2=80=9Csomething changed=E2=80=9D not =E2=80=9Cwhat you sent= is guaranteed to be invalid=E2=80=9D or even =E2=80=9Cone or more of the= elements you sent changed".  I thought about changing the name of t= he notification, but I didn=E2=80=99t do that.  The practical use ca= se remains the same.
 
Brian



On Aug 23, 2021, at 5:07 PM, Caron,= Guy <g.caron@bell.ca> wrote:
 = ;
Not all LoST server implementations perform lo= cation validations. When location validation is requested by the client, = it adds the =E2=80=9CvalidateLocation=E2=80=9D attribute to the <findS= ervice> element.
 
So= the question is: Should =E2=80=9CplannedChange=E2=80=9D be bound to =E2=80= =9CvalidateLocation=E2=80=9D?
 
If you believe not, what would be the expected behaviour of a LoS= T server receiving a <plannedChange> element outside of a validatio= n request?
=
 
=
Thanks,
 
= Guy
 
External Email: Please use caution when opening lin= ks and attachments / = Courriel externe: <= span style=3D"font-size: 9pt; color: blue;" class=3D"">Soyez prudent avec= les liens et documents joints
=  
External Email: Please use cau= tion when opening links and attachments / Courriel externe: Soyez prudent= avec les liens et documents joints

______________________= _________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

--=_MailMate_2021BC80-E074-4115-A40D-3C9DD7F784A2_=-- From nobody Mon Aug 23 15:22:17 2021 Return-Path: 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 621FB3A1FCF for ; Mon, 23 Aug 2021 15:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, 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.20150623.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 8sSoeDT4LS06 for ; Mon, 23 Aug 2021 15:22:09 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 7BF3D3A1FD0 for ; Mon, 23 Aug 2021 15:22:09 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id f6so16282893iox.0 for ; Mon, 23 Aug 2021 15:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Se6eMlgiYjTE+NiBns9xAW4Z2LJz3Jq67R0qW7S7Mo4=; b=q3760MULHJoiGsN+m3MgPO/OJxQfJjWzNU0zOm26yt+/15uQ1RKZY91tO13BvO1giW OfW/P0tcZi08q38Zr3IPCCyr0EfqONZKxHTVAtpe+EwGh6JY1o9S/kL/ICTjL+C7CI0q VgpD/wl3myIBckFeFn8iwgDALby2UskdmXkgS+U77DVUNBJEdDn8KEr19UL7lDOr65AD yt9iJ50NyGM2hzHHVcDSYDG+xS8FvLhU7Uh/n7WRnEmvyRQclmdtBlfjublH8RBeBSUB bcu9vZ74W97B5Dhya7kmhRW0ITHNp/7YqaiNRN/ROkm5EXYyPFvaluEo+ywSwtJiTQ1m d+vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Se6eMlgiYjTE+NiBns9xAW4Z2LJz3Jq67R0qW7S7Mo4=; b=sxP7PLrfzknhLl63TWp+NkM3MrGgElDRU4KBJzqBg3xK7qsXXXLqakLEp2401ecSum mdFnvMGkImkLIp9MuFPysrnRfYG4I0mWz9Lb6HpuCcafU3qCsrnQmgI9mPk2Go2/tsK+ eHtoCbhDtXXOCQagZZeRxvSIwzCmJi2RLJ94BSHzWQQbFXPYZvhw2O2/bj03M1+fb5bI fUZc8R+t4DLtUsZJBQLjEolcxfWLZx2eHMcaIJH4rDmuT/HLA62Exy/tmOCoioRqBji3 w/FG19vf76lMYZED+WZ/Zi2YM376CISLmDxeYIxCVUq75tCM9/JmB3dyIt5xsrAgAtxs gxQA== X-Gm-Message-State: AOAM5318ndHCao6d85tqmd/64Ks3+fPY3SSsSLDQsxXv/0839c5ctK4o F7i138DeCFjV5M719xEVuAzEUQ== X-Google-Smtp-Source: ABdhPJznHJyuYLAt3D/H42ehOXk5FyqJmsR2552lQhaCpTudsoduDX7QzuclzM2M3+/imVa1RF6RTw== X-Received: by 2002:a05:6638:168f:: with SMTP id f15mr31515763jat.85.1629757328453; Mon, 23 Aug 2021 15:22:08 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id x13sm9303851ilq.18.2021.08.23.15.22.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Aug 2021 15:22:07 -0700 (PDT) From: Brian Rosen Message-Id: <955D85AF-7FFE-416C-A28B-E4A4C65A1E00@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_55FF35C7-0E5B-4C9C-98DB-241D7837528F" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Mon, 23 Aug 2021 18:22:06 -0400 In-Reply-To: <9FA8CD6B-0DF0-4D30-A182-1AF77A155871@randy.pensive.org> Cc: "Caron, Guy" , ecrit@ietf.org To: Randall Gellens References: <8508C216-7FF5-41D2-A78D-EBF475F83C7F@randy.pensive.org> <9FA8CD6B-0DF0-4D30-A182-1AF77A155871@randy.pensive.org> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: Locations are not always invalidated X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 22:22:16 -0000 --Apple-Mail=_55FF35C7-0E5B-4C9C-98DB-241D7837528F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The MAY is because it may not allow/have room/=E2=80=A6 for the URI (or = not implement it). If you think the text would allow it, for example, = to send a notification where some location other than the one the URI = was sent on changed, then I would like to prohibit that. I especially = don=E2=80=99t want a lazy server sending notifications all over the = place when some change to some location was made, and it sends = notifications to every URI it has.=20 Hmmm. We might want to say that if the location was invalid (regardless = of whether validation was requested), and the LI sent matches more than = one location, the server MUST NOT save the URI, and MUST send the error. = The text that says you may get a notification even if it=E2=80=99s = still valid could be expanded to cover that case as an alternative to = that. Brian > On Aug 23, 2021, at 6:12 PM, Randall Gellens = wrote: >=20 > In my suggested edits I changed this to add "may". >=20 > --Randall >=20 > On 23 Aug 2021, at 15:08, Caron, Guy wrote: >=20 > Taken from section 3: > =20 > The URI will be stored by the server against the location in the = request for subsequent use with the notification function defined = below. > =20 > Guy > =20 > De : Randall Gellens =20 > Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:51 > =C3=80 : Caron, Guy > Cc : Brian Rosen ; ecrit@ietf.org > Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: Locations are not = always invalidated > =20 > I don't know that that's true. My interpretation is that a LoST server = might maintain a list of URIs but not associate each with specific = location records, and when there is a change, it would then send a = notification to each stored URI. The location that was used for the = original validation query might not be impacted. >=20 > --Randall >=20 > On 23 Aug 2021, at 14:48, Caron, Guy wrote: >=20 > I think these locations are impacted in one way or the other = otherwise, the LoST server would not be able to determine that it should = send notifications; they may just not become invalid in the LoST sense. >=20 > =20 > Thanks, >=20 > =20 > Guy >=20 > =20 > =20 > =20 > De : Randall Gellens >=20 > Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:42 > =C3=80 : Caron, Guy > > Cc : Brian Rosen >; = ecrit@ietf.org > Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: Locations are not = always invalidated >=20 > =20 > Using 'impacted' is not really better, because a location may or may = not actually be impacted. If we go down the path of precise names we = should use something such as 'locationPotentiallyInvalidated', which = seems silly. I think the draft makes it clear (especially with my = suggested edits) that a notified location is potentially invalidated. >=20 > --Randall >=20 > On 23 Aug 2021, at 14:24, Caron, Guy wrote: >=20 > This new version introduces variability in whether a location is = indeed invalidated or not by a change, which I agree with. >=20 > =20 > Given this, the names =E2=80=9ClocationInvalidated=E2=80=9D and = =E2=80=9CinvalidatedAsOf=E2=80=9D seem misleading. Should = =E2=80=9Cinvalidated=E2=80=9D be changed to something like = =E2=80=9CImpacted=E2=80=9D? >=20 > =20 > Thanks, >=20 > =20 > Guy >=20 > =20 > =20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit = > External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints >=20 > External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints --Apple-Mail=_55FF35C7-0E5B-4C9C-98DB-241D7837528F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = MAY is because it may not allow/have room/=E2=80=A6 for the URI (or not = implement it).  If you think the text would allow it, for example, = to send a notification where some location other than the one the URI = was sent on changed, then I would like to prohibit that.  I = especially don=E2=80=99t want a lazy server sending notifications all = over the place when some change to some location was made, and it sends = notifications to every URI it has. 

Hmmm.  We might want to say that = if the location was invalid (regardless of whether validation was = requested), and the LI sent matches more than one location, the server = MUST NOT save the URI, and MUST send the error.  The text that says = you may get a notification even if it=E2=80=99s still valid could be = expanded to cover that case as an alternative to that.

Brian

On Aug 23, 2021, at 6:12 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

In my = suggested edits I changed this to add "may".

--Randall

On 23 Aug 2021, at = 15:08, Caron, Guy wrote:

Taken from section = 3:

 

The URI will be stored by the server against the location in = the request for subsequent use with the notification function = defined  below.

 

Guy

 

De : Randall Gellens <rg+ietf@randy.pensive.org>
Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:51
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : Brian Rosen <br@brianrosen.net>; = ecrit@ietf.org
Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: = Locations are not always invalidated

 

I don't = know that that's true. My interpretation is that a LoST server might = maintain a list of URIs but not associate each with specific location = records, and when there is a change, it would then send a notification to each stored URI. The location that was used for the original = validation query might not be impacted.

--Randall

On 23 Aug = 2021, at 14:48, Caron, Guy wrote:

I think these locations = are impacted in one way or the other otherwise, the LoST server would = not be able to determine that it should send notifications; they may just not become invalid in the LoST = sense.

 

Thanks,

 

Guy

 
 
 

De : Randall Gellens <rg+ietf@randy.pensive.org>
Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:42
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : Brian Rosen <br@brianrosen.net>; ecrit@ietf.org
Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: = Locations are not always invalidated

 

Using 'impacted' is not really better, because a location may = or may not actually be impacted. If we go down the path of precise names = we should use something such as 'locationPotentiallyInvalidated', which seems silly. I think the draft makes it clear (especially with my = suggested edits) that a notified location is potentially = invalidated.

--Randall

On 23 Aug 2021, at 14:24, Caron, Guy wrote:

This new version = introduces variability in whether a location is indeed invalidated or = not by a change, which I agree with.

 

Given this, the names = =E2=80=9ClocationInvalidated=E2=80=9D and =E2=80=9CinvalidatedAsOf=E2=80=9D= seem misleading. Should =E2=80=9Cinvalidated=E2=80=9D be changed to = something like =E2=80=9CImpacted=E2=80=9D?

 

Thanks,

 

Guy

 
 

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

External = Email: Please use caution when = opening links and attachments / Courriel = externe: Soyez prudent avec les = liens et documents joints

External Email: Please use caution when = opening links and attachments / Courriel = externe: Soyez prudent avec les = liens et documents joints

= --Apple-Mail=_55FF35C7-0E5B-4C9C-98DB-241D7837528F-- From nobody Mon Aug 23 15:26:47 2021 Return-Path: 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 0BE1B3A2023 for ; Mon, 23 Aug 2021 15:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=bell.ca 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 jMnKFllPxFd0 for ; Mon, 23 Aug 2021 15:26:40 -0700 (PDT) Received: from ESA2-Wyn.bell.ca (esa2-wyn.bell.ca [67.69.243.180]) (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 CCA763A2018 for ; Mon, 23 Aug 2021 15:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1629757599; x=1661293599; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=lhDBY2KLNsPrIv9LZmM0u7zcVWOdqnUsbIx/2UETHyc=; b=LhinKp9LsW6z31X9XhBAPdwLbd9oA/nSwq+3l2xsHa6Bo1RZKak97Sp7 eObSQ3aWY/oX+CKVRj0TB7GEZTTb/fFvEknXhuuulRfzXIZ2sPF5ZcmCT 7gTWzaOVxZvdGlVRAsGijJceuSR6SV6ZgiQmaTlfoV8VmHVx9IqnNxqAr 6E0vEeir90K6f5r7svXNCdg0vQSPiWhK8F5nb1r0BRGYa7MK54+OZBFUb tXw1u1oW+BWmjbAI04iglEZMXU+UeZrfpenDyfwovZ1YCxpsEf29gjeZW BnMe0NGQr2eu1FqDbkbS211rY4/nu+yL9ZE3x2PLjBJgKLiLOVvizBVWq g==; IronPort-SDR: gROEm0ft7Mn4px/RgEvcLNsVAEME3aF2CqRhetl1tSLb+z/vdtdCSqa2t+D/Eme8W3RM5GV1Vv EwGGlSoZR2aA== Received: from dm5czo-d01.bellca.int.bell.ca (HELO DG4MBX01-WYN.bell.corp.bce.ca) ([198.235.102.33]) by esa02corp-wyn.bell.corp.bce.ca with ESMTP; 23 Aug 2021 18:26:38 -0400 Received: from DG12MBX03-WYN.bell.corp.bce.ca (142.182.18.48) by DG4MBX01-WYN.bell.corp.bce.ca (142.182.18.27) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 23 Aug 2021 18:26:38 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX03-WYN.bell.corp.bce.ca (142.182.18.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Mon, 23 Aug 2021 18:26:37 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Mon, 23 Aug 2021 18:26:37 -0400 From: "Caron, Guy" To: Brian Rosen CC: "ecrit@ietf.org" Thread-Topic: [EXT]Re: lost-planned-changes-04: plannedChange bound to validateLocation? Thread-Index: AdeYYhykIa0/cXEHQDGV6seRBYfoOQAJEtyAAAfVt2D//8qpgIAAQotw///AlICAAEJzIP//v5YAgABAQPA= Date: Mon, 23 Aug 2021 22:26:37 +0000 Message-ID: References: <8bdda7ea7d004b4591ff715526d93a73@bell.ca> <791ea34f628d48d3addeb04613d5721a@bell.ca> <9158D09E-770E-4E65-BE46-E39060EAC884@brianrosen.net> <0b81d439e4824aec8a3476906ce5cbc1@bell.ca> <7C21F96F-E238-4DA2-82BB-D7C731A84D53@brianrosen.net> <038dcfc4405d4ebe8930d6225f09ea83@bell.ca> <6EC6E0D3-B9E8-476D-A6F7-E1D20817B58E@brianrosen.net> In-Reply-To: <6EC6E0D3-B9E8-476D-A6F7-E1D20817B58E@brianrosen.net> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.79] Content-Type: multipart/alternative; boundary="_000_cd5677dfaa91450f899a56764c18809abellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 22:26:46 -0000 --_000_cd5677dfaa91450f899a56764c18809abellca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB1bmRlcnN0YW5kIGFuZCB3aGF0IEnigJltIHN1Z2dlc3RpbmcgaXMgdG8gYmUgY2xlYXIgYWJv dXQgd2hhdCBMb1NUIGNsaWVudHMgYXJlIGV4cGVjdGVkIHRvIGRvLiBXZSBkbyBub3Qgd2FudCBh IGxlYXN5IGltcGxlbWVudGF0aW9uIHNlbmRpbmcgPHBsYW5uZWRDaGFuZ2U+IGFjcm9zcyB0aGUg Ym9hcmQsIGRvbuKAmXQgd2U/IEkgdGhpbmsgaXQgaXMgZWFzeSBhbmQgY2hlZXAgdG8gZml4IGlu IHRoZSBkcmFmdCByYXRoZXIgdG8gdHJ5IHRvIGZpeCBpbXBsZW1lbnRhdGlvbnMgbGF0ZXIuDQoN Ckd1eQ0KDQpEZSA6IEJyaWFuIFJvc2VuIDxickBicmlhbnJvc2VuLm5ldD4NCkVudm95w6kgOiAy MyBhb8O7dCAyMDIxIDE4OjE0DQrDgCA6IENhcm9uLCBHdXkgPGcuY2Fyb25AYmVsbC5jYT4NCkNj IDogZWNyaXRAaWV0Zi5vcmcNCk9iamV0IDogW0VYVF1SZTogbG9zdC1wbGFubmVkLWNoYW5nZXMt MDQ6IHBsYW5uZWRDaGFuZ2UgYm91bmQgdG8gdmFsaWRhdGVMb2NhdGlvbj8NCg0KU3VyZSwgUFNB UHMgY291bGQgYmUgYSBMb1NUIGNsaWVudCBmb3IgZXhhbXBsZS4gIEEgcm91dGluZyBwcm94eSBj YW4gYmUgYSBMb1NUIGNsaWVudC4gIEJ1dCB0aGV5IHdvdWxkbuKAmXQgYXNrIHRvIHN0b3JlIHRo ZSBVUkkuICBZb3UgaGF2ZSB0byBhc2sgZm9yIGl0IHRvIGdldCB0aGUgbm90aWZpY2F0aW9uLg0K DQpCcmlhbg0KDQoNCk9uIEF1ZyAyMywgMjAyMSwgYXQgNjoxMCBQTSwgQ2Fyb24sIEd1eSA8Zy5j YXJvbkBiZWxsLmNhPG1haWx0bzpnLmNhcm9uQGJlbGwuY2E+PiB3cm90ZToNCg0KWW91IG1pc3Mg bXkgcG9pbnQuIFRoZSBMb1NUIGNsaWVudCBtYXkgbm90IGJlIGEgTElTLiBJZiB3ZSBtYWtlIGl0 IGV4cGxpY2l0IHRoYXQgb25seSBMSVNlcyBhcmUgTG9TVCBjbGllbnRzIGluIHRoZSBjb250ZXh0 IG9mIHRoaXMgZHJhZnQsIEkgbWF5IG5vdCBoYXZlIGFzIHN0cm9uZyBvYmplY3Rpb25zLg0KDQpH dXkNCg0KRGUgOiBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ8bWFpbHRvOmJyQGJyaWFu cm9zZW4ubmV0Pj4NCkVudm95w6kgOiAyMyBhb8O7dCAyMDIxIDE4OjA2DQrDgCA6IENhcm9uLCBH dXkgPGcuY2Fyb25AYmVsbC5jYTxtYWlsdG86Zy5jYXJvbkBiZWxsLmNhPj4NCkNjIDogZWNyaXRA aWV0Zi5vcmc8bWFpbHRvOmVjcml0QGlldGYub3JnPg0KT2JqZXQgOiBbRVhUXVJlOiBsb3N0LXBs YW5uZWQtY2hhbmdlcy0wNDogcGxhbm5lZENoYW5nZSBib3VuZCB0byB2YWxpZGF0ZUxvY2F0aW9u Pw0KDQpPbmx5IGlmIGl0IGFza2VkIGZvciBpdCwgcGVyIGxvY2F0aW9uLiAgSXQgYXNrZWQgZm9y IGl0LCBpdCBnb3QgaXQuDQoNCkl0IGhhcyBOT1RISU5HIHRvIGRvIHdpdGggYWN0dWFsIGNhbGxz LiAgSXTigJlzIGp1c3QgYW4gYWx0ZXJuYXRpdmUgdG8gcGVyaW9kaWMgcmV2YWxpZGF0aW9uIGZv ciByZWNvcmRzIGluIHRoZSBMSVMuDQoNCkEgbW9yZSBpbnRlcmVzdGluZyBpc3N1ZSBpcyB3aGF0 IGRvZXMgYSBMSVMgZG8gd2hlbiBpdCBkZWxldGVzIGEgcmVjb3JkIGZvciB3aGljaCBhIFVSSSBp cyBzdG9yZWQgaW4gdGhlIHNlcnZlci4gIFByb2JhYmx5IGl0IG1hcmtzIHRoYXQgVVJJIGlzIE9C RS4gQW5vdGhlciBwb3NzaWJpbGl0eSBpcyB0aGF0IGl0IHN0b3JlcyBhIG5ldyBVUkkgdGhhdCBp cyBhIGNhdGNoLWFsbCDigJxpZ25vcmUgbWXigJ0NCg0KSG1tbS4gIEkgd29uZGVyIGlmIHdlIHNo b3VsZCBoYXZlIGFuIGV4cGxpY2l0IGRlbGV0ZS4gIE51bGwgVVJJID0gZGVsZXRlLg0KDQpCcmlh bg0KDQoNCg0KDQpPbiBBdWcgMjMsIDIwMjEsIGF0IDY6MDEgUE0sIENhcm9uLCBHdXkgPGcuY2Fy b25AYmVsbC5jYTxtYWlsdG86Zy5jYXJvbkBiZWxsLmNhPj4gd3JvdGU6DQoNCkEgTG9TVCBjbGll bnQgdGhhdCBzZW5kcyByb3V0aW5nIHJlcXVlc3RzIHRvIHRoZSBzZXJ2ZXIgd291bGQgcmVjZWl2 ZSwgd2F5IGFmdGVyIGNhbGxzIGhhdmUgYmVlbiBkZWxpdmVyZWQsIGEgbm90aWZpY2F0aW9uIHdp dGggYSA8bG9jYXRpb25JbnZhbGlkPiBib2R5LiBXaGF0IHdvdWxkIGl0IGRvIHdpdGggdGhpcz8N Cg0KTWFrZXMgbm8gc2Vuc2UgdG8gbWUuDQoNCkd1eQ0KDQpEZSA6IEJyaWFuIFJvc2VuIDxickBi cmlhbnJvc2VuLm5ldDxtYWlsdG86YnJAYnJpYW5yb3Nlbi5uZXQ+Pg0KRW52b3nDqSA6IDIzIGFv w7t0IDIwMjEgMTc6NTUNCsOAIDogQ2Fyb24sIEd1eSA8Zy5jYXJvbkBiZWxsLmNhPG1haWx0bzpn LmNhcm9uQGJlbGwuY2E+Pg0KQ2MgOiBlY3JpdEBpZXRmLm9yZzxtYWlsdG86ZWNyaXRAaWV0Zi5v cmc+DQpPYmpldCA6IFtFWFRdUmU6IGxvc3QtcGxhbm5lZC1jaGFuZ2VzLTA0OiBwbGFubmVkQ2hh bmdlIGJvdW5kIHRvIHZhbGlkYXRlTG9jYXRpb24/DQoNCkkgZG9u4oCZdCB1bmRlcnN0YW5kIHRo ZSByZWFzb25pbmcgb24g4oCcY3JlYXRpbmcgaGF2b2PigJ0uICBJIGRvbuKAmXQga25vdyB3aHkg YSBjbGllbnQgd291bGQgZXZlciBkbyBpdCwgYnV0IGl0IOKAnHdvcmtz4oCdIGluIHRoYXQgdGhl IHNlcnZlciBkb2VzbuKAmXQgaGF2ZSB0byB2YWxpZGF0ZSB0byBzYXZlIHRoZSBVUkkuICBJZiBJ IGNsaWVudCBzZW5kcyB0aGUgVVJJIGFuZCBkb2VzbuKAmXQgdmFsaWRhdGUsIGl04oCZcyB3ZWly ZCwgYnV0IG5vdCB3cm9uZy4NCg0KV2UgY2FuIGRlY2lkZSB0byBwcm9oaWJpdCBpdC4gIEJ1dCB3 ZSBkb27igJl0IHJlYWxseSBoYXZlIGEganVzdGlmaWNhdGlvbi4NCg0KQnJpYW4NCg0KDQoNCg0K T24gQXVnIDIzLCAyMDIxLCBhdCA1OjQ0IFBNLCBDYXJvbiwgR3V5IDxnLmNhcm9uQGJlbGwuY2E8 bWFpbHRvOmcuY2Fyb25AYmVsbC5jYT4+IHdyb3RlOg0KDQpJIGFncmVlIHRoYXQgYWNjb21tb2Rh dGluZyB0aGlzIGNvbW1lbnQgd291bGQgcmVxdWlyZSBkZWVwZXIgWE1MIGNoYW5nZXMuDQoNCklm IHdlIGRvIG5vdCB3YW50IHRvIGdvIHRoZXJlLCBJIHRoaW5rIHRoZSBkcmFmdCBzaG91bGQgYmUg Y2xlYXIgdGhhdCB0aGVyZSBpcyBubyB1c2VjYXNlIGZvciBzZW5kaW5nIDxwbGFubmVkQ2hhbmdl PiBvdXRzaWRlIG9mIGEgbG9jYXRpb24gdmFsaWRhdGlvbiByZXF1ZXN0IGFuZCBhcyBzdWNoLCBz aG91bGQgbm9ybWF0aXZlbHkgcmVjb21tZW5kIG5vdCBkb2luZyBzby4NCg0KSSBkbyBub3QgYWdy ZWUgdGhhdCBhIExvU1Qgc2VydmVyIHJlY2VpdmluZyA8cGxhbm5lZENoYW5nZT4gb3V0c2lkZSBv ZiBhIGxvY2F0aW9uIHZhbGlkYXRpb24gcmVxdWVzdCB3b3VsZCByZXRhaW4gdGhlIFVSSSBhbmQg c2VuZCBub3RpZmljYXRpb24gaWYgdGhlIHJlY29yZCBjaGFuZ2VkIGFmdGVyd2FyZC4gSSB0aGlu ayB0aGlzIHdvdWxkIGNyZWF0ZSBoYXZvYyBvbiB0aGUgY2xpZW504oCZIHNpZGUuDQoNClRoYW5r cywNCg0KR3V5DQoNCkRlIDogQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0PG1haWx0bzpi ckBicmlhbnJvc2VuLm5ldD4+DQpFbnZvecOpIDogMjMgYW/Du3QgMjAyMSAxNzoyMg0Kw4AgOiBD YXJvbiwgR3V5IDxnLmNhcm9uQGJlbGwuY2E8bWFpbHRvOmcuY2Fyb25AYmVsbC5jYT4+DQpDYyA6 IGVjcml0QGlldGYub3JnPG1haWx0bzplY3JpdEBpZXRmLm9yZz4NCk9iamV0IDogW0VYVF1SZTog bG9zdC1wbGFubmVkLWNoYW5nZXMtMDQ6IHBsYW5uZWRDaGFuZ2UgYm91bmQgdG8gdmFsaWRhdGVM b2NhdGlvbj8NCg0KdmFsaWRhdGVMb2NhdGlvbiBpcyBhbiBhdHRyaWJ1dGUsIG5vdCBhbiBlbGVt ZW50LCBzbyBJIGNhbuKAmXQgZXh0ZW5kIGl0Lg0KDQpUaGVyZSBpc27igJl0IGFuIGFjdHVhbCBy ZXF1aXJlbWVudCB0byB0aWUgcGxhbm5lZENoYW5nZSB0byB2YWxpZGF0ZUxvY2F0aW9uLiAgSXQg bWF5IG5vdCBtYWtlIGEgbG90IG9mIHNlbnNlLCBidXQgaWYgeW91IGRpZCBpdCwgdGhlIExvU1Qg c2VydmVyIHdvdWxkIG5vdCByZXR1cm4gdmFsaWRhdGlvbiBkYXRhLCB3b3VsZCByZXRhaW4gdGhl IFVSSSBhbmQgd291bGQgc2VuZCB0aGUgbm90aWZpY2F0aW9uIGlmIHRoZSByZWNvcmQgY2hhbmdl ZC4gIE5vdGUgbXkgdGV4dCB0aGF0IHRoZSBMb1NUIHNlcnZlciBkb2VzbuKAmXQgc3RvcmUgdGhl IExJIC0gdGhlIG5vdGlmaWNhdGlvbiBpcyDigJxzb21ldGhpbmcgY2hhbmdlZOKAnSBub3Qg4oCc d2hhdCB5b3Ugc2VudCBpcyBndWFyYW50ZWVkIHRvIGJlIGludmFsaWTigJ0gb3IgZXZlbiDigJxv bmUgb3IgbW9yZSBvZiB0aGUgZWxlbWVudHMgeW91IHNlbnQgY2hhbmdlZCIuICBJIHRob3VnaHQg YWJvdXQgY2hhbmdpbmcgdGhlIG5hbWUgb2YgdGhlIG5vdGlmaWNhdGlvbiwgYnV0IEkgZGlkbuKA mXQgZG8gdGhhdC4gIFRoZSBwcmFjdGljYWwgdXNlIGNhc2UgcmVtYWlucyB0aGUgc2FtZS4NCg0K QnJpYW4NCg0KDQoNCg0KDQpPbiBBdWcgMjMsIDIwMjEsIGF0IDU6MDcgUE0sIENhcm9uLCBHdXkg PGcuY2Fyb25AYmVsbC5jYTxtYWlsdG86Zy5jYXJvbkBiZWxsLmNhPj4gd3JvdGU6DQoNCk5vdCBh bGwgTG9TVCBzZXJ2ZXIgaW1wbGVtZW50YXRpb25zIHBlcmZvcm0gbG9jYXRpb24gdmFsaWRhdGlv bnMuIFdoZW4gbG9jYXRpb24gdmFsaWRhdGlvbiBpcyByZXF1ZXN0ZWQgYnkgdGhlIGNsaWVudCwg aXQgYWRkcyB0aGUg4oCcdmFsaWRhdGVMb2NhdGlvbuKAnSBhdHRyaWJ1dGUgdG8gdGhlIDxmaW5k U2VydmljZT4gZWxlbWVudC4NCg0KU28gdGhlIHF1ZXN0aW9uIGlzOiBTaG91bGQg4oCccGxhbm5l ZENoYW5nZeKAnSBiZSBib3VuZCB0byDigJx2YWxpZGF0ZUxvY2F0aW9u4oCdPw0KDQpJZiB5b3Ug YmVsaWV2ZSBub3QsIHdoYXQgd291bGQgYmUgdGhlIGV4cGVjdGVkIGJlaGF2aW91ciBvZiBhIExv U1Qgc2VydmVyIHJlY2VpdmluZyBhIDxwbGFubmVkQ2hhbmdlPiBlbGVtZW50IG91dHNpZGUgb2Yg YSB2YWxpZGF0aW9uIHJlcXVlc3Q/DQoNClRoYW5rcywNCg0KR3V5DQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpFeHRlcm5hbCBFbWFpbDogUGxlYXNlIHVzZSBjYXV0aW9uIHdo ZW4gb3BlbmluZyBsaW5rcyBhbmQgYXR0YWNobWVudHMgLyBDb3VycmllbCBleHRlcm5lOiBTb3ll eiBwcnVkZW50IGF2ZWMgbGVzIGxpZW5zIGV0IGRvY3VtZW50cyBqb2ludHMNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkV4dGVybmFsIEVtYWlsOiBQbGVhc2UgdXNlIGNhdXRp b24gd2hlbiBvcGVuaW5nIGxpbmtzIGFuZCBhdHRhY2htZW50cyAvIENvdXJyaWVsIGV4dGVybmU6 IFNveWV6IHBydWRlbnQgYXZlYyBsZXMgbGllbnMgZXQgZG9jdW1lbnRzIGpvaW50cw0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRXh0ZXJuYWwgRW1haWw6IFBsZWFzZSB1c2Ug Y2F1dGlvbiB3aGVuIG9wZW5pbmcgbGlua3MgYW5kIGF0dGFjaG1lbnRzIC8gQ291cnJpZWwgZXh0 ZXJuZTogU295ZXogcHJ1ZGVudCBhdmVjIGxlcyBsaWVucyBldCBkb2N1bWVudHMgam9pbnRzDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpFeHRlcm5hbCBFbWFpbDogUGxlYXNl IHVzZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQgYXR0YWNobWVudHMgLyBDb3Vycmll bCBleHRlcm5lOiBTb3lleiBwcnVkZW50IGF2ZWMgbGVzIGxpZW5zIGV0IGRvY3VtZW50cyBqb2lu dHMNCg== --_000_cd5677dfaa91450f899a56764c18809abellca_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5t c29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFt ZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpz cGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0 ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlItQ0Ei IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSB1bmRlcnN0YW5kIGFuZCB3aGF0 IEnigJltIHN1Z2dlc3RpbmcgaXMgdG8gYmUgY2xlYXIgYWJvdXQgd2hhdCBMb1NUIGNsaWVudHMg YXJlIGV4cGVjdGVkIHRvIGRvLiBXZSBkbyBub3Qgd2FudCBhIGxlYXN5DQogaW1wbGVtZW50YXRp b24gc2VuZGluZyAmbHQ7cGxhbm5lZENoYW5nZSZndDsgYWNyb3NzIHRoZSBib2FyZCwgZG9u4oCZ dCB3ZT8gSSB0aGluayBpdCBpcyBlYXN5IGFuZCBjaGVlcCB0byBmaXggaW4gdGhlIGRyYWZ0IHJh dGhlciB0byB0cnkgdG8gZml4IGltcGxlbWVudGF0aW9ucyBsYXRlci48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+R3V5PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkRlJm5ic3A7Ojwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEJyaWFuIFJvc2VuICZsdDtickBi cmlhbnJvc2VuLm5ldCZndDsNCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiAyMyBhb8O7dCAy MDIxIDE4OjE0PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBDYXJvbiwgR3V5ICZsdDtnLmNhcm9uQGJl bGwuY2EmZ3Q7PGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBlY3JpdEBpZXRmLm9yZzxicj4NCjxiPk9i amV0Jm5ic3A7OjwvYj4gW0VYVF1SZTogbG9zdC1wbGFubmVkLWNoYW5nZXMtMDQ6IHBsYW5uZWRD aGFuZ2UgYm91bmQgdG8gdmFsaWRhdGVMb2NhdGlvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUNBIj5TdXJlLCBQU0FQcyBjb3VsZCBiZSBhIExvU1QgY2xpZW50IGZvciBleGFtcGxl LiAmbmJzcDtBIHJvdXRpbmcgcHJveHkgY2FuIGJlIGEgTG9TVCBjbGllbnQuICZuYnNwO0J1dCB0 aGV5IHdvdWxkbuKAmXQgYXNrIHRvIHN0b3JlIHRoZSBVUkkuICZuYnNwO1lvdSBoYXZlIHRvIGFz ayBmb3IgaXQgdG8gZ2V0IHRoZSBub3RpZmljYXRpb24uJm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+QnJpYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIj5PbiBBdWcgMjMsIDIwMjEsIGF0IDY6MTAgUE0sIENhcm9uLCBHdXkgJmx0 Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86Zy5jYXJvbkBiZWxsLmNhIj48c3BhbiBsYW5nPSJFTi1D QSI+Zy5jYXJvbkBiZWxsLmNhPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1DQSI+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUNBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+WW91IG1pc3MgbXkgcG9pbnQuIFRoZSBMb1NUIGNsaWVudCBtYXkgbm90IGJl IGEgTElTLiBJZiB3ZSBtYWtlIGl0IGV4cGxpY2l0IHRoYXQgb25seSBMSVNlcyBhcmUgTG9TVCBj bGllbnRzIGluIHRoZSBjb250ZXh0IG9mIHRoaXMgZHJhZnQsIEkgbWF5DQogbm90IGhhdmUgYXMg c3Ryb25nIG9iamVjdGlvbnMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5H dXk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9z cGFuPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkJyaWFuDQogUm9zZW4gJmx0Ozwvc3Bh bj48YSBocmVmPSJtYWlsdG86YnJAYnJpYW5yb3Nlbi5uZXQiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPmJyQGJyaWFucm9zZW4ubmV0PC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4yMyBhb8O7dCAyMDIxIDE4OjA2PGJyPg0KPGI+w4Am bmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5DYXJvbiwgR3V5ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmcuY2Fyb25AYmVsbC5jYSI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Zy5jYXJvbkBiZWxsLmNhPC9zcGFuPjwvYT48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PGJyPg0KPGI+Q2MmbmJzcDs6PC9iPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PGEg aHJlZj0ibWFpbHRvOmVjcml0QGlldGYub3JnIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5lY3JpdEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5bRVhUXVJlOiBsb3N0LXBsYW5uZWQtY2hhbmdlcy0wNDogcGxhbm5l ZENoYW5nZSBib3VuZCB0byB2YWxpZGF0ZUxvY2F0aW9uPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1D QSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1DQSI+T25seSBpZiBpdCBhc2tlZCBmb3IgaXQsIHBlciBsb2NhdGlvbi4gJm5ic3A7 SXQgYXNrZWQgZm9yIGl0LCBpdCBnb3QgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+SXQgaGFzIE5PVEhJTkcg dG8gZG8gd2l0aCBhY3R1YWwgY2FsbHMuICZuYnNwO0l04oCZcyBqdXN0IGFuIGFsdGVybmF0aXZl IHRvIHBlcmlvZGljIHJldmFsaWRhdGlvbiBmb3IgcmVjb3JkcyBpbiB0aGUgTElTLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1DQSI+QSBtb3JlIGludGVyZXN0aW5nIGlzc3VlIGlzIHdoYXQgZG9lcyBhIExJ UyBkbyB3aGVuIGl0IGRlbGV0ZXMgYSByZWNvcmQgZm9yIHdoaWNoIGEgVVJJIGlzIHN0b3JlZCBp biB0aGUgc2VydmVyLiAmbmJzcDtQcm9iYWJseSBpdCBtYXJrcyB0aGF0IFVSSSBpcyBPQkUuIEFu b3RoZXIgcG9zc2liaWxpdHkgaXMgdGhhdCBpdCBzdG9yZXMgYSBuZXcgVVJJIHRoYXQgaXMgYSBj YXRjaC1hbGwNCiDigJxpZ25vcmUgbWXigJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1DQSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPkhtbW0uICZu YnNwO0kgd29uZGVyIGlmIHdlIHNob3VsZCBoYXZlIGFuIGV4cGxpY2l0IGRlbGV0ZS4gJm5ic3A7 TnVsbCBVUkkgPSBkZWxldGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5CcmlhbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t Q0EiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5PbiBB dWcgMjMsIDIwMjEsIGF0IDY6MDEgUE0sIENhcm9uLCBHdXkgJmx0Ozwvc3Bhbj48YSBocmVmPSJt YWlsdG86Zy5jYXJvbkBiZWxsLmNhIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOnB1 cnBsZSI+Zy5jYXJvbkBiZWxsLmNhPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1DQSI+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QSBMb1NUIGNsaWVu dCB0aGF0IHNlbmRzIHJvdXRpbmcgcmVxdWVzdHMgdG8gdGhlIHNlcnZlciB3b3VsZCByZWNlaXZl LCB3YXkgYWZ0ZXIgY2FsbHMgaGF2ZSBiZWVuIGRlbGl2ZXJlZCwgYSBub3RpZmljYXRpb24gd2l0 aCBhICZsdDtsb2NhdGlvbkludmFsaWQmZ3Q7DQogYm9keS4gV2hhdCB3b3VsZCBpdCBkbyB3aXRo IHRoaXM/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5NYWtlcyBubyBzZW5zZSB0byBtZS48L3NwYW4+PHNwYW4gbGFuZz0i RU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkd1eTwvc3Bh bj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0Ei PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5EZSZuYnNwOzo8L3NwYW4+PC9iPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ QnJpYW4NCiBSb3NlbiAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpickBicmlhbnJvc2VuLm5l dCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGUiPmJyQGJyaWFucm9z ZW4ubmV0PC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPkVudm95 w6kmbmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj4yMyBhb8O7dCAyMDIxIDE3OjU1PGJyPg0KPGI+w4AmbmJzcDs6PC9iPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5DYXJvbiwgR3V5ICZsdDs8L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOmcuY2Fyb25AYmVsbC5jYSI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpwdXJwbGUiPmcuY2Fyb25AYmVsbC5jYTwvc3Bhbj48L2E+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozxicj4NCjxiPkNjJm5ic3A7OjwvYj48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxhIGhyZWY9Im1h aWx0bzplY3JpdEBpZXRmLm9yZyI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpw dXJwbGUiPmVjcml0QGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPltFWFRdUmU6IGxvc3QtcGxhbm5lZC1jaGFuZ2VzLTA0OiBw bGFubmVkQ2hhbmdlIGJvdW5kIHRvIHZhbGlkYXRlTG9jYXRpb24/PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t Q0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5JIGRvbuKAmXQg dW5kZXJzdGFuZCB0aGUgcmVhc29uaW5nIG9uIOKAnGNyZWF0aW5nIGhhdm9j4oCdLiAmbmJzcDtJ IGRvbuKAmXQga25vdyB3aHkgYSBjbGllbnQgd291bGQgZXZlciBkbyBpdCwgYnV0IGl0IOKAnHdv cmtz4oCdIGluIHRoYXQgdGhlIHNlcnZlciBkb2VzbuKAmXQgaGF2ZSB0byB2YWxpZGF0ZSB0byBz YXZlIHRoZSBVUkkuICZuYnNwO0lmIEkgY2xpZW50IHNlbmRzIHRoZSBVUkkgYW5kIGRvZXNu4oCZ dCB2YWxpZGF0ZSwNCiBpdOKAmXMgd2VpcmQsIGJ1dCBub3Qgd3JvbmcuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+V2UgY2FuIGRlY2lkZSB0byBwcm9oaWJpdCBp dC4gJm5ic3A7QnV0IHdlIGRvbuKAmXQgcmVhbGx5IGhhdmUgYSBqdXN0aWZpY2F0aW9uLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+QnJpYW48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+PGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiPk9uIEF1ZyAyMywgMjAyMSwgYXQgNTo0NCBQTSwgQ2Fyb24sIEd1eSAmbHQ7PC9z cGFuPjxhIGhyZWY9Im1haWx0bzpnLmNhcm9uQGJlbGwuY2EiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iY29sb3I6cHVycGxlIj5nLmNhcm9uQGJlbGwuY2E8L3NwYW4+PC9hPjxzcGFuIGxhbmc9 IkVOLUNBIj4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tQ0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGFncmVlIHRoYXQgYWNjb21tb2RhdGlu ZyB0aGlzIGNvbW1lbnQgd291bGQgcmVxdWlyZSBkZWVwZXIgWE1MIGNoYW5nZXMuPC9zcGFuPjxz cGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JZiB3ZSBkbyBub3Qgd2FudCB0byBnbyB0 aGVyZSwgSSB0aGluayB0aGUgZHJhZnQgc2hvdWxkIGJlIGNsZWFyIHRoYXQgdGhlcmUgaXMgbm8g dXNlY2FzZSBmb3Igc2VuZGluZyAmbHQ7cGxhbm5lZENoYW5nZSZndDsgb3V0c2lkZSBvZiBhIGxv Y2F0aW9uIHZhbGlkYXRpb24NCiByZXF1ZXN0IGFuZCBhcyBzdWNoLCBzaG91bGQgbm9ybWF0aXZl bHkgcmVjb21tZW5kIG5vdCBkb2luZyBzby48L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkkgZG8gbm90IGFncmVlIHRoYXQgYSBMb1NUIHNlcnZlciByZWNlaXZpbmcgJmx0 O3BsYW5uZWRDaGFuZ2UmZ3Q7IG91dHNpZGUgb2YgYSBsb2NhdGlvbiB2YWxpZGF0aW9uIHJlcXVl c3Qgd291bGQgcmV0YWluIHRoZSBVUkkgYW5kIHNlbmQgbm90aWZpY2F0aW9uIGlmDQogdGhlIHJl Y29yZCBjaGFuZ2VkIGFmdGVyd2FyZC4gSSB0aGluayB0aGlzIHdvdWxkIGNyZWF0ZSBoYXZvYyBv biB0aGUgY2xpZW504oCZIHNpZGUuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5UaGFua3MsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5HdXk8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9z cGFuPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkJyaWFuDQogUm9zZW4gJmx0Ozwvc3Bh bj48YSBocmVmPSJtYWlsdG86YnJAYnJpYW5yb3Nlbi5uZXQiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6cHVycGxlIj5ickBicmlhbnJvc2VuLm5ldDwvc3Bhbj48L2E+PHNwYW4g bGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+MjMgYW/Du3QgMjAyMSAxNzoy Mjxicj4NCjxiPsOAJm5ic3A7OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+Q2Fyb24sIEd1eSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpnLmNh cm9uQGJlbGwuY2EiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj5n LmNhcm9uQGJlbGwuY2E8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZn dDs8YnI+DQo8Yj5DYyZuYnNwOzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZWNyaXRAaWV0Zi5vcmciPjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj5lY3JpdEBpZXRmLm9yZzwv c3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPGI+T2JqZXQmbmJz cDs6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5b RVhUXVJlOiBsb3N0LXBsYW5uZWQtY2hhbmdlcy0wNDogcGxhbm5lZENoYW5nZSBib3VuZCB0byB2 YWxpZGF0ZUxvY2F0aW9uPzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+dmFs aWRhdGVMb2NhdGlvbiBpcyBhbiBhdHRyaWJ1dGUsIG5vdCBhbiBlbGVtZW50LCBzbyBJIGNhbuKA mXQgZXh0ZW5kIGl0LiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5UaGVyZSBpc27igJl0IGFuIGFj dHVhbCByZXF1aXJlbWVudCB0byB0aWUgcGxhbm5lZENoYW5nZSB0byB2YWxpZGF0ZUxvY2F0aW9u LiAmbmJzcDtJdCBtYXkgbm90IG1ha2UgYSBsb3Qgb2Ygc2Vuc2UsIGJ1dCBpZiB5b3UgZGlkIGl0 LCB0aGUgTG9TVCBzZXJ2ZXIgd291bGQgbm90IHJldHVybiB2YWxpZGF0aW9uIGRhdGEsIHdvdWxk IHJldGFpbiB0aGUgVVJJIGFuZCB3b3VsZCBzZW5kIHRoZQ0KIG5vdGlmaWNhdGlvbiBpZiB0aGUg cmVjb3JkIGNoYW5nZWQuICZuYnNwO05vdGUgbXkgdGV4dCB0aGF0IHRoZSBMb1NUIHNlcnZlciBk b2VzbuKAmXQgc3RvcmUgdGhlIExJIC0gdGhlIG5vdGlmaWNhdGlvbiBpcyDigJxzb21ldGhpbmcg Y2hhbmdlZOKAnSBub3Qg4oCcd2hhdCB5b3Ugc2VudCBpcyBndWFyYW50ZWVkIHRvIGJlIGludmFs aWTigJ0gb3IgZXZlbiDigJxvbmUgb3IgbW9yZSBvZiB0aGUgZWxlbWVudHMgeW91IHNlbnQgY2hh bmdlZCZxdW90Oy4gJm5ic3A7SSB0aG91Z2h0IGFib3V0IGNoYW5naW5nDQogdGhlIG5hbWUgb2Yg dGhlIG5vdGlmaWNhdGlvbiwgYnV0IEkgZGlkbuKAmXQgZG8gdGhhdC4gJm5ic3A7VGhlIHByYWN0 aWNhbCB1c2UgY2FzZSByZW1haW5zIHRoZSBzYW1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+ QnJpYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQ0EiPjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5P biBBdWcgMjMsIDIwMjEsIGF0IDU6MDcgUE0sIENhcm9uLCBHdXkgJmx0Ozwvc3Bhbj48YSBocmVm PSJtYWlsdG86Zy5jYXJvbkBiZWxsLmNhIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9y OnB1cnBsZSI+Zy5jYXJvbkBiZWxsLmNhPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1DQSI+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUNBIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Tm90IGFs bCBMb1NUIHNlcnZlciBpbXBsZW1lbnRhdGlvbnMgcGVyZm9ybSBsb2NhdGlvbiB2YWxpZGF0aW9u cy4gV2hlbiBsb2NhdGlvbiB2YWxpZGF0aW9uIGlzIHJlcXVlc3RlZCBieSB0aGUgY2xpZW50LCBp dCBhZGRzIHRoZSDigJx2YWxpZGF0ZUxvY2F0aW9u4oCdDQogYXR0cmlidXRlIHRvIHRoZSAmbHQ7 ZmluZFNlcnZpY2UmZ3Q7IGVsZW1lbnQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1D QSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TbyB0aGUgcXVlc3Rpb24gaXM6 IFNob3VsZCDigJxwbGFubmVkQ2hhbmdl4oCdIGJlIGJvdW5kIHRvIOKAnHZhbGlkYXRlTG9jYXRp b27igJ0/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5JZiB5b3UgYmVsaWV2ZSBub3QsIHdoYXQgd291bGQgYmUgdGhl IGV4cGVjdGVkIGJlaGF2aW91ciBvZiBhIExvU1Qgc2VydmVyIHJlY2VpdmluZyBhICZsdDtwbGFu bmVkQ2hhbmdlJmd0OyBlbGVtZW50IG91dHNpZGUgb2YgYSB2YWxpZGF0aW9uIHJlcXVlc3Q/PC9z cGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkd1eTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRl ciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Ryb25nPjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+RXh0ZXJuYWwgRW1haWw6PC9zcGFu PjwvaT48L3N0cm9uZz48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48aT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48L2k+PC9z cGFuPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPlBsZWFzZQ0K IHVzZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQgYXR0YWNobWVudHMgLzwvc3Bhbj48 L2VtPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxpPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjwvaT48L3NwYW4+PHN0cm9u Zz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPkNvdXJyaWVsIGV4 dGVybmU6PC9zcGFuPjwvaT48L3N0cm9uZz48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPiZuYnNwOzwv c3Bhbj48L2k+PC9zcGFuPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJs dWUiPlNveWV6DQogcHJ1ZGVudCBhdmVjIGxlcyBsaWVucyBldCBkb2N1bWVudHMgam9pbnRzPC9z cGFuPjwvZW0+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0 LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIi Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzdHJvbmc+PGk+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj5FeHRlcm5hbCBFbWFpbDo8 L3NwYW4+PC9pPjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxp PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjwv aT48L3NwYW4+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+UGxl YXNlDQogdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxpbmtzIGFuZCBhdHRhY2htZW50cyAvPC9z cGFuPjwvZW0+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PC9pPjwvc3Bhbj48 c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+Q291cnJp ZWwgZXh0ZXJuZTo8L3NwYW4+PC9pPjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+Jm5i c3A7PC9zcGFuPjwvaT48L3NwYW4+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29s b3I6Ymx1ZSI+U295ZXoNCiBwcnVkZW50IGF2ZWMgbGVzIGxpZW5zIGV0IGRvY3VtZW50cyBqb2lu dHM8L3NwYW4+PC9lbT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIyIiB3aWR0 aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+ RXh0ZXJuYWwgRW1haWw6PC9zcGFuPjwvaT48L3N0cm9uZz48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUi PiZuYnNwOzwvc3Bhbj48L2k+PC9zcGFuPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2NvbG9yOmJsdWUiPlBsZWFzZQ0KIHVzZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQg YXR0YWNobWVudHMgLzwvc3Bhbj48L2VtPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9z cGFuPjwvaT48L3NwYW4+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Nv bG9yOmJsdWUiPkNvdXJyaWVsIGV4dGVybmU6PC9zcGFuPjwvaT48L3N0cm9uZz48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48L2k+PC9zcGFuPjxlbT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPlNveWV6DQogcHJ1ZGVudCBhdmVjIGxlcyBsaWVucyBl dCBkb2N1bWVudHMgam9pbnRzPC9zcGFuPjwvZW0+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2Vu dGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAl IiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHN0cm9uZz48 aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPkV4dGVybmFsIEVtYWls Ojwvc3Bhbj48L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29s b3I6Ymx1ZSI+IFBsZWFzZSB1c2UgY2F1dGlvbiB3aGVuIG9wZW5pbmcgbGlua3MgYW5kIGF0dGFj aG1lbnRzIC8NCjwvc3Bhbj48L2VtPjxzdHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtjb2xvcjpibHVlIj5Db3VycmllbCBleHRlcm5lOjwvc3Bhbj48L2k+PC9zdHJvbmc+PGVt PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+IFNveWV6IHBydWRlbnQg YXZlYyBsZXMgbGllbnMgZXQgZG9jdW1lbnRzIGpvaW50cw0KPC9zcGFuPjwvZW0+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_cd5677dfaa91450f899a56764c18809abellca_-- From nobody Mon Aug 23 15:34:23 2021 Return-Path: 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 3CE483A209F for ; Mon, 23 Aug 2021 15:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=bell.ca 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 1zEtoe4SdUst for ; Mon, 23 Aug 2021 15:34:15 -0700 (PDT) Received: from ESA2-Dor.bell.ca (esa2-dor.bell.ca [204.101.223.59]) (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 644BA3A1EA0 for ; Mon, 23 Aug 2021 15:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1629758055; x=1661294055; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=z2JYQinPmNFRWE2oUIaviiUGThauOjNGlGB3tnQ92tc=; b=IeiNlK/VLCr4VuyHGEUcO450XR/HaGTya/Us4QInWQvgQGeHj3q56E/8 R0y4xX0Dz9WP5NBk8BIAZ6664KNWmxQrfFJw6bvT6NdKZj7fOeQbrEFPT rwY3XxLdGvCHWWM5/oBE905qbT+5AWrohfkFl81SHrrAgHnxWsb5VUI1p kCtegzUVN+ZLOCkzwFVlwXybCXN8jQdO7yzXgikMmdGAqFnnnDDeX3xnJ YgGJKf2Nbc2ICoxk6nQ9ctRwbjsUDsIi+rXzgXqtl1L+J4UVVRBG8shR3 gJBUu0cR0T5LCUJ3BUAIjKyfIIEtle0ExSXIciUiVtstQ2qTFT3EApgqm g==; IronPort-SDR: UBmiKPf6vEagLFe1YW0+NeYG8H7AnHK24WI/MrUycNkbeAL0VE4UVHzSvKhQ4OpE2kaais6DFH Pbn+HUX7HEPA== Received: from dc5cmy-d01.bellca.int.bell.ca (HELO DG1MBX03-WYN.bell.corp.bce.ca) ([198.235.121.230]) by esa02corp-dor.bell.corp.bce.ca with ESMTP; 23 Aug 2021 18:34:13 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG1MBX03-WYN.bell.corp.bce.ca (142.182.18.13) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 23 Aug 2021 18:34:13 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Mon, 23 Aug 2021 18:34:13 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Mon, 23 Aug 2021 18:34:13 -0400 From: "Caron, Guy" To: Randall Gellens CC: Brian Rosen , "ecrit@ietf.org" Thread-Topic: [EXT]Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation? Thread-Index: AQHXmG6diYrOvVeBqkq3ZlL20BGRLauBrHug Date: Mon, 23 Aug 2021 22:34:13 +0000 Message-ID: <794ed22ebe3e48cdb0e72cf3f0a91429@bell.ca> References: <8bdda7ea7d004b4591ff715526d93a73@bell.ca> <791ea34f628d48d3addeb04613d5721a@bell.ca> <9158D09E-770E-4E65-BE46-E39060EAC884@brianrosen.net> <0b81d439e4824aec8a3476906ce5cbc1@bell.ca> <7C21F96F-E238-4DA2-82BB-D7C731A84D53@brianrosen.net> <038dcfc4405d4ebe8930d6225f09ea83@bell.ca> <6EC6E0D3-B9E8-476D-A6F7-E1D20817B58E@brianrosen.net> <64E97C26-36C8-4024-89E3-E23379E614B5@randy.pensive.org> In-Reply-To: <64E97C26-36C8-4024-89E3-E23379E614B5@randy.pensive.org> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.79] Content-Type: multipart/alternative; boundary="_000_794ed22ebe3e48cdb0e72cf3f0a91429bellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 22:34:21 -0000 --_000_794ed22ebe3e48cdb0e72cf3f0a91429bellca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gbm90IGNvbmNlcm5lZCBhYm91dCBhIGNsaWVudCB0aGF0IHdpbGxmdWxseSBhbmQga25v d2luZ2x5IGFza3MgZm9yIGl0Lg0KDQpUaGlzIHdob2xlIGRyYWZ0IHJldm9sdmVzIGFyb3VuZCBs b2NhdGlvbiB2YWxpZGF0aW9uLiBJ4oCZbSBub3QgdW5kZXJzdGFuZGluZyB0aGUgcHVzaGJhY2sg aGVyZS4NCg0KR3V5DQoNCkRlIDogUmFuZGFsbCBHZWxsZW5zIDxyZytpZXRmQHJhbmR5LnBlbnNp dmUub3JnPg0KRW52b3nDqSA6IDIzIGFvw7t0IDIwMjEgMTg6MzENCsOAIDogQ2Fyb24sIEd1eSA8 Zy5jYXJvbkBiZWxsLmNhPg0KQ2MgOiBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ+OyBl Y3JpdEBpZXRmLm9yZw0KT2JqZXQgOiBbRVhUXVJlOiBbRWNyaXRdIGxvc3QtcGxhbm5lZC1jaGFu Z2VzLTA0OiBwbGFubmVkQ2hhbmdlIGJvdW5kIHRvIHZhbGlkYXRlTG9jYXRpb24/DQoNCg0KSWYg YSBjbGllbnQgd2FudHMgdG8gZ2V0IG5vdGlmaWVkIHRoYXQgYSBsb2NhdGlvbiBtYXkgaGF2ZSBi ZWNvbWUgaW52YWxpZGF0ZWQsIHdoeSBkbyB3ZSBjYXJlIHdoeSBvciB3aGF0IHR5cGUgb2YgY2xp ZW50IGl0IGlzPw0KDQotLVJhbmRhbGwNCg0KT24gMjMgQXVnIDIwMjEsIGF0IDE1OjI2LCBDYXJv biwgR3V5IHdyb3RlOg0KDQpJIHVuZGVyc3RhbmQgYW5kIHdoYXQgSeKAmW0gc3VnZ2VzdGluZyBp cyB0byBiZSBjbGVhciBhYm91dCB3aGF0IExvU1QgY2xpZW50cyBhcmUgZXhwZWN0ZWQgdG8gZG8u IFdlIGRvIG5vdCB3YW50IGEgbGVhc3kgaW1wbGVtZW50YXRpb24gc2VuZGluZyA8cGxhbm5lZENo YW5nZT4gYWNyb3NzIHRoZSBib2FyZCwgZG9u4oCZdCB3ZT8gSSB0aGluayBpdCBpcyBlYXN5IGFu ZCBjaGVlcCB0byBmaXggaW4gdGhlIGRyYWZ0IHJhdGhlciB0byB0cnkgdG8gZml4IGltcGxlbWVu dGF0aW9ucyBsYXRlci4NCg0KDQoNCkd1eQ0KDQoNCg0KRGUgOiBCcmlhbiBSb3NlbiA8YnJAYnJp YW5yb3Nlbi5uZXQ8bWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0Pj4NCkVudm95w6kgOiAyMyBhb8O7 dCAyMDIxIDE4OjE0DQrDgCA6IENhcm9uLCBHdXkgPGcuY2Fyb25AYmVsbC5jYTxtYWlsdG86Zy5j YXJvbkBiZWxsLmNhPj4NCkNjIDogZWNyaXRAaWV0Zi5vcmc8bWFpbHRvOmVjcml0QGlldGYub3Jn Pg0KT2JqZXQgOiBbRVhUXVJlOiBsb3N0LXBsYW5uZWQtY2hhbmdlcy0wNDogcGxhbm5lZENoYW5n ZSBib3VuZCB0byB2YWxpZGF0ZUxvY2F0aW9uPw0KDQoNCg0KU3VyZSwgUFNBUHMgY291bGQgYmUg YSBMb1NUIGNsaWVudCBmb3IgZXhhbXBsZS4gIEEgcm91dGluZyBwcm94eSBjYW4gYmUgYSBMb1NU IGNsaWVudC4gIEJ1dCB0aGV5IHdvdWxkbuKAmXQgYXNrIHRvIHN0b3JlIHRoZSBVUkkuICBZb3Ug aGF2ZSB0byBhc2sgZm9yIGl0IHRvIGdldCB0aGUgbm90aWZpY2F0aW9uLg0KDQoNCg0KQnJpYW4N Cg0KDQoNCk9uIEF1ZyAyMywgMjAyMSwgYXQgNjoxMCBQTSwgQ2Fyb24sIEd1eSA8Zy5jYXJvbkBi ZWxsLmNhPG1haWx0bzpnLmNhcm9uQGJlbGwuY2E+PiB3cm90ZToNCg0KDQoNCllvdSBtaXNzIG15 IHBvaW50LiBUaGUgTG9TVCBjbGllbnQgbWF5IG5vdCBiZSBhIExJUy4gSWYgd2UgbWFrZSBpdCBl eHBsaWNpdCB0aGF0IG9ubHkgTElTZXMgYXJlIExvU1QgY2xpZW50cyBpbiB0aGUgY29udGV4dCBv ZiB0aGlzIGRyYWZ0LCBJIG1heSBub3QgaGF2ZSBhcyBzdHJvbmcgb2JqZWN0aW9ucy4NCg0KDQoN Ckd1eQ0KDQoNCg0KRGUgOiBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ8bWFpbHRvOmJy QGJyaWFucm9zZW4ubmV0Pj4NCkVudm95w6kgOiAyMyBhb8O7dCAyMDIxIDE4OjA2DQrDgCA6IENh cm9uLCBHdXkgPGcuY2Fyb25AYmVsbC5jYTxtYWlsdG86Zy5jYXJvbkBiZWxsLmNhPj4NCkNjIDog ZWNyaXRAaWV0Zi5vcmc8bWFpbHRvOmVjcml0QGlldGYub3JnPg0KT2JqZXQgOiBbRVhUXVJlOiBs b3N0LXBsYW5uZWQtY2hhbmdlcy0wNDogcGxhbm5lZENoYW5nZSBib3VuZCB0byB2YWxpZGF0ZUxv Y2F0aW9uPw0KDQoNCg0KT25seSBpZiBpdCBhc2tlZCBmb3IgaXQsIHBlciBsb2NhdGlvbi4gIEl0 IGFza2VkIGZvciBpdCwgaXQgZ290IGl0Lg0KDQoNCg0KSXQgaGFzIE5PVEhJTkcgdG8gZG8gd2l0 aCBhY3R1YWwgY2FsbHMuICBJdOKAmXMganVzdCBhbiBhbHRlcm5hdGl2ZSB0byBwZXJpb2RpYyBy ZXZhbGlkYXRpb24gZm9yIHJlY29yZHMgaW4gdGhlIExJUy4NCg0KDQoNCkEgbW9yZSBpbnRlcmVz dGluZyBpc3N1ZSBpcyB3aGF0IGRvZXMgYSBMSVMgZG8gd2hlbiBpdCBkZWxldGVzIGEgcmVjb3Jk IGZvciB3aGljaCBhIFVSSSBpcyBzdG9yZWQgaW4gdGhlIHNlcnZlci4gIFByb2JhYmx5IGl0IG1h cmtzIHRoYXQgVVJJIGlzIE9CRS4gQW5vdGhlciBwb3NzaWJpbGl0eSBpcyB0aGF0IGl0IHN0b3Jl cyBhIG5ldyBVUkkgdGhhdCBpcyBhIGNhdGNoLWFsbCDigJxpZ25vcmUgbWXigJ0NCg0KDQoNCkht bW0uICBJIHdvbmRlciBpZiB3ZSBzaG91bGQgaGF2ZSBhbiBleHBsaWNpdCBkZWxldGUuICBOdWxs IFVSSSA9IGRlbGV0ZS4NCg0KDQoNCkJyaWFuDQoNCg0KDQoNCg0KT24gQXVnIDIzLCAyMDIxLCBh dCA2OjAxIFBNLCBDYXJvbiwgR3V5IDxnLmNhcm9uQGJlbGwuY2E8bWFpbHRvOmcuY2Fyb25AYmVs bC5jYT4+IHdyb3RlOg0KDQoNCg0KQSBMb1NUIGNsaWVudCB0aGF0IHNlbmRzIHJvdXRpbmcgcmVx dWVzdHMgdG8gdGhlIHNlcnZlciB3b3VsZCByZWNlaXZlLCB3YXkgYWZ0ZXIgY2FsbHMgaGF2ZSBi ZWVuIGRlbGl2ZXJlZCwgYSBub3RpZmljYXRpb24gd2l0aCBhIDxsb2NhdGlvbkludmFsaWQ+IGJv ZHkuIFdoYXQgd291bGQgaXQgZG8gd2l0aCB0aGlzPw0KDQoNCg0KTWFrZXMgbm8gc2Vuc2UgdG8g bWUuDQoNCg0KDQpHdXkNCg0KDQoNCkRlIDogQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0 PG1haWx0bzpickBicmlhbnJvc2VuLm5ldD4+DQpFbnZvecOpIDogMjMgYW/Du3QgMjAyMSAxNzo1 NQ0Kw4AgOiBDYXJvbiwgR3V5IDxnLmNhcm9uQGJlbGwuY2E8bWFpbHRvOmcuY2Fyb25AYmVsbC5j YT4+DQpDYyA6IGVjcml0QGlldGYub3JnPG1haWx0bzplY3JpdEBpZXRmLm9yZz4NCk9iamV0IDog W0VYVF1SZTogbG9zdC1wbGFubmVkLWNoYW5nZXMtMDQ6IHBsYW5uZWRDaGFuZ2UgYm91bmQgdG8g dmFsaWRhdGVMb2NhdGlvbj8NCg0KDQoNCkkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSByZWFzb25p bmcgb24g4oCcY3JlYXRpbmcgaGF2b2PigJ0uICBJIGRvbuKAmXQga25vdyB3aHkgYSBjbGllbnQg d291bGQgZXZlciBkbyBpdCwgYnV0IGl0IOKAnHdvcmtz4oCdIGluIHRoYXQgdGhlIHNlcnZlciBk b2VzbuKAmXQgaGF2ZSB0byB2YWxpZGF0ZSB0byBzYXZlIHRoZSBVUkkuICBJZiBJIGNsaWVudCBz ZW5kcyB0aGUgVVJJIGFuZCBkb2VzbuKAmXQgdmFsaWRhdGUsIGl04oCZcyB3ZWlyZCwgYnV0IG5v dCB3cm9uZy4NCg0KDQoNCldlIGNhbiBkZWNpZGUgdG8gcHJvaGliaXQgaXQuICBCdXQgd2UgZG9u 4oCZdCByZWFsbHkgaGF2ZSBhIGp1c3RpZmljYXRpb24uDQoNCg0KDQpCcmlhbg0KDQoNCg0KDQpP biBBdWcgMjMsIDIwMjEsIGF0IDU6NDQgUE0sIENhcm9uLCBHdXkgPGcuY2Fyb25AYmVsbC5jYTxt YWlsdG86Zy5jYXJvbkBiZWxsLmNhPj4gd3JvdGU6DQoNCg0KDQpJIGFncmVlIHRoYXQgYWNjb21t b2RhdGluZyB0aGlzIGNvbW1lbnQgd291bGQgcmVxdWlyZSBkZWVwZXIgWE1MIGNoYW5nZXMuDQoN Cg0KDQpJZiB3ZSBkbyBub3Qgd2FudCB0byBnbyB0aGVyZSwgSSB0aGluayB0aGUgZHJhZnQgc2hv dWxkIGJlIGNsZWFyIHRoYXQgdGhlcmUgaXMgbm8gdXNlY2FzZSBmb3Igc2VuZGluZyA8cGxhbm5l ZENoYW5nZT4gb3V0c2lkZSBvZiBhIGxvY2F0aW9uIHZhbGlkYXRpb24gcmVxdWVzdCBhbmQgYXMg c3VjaCwgc2hvdWxkIG5vcm1hdGl2ZWx5IHJlY29tbWVuZCBub3QgZG9pbmcgc28uDQoNCg0KDQpJ IGRvIG5vdCBhZ3JlZSB0aGF0IGEgTG9TVCBzZXJ2ZXIgcmVjZWl2aW5nIDxwbGFubmVkQ2hhbmdl PiBvdXRzaWRlIG9mIGEgbG9jYXRpb24gdmFsaWRhdGlvbiByZXF1ZXN0IHdvdWxkIHJldGFpbiB0 aGUgVVJJIGFuZCBzZW5kIG5vdGlmaWNhdGlvbiBpZiB0aGUgcmVjb3JkIGNoYW5nZWQgYWZ0ZXJ3 YXJkLiBJIHRoaW5rIHRoaXMgd291bGQgY3JlYXRlIGhhdm9jIG9uIHRoZSBjbGllbnTigJkgc2lk ZS4NCg0KDQoNClRoYW5rcywNCg0KDQoNCkd1eQ0KDQoNCg0KRGUgOiBCcmlhbiBSb3NlbiA8YnJA YnJpYW5yb3Nlbi5uZXQ8bWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0Pj4NCkVudm95w6kgOiAyMyBh b8O7dCAyMDIxIDE3OjIyDQrDgCA6IENhcm9uLCBHdXkgPGcuY2Fyb25AYmVsbC5jYTxtYWlsdG86 Zy5jYXJvbkBiZWxsLmNhPj4NCkNjIDogZWNyaXRAaWV0Zi5vcmc8bWFpbHRvOmVjcml0QGlldGYu b3JnPg0KT2JqZXQgOiBbRVhUXVJlOiBsb3N0LXBsYW5uZWQtY2hhbmdlcy0wNDogcGxhbm5lZENo YW5nZSBib3VuZCB0byB2YWxpZGF0ZUxvY2F0aW9uPw0KDQoNCg0KdmFsaWRhdGVMb2NhdGlvbiBp cyBhbiBhdHRyaWJ1dGUsIG5vdCBhbiBlbGVtZW50LCBzbyBJIGNhbuKAmXQgZXh0ZW5kIGl0Lg0K DQoNCg0KVGhlcmUgaXNu4oCZdCBhbiBhY3R1YWwgcmVxdWlyZW1lbnQgdG8gdGllIHBsYW5uZWRD aGFuZ2UgdG8gdmFsaWRhdGVMb2NhdGlvbi4gIEl0IG1heSBub3QgbWFrZSBhIGxvdCBvZiBzZW5z ZSwgYnV0IGlmIHlvdSBkaWQgaXQsIHRoZSBMb1NUIHNlcnZlciB3b3VsZCBub3QgcmV0dXJuIHZh bGlkYXRpb24gZGF0YSwgd291bGQgcmV0YWluIHRoZSBVUkkgYW5kIHdvdWxkIHNlbmQgdGhlIG5v dGlmaWNhdGlvbiBpZiB0aGUgcmVjb3JkIGNoYW5nZWQuICBOb3RlIG15IHRleHQgdGhhdCB0aGUg TG9TVCBzZXJ2ZXIgZG9lc27igJl0IHN0b3JlIHRoZSBMSSAtIHRoZSBub3RpZmljYXRpb24gaXMg 4oCcc29tZXRoaW5nIGNoYW5nZWTigJ0gbm90IOKAnHdoYXQgeW91IHNlbnQgaXMgZ3VhcmFudGVl ZCB0byBiZSBpbnZhbGlk4oCdIG9yIGV2ZW4g4oCcb25lIG9yIG1vcmUgb2YgdGhlIGVsZW1lbnRz IHlvdSBzZW50IGNoYW5nZWQiLiAgSSB0aG91Z2h0IGFib3V0IGNoYW5naW5nIHRoZSBuYW1lIG9m IHRoZSBub3RpZmljYXRpb24sIGJ1dCBJIGRpZG7igJl0IGRvIHRoYXQuICBUaGUgcHJhY3RpY2Fs IHVzZSBjYXNlIHJlbWFpbnMgdGhlIHNhbWUuDQoNCg0KDQpCcmlhbg0KDQoNCg0KDQoNCk9uIEF1 ZyAyMywgMjAyMSwgYXQgNTowNyBQTSwgQ2Fyb24sIEd1eSA8Zy5jYXJvbkBiZWxsLmNhPG1haWx0 bzpnLmNhcm9uQGJlbGwuY2E+PiB3cm90ZToNCg0KDQoNCk5vdCBhbGwgTG9TVCBzZXJ2ZXIgaW1w bGVtZW50YXRpb25zIHBlcmZvcm0gbG9jYXRpb24gdmFsaWRhdGlvbnMuIFdoZW4gbG9jYXRpb24g dmFsaWRhdGlvbiBpcyByZXF1ZXN0ZWQgYnkgdGhlIGNsaWVudCwgaXQgYWRkcyB0aGUg4oCcdmFs aWRhdGVMb2NhdGlvbuKAnSBhdHRyaWJ1dGUgdG8gdGhlIDxmaW5kU2VydmljZT4gZWxlbWVudC4N Cg0KDQoNClNvIHRoZSBxdWVzdGlvbiBpczogU2hvdWxkIOKAnHBsYW5uZWRDaGFuZ2XigJ0gYmUg Ym91bmQgdG8g4oCcdmFsaWRhdGVMb2NhdGlvbuKAnT8NCg0KDQoNCklmIHlvdSBiZWxpZXZlIG5v dCwgd2hhdCB3b3VsZCBiZSB0aGUgZXhwZWN0ZWQgYmVoYXZpb3VyIG9mIGEgTG9TVCBzZXJ2ZXIg cmVjZWl2aW5nIGEgPHBsYW5uZWRDaGFuZ2U+IGVsZW1lbnQgb3V0c2lkZSBvZiBhIHZhbGlkYXRp b24gcmVxdWVzdD8NCg0KDQoNClRoYW5rcywNCg0KDQoNCkd1eQ0KDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KRXh0ZXJuYWwgRW1haWw6IFBsZWFzZSB1c2UgY2F1dGlv biB3aGVuIG9wZW5pbmcgbGlua3MgYW5kIGF0dGFjaG1lbnRzIC8gQ291cnJpZWwgZXh0ZXJuZTog U295ZXogcHJ1ZGVudCBhdmVjIGxlcyBsaWVucyBldCBkb2N1bWVudHMgam9pbnRzDQoNCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpFeHRlcm5hbCBFbWFpbDogUGxlYXNl IHVzZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQgYXR0YWNobWVudHMgLyBDb3Vycmll bCBleHRlcm5lOiBTb3lleiBwcnVkZW50IGF2ZWMgbGVzIGxpZW5zIGV0IGRvY3VtZW50cyBqb2lu dHMNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkV4dGVybmFsIEVt YWlsOiBQbGVhc2UgdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxpbmtzIGFuZCBhdHRhY2htZW50 cyAvIENvdXJyaWVsIGV4dGVybmU6IFNveWV6IHBydWRlbnQgYXZlYyBsZXMgbGllbnMgZXQgZG9j dW1lbnRzIGpvaW50cw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K RXh0ZXJuYWwgRW1haWw6IFBsZWFzZSB1c2UgY2F1dGlvbiB3aGVuIG9wZW5pbmcgbGlua3MgYW5k IGF0dGFjaG1lbnRzIC8gQ291cnJpZWwgZXh0ZXJuZTogU295ZXogcHJ1ZGVudCBhdmVjIGxlcyBs aWVucyBldCBkb2N1bWVudHMgam9pbnRzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpFY3JpdCBtYWlsaW5nIGxpc3QNCkVjcml0QGlldGYub3JnPG1h aWx0bzpFY3JpdEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZWNyaXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkV4dGVybmFsIEVt YWlsOiBQbGVhc2UgdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxpbmtzIGFuZCBhdHRhY2htZW50 cyAvIENvdXJyaWVsIGV4dGVybmU6IFNveWV6IHBydWRlbnQgYXZlYyBsZXMgbGllbnMgZXQgZG9j dW1lbnRzIGpvaW50cw0K --_000_794ed22ebe3e48cdb0e72cf3f0a91429bellca_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJ e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSLUNB IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPknigJltIG5vdCBjb25jZXJuZWQg YWJvdXQgYSBjbGllbnQgdGhhdCB3aWxsZnVsbHkgYW5kIGtub3dpbmdseSBhc2tzIGZvciBpdC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+VGhpcyB3aG9sZSBkcmFmdCByZXZvbHZlcyBhcm91bmQgbG9jYXRpb24gdmFsaWRh dGlvbi4gSeKAmW0gbm90IHVuZGVyc3RhbmRpbmcgdGhlIHB1c2hiYWNrIGhlcmUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi Pkd1eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5EZSZuYnNwOzo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBSYW5kYWxsIEdlbGxlbnMgJmx0 O3JnJiM0MztpZXRmQHJhbmR5LnBlbnNpdmUub3JnJmd0Ow0KPGJyPg0KPGI+RW52b3nDqSZuYnNw Ozo8L2I+IDIzIGFvw7t0IDIwMjEgMTg6MzE8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IENhcm9uLCBH dXkgJmx0O2cuY2Fyb25AYmVsbC5jYSZndDs8YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IEJyaWFuIFJv c2VuICZsdDtickBicmlhbnJvc2VuLm5ldCZndDs7IGVjcml0QGlldGYub3JnPGJyPg0KPGI+T2Jq ZXQmbmJzcDs6PC9iPiBbRVhUXVJlOiBbRWNyaXRdIGxvc3QtcGxhbm5lZC1jaGFuZ2VzLTA0OiBw bGFubmVkQ2hhbmdlIGJvdW5kIHRvIHZhbGlkYXRlTG9jYXRpb24/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SWYgYSBjbGllbnQgd2FudHMgdG8gZ2V0IG5vdGlmaWVk IHRoYXQgYSBsb2NhdGlvbiBtYXkgaGF2ZSBiZWNvbWUgaW52YWxpZGF0ZWQsIHdoeSBkbyB3ZSBj YXJlIHdoeSBvciB3aGF0IHR5cGUgb2YgY2xpZW50IGl0IGlzPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj4tLVJhbmRhbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+T24gMjMgQXVnIDIwMjEsIGF0 IDE1OjI2LCBDYXJvbiwgR3V5IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICM3Nzc3Nzcg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdDttYXJnaW4tbGVmdDowY207bWFyZ2luLXJp Z2h0OjBjbTttYXJnaW4tYm90dG9tOjMuNzVwdCI+DQo8ZGl2IGlkPSJEOTlFRDRDOS1DMDQ2LTQ1 QjEtQUIzQy0yMUQxN0RDREMxNUQiPg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIHVuZGVyc3RhbmQgYW5kIHdoYXQgSeKA mW0gc3VnZ2VzdGluZyBpcyB0byBiZSBjbGVhciBhYm91dCB3aGF0IExvU1QgY2xpZW50cyBhcmUg ZXhwZWN0ZWQgdG8gZG8uDQogV2UgZG8gbm90IHdhbnQgYSBsZWFzeSBpbXBsZW1lbnRhdGlvbiBz ZW5kaW5nICZsdDtwbGFubmVkQ2hhbmdlJmd0OyBhY3Jvc3MgdGhlIGJvYXJkLCBkb27igJl0IHdl PyBJIHRoaW5rIGl0IGlzIGVhc3kgYW5kIGNoZWVwIHRvIGZpeCBpbiB0aGUgZHJhZnQgcmF0aGVy IHRvIHRyeSB0byBmaXggaW1wbGVtZW50YXRpb25zIGxhdGVyLjwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjow Y207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkd1eTwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg c3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImNvbG9yOiM3Nzc3Nzc7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIHN0eWxlPSJtYXJnaW46MGNt O21hcmdpbi1ib3R0b206LjAwMDFwdCI+PGI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojNzc3Nzc3Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6Izc3Nzc3NyI+IEJyaWFuIFJvc2VuDQogJmx0OzxhIGhyZWY9Im1haWx0bzpi ckBicmlhbnJvc2VuLm5ldCI+YnJAYnJpYW5yb3Nlbi5uZXQ8L2E+Jmd0OyA8YnI+DQo8Yj5FbnZv ecOpJm5ic3A7OjwvYj4gMjMgYW/Du3QgMjAyMSAxODoxNDxicj4NCjxiPsOAJm5ic3A7OjwvYj4g Q2Fyb24sIEd1eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmcuY2Fyb25AYmVsbC5jYSI+Zy5jYXJvbkBi ZWxsLmNhPC9hPiZndDs8YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IDxhIGhyZWY9Im1haWx0bzplY3Jp dEBpZXRmLm9yZyI+ZWNyaXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBb RVhUXVJlOiBsb3N0LXBsYW5uZWQtY2hhbmdlcy0wNDogcGxhbm5lZENoYW5nZSBib3VuZCB0byB2 YWxpZGF0ZUxvY2F0aW9uPzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21h cmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjojNzc3 Nzc3Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij5TdXJlLCBQU0FQcyBjb3Vs ZCBiZSBhIExvU1QgY2xpZW50IGZvciBleGFtcGxlLiAmbmJzcDtBIHJvdXRpbmcgcHJveHkgY2Fu IGJlIGEgTG9TVCBjbGllbnQuICZuYnNwO0J1dCB0aGV5IHdvdWxkbuKAmXQgYXNrIHRvIHN0b3Jl IHRoZSBVUkkuICZuYnNwO1lvdSBoYXZlIHRvIGFzayBmb3IgaXQgdG8gZ2V0IHRoZSBub3RpZmlj YXRpb24uJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTou MDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOiM3Nzc3NzciPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0 Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOiM3Nzc3NzciPkJyaWFuPC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4t Ym90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDowY20iPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3 NzciPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJn aW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJj b2xvcjojNzc3Nzc3Ij5PbiBBdWcgMjMsIDIwMjEsIGF0IDY6MTAgUE0sIENhcm9uLCBHdXkgJmx0 Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PGEgaHJlZj0ibWFpbHRvOmcuY2Fy b25AYmVsbC5jYSI+PHNwYW4gbGFuZz0iRU4tQ0EiPmcuY2Fyb25AYmVsbC5jYTwvc3Bhbj48L2E+ PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+Jmd0Ow0KIHdy b3RlOjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQi PjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+Jm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4g bGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Zb3UgbWlzcyBteSBwb2ludC4g VGhlIExvU1QgY2xpZW50IG1heSBub3QgYmUgYSBMSVMuIElmIHdlIG1ha2UgaXQgZXhwbGljaXQg dGhhdCBvbmx5IExJU2VzIGFyZSBMb1NUIGNsaWVudHMgaW4gdGhlIGNvbnRleHQNCiBvZiB0aGlz IGRyYWZ0LCBJIG1heSBub3QgaGF2ZSBhcyBzdHJvbmcgb2JqZWN0aW9ucy48L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5HdXk8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIHN0 eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3 Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9t Oi4wMDAxcHQiPjxiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+ RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3 Nzc3NzciPiZuYnNwO0JyaWFuIFJvc2VuDQogJmx0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 Izc3Nzc3NyI+PGEgaHJlZj0ibWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0Ij48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5ickBicmlhbnJvc2VuLm5ldDwvc3Bhbj48L2E+PC9zcGFuPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+Jmd0OyZuYnNwOzxicj4NCjxi PkVudm95w6kmbmJzcDs6PC9iPiZuYnNwOzIzIGFvw7t0IDIwMjEgMTg6MDY8YnI+DQo8Yj7DgCZu YnNwOzo8L2I+Jm5ic3A7Q2Fyb24sIEd1eSAmbHQ7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjoj Nzc3Nzc3Ij48YSBocmVmPSJtYWlsdG86Zy5jYXJvbkBiZWxsLmNhIj48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5nLmNhcm9uQGJlbGwuY2E8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPiZndDs8YnI+DQo8Yj5DYyZuYnNwOzo8 L2I+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48YSBocmVmPSJtYWls dG86ZWNyaXRAaWV0Zi5vcmciPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmVjcml0QGll dGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNzc3Nzc3Ij48YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+Jm5ic3A7W0VYVF1SZTogbG9zdC1w bGFubmVkLWNoYW5nZXMtMDQ6IHBsYW5uZWRDaGFuZ2UgYm91bmQgdG8gdmFsaWRhdGVMb2NhdGlv bj88L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTtt YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6Izc3 Nzc3NyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+ T25seSBpZiBpdCBhc2tlZCBmb3IgaXQsIHBlciBsb2NhdGlvbi4gJm5ic3A7SXQgYXNrZWQgZm9y IGl0LCBpdCBnb3QgaXQuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjow Y207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9y OiM3Nzc3NzciPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9 Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImNvbG9yOiM3Nzc3NzciPkl0IGhhcyBOT1RISU5HIHRvIGRvIHdpdGggYWN0dWFsIGNhbGxz LiAmbmJzcDtJdOKAmXMganVzdCBhbiBhbHRlcm5hdGl2ZSB0byBwZXJpb2RpYyByZXZhbGlkYXRp b24gZm9yIHJlY29yZHMgaW4gdGhlIExJUy48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3 NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij5BIG1vcmUgaW50ZXJlc3Rpbmcg aXNzdWUgaXMgd2hhdCBkb2VzIGEgTElTIGRvIHdoZW4gaXQgZGVsZXRlcyBhIHJlY29yZCBmb3Ig d2hpY2ggYSBVUkkgaXMgc3RvcmVkIGluIHRoZSBzZXJ2ZXIuICZuYnNwO1Byb2JhYmx5IGl0IG1h cmtzIHRoYXQgVVJJIGlzIE9CRS4gQW5vdGhlciBwb3NzaWJpbGl0eSBpcw0KIHRoYXQgaXQgc3Rv cmVzIGEgbmV3IFVSSSB0aGF0IGlzIGEgY2F0Y2gtYWxsIOKAnGlnbm9yZSBtZeKAnTwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRv bTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOiM3Nzc3NzciPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFy Z2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOiM3Nzc3 NzciPkhtbW0uICZuYnNwO0kgd29uZGVyIGlmIHdlIHNob3VsZCBoYXZlIGFuIGV4cGxpY2l0IGRl bGV0ZS4gJm5ic3A7TnVsbCBVUkkgPSBkZWxldGUuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjoj Nzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQi PjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+QnJpYW48L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206 LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTtt YXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjBjbSI+DQo8 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxicj4NCjxicj4NCjwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTou MDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOiM3Nzc3NzciPk9uIEF1ZyAy MywgMjAyMSwgYXQgNjowMSBQTSwgQ2Fyb24sIEd1eSAmbHQ7PC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjojNzc3Nzc3Ij48YSBocmVmPSJtYWlsdG86Zy5jYXJvbkBiZWxsLmNhIj48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImNvbG9yOnB1cnBsZSI+Zy5jYXJvbkBiZWxsLmNhPC9zcGFuPjwvYT48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij4mZ3Q7DQogd3Jv dGU6PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1i b3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij4m bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkEgTG9TVCBjbGllbnQgdGhhdCBzZW5kcyByb3V0aW5nIHJlcXVlc3RzIHRvIHRo ZSBzZXJ2ZXIgd291bGQgcmVjZWl2ZSwgd2F5IGFmdGVyIGNhbGxzIGhhdmUgYmVlbiBkZWxpdmVy ZWQsIGEgbm90aWZpY2F0aW9uDQogd2l0aCBhICZsdDtsb2NhdGlvbkludmFsaWQmZ3Q7IGJvZHku IFdoYXQgd291bGQgaXQgZG8gd2l0aCB0aGlzPzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3 Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0 Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk1ha2VzIG5vIHNl bnNlIHRvIG1lLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdp bjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg c3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkd1eTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOiM3Nzc3NzciPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxl PSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PGI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+Jm5ic3A7QnJpYW4gUm9zZW4NCiAmbHQ7 PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48YSBocmVmPSJtYWlsdG86YnJAYnJp YW5yb3Nlbi5uZXQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj5i ckBicmlhbnJvc2VuLm5ldDwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6Izc3Nzc3NyI+Jmd0OyZuYnNwOzxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9i PiZuYnNwOzIzIGFvw7t0IDIwMjEgMTc6NTU8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+Jm5ic3A7Q2Fy b24sIEd1eSAmbHQ7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48YSBocmVmPSJt YWlsdG86Zy5jYXJvbkBiZWxsLmNhIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OnB1cnBsZSI+Zy5jYXJvbkBiZWxsLmNhPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij4mZ3Q7PGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PGEgaHJlZj0ibWFpbHRvOmVj cml0QGlldGYub3JnIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZSI+ ZWNyaXRAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM3Nzc3NzciPjxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4mbmJzcDtbRVhUXVJl OiBsb3N0LXBsYW5uZWQtY2hhbmdlcy0wNDogcGxhbm5lZENoYW5nZSBib3VuZCB0byB2YWxpZGF0 ZUxvY2F0aW9uPzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij5JIGRvbuKAmXQgdW5kZXJzdGFu ZCB0aGUgcmVhc29uaW5nIG9uIOKAnGNyZWF0aW5nIGhhdm9j4oCdLiAmbmJzcDtJIGRvbuKAmXQg a25vdyB3aHkgYSBjbGllbnQgd291bGQgZXZlciBkbyBpdCwgYnV0IGl0IOKAnHdvcmtz4oCdIGlu IHRoYXQgdGhlIHNlcnZlciBkb2VzbuKAmXQgaGF2ZSB0byB2YWxpZGF0ZSB0byBzYXZlIHRoZSBV UkkuDQogJm5ic3A7SWYgSSBjbGllbnQgc2VuZHMgdGhlIFVSSSBhbmQgZG9lc27igJl0IHZhbGlk YXRlLCBpdOKAmXMgd2VpcmQsIGJ1dCBub3Qgd3JvbmcuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0 Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOiM3Nzc3NzciPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjow Y207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9y OiM3Nzc3NzciPldlIGNhbiBkZWNpZGUgdG8gcHJvaGliaXQgaXQuICZuYnNwO0J1dCB3ZSBkb27i gJl0IHJlYWxseSBoYXZlIGEganVzdGlmaWNhdGlvbi48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206 LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJt YXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJjb2xvcjojNzc3Nzc3Ij5Ccmlhbjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2lu LXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDowY20iPg0KPHNwYW4g bGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48YnI+DQo8YnI+DQo8YnI+DQo8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGNt O21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjoj Nzc3Nzc3Ij5PbiBBdWcgMjMsIDIwMjEsIGF0IDU6NDQgUE0sIENhcm9uLCBHdXkgJmx0Ozwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PGEgaHJlZj0ibWFpbHRvOmcuY2Fyb25AYmVs bC5jYSI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmcuY2Fyb25AYmVs bC5jYTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6Izc3 Nzc3NyI+Jmd0Ow0KIHdyb3RlOjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0 b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5J IGFncmVlIHRoYXQgYWNjb21tb2RhdGluZyB0aGlzIGNvbW1lbnQgd291bGQgcmVxdWlyZSBkZWVw ZXIgWE1MIGNoYW5nZXMuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJn aW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+SWYgd2UgZG8gbm90IHdhbnQgdG8gZ28gdGhlcmUsIEkgdGhpbmsgdGhlIGRyYWZ0IHNo b3VsZCBiZSBjbGVhciB0aGF0IHRoZXJlIGlzIG5vIHVzZWNhc2UgZm9yIHNlbmRpbmcgJmx0O3Bs YW5uZWRDaGFuZ2UmZ3Q7IG91dHNpZGUNCiBvZiBhIGxvY2F0aW9uIHZhbGlkYXRpb24gcmVxdWVz dCBhbmQgYXMgc3VjaCwgc2hvdWxkIG5vcm1hdGl2ZWx5IHJlY29tbWVuZCBub3QgZG9pbmcgc28u PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0i bWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3 Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBkbyBub3Qg YWdyZWUgdGhhdCBhIExvU1Qgc2VydmVyIHJlY2VpdmluZyAmbHQ7cGxhbm5lZENoYW5nZSZndDsg b3V0c2lkZSBvZiBhIGxvY2F0aW9uIHZhbGlkYXRpb24gcmVxdWVzdCB3b3VsZCByZXRhaW4gdGhl IFVSSQ0KIGFuZCBzZW5kIG5vdGlmaWNhdGlvbiBpZiB0aGUgcmVjb3JkIGNoYW5nZWQgYWZ0ZXJ3 YXJkLiBJIHRoaW5rIHRoaXMgd291bGQgY3JlYXRlIGhhdm9jIG9uIHRoZSBjbGllbnTigJkgc2lk ZS48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxl PSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3 Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAw MDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3Ms PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0i bWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3 Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+R3V5PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2lu OjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29s b3I6Izc3Nzc3NyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdp bjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48Yj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM3Nzc3NzciPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij4mbmJzcDtCcmlhbiBSb3Nlbg0KICZsdDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxhIGhyZWY9Im1haWx0bzpickBicmlhbnJvc2Vu Lm5ldCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGUiPmJyQGJyaWFu cm9zZW4ubmV0PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojNzc3Nzc3Ij4mZ3Q7Jm5ic3A7PGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+Jm5ic3A7 MjMgYW/Du3QgMjAyMSAxNzoyMjxicj4NCjxiPsOAJm5ic3A7OjwvYj4mbmJzcDtDYXJvbiwgR3V5 ICZsdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxhIGhyZWY9Im1haWx0bzpn LmNhcm9uQGJlbGwuY2EiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxl Ij5nLmNhcm9uQGJlbGwuY2E8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiM3Nzc3NzciPiZndDs8YnI+DQo8Yj5DYyZuYnNwOzo8L2I+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48YSBocmVmPSJtYWlsdG86ZWNyaXRAaWV0 Zi5vcmciPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj5lY3JpdEBp ZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6Izc3Nzc3NyI+PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiZuYnNwO1tFWFRdUmU6IGxvc3Qt cGxhbm5lZC1jaGFuZ2VzLTA0OiBwbGFubmVkQ2hhbmdlIGJvdW5kIHRvIHZhbGlkYXRlTG9jYXRp b24/PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3Bh biBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOiM3Nzc3NzciPiZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFy Z2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOiM3Nzc3 NzciPnZhbGlkYXRlTG9jYXRpb24gaXMgYW4gYXR0cmlidXRlLCBub3QgYW4gZWxlbWVudCwgc28g SSBjYW7igJl0IGV4dGVuZCBpdC4gJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3 Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRv bTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOiM3Nzc3NzciPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOiM3Nzc3NzciPlRoZXJlIGlzbuKAmXQgYW4gYWN0dWFs IHJlcXVpcmVtZW50IHRvIHRpZSBwbGFubmVkQ2hhbmdlIHRvIHZhbGlkYXRlTG9jYXRpb24uICZu YnNwO0l0IG1heSBub3QgbWFrZSBhIGxvdCBvZiBzZW5zZSwgYnV0IGlmIHlvdSBkaWQgaXQsIHRo ZSBMb1NUIHNlcnZlciB3b3VsZCBub3QgcmV0dXJuIHZhbGlkYXRpb24NCiBkYXRhLCB3b3VsZCBy ZXRhaW4gdGhlIFVSSSBhbmQgd291bGQgc2VuZCB0aGUgbm90aWZpY2F0aW9uIGlmIHRoZSByZWNv cmQgY2hhbmdlZC4gJm5ic3A7Tm90ZSBteSB0ZXh0IHRoYXQgdGhlIExvU1Qgc2VydmVyIGRvZXNu 4oCZdCBzdG9yZSB0aGUgTEkgLSB0aGUgbm90aWZpY2F0aW9uIGlzIOKAnHNvbWV0aGluZyBjaGFu Z2Vk4oCdIG5vdCDigJx3aGF0IHlvdSBzZW50IGlzIGd1YXJhbnRlZWQgdG8gYmUgaW52YWxpZOKA nSBvciBldmVuIOKAnG9uZSBvciBtb3JlIG9mIHRoZQ0KIGVsZW1lbnRzIHlvdSBzZW50IGNoYW5n ZWQmcXVvdDsuICZuYnNwO0kgdGhvdWdodCBhYm91dCBjaGFuZ2luZyB0aGUgbmFtZSBvZiB0aGUg bm90aWZpY2F0aW9uLCBidXQgSSBkaWRu4oCZdCBkbyB0aGF0LiAmbmJzcDtUaGUgcHJhY3RpY2Fs IHVzZSBjYXNlIHJlbWFpbnMgdGhlIHNhbWUuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3 Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJn aW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6Izc3Nzc3 NyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQi PjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+QnJpYW48L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdp bi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjBjbSI+DQo8c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImNvbG9yOiM3Nzc3NzciPjxicj4NCjxicj4NCjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdp bjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNv bG9yOiM3Nzc3NzciPk9uIEF1ZyAyMywgMjAyMSwgYXQgNTowNyBQTSwgQ2Fyb24sIEd1eSAmbHQ7 PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48YSBocmVmPSJtYWlsdG86Zy5jYXJv bkBiZWxsLmNhIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOnB1cnBsZSI+Zy5jYXJv bkBiZWxsLmNhPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xv cjojNzc3Nzc3Ij4mZ3Q7DQogd3JvdGU6PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206 LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk5vdCBhbGwgTG9TVCBzZXJ2ZXIgaW1w bGVtZW50YXRpb25zIHBlcmZvcm0gbG9jYXRpb24gdmFsaWRhdGlvbnMuIFdoZW4gbG9jYXRpb24g dmFsaWRhdGlvbiBpcyByZXF1ZXN0ZWQgYnkgdGhlIGNsaWVudCwgaXQNCiBhZGRzIHRoZSDigJx2 YWxpZGF0ZUxvY2F0aW9u4oCdIGF0dHJpYnV0ZSB0byB0aGUgJmx0O2ZpbmRTZXJ2aWNlJmd0OyBl bGVtZW50Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg c3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNvIHRoZSBxdWVzdGlvbiBpczogU2hvdWxkIOKA nHBsYW5uZWRDaGFuZ2XigJ0gYmUgYm91bmQgdG8g4oCcdmFsaWRhdGVMb2NhdGlvbuKAnT88L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJn aW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5JZiB5b3UgYmVsaWV2ZSBub3QsIHdoYXQgd291bGQgYmUgdGhlIGV4 cGVjdGVkIGJlaGF2aW91ciBvZiBhIExvU1Qgc2VydmVyIHJlY2VpdmluZyBhICZsdDtwbGFubmVk Q2hhbmdlJmd0OyBlbGVtZW50IG91dHNpZGUgb2YgYQ0KIHZhbGlkYXRpb24gcmVxdWVzdD88L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJn aW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5UaGFua3MsPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQi PjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+R3V5PC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4w MDAxcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBzdHls ZT0iY29sb3I6Izc3Nzc3NyI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50 ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdp bjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+RXh0ZXJuYWwgRW1haWw6PC9zcGFuPjwvaT48L3N0cm9u Zz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPiZuYnNwOzxlbT5Q bGVhc2UgdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxpbmtzIGFuZCBhdHRhY2htZW50cyAvPC9l bT4mbmJzcDs8c3Ryb25nPkNvdXJyaWVsDQogZXh0ZXJuZTo8L3N0cm9uZz4mbmJzcDs8ZW0+U295 ZXogcHJ1ZGVudCBhdmVjIGxlcyBsaWVucyBldCBkb2N1bWVudHMgam9pbnRzPC9lbT48L3NwYW4+ PC9pPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxl PSJjb2xvcjojNzc3Nzc3Ij4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRl ciI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21h cmdpbi1ib3R0b206LjAwMDFwdCI+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2NvbG9yOmJsdWUiPkV4dGVybmFsIEVtYWlsOjwvc3Bhbj48L2k+PC9zdHJvbmc+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj4mbmJzcDs8ZW0+UGxlYXNlIHVz ZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQgYXR0YWNobWVudHMgLzwvZW0+Jm5ic3A7 PHN0cm9uZz5Db3VycmllbA0KIGV4dGVybmU6PC9zdHJvbmc+Jm5ic3A7PGVtPlNveWV6IHBydWRl bnQgYXZlYyBsZXMgbGllbnMgZXQgZG9jdW1lbnRzIGpvaW50czwvZW0+PC9zcGFuPjwvaT48c3Bh biBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1h cmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3 NyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48 c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFs aWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGNt O21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2NvbG9yOmJsdWUiPkV4dGVybmFsIEVtYWlsOjwvc3Bhbj48L2k+PC9zdHJvbmc+PGk+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj4mbmJzcDs8ZW0+UGxlYXNl IHVzZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQgYXR0YWNobWVudHMgLzwvZW0+Jm5i c3A7PHN0cm9uZz5Db3VycmllbA0KIGV4dGVybmU6PC9zdHJvbmc+Jm5ic3A7PGVtPlNveWV6IHBy dWRlbnQgYXZlYyBsZXMgbGllbnMgZXQgZG9jdW1lbnRzIGpvaW50czwvZW0+PC9zcGFuPjwvaT48 c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFy Z2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gc3R5bGU9ImNvbG9yOiM3 Nzc3NzciPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bh bj48L2Rpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHN0 cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPkV4dGVybmFs IEVtYWlsOjwvc3Bhbj48L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Y29sb3I6Ymx1ZSI+IFBsZWFzZSB1c2UgY2F1dGlvbiB3aGVuIG9wZW5pbmcgbGlua3MgYW5k IGF0dGFjaG1lbnRzIC8NCjwvc3Bhbj48L2VtPjxzdHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtjb2xvcjpibHVlIj5Db3VycmllbCBleHRlcm5lOjwvc3Bhbj48L2k+PC9zdHJv bmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+IFNveWV6IHBy dWRlbnQgYXZlYyBsZXMgbGllbnMgZXQgZG9jdW1lbnRzIGpvaW50cw0KPC9zcGFuPjwvZW0+PHNw YW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICM3Nzc3NzcgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdDttYXJnaW4tbGVmdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjMuNzVw dCI+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNzc3Nzc3Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCkVjcml0IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpF Y3JpdEBpZXRmLm9yZyI+RWNyaXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM3 Nzc3NzciPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQ8L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWdu OmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Y29sb3I6Ymx1ZSI+RXh0ZXJuYWwgRW1haWw6PC9zcGFuPjwvaT48L3N0cm9uZz48 ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj4gUGxlYXNlIHVzZSBj YXV0aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQgYXR0YWNobWVudHMgLw0KPC9zcGFuPjwvZW0+ PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPkNvdXJy aWVsIGV4dGVybmU6PC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtjb2xvcjpibHVlIj4gU295ZXogcHJ1ZGVudCBhdmVjIGxlcyBsaWVucyBldCBkb2N1 bWVudHMgam9pbnRzDQo8L3NwYW4+PC9lbT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_794ed22ebe3e48cdb0e72cf3f0a91429bellca_-- From nobody Mon Aug 23 16:11:57 2021 Return-Path: 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 672793A0818 for ; Mon, 23 Aug 2021 16:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, 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.20150623.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 jmPDiiL_JzFu for ; Mon, 23 Aug 2021 16:11:48 -0700 (PDT) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 548373A0817 for ; Mon, 23 Aug 2021 16:11:48 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id x5so18726824ill.3 for ; Mon, 23 Aug 2021 16:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ZsYuOA7PrASRCRSsqFNooClUwGkp7QhxpNDb3YgwKnI=; b=n+TNf/DkKCxfP8I/cfve1EpWI216U44/z+PwBdvIAZC+faVA4QIbt6X1NNDfKRVLPG 7aeL9105lrlr7Ufnvw2G6srOrA7qqPn/AwE+QWl6CXy5xBraPQEeyV6BZ7ufB+EZD8LE DPmz1jc6nn/Te3kokW+8abe6KQwL7MO7XRTYUyzoKQt9xywOFAi6ScMCsdYrjfYso2kQ kF6HkdrLpIhzY/uoRWa1tb5dV6SVRMEJunuCjH92UxsKL530acy7ddtJBUFhsuxBaBhV DHc0Z/V5mbG9sOtKyMdND/N5qmn4v9j77liRlCoLgrmYRl01EL9CrhxcfISgbbL5M0Vc +pyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ZsYuOA7PrASRCRSsqFNooClUwGkp7QhxpNDb3YgwKnI=; b=t17fA3LxLZOG+6EAVtbLs8wE0fTdbkshZgmhet/w2J/VdFRcoog+92l1JnKdhniKog ISCWL8QYW0kR4SwuLW+xlX3rsk9Gk9VFp50QWGFNhHMfwGfaqJAYOLWEty0vUV4tOERE p1fyESacW8D3WQz9LPT+eImujrBw6s8LkNFMf6alttrohKJPGwG5J4JwNxpNa3zJNmVr EV4F3ETCIs2qMWoCMKd1A+Hs5qBUIepyM8oIFoebn606CSsuY3bX2N3+9czkJJY57WOC RrOVly4ktwhG6+EpSBr91HYBTH9SMOMcUqpFszbtODKC+sHNQRYJExim3/ysFXWgYk02 xaMg== X-Gm-Message-State: AOAM530sJhNqp+Az6Qhud3bhh8dPOY0QKy9Yrzk6h+ct3uOFHyHyFkGk 3iw3gVQWvz5JCfEhfDEwpfZc8A== X-Google-Smtp-Source: ABdhPJxkqniya8xKo6+H8zrsIW5iLHTYDeabHAG4hRH+zR9P6nVXecZeXcMQxR2rDCHnRzQ4cLobxg== X-Received: by 2002:a05:6e02:154a:: with SMTP id j10mr5281295ilu.79.1629760307409; Mon, 23 Aug 2021 16:11:47 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id d8sm8396205ilv.55.2021.08.23.16.11.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Aug 2021 16:11:46 -0700 (PDT) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3EA375AC-C98A-45E3-864F-73509C0D8E81" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Mon, 23 Aug 2021 19:11:45 -0400 In-Reply-To: Cc: "Caron, Guy" , ecrit@ietf.org To: Randall Gellens References: <8508C216-7FF5-41D2-A78D-EBF475F83C7F@randy.pensive.org> <9FA8CD6B-0DF0-4D30-A182-1AF77A155871@randy.pensive.org> <955D85AF-7FFE-416C-A28B-E4A4C65A1E00@brianrosen.net> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: Locations are not always invalidated X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 23:11:56 -0000 --Apple-Mail=_3EA375AC-C98A-45E3-864F-73509C0D8E81 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Anything that shows up on the unchecked list. An example might be the = NAM element, The US has pretty tight rules on this, so it really would = only be for things like NAM if you had no elements on the invalid list. = But other countries may not have as stringent rules as the US on how the = invalid/unchecked lists are populated. Brian > On Aug 23, 2021, at 6:29 PM, Randall Gellens = wrote: >=20 > I interpreted it as allowing a server to save URIs but for an = approximate location rather than an exact one, or not associated with a = location, and hence it would send a notification if a change might = invalidate the location in the query that supplied the URI. If that's = not what we mean, then let's be explicit about what we do mean. Under = what circumstances would a LoST server save a URI and know that the = location in the query might be invalidated but not know for sure? >=20 > --Randall >=20 > On 23 Aug 2021, at 15:22, Brian Rosen wrote: >=20 > The MAY is because it may not allow/have room/=E2=80=A6 for the URI = (or not implement it). If you think the text would allow it, for = example, to send a notification where some location other than the one = the URI was sent on changed, then I would like to prohibit that. I = especially don=E2=80=99t want a lazy server sending notifications all = over the place when some change to some location was made, and it sends = notifications to every URI it has.=20 >=20 > Hmmm. We might want to say that if the location was invalid = (regardless of whether validation was requested), and the LI sent = matches more than one location, the server MUST NOT save the URI, and = MUST send the error. The text that says you may get a notification even = if it=E2=80=99s still valid could be expanded to cover that case as an = alternative to that. >=20 > Brian >=20 >> On Aug 23, 2021, at 6:12 PM, Randall Gellens = > wrote: >>=20 >> In my suggested edits I changed this to add "may". >>=20 >> --Randall >>=20 >> On 23 Aug 2021, at 15:08, Caron, Guy wrote: >>=20 >> Taken from section 3: >> =20 >> The URI will be stored by the server against the location in the = request for subsequent use with the notification function defined = below. >> =20 >> Guy >> =20 >> De : Randall Gellens >=20 >> Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:51 >> =C3=80 : Caron, Guy > >> Cc : Brian Rosen >; = ecrit@ietf.org >> Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: Locations are not = always invalidated >> =20 >> I don't know that that's true. My interpretation is that a LoST = server might maintain a list of URIs but not associate each with = specific location records, and when there is a change, it would then = send a notification to each stored URI. The location that was used for = the original validation query might not be impacted. >>=20 >> --Randall >>=20 >> On 23 Aug 2021, at 14:48, Caron, Guy wrote: >>=20 >> I think these locations are impacted in one way or the other = otherwise, the LoST server would not be able to determine that it should = send notifications; they may just not become invalid in the LoST sense. >>=20 >> =20 >> Thanks, >>=20 >> =20 >> Guy >>=20 >> =20 >> =20 >> =20 >> De : Randall Gellens >=20 >> Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:42 >> =C3=80 : Caron, Guy > >> Cc : Brian Rosen >; = ecrit@ietf.org >> Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: Locations are not = always invalidated >>=20 >> =20 >> Using 'impacted' is not really better, because a location may or may = not actually be impacted. If we go down the path of precise names we = should use something such as 'locationPotentiallyInvalidated', which = seems silly. I think the draft makes it clear (especially with my = suggested edits) that a notified location is potentially invalidated. >>=20 >> --Randall >>=20 >> On 23 Aug 2021, at 14:24, Caron, Guy wrote: >>=20 >> This new version introduces variability in whether a location is = indeed invalidated or not by a change, which I agree with. >>=20 >> =20 >> Given this, the names =E2=80=9ClocationInvalidated=E2=80=9D and = =E2=80=9CinvalidatedAsOf=E2=80=9D seem misleading. Should = =E2=80=9Cinvalidated=E2=80=9D be changed to something like = =E2=80=9CImpacted=E2=80=9D? >>=20 >> =20 >> Thanks, >>=20 >> =20 >> Guy >>=20 >> =20 >> =20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit = >> External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints >>=20 >> External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints >=20 --Apple-Mail=_3EA375AC-C98A-45E3-864F-73509C0D8E81 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Anything that shows up on the unchecked list.  An = example might be the NAM element,   The US has pretty tight rules = on this, so it really would only be for things like NAM if you had no = elements on the invalid list.  But other countries may not have as = stringent rules as the US on how the invalid/unchecked lists are = populated.

Brian

On Aug 23, 2021, at 6:29 PM, Randall Gellens = <rg+ietf@randy.pensive.org> wrote:

I = interpreted it as allowing a server to save URIs but for an approximate = location rather than an exact one, or not associated with a location, = and hence it would send a notification if a change might invalidate the = location in the query that supplied the URI. If that's not what we = mean, then let's be explicit about what we do mean. Under what = circumstances would a LoST server save a URI and know that the location = in the query might be invalidated but not know for sure?

--Randall

On 23 = Aug 2021, at 15:22, Brian Rosen wrote:

The MAY is because it may not allow/have = room/=E2=80=A6 for the URI (or not implement it).  If you think the = text would allow it, for example, to send a notification where some = location other than the one the URI was sent on changed, then I would = like to prohibit that.  I especially don=E2=80=99t want a lazy = server sending notifications all over the place when some change to some = location was made, and it sends notifications to every URI it = has. 

Hmmm. =  We might want to say that if the location was invalid (regardless = of whether validation was requested), and the LI sent matches more than = one location, the server MUST NOT save the URI, and MUST send the error. =  The text that says you may get a notification even if it=E2=80=99s = still valid could be expanded to cover that case as an alternative to = that.

Brian

On Aug = 23, 2021, at 6:12 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

In my = suggested edits I changed this to add "may".

--Randall

On 23 Aug 2021, at = 15:08, Caron, Guy wrote:

Taken from section = 3:

 

The URI will be stored by the server against the location in = the request for subsequent use with the notification function = defined  below.

 

Guy

 

De : Randall Gellens <rg+ietf@randy.pensive.org>
Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:51
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : Brian Rosen <br@brianrosen.net>; = ecrit@ietf.org
Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: = Locations are not always invalidated

 

I don't = know that that's true. My interpretation is that a LoST server might = maintain a list of URIs but not associate each with specific location = records, and when there is a change, it would then send a notification to each stored URI. The location that was used for the original = validation query might not be impacted.

--Randall

On 23 Aug = 2021, at 14:48, Caron, Guy wrote:

I think these locations = are impacted in one way or the other otherwise, the LoST server would = not be able to determine that it should send notifications; they may just not become invalid in the LoST = sense.

 

Thanks,

 

Guy

 
 
 

De : Randall Gellens <rg+ietf@randy.pensive.org>
Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:42
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : Brian Rosen <br@brianrosen.net>; ecrit@ietf.org
Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: = Locations are not always invalidated

 

Using 'impacted' is not really better, because a location may = or may not actually be impacted. If we go down the path of precise names = we should use something such as 'locationPotentiallyInvalidated', which seems silly. I think the draft makes it clear (especially with my = suggested edits) that a notified location is potentially = invalidated.

--Randall

On 23 Aug 2021, at 14:24, Caron, Guy wrote:

This new version = introduces variability in whether a location is indeed invalidated or = not by a change, which I agree with.

 

Given this, the names = =E2=80=9ClocationInvalidated=E2=80=9D and =E2=80=9CinvalidatedAsOf=E2=80=9D= seem misleading. Should =E2=80=9Cinvalidated=E2=80=9D be changed to = something like =E2=80=9CImpacted=E2=80=9D?

 

Thanks,

 

Guy

 
 

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

External = Email: Please use caution when = opening links and attachments / Courriel = externe: Soyez prudent avec les = liens et documents joints

External Email: Please use caution when = opening links and attachments / Courriel = externe: Soyez prudent avec les = liens et documents joints


= --Apple-Mail=_3EA375AC-C98A-45E3-864F-73509C0D8E81-- From nobody Mon Aug 23 16:17:59 2021 Return-Path: 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 0A7A23A08A6 for ; Mon, 23 Aug 2021 16:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 ZuzxyX6dzWSc for ; Mon, 23 Aug 2021 16:17:50 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 467973A089B for ; Mon, 23 Aug 2021 16:17:50 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 23 Aug 2021 15:17:50 -0700 From: "Randall Gellens" To: "Caron, Guy" Cc: "Brian Rosen" , ecrit@ietf.org Date: Mon, 23 Aug 2021 15:17:50 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <25050ACE-D481-42D7-8D74-9F2DD0220C41@randy.pensive.org> In-Reply-To: <038dcfc4405d4ebe8930d6225f09ea83@bell.ca> References: <8bdda7ea7d004b4591ff715526d93a73@bell.ca> <791ea34f628d48d3addeb04613d5721a@bell.ca> <9158D09E-770E-4E65-BE46-E39060EAC884@brianrosen.net> <0b81d439e4824aec8a3476906ce5cbc1@bell.ca> <7C21F96F-E238-4DA2-82BB-D7C731A84D53@brianrosen.net> <038dcfc4405d4ebe8930d6225f09ea83@bell.ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_03AEC4FC-A8C2-4702-946C-96C8CB744941_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[500, 20483], "plain":[169, 4594], "uuid":"F7535A32-18CE-4D71-8C80-176FA4626C49"}] Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 23:17:56 -0000 --=_MailMate_03AEC4FC-A8C2-4702-946C-96C8CB744941_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit It doesn't matter if the client is a LIS or not. The client won't get a notification unless it asks for one. --Randall On 23 Aug 2021, at 15:10, Caron, Guy wrote: > You miss my point. The LoST client may not be a LIS. If we make it > explicit that only LISes are LoST clients in the context of this > draft, I may not have as strong objections. > > Guy > > De : Brian Rosen > Envoyé : 23 août 2021 18:06 > À : Caron, Guy > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to > validateLocation? > > Only if it asked for it, per location. It asked for it, it got it. > > It has NOTHING to do with actual calls. It’s just an alternative to > periodic revalidation for records in the LIS. > > A more interesting issue is what does a LIS do when it deletes a > record for which a URI is stored in the server. Probably it marks > that URI is OBE. Another possibility is that it stores a new URI that > is a catch-all “ignore me†> > Hmmm. I wonder if we should have an explicit delete. Null URI = > delete. > > Brian > > > > On Aug 23, 2021, at 6:01 PM, Caron, Guy > > wrote: > > A LoST client that sends routing requests to the server would receive, > way after calls have been delivered, a notification with a > body. What would it do with this? > > Makes no sense to me. > > Guy > > De : Brian Rosen > > Envoyé : 23 août 2021 17:55 > À : Caron, Guy > > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to > validateLocation? > > I don’t understand the reasoning on “creating havocâ€. I don’t > know why a client would ever do it, but it “works†in that the > server doesn’t have to validate to save the URI. If I client sends > the URI and doesn’t validate, it’s weird, but not wrong. > > We can decide to prohibit it. But we don’t really have a > justification. > > Brian > > > > On Aug 23, 2021, at 5:44 PM, Caron, Guy > > wrote: > > I agree that accommodating this comment would require deeper XML > changes. > > If we do not want to go there, I think the draft should be clear that > there is no usecase for sending outside of a location > validation request and as such, should normatively recommend not doing > so. > > I do not agree that a LoST server receiving outside of > a location validation request would retain the URI and send > notification if the record changed afterward. I think this would > create havoc on the client’ side. > > Thanks, > > Guy > > De : Brian Rosen > > Envoyé : 23 août 2021 17:22 > À : Caron, Guy > > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to > validateLocation? > > validateLocation is an attribute, not an element, so I can’t extend > it. > > There isn’t an actual requirement to tie plannedChange to > validateLocation. It may not make a lot of sense, but if you did it, > the LoST server would not return validation data, would retain the URI > and would send the notification if the record changed. Note my text > that the LoST server doesn’t store the LI - the notification is > “something changed†not “what you sent is guaranteed to be > invalid†or even “one or more of the elements you sent changed". > I thought about changing the name of the notification, but I didn’t > do that. The practical use case remains the same. > > Brian > > > > > On Aug 23, 2021, at 5:07 PM, Caron, Guy > > wrote: > > Not all LoST server implementations perform location validations. When > location validation is requested by the client, it adds the > “validateLocation†attribute to the element. > > So the question is: Should “plannedChange†be bound to > “validateLocationâ€? > > If you believe not, what would be the expected behaviour of a LoST > server receiving a element outside of a validation > request? > > Thanks, > > Guy > > ________________________________ > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints > > ________________________________ > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints > > ________________________________ > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --=_MailMate_03AEC4FC-A8C2-4702-946C-96C8CB744941_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">It doesn't matter if the client is a LIS or not. The clie= nt won't get a notification unless it asks for one.

--Randall

On 23 Aug 2021, at 15:10, Caron, Guy wrote:

You miss my point. The LoST client may not be a LIS. If we make it exp= licit that only LISes are LoST clients in the context of this draft, I may not have as strong objections.

=C2=A0

Guy

=C2=A0

De=C2=A0: Brian Rosen = <br@brianrosen.net>
Envoy=C3=A9=C2=A0: 23 ao=C3=BBt 2021 18:06
=C3=80=C2=A0: Caron, Guy <g.caron@bell.ca>
Cc=C2=A0: ecrit@ietf.org
Objet=C2=A0: [EXT]Re: lost-planned-changes-04: plannedChange bound= to validateLocation?

=C2=A0

Only if it asked for it, per location. =C2=A0I= t asked for it, it got it.

=C2=A0

It has NOTHING to do with actual calls. =C2=A0= It=E2=80=99s just an alternative to periodic revalidation for records in = the LIS.

=C2=A0

A more interesting issue is what does a LIS do= when it deletes a record for which a URI is stored in the server. =C2=A0= Probably it marks that URI is OBE. Another possibility is that it stores = a new URI that is a catch-all =E2=80=9Cignore me=E2=80=9D

=C2=A0

Hmmm. =C2=A0I wonder if we should have an expl= icit delete. =C2=A0Null URI =3D delete.

=C2=A0

Brian

=C2=A0



On Aug 23, 2021, at 6:01 PM, Caron, Guy <g.caron@bell.ca> wrote:

=C2=A0

A LoST client that sends= routing requests to the server would receive, way after calls have been = delivered, a notification with a <locationInvalid> body. What would it do with this?

=C2=A0

Makes no sense to me.

=C2=A0

Guy

=C2=A0

De=C2=A0:=C2=A0Brian Rosen <br@brianrosen.net>= =C2=A0
Envoy=C3=A9=C2=A0:=C2=A023 ao=C3=BBt 2021 17:55
=C3=80=C2=A0:= =C2=A0Caron, Guy <g.caron@be= ll.ca>
Cc=C2=A0:=C2=A0= ecrit@ietf.org
Objet=C2=A0:=C2= =A0[EXT]Re: lost-planned-changes-04: plannedChange bound to valida= teLocation?

=C2=A0

I don=E2=80=99t understand the reasoning on =E2= =80=9Ccreating havoc=E2=80=9D. =C2=A0I don=E2=80=99t know why a client wo= uld ever do it, but it =E2=80=9Cworks=E2=80=9D in that the server doesn=E2= =80=99t have to validate to save the URI. =C2=A0If I client sends the URI= and doesn=E2=80=99t validate, it=E2=80=99s weird, but not wrong.

=C2=A0

We can decide to prohibit it. =C2=A0But we don= =E2=80=99t really have a justification.

=C2=A0

Brian




On Aug 23, 2021, at 5:44 PM, Caron, Guy <g.caron@bel= l.ca> wrote:

=C2=A0

I agree that accommodati= ng this comment would require deeper XML changes.

=C2=A0

If we do not want to go = there, I think the draft should be clear that there is no usecase for sen= ding <plannedChange> outside of a location validation request and as such, should normatively recommend not doing so.

=C2=A0

I do not agree that a Lo= ST server receiving <plannedChange> outside of a location validatio= n request would retain the URI and send notification if the record changed afterward. I think this would create havoc on the cli= ent=E2=80=99 side.

=C2=A0

Thanks,

=C2=A0

Guy

=C2=A0

De=C2=A0:=C2=A0Brian Rosen <br@brianrosen.net>=C2=A0
Envoy=C3=A9=C2=A0:=C2=A023 ao=C3=BBt 2021 17:22
=C3=80=C2=A0:= =C2=A0Caron, Guy <g.caron@bell.ca>
Cc=C2=A0:=C2=A0= ecr= it@ietf.org
Objet=C2=A0:=C2= =A0[EXT]Re: lost-planned-changes-04: plannedChange bound to valida= teLocation?

=C2=A0

validateLocation is an attribute, not an eleme= nt, so I can=E2=80=99t extend it. =C2=A0

=C2=A0

There isn=E2=80=99t an actual requirement to t= ie plannedChange to validateLocation. =C2=A0It may not make a lot of sens= e, but if you did it, the LoST server would not return validation data, w= ould retain the URI and would send the notification if the record changed. =C2=A0Note my text that the LoST server doesn=E2=80=99t = store the LI - the notification is =E2=80=9Csomething changed=E2=80=9D no= t =E2=80=9Cwhat you sent is guaranteed to be invalid=E2=80=9D or even =E2= =80=9Cone or more of the elements you sent changed". =C2=A0I thought abou= t changing the name of the notification, but I didn=E2=80=99t do that. =C2=A0The practical use = case remains the same.

=C2=A0

Brian





On Aug 23, 2021, at 5:07 PM, Caron, Guy <g.caron@bel= l.ca> wrote:

=C2=A0

Not all LoST server impl= ementations perform location validations. When location validation is req= uested by the client, it adds the =E2=80=9CvalidateLocation=E2=80=9D attribute to the <findService> element.

=C2=A0

So the question is: Shou= ld =E2=80=9CplannedChange=E2=80=9D be bound to =E2=80=9CvalidateLocation=E2= =80=9D?

=C2=A0

If you believe not, what= would be the expected behaviour of a LoST server receiving a <planned= Change> element outside of a validation request?

=C2=A0

Thanks,

=C2=A0

Guy

=C2=A0

External Email:=C2=A0= Please use caution when opening links and attachments /=C2=A0Courriel externe:=C2=A0Soyez prudent avec les liens et documents joints

=C2=A0

External Email:=C2=A0= Please use caution when opening links and attachments /=C2=A0Courriel externe:=C2=A0Soyez prudent avec les liens et documents joints

=C2=A0

External Email: Please use caution when opening links and attachments= / Courrie= l externe: Soyez prudent avec les liens et documents joints

______________________= _________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

--=_MailMate_03AEC4FC-A8C2-4702-946C-96C8CB744941_=-- From nobody Mon Aug 23 16:18:05 2021 Return-Path: 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 87C143A089B for ; Mon, 23 Aug 2021 16:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 gCwLhLsgZlAq for ; Mon, 23 Aug 2021 16:17:50 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id C28893A089F for ; Mon, 23 Aug 2021 16:17:50 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 23 Aug 2021 15:31:01 -0700 From: "Randall Gellens" To: "Caron, Guy" Cc: "Brian Rosen" , ecrit@ietf.org Date: Mon, 23 Aug 2021 15:31:01 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <64E97C26-36C8-4024-89E3-E23379E614B5@randy.pensive.org> In-Reply-To: References: <8bdda7ea7d004b4591ff715526d93a73@bell.ca> <791ea34f628d48d3addeb04613d5721a@bell.ca> <9158D09E-770E-4E65-BE46-E39060EAC884@brianrosen.net> <0b81d439e4824aec8a3476906ce5cbc1@bell.ca> <7C21F96F-E238-4DA2-82BB-D7C731A84D53@brianrosen.net> <038dcfc4405d4ebe8930d6225f09ea83@bell.ca> <6EC6E0D3-B9E8-476D-A6F7-E1D20817B58E@brianrosen.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_08071BD5-5AC6-46E1-9FD3-DA87AFDB4753_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[518, 29340], "plain":[187, 5650], "uuid":"D99ED4C9-C046-45B1-AB3C-21D17DCDC15D"}] Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 23:17:57 -0000 --=_MailMate_08071BD5-5AC6-46E1-9FD3-DA87AFDB4753_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit If a client wants to get notified that a location may have become invalidated, why do we care why or what type of client it is? --Randall On 23 Aug 2021, at 15:26, Caron, Guy wrote: > I understand and what I’m suggesting is to be clear about what LoST > clients are expected to do. We do not want a leasy implementation > sending across the board, don’t we? I think it is > easy and cheep to fix in the draft rather to try to fix > implementations later. > > Guy > > De : Brian Rosen > Envoyé : 23 août 2021 18:14 > À : Caron, Guy > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to > validateLocation? > > Sure, PSAPs could be a LoST client for example. A routing proxy can > be a LoST client. But they wouldn’t ask to store the URI. You have > to ask for it to get the notification. > > Brian > > > On Aug 23, 2021, at 6:10 PM, Caron, Guy > > wrote: > > You miss my point. The LoST client may not be a LIS. If we make it > explicit that only LISes are LoST clients in the context of this > draft, I may not have as strong objections. > > Guy > > De : Brian Rosen > > Envoyé : 23 août 2021 18:06 > À : Caron, Guy > > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to > validateLocation? > > Only if it asked for it, per location. It asked for it, it got it. > > It has NOTHING to do with actual calls. It’s just an alternative to > periodic revalidation for records in the LIS. > > A more interesting issue is what does a LIS do when it deletes a > record for which a URI is stored in the server. Probably it marks > that URI is OBE. Another possibility is that it stores a new URI that > is a catch-all “ignore me†> > Hmmm. I wonder if we should have an explicit delete. Null URI = > delete. > > Brian > > > > > On Aug 23, 2021, at 6:01 PM, Caron, Guy > > wrote: > > A LoST client that sends routing requests to the server would receive, > way after calls have been delivered, a notification with a > body. What would it do with this? > > Makes no sense to me. > > Guy > > De : Brian Rosen > > Envoyé : 23 août 2021 17:55 > À : Caron, Guy > > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to > validateLocation? > > I don’t understand the reasoning on “creating havocâ€. I don’t > know why a client would ever do it, but it “works†in that the > server doesn’t have to validate to save the URI. If I client sends > the URI and doesn’t validate, it’s weird, but not wrong. > > We can decide to prohibit it. But we don’t really have a > justification. > > Brian > > > > > On Aug 23, 2021, at 5:44 PM, Caron, Guy > > wrote: > > I agree that accommodating this comment would require deeper XML > changes. > > If we do not want to go there, I think the draft should be clear that > there is no usecase for sending outside of a location > validation request and as such, should normatively recommend not doing > so. > > I do not agree that a LoST server receiving outside of > a location validation request would retain the URI and send > notification if the record changed afterward. I think this would > create havoc on the client’ side. > > Thanks, > > Guy > > De : Brian Rosen > > Envoyé : 23 août 2021 17:22 > À : Caron, Guy > > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to > validateLocation? > > validateLocation is an attribute, not an element, so I can’t extend > it. > > There isn’t an actual requirement to tie plannedChange to > validateLocation. It may not make a lot of sense, but if you did it, > the LoST server would not return validation data, would retain the URI > and would send the notification if the record changed. Note my text > that the LoST server doesn’t store the LI - the notification is > “something changed†not “what you sent is guaranteed to be > invalid†or even “one or more of the elements you sent changed". > I thought about changing the name of the notification, but I didn’t > do that. The practical use case remains the same. > > Brian > > > > > > On Aug 23, 2021, at 5:07 PM, Caron, Guy > > wrote: > > Not all LoST server implementations perform location validations. When > location validation is requested by the client, it adds the > “validateLocation†attribute to the element. > > So the question is: Should “plannedChange†be bound to > “validateLocationâ€? > > If you believe not, what would be the expected behaviour of a LoST > server receiving a element outside of a validation > request? > > Thanks, > > Guy > > ________________________________ > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints > > ________________________________ > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints > > ________________________________ > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints > > ________________________________ > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --=_MailMate_08071BD5-5AC6-46E1-9FD3-DA87AFDB4753_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">If a client wants to get notified that a location may have= become invalidated, why do we care why or what type of client it is?

=

--Randall

On 23 Aug 2021, at 15:26, Caron, Guy wrote:

I understand and what I=E2=80=99m suggesting is to be clear about what= LoST clients are expected to do. We do not want a leasy implementation sending <plannedChange> across the board, don=E2=80= =99t we? I think it is easy and cheep to fix in the draft rather to try t= o fix implementations later.

=C2=A0

Guy

=C2=A0

De=C2=A0: Brian = Rosen <br@brianrosen.net>
Envoy=C3=A9=C2=A0: 23 ao=C3=BBt 2021 18:14
=C3=80=C2=A0: Caron, Guy <g.caron@bell.ca>
Cc=C2=A0: ecrit@ietf.org
Objet=C2=A0: [EXT]Re: lost-planned-changes-04: plannedChange bound= to validateLocation?

=C2=A0

Sure, PSAPs could be a Lo= ST client for example. =C2=A0A routing proxy can be a LoST client. =C2=A0= But they wouldn=E2=80=99t ask to store the URI. =C2=A0You have to ask for= it to get the notification.=C2=A0

=C2=A0

Brian



On Aug 23, 2021, at 6:10 = PM, Caron, Guy <g.caron@bell.ca> wrote:=

=C2=A0

You miss my point. The L= oST client may not be a LIS. If we make it explicit that only LISes are L= oST clients in the context of this draft, I may not have as strong objections.

=C2=A0

Guy

=C2=A0

De=C2=A0:=C2=A0Brian Rosen <br@brianro= sen.net>=C2=A0
Envoy=C3=A9=C2=A0:=C2=A023 ao=C3=BBt 2021 18:06
=C3=80=C2=A0:= =C2=A0Caron, Guy <g.caron@bell.ca>
Cc=C2=A0:=C2=A0= ecrit@ietf.org
Objet=C2=A0:=C2= =A0[EXT]Re: lost-planned-changes-04: plannedChange bound to valida= teLocation?

=C2=A0

Only if it asked for it, = per location. =C2=A0It asked for it, it got it.

=C2=A0

It has NOTHING to do with= actual calls. =C2=A0It=E2=80=99s just an alternative to periodic revalid= ation for records in the LIS.

=C2=A0

A more interesting issue = is what does a LIS do when it deletes a record for which a URI is stored = in the server. =C2=A0Probably it marks that URI is OBE. Another possibili= ty is that it stores a new URI that is a catch-all =E2=80=9Cignore me=E2=80=9D

=C2=A0

Hmmm. =C2=A0I wonder if w= e should have an explicit delete. =C2=A0Null URI =3D delete.

=C2=A0

Brian

=C2=A0




On Aug 23, 2021, at 6:01 = PM, Caron, Guy <g.caron@bell.ca> wrote:

=C2=A0

A LoST client that sends= routing requests to the server would receive, way after calls have been = delivered, a notification with a <locationInvalid> body. What would it do with this?

=

=C2=A0

Makes no sense to me.

=C2=A0

Guy

=C2=A0

De=C2=A0:=C2=A0Brian Rosen <br@brianrosen.net>=C2=A0
Envoy=C3=A9=C2=A0:=C2=A023 ao=C3=BBt 2021 17:55
=C3=80=C2=A0:= =C2=A0Caron, Guy <g.caron@bell.ca>
Cc=C2=A0:=C2=A0= ecri= t@ietf.org
Objet=C2=A0:=C2= =A0[EXT]Re: lost-planned-changes-04: plannedChange bound to valida= teLocation?

=C2=A0

I don=E2=80=99t understan= d the reasoning on =E2=80=9Ccreating havoc=E2=80=9D. =C2=A0I don=E2=80=99= t know why a client would ever do it, but it =E2=80=9Cworks=E2=80=9D in t= hat the server doesn=E2=80=99t have to validate to save the URI. =C2=A0If= I client sends the URI and doesn=E2=80=99t validate, it=E2=80=99s weird, but not wrong.

=C2=A0

We can decide to prohibit= it. =C2=A0But we don=E2=80=99t really have a justification.

=C2=A0

Brian





On Aug 23, 2021, at 5:44 = PM, Caron, Guy <g.caron@bell.ca> wrote:

=C2=A0

I agree that accommodati= ng this comment would require deeper XML changes.

=C2=A0

If we do not want to go = there, I think the draft should be clear that there is no usecase for sen= ding <plannedChange> outside of a location validation request and as such, should normatively recommend not doing so.

=C2=A0

I do not agree that a Lo= ST server receiving <plannedChange> outside of a location validatio= n request would retain the URI and send notification if the record changed afterward. I think this would create havoc on the cli= ent=E2=80=99 side.

=C2=A0

Thanks,

=C2=A0

Guy

=C2=A0

De=C2=A0:=C2=A0Brian Rosen <br@brianrosen.net>=C2=A0
Envoy=C3=A9=C2=A0:=C2=A023 ao=C3=BBt 2021 17:22
=C3=80=C2=A0:= =C2=A0Caron, Guy <g.caron@bell.ca>
Cc=C2=A0:=C2=A0= ecri= t@ietf.org
Objet=C2=A0:=C2= =A0[EXT]Re: lost-planned-changes-04: plannedChange bound to valida= teLocation?

=C2=A0

validateLocation is an at= tribute, not an element, so I can=E2=80=99t extend it. =C2=A0

=C2=A0

There isn=E2=80=99t an ac= tual requirement to tie plannedChange to validateLocation. =C2=A0It may n= ot make a lot of sense, but if you did it, the LoST server would not retu= rn validation data, would retain the URI and would send the notification if the record changed. =C2=A0Note my text that the LoST ser= ver doesn=E2=80=99t store the LI - the notification is =E2=80=9Csomething= changed=E2=80=9D not =E2=80=9Cwhat you sent is guaranteed to be invalid=E2= =80=9D or even =E2=80=9Cone or more of the elements you sent changed". =C2= =A0I thought about changing the name of the notification, but I didn=E2=80=99t do that. =C2=A0The pr= actical use case remains the same.

=C2=A0

Brian






On Aug 23, 2021, at 5:07 = PM, Caron, Guy <g.caron@bell.ca> wrote:

=C2=A0

Not all LoST server impl= ementations perform location validations. When location validation is req= uested by the client, it adds the =E2=80=9CvalidateLocation=E2=80=9D attribute to the <findService> element.

=C2=A0

So the question is: Shou= ld =E2=80=9CplannedChange=E2=80=9D be bound to =E2=80=9CvalidateLocation=E2= =80=9D?

=C2=A0

If you believe not, what= would be the expected behaviour of a LoST server receiving a <planned= Change> element outside of a validation request?

=C2=A0

Thanks,

=C2=A0

Guy

=C2=A0

External Email:=C2=A0= Please use caution when opening links and attachments /=C2=A0Courriel externe:=C2=A0Soyez prudent avec les liens et documents joints

=C2=A0

External Email:=C2=A0= Please use caution when opening links and attachments /=C2=A0Courriel externe:=C2=A0Soyez prudent avec les liens et documents joints

=C2=A0

External Email:=C2=A0= Please use caution when opening links and attachments /=C2=A0Courriel externe:=C2=A0Soyez prudent avec les liens et documents joints

=C2=A0

External Email: Please use caution when opening links and attachments= / Courrie= l externe: Soyez prudent avec les liens et documents joints

______________________= _________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

--=_MailMate_08071BD5-5AC6-46E1-9FD3-DA87AFDB4753_=-- From nobody Mon Aug 23 16:18:11 2021 Return-Path: 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 C47133A089F for ; Mon, 23 Aug 2021 16:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, 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 uywTrH6BQkp5 for ; Mon, 23 Aug 2021 16:17:50 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 88E663A089C for ; Mon, 23 Aug 2021 16:17:50 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 23 Aug 2021 15:29:44 -0700 From: "Randall Gellens" To: "Brian Rosen" Cc: "Caron, Guy" , ecrit@ietf.org Date: Mon, 23 Aug 2021 15:29:44 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: <955D85AF-7FFE-416C-A28B-E4A4C65A1E00@brianrosen.net> References: <8508C216-7FF5-41D2-A78D-EBF475F83C7F@randy.pensive.org> <9FA8CD6B-0DF0-4D30-A182-1AF77A155871@randy.pensive.org> <955D85AF-7FFE-416C-A28B-E4A4C65A1E00@brianrosen.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_4DAF40F3-C4C1-4BE3-8C10-9D0C2428F76E_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[868, 20325], "plain":[537, 3749], "uuid":"F67DF9FA-40FC-43C7-B396-9869F71A3A2B"}] Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: Locations are not always invalidated X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 23:17:57 -0000 --=_MailMate_4DAF40F3-C4C1-4BE3-8C10-9D0C2428F76E_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit I interpreted it as allowing a server to save URIs but for an approximate location rather than an exact one, or not associated with a location, and hence it would send a notification if a change might invalidate the location in the query that supplied the URI. If that's not what we mean, then let's be explicit about what we do mean. Under what circumstances would a LoST server save a URI and know that the location in the query might be invalidated but not know for sure? --Randall On 23 Aug 2021, at 15:22, Brian Rosen wrote: > The MAY is because it may not allow/have room/… for the URI (or not > implement it). If you think the text would allow it, for example, to > send a notification where some location other than the one the URI was > sent on changed, then I would like to prohibit that. I especially > don’t want a lazy server sending notifications all over the place > when some change to some location was made, and it sends notifications > to every URI it has. > > Hmmm. We might want to say that if the location was invalid > (regardless of whether validation was requested), and the LI sent > matches more than one location, the server MUST NOT save the URI, and > MUST send the error. The text that says you may get a notification > even if it’s still valid could be expanded to cover that case as an > alternative to that. > > Brian > >> On Aug 23, 2021, at 6:12 PM, Randall Gellens >> wrote: >> >> In my suggested edits I changed this to add "may". >> >> --Randall >> >> On 23 Aug 2021, at 15:08, Caron, Guy wrote: >> >> Taken from section 3: >> >> The URI will be stored by the server against the location in the >> request for subsequent use with the notification function defined >> below. >> >> Guy >> >> De : Randall Gellens >> Envoyé : 23 août 2021 17:51 >> À : Caron, Guy >> Cc : Brian Rosen ; ecrit@ietf.org >> Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: Locations are not >> always invalidated >> >> I don't know that that's true. My interpretation is that a LoST >> server might maintain a list of URIs but not associate each with >> specific location records, and when there is a change, it would then >> send a notification to each stored URI. The location that was used >> for the original validation query might not be impacted. >> >> --Randall >> >> On 23 Aug 2021, at 14:48, Caron, Guy wrote: >> >> I think these locations are impacted in one way or the other >> otherwise, the LoST server would not be able to determine that it >> should send notifications; they may just not become invalid in the >> LoST sense. >> >> >> Thanks, >> >> >> Guy >> >> >> >> >> De : Randall Gellens > > >> Envoyé : 23 août 2021 17:42 >> À : Caron, Guy > >> Cc : Brian Rosen >; >> ecrit@ietf.org >> Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: Locations are not >> always invalidated >> >> >> Using 'impacted' is not really better, because a location may or may >> not actually be impacted. If we go down the path of precise names we >> should use something such as 'locationPotentiallyInvalidated', which >> seems silly. I think the draft makes it clear (especially with my >> suggested edits) that a notified location is potentially invalidated. >> >> --Randall >> >> On 23 Aug 2021, at 14:24, Caron, Guy wrote: >> >> This new version introduces variability in whether a location is >> indeed invalidated or not by a change, which I agree with. >> >> >> Given this, the names “locationInvalidated†and >> “invalidatedAsOf†seem misleading. Should “invalidated†be >> changed to something like “Impacted� >> >> >> Thanks, >> >> >> Guy >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >> External Email: Please use caution when opening links and attachments >> / Courriel externe: Soyez prudent avec les liens et documents joints >> >> External Email: Please use caution when opening links and attachments >> / Courriel externe: Soyez prudent avec les liens et documents joints --=_MailMate_4DAF40F3-C4C1-4BE3-8C10-9D0C2428F76E_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">I interpreted it as allowing a server to save URIs but for= an approximate location rather than an exact one, or not associated with= a location, and hence it would send a notification if a change might inv= alidate the location in the query that supplied the URI. If that's not w= hat we mean, then let's be explicit about what we do mean. Under what ci= rcumstances would a LoST server save a URI and know that the location in = the query might be invalidated but not know for sure?

--Randall

On 23 Aug 2021, at 15:22, Brian Rosen wrote:

The MAY is because it may not allow/have r= oom/=E2=80=A6 for the URI (or not implement it).  If you think the t= ext would allow it, for example, to send a notification where some locati= on other than the one the URI was sent on changed, then I would like to p= rohibit that.  I especially don=E2=80=99t want a lazy server sending= notifications all over the place when some change to some location was m= ade, and it sends notifications to every URI it has. 

Hmmm.  We might want to say th= at if the location was invalid (regardless of whether validation was requ= ested), and the LI sent matches more than one location, the server MUST N= OT save the URI, and MUST send the error.  The text that says you ma= y get a notification even if it=E2=80=99s still valid could be expanded t= o cover that case as an alternative to that.

Brian

On Aug 23, 2021, = at 6:12 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

In my suggested edits I c= hanged this to add "may".

--Randall

On 23 Aug 2021, at 15:08, Caron, Guy wrote:

Taken from section 3:

 

The URI will be stored by the server against the location in the request= for subsequent use with the notification function defined  below.

 

Guy

 =

De : Randall Gellens <rg+ietf@randy.pensive.org>
Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:51
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : Brian Rosen <br@brianrosen.net>; ecrit@ietf.org
Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: = Locations are not always invalidated

 

I don't know t= hat that's true. My interpretation is that a LoST server might maintain a= list of URIs but not associate each with specific location records, and = when there is a change, it would then send a notification to each stored URI. The location that was used for the original validati= on query might not be impacted.

--Randall

On 23 Aug 2021, at 14:48, Caron, Guy wrote:

I think thes= e locations are impacted in one way or the other otherwise, the LoST serv= er would not be able to determine that it should send notifications; they may just not become invalid in the LoST sense.

 

Thanks,

 <= br class=3D"webkit-block-placeholder">

Guy

 
= &nb= sp;
 

De : Randall Gellens <= rg+ietf@randy.pensive.org>
Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:42
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : Brian Rosen <br@brianrosen.net>; ecrit@ietf.org
Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: = Locations are not always invalidated

 

= Using 'impacted' is not really better, because a location may or may not = actually be impacted. If we go down the path of precise names we should u= se something such as 'locationPotentiallyInvalidated', which seems silly. I think the draft makes it clear (especially with my = suggested edits) that a notified location is potentially invalidated.

--Randall

On 23 Aug 2021, at 14:24, Caron, Guy wrote:

This new ver= sion introduces variability in whether a location is indeed invalidated o= r not by a change, which I agree with.

 

Given this, the names =E2=80=9ClocationInvalidated=E2=80=9D and =E2= =80=9CinvalidatedAsOf=E2=80=9D seem misleading. Should =E2=80=9Cinvalidat= ed=E2=80=9D be changed to something like =E2=80=9CImpacted=E2=80=9D?

 

Thanks,

 =

Guy

&nb= sp;
&nbs= p;

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org<= span style=3D"font-family:"Arial",sans-serif;color:#777777" cla= ss=3D"">
https://www.ietf.org/mailman/listinfo/ecrit

External Email: Please use caution when opening links a= nd attachments / Courriel externe: Soyez prudent a= vec les liens et documents joints

External= Email: Please use caution when opening links and attachm= ents / Courriel externe: Soyez prudent a= vec les liens et documents joints

--=_MailMate_4DAF40F3-C4C1-4BE3-8C10-9D0C2428F76E_=-- From nobody Mon Aug 23 16:18:14 2021 Return-Path: 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 E0D143A089B for ; Mon, 23 Aug 2021 16:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, 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 COTBUivpIIWZ for ; Mon, 23 Aug 2021 16:17:51 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4963A08A5 for ; Mon, 23 Aug 2021 16:17:51 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 23 Aug 2021 15:39:48 -0700 From: "Randall Gellens" To: "Caron, Guy" Cc: "Brian Rosen" , ecrit@ietf.org Date: Mon, 23 Aug 2021 15:39:47 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <2B6FB05F-6A89-4680-893F-06584E7EFAF8@randy.pensive.org> In-Reply-To: <794ed22ebe3e48cdb0e72cf3f0a91429@bell.ca> References: <8bdda7ea7d004b4591ff715526d93a73@bell.ca> <791ea34f628d48d3addeb04613d5721a@bell.ca> <9158D09E-770E-4E65-BE46-E39060EAC884@brianrosen.net> <0b81d439e4824aec8a3476906ce5cbc1@bell.ca> <7C21F96F-E238-4DA2-82BB-D7C731A84D53@brianrosen.net> <038dcfc4405d4ebe8930d6225f09ea83@bell.ca> <6EC6E0D3-B9E8-476D-A6F7-E1D20817B58E@brianrosen.net> <64E97C26-36C8-4024-89E3-E23379E614B5@randy.pensive.org> <794ed22ebe3e48cdb0e72cf3f0a91429@bell.ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_136AFBB1-4771-4A9C-AC30-931CB95394FF_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[758, 45562], "plain":[427, 6875], "uuid":"7222DF3E-5E3D-4253-89D1-F102649DB7AE"}] Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 23:17:58 -0000 --=_MailMate_136AFBB1-4771-4A9C-AC30-931CB95394FF_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit I'm trying to understand the harm of allowing a client to request notification whether it is asking for validation or not. We already say that server policy can refuse to store a URI for any reason, so a server could prohibit this if it wants to (e.g., to save resources). If a server is OK providing this server, what do we care? It doesn't harm interoperability. --Randall On 23 Aug 2021, at 15:34, Caron, Guy wrote: > I’m not concerned about a client that willfully and knowingly asks > for it. > > This whole draft revolves around location validation. I’m not > understanding the pushback here. > > Guy > > De : Randall Gellens > Envoyé : 23 août 2021 18:31 > À : Caron, Guy > Cc : Brian Rosen ; ecrit@ietf.org > Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: plannedChange bound > to validateLocation? > > > If a client wants to get notified that a location may have become > invalidated, why do we care why or what type of client it is? > > --Randall > > On 23 Aug 2021, at 15:26, Caron, Guy wrote: > > I understand and what I’m suggesting is to be clear about what LoST > clients are expected to do. We do not want a leasy implementation > sending across the board, don’t we? I think it is > easy and cheep to fix in the draft rather to try to fix > implementations later. > > > > Guy > > > > De : Brian Rosen > > Envoyé : 23 août 2021 18:14 > À : Caron, Guy > > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to > validateLocation? > > > > Sure, PSAPs could be a LoST client for example. A routing proxy can > be a LoST client. But they wouldn’t ask to store the URI. You have > to ask for it to get the notification. > > > > Brian > > > > On Aug 23, 2021, at 6:10 PM, Caron, Guy > > wrote: > > > > You miss my point. The LoST client may not be a LIS. If we make it > explicit that only LISes are LoST clients in the context of this > draft, I may not have as strong objections. > > > > Guy > > > > De : Brian Rosen > > Envoyé : 23 août 2021 18:06 > À : Caron, Guy > > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to > validateLocation? > > > > Only if it asked for it, per location. It asked for it, it got it. > > > > It has NOTHING to do with actual calls. It’s just an alternative to > periodic revalidation for records in the LIS. > > > > A more interesting issue is what does a LIS do when it deletes a > record for which a URI is stored in the server. Probably it marks > that URI is OBE. Another possibility is that it stores a new URI that > is a catch-all “ignore me†> > > > Hmmm. I wonder if we should have an explicit delete. Null URI = > delete. > > > > Brian > > > > > > On Aug 23, 2021, at 6:01 PM, Caron, Guy > > wrote: > > > > A LoST client that sends routing requests to the server would receive, > way after calls have been delivered, a notification with a > body. What would it do with this? > > > > Makes no sense to me. > > > > Guy > > > > De : Brian Rosen > > Envoyé : 23 août 2021 17:55 > À : Caron, Guy > > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to > validateLocation? > > > > I don’t understand the reasoning on “creating havocâ€. I don’t > know why a client would ever do it, but it “works†in that the > server doesn’t have to validate to save the URI. If I client sends > the URI and doesn’t validate, it’s weird, but not wrong. > > > > We can decide to prohibit it. But we don’t really have a > justification. > > > > Brian > > > > > On Aug 23, 2021, at 5:44 PM, Caron, Guy > > wrote: > > > > I agree that accommodating this comment would require deeper XML > changes. > > > > If we do not want to go there, I think the draft should be clear that > there is no usecase for sending outside of a location > validation request and as such, should normatively recommend not doing > so. > > > > I do not agree that a LoST server receiving outside of > a location validation request would retain the URI and send > notification if the record changed afterward. I think this would > create havoc on the client’ side. > > > > Thanks, > > > > Guy > > > > De : Brian Rosen > > Envoyé : 23 août 2021 17:22 > À : Caron, Guy > > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to > validateLocation? > > > > validateLocation is an attribute, not an element, so I can’t extend > it. > > > > There isn’t an actual requirement to tie plannedChange to > validateLocation. It may not make a lot of sense, but if you did it, > the LoST server would not return validation data, would retain the URI > and would send the notification if the record changed. Note my text > that the LoST server doesn’t store the LI - the notification is > “something changed†not “what you sent is guaranteed to be > invalid†or even “one or more of the elements you sent changed". > I thought about changing the name of the notification, but I didn’t > do that. The practical use case remains the same. > > > > Brian > > > > > > On Aug 23, 2021, at 5:07 PM, Caron, Guy > > wrote: > > > > Not all LoST server implementations perform location validations. When > location validation is requested by the client, it adds the > “validateLocation†attribute to the element. > > > > So the question is: Should “plannedChange†be bound to > “validateLocationâ€? > > > > If you believe not, what would be the expected behaviour of a LoST > server receiving a element outside of a validation > request? > > > > Thanks, > > > > Guy > > > > ________________________________ > > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints > > > > ________________________________ > > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints > > > > ________________________________ > > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints > > > > ________________________________ > > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > ________________________________ > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints --=_MailMate_136AFBB1-4771-4A9C-AC30-931CB95394FF_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">I'm trying to understand the harm of allowing a client to = request notification whether it is asking for validation or not. We alre= ady say that server policy can refuse to store a URI for any reason, so a= server could prohibit this if it wants to (e.g., to save resources). If= a server is OK providing this server, what do we care? It doesn't harm = interoperability.

--Randall

On 23 Aug 2021, at 15:34, Caron, Guy wrote:

I=E2=80=99m not concerned about a cli= ent that willfully and knowingly asks for it.

=C2=A0

This whole draft revolves around loca= tion validation. I=E2=80=99m not understanding the pushback here.<= /p>

=C2=A0

Guy

=C2=A0

De=C2= =A0: Randall Gellens <rg+ietf@randy.pensive.org>
Envoy=C3=A9=C2=A0: 23 ao=C3=BBt 2021 18:31
=C3=80=C2=A0: Caron, Guy <g.caron@bell.ca>
Cc=C2=A0: Brian Rosen <br@brianrosen.net>; ecrit@ietf.org Objet=C2=A0: [EXT]Re: [Ecrit] lost-planned-changes-04: plannedChan= ge bound to validateLocation?

=C2=A0

If a client wants to get notified that a location may have become invali= dated, why do we care why or what type of client it is?

--Randall

On 23 Aug 2021, at 15:26, Caron, Guy wrote:

=

I understand and what I=E2=80=99m sug= gesting is to be clear about what LoST clients are expected to do. We do not want a leasy implementation sending <plannedChange> acro= ss the board, don=E2=80=99t we? I think it is easy and cheep to fix in th= e draft rather to try to fix implementations later.

=C2=A0

Guy

=C2=A0<= span style=3D"color:#777777">

De=C2=A0: Brian Rosen <br@brianrosen.net>
Envoy=C3=A9=C2=A0: 23 ao=C3=BBt 2021 18:14
=C3=80=C2=A0: Caron, Guy <g.= caron@bell.ca>
Cc=C2=A0: ecrit@ietf.org
= Objet=C2=A0: [EXT]Re: lost-planned-changes-04: plannedChange bound= to validateLocation?

=C2=A0

Sure, PSAPs could be a LoST client for ex= ample. =C2=A0A routing proxy can be a LoST client. =C2=A0But they wouldn=E2= =80=99t ask to store the URI. =C2=A0You have to ask for it to get the not= ification.=C2=A0

=C2=A0

Brian

=C2=A0

On Aug 23, 2021, at 6:10 PM, Caron, Guy &= lt;g.caron@bell.ca> wrote:

=C2=A0

You miss my point. The LoST client may not be a LIS. If we make = it explicit that only LISes are LoST clients in the context of this draft, I may not have as strong objections.

=C2=A0

Guy

=C2=A0

De=C2=A0:=C2=A0Brian Rosen <br@brianrosen.net= >=C2=A0
Envoy=C3=A9=C2=A0:=C2=A023 ao=C3=BBt 2021 18:06
=C3=80=C2=A0:=C2=A0Caron, Guy <g.caron@bell.ca>
Cc=C2=A0:=C2=A0ecrit@ietf.org
Objet=C2=A0:=C2=A0[EXT]Re: lost-planned-changes-04: plannedChange = bound to validateLocation?

=C2=A0

Only if it asked for it, per location. =C2= =A0It asked for it, it got it.

=C2=A0

It has NOTHING to do with actual calls. =C2= =A0It=E2=80=99s just an alternative to periodic revalidation for records = in the LIS.

=C2=A0

A more interesting issue is what does a L= IS do when it deletes a record for which a URI is stored in the server. =C2= =A0Probably it marks that URI is OBE. Another possibility is that it stores a new URI that is a catch-all =E2=80=9Cignore me=E2=80=9D=

=C2=A0

Hmmm. =C2=A0I wonder if we should have an= explicit delete. =C2=A0Null URI =3D delete.

=C2=A0

Brian

=C2=A0



On Aug 23, 2021, at 6:01 PM, Caron, Guy &= lt;g.caron@bell.ca<= /span>> wrote:

=C2=A0

A LoST client that sends routing requests to the server would re= ceive, way after calls have been delivered, a notification with a <locationInvalid> body. What would it do with this?<= span style=3D"color:#777777">

=C2=A0

Makes no sense to me.

=C2=A0

Guy

=C2=A0

De=C2=A0:=C2=A0Brian Rosen <br@brianrosen.net>=C2=A0
Envoy=C3=A9=C2=A0:=C2=A023 ao=C3=BBt 2021 17:55
=C3=80=C2=A0:=C2=A0Caron, Guy <g.caron@bell= =2Eca>
Cc=C2=A0:=C2=A0ecrit@ietf.org=
Objet=C2=A0:=C2=A0[EXT]Re: lost-planned-changes-04: plannedChange = bound to validateLocation?

=C2=A0

I don=E2=80=99t understand the reasoning = on =E2=80=9Ccreating havoc=E2=80=9D. =C2=A0I don=E2=80=99t know why a cli= ent would ever do it, but it =E2=80=9Cworks=E2=80=9D in that the server d= oesn=E2=80=99t have to validate to save the URI. =C2=A0If I client sends the URI and doesn=E2=80=99t validate, it=E2=80=99= s weird, but not wrong.

=C2=A0

We can decide to prohibit it. =C2=A0But w= e don=E2=80=99t really have a justification.

=C2=A0

Brian




On Aug 23, 2021, at 5:44 PM, Caron, Guy &= lt;g.caron@bell.ca<= /span>> wrote:

=C2=A0

I agree that accommodating this comment would require deeper XML= changes.

=C2=A0

If we do not want to go there, I think the draft should be clear= that there is no usecase for sending <plannedChange> outside of a location validation request and as such, should normatively recomme= nd not doing so.

=C2=A0

I do not agree that a LoST server receiving <plannedChange>= ; outside of a location validation request would retain the URI and send notification if the record changed afterward. I think this woul= d create havoc on the client=E2=80=99 side.

=C2=A0

Thanks,

=C2=A0

Guy

=C2=A0

De=C2=A0:=C2=A0Brian Rosen <br@brianrosen.net>=C2=A0
Envoy=C3=A9=C2=A0:=C2=A023 ao=C3=BBt 2021 17:22
=C3=80=C2=A0:=C2=A0Caron, Guy <g.caron@bell= =2Eca>
Cc=C2=A0:=C2=A0ecrit@ietf.org=
Objet=C2=A0:=C2=A0[EXT]Re: lost-planned-changes-04: plannedChange = bound to validateLocation?

=C2=A0

validateLocation is an attribute, not an = element, so I can=E2=80=99t extend it. =C2=A0

=C2=A0

There isn=E2=80=99t an actual requirement= to tie plannedChange to validateLocation. =C2=A0It may not make a lot of= sense, but if you did it, the LoST server would not return validation data, would retain the URI and would send the notification if the record= changed. =C2=A0Note my text that the LoST server doesn=E2=80=99t store t= he LI - the notification is =E2=80=9Csomething changed=E2=80=9D not =E2=80= =9Cwhat you sent is guaranteed to be invalid=E2=80=9D or even =E2=80=9Con= e or more of the elements you sent changed". =C2=A0I thought about changing the name of t= he notification, but I didn=E2=80=99t do that. =C2=A0The practical use ca= se remains the same.

=C2=A0

Brian





On Aug 23, 2021, at 5:07 PM, Caron, Guy &= lt;g.caron@bell.ca<= /span>> wrote:

=C2=A0

Not all LoST server implementations perform location validations= =2E When location validation is requested by the client, it adds the =E2=80=9CvalidateLocation=E2=80=9D attribute to the <findSer= vice> element.

=C2=A0

So the question is: Should =E2=80=9CplannedChange=E2=80=9D be bo= und to =E2=80=9CvalidateLocation=E2=80=9D?

=C2=A0

If you believe not, what would be the expected behaviour of a Lo= ST server receiving a <plannedChange> element outside of a validation request?

=C2=A0

Thanks,

=C2=A0

Guy

=C2=A0

<= span style=3D"font-size:9.0pt;color:blue">External Email:=C2=A0Please use ca= ution when opening links and attachments /=C2=A0Courriel externe:=C2=A0Soyez prudent avec les liens et documents joi= nts

=C2=A0

<= span style=3D"font-size:9.0pt;color:blue">External Email:=C2=A0Please use ca= ution when opening links and attachments /=C2=A0Courriel externe:=C2=A0Soyez prudent avec les liens et documents joi= nts

=C2=A0

<= span style=3D"font-size:9.0pt;color:blue">External Email:=C2=A0Please use ca= ution when opening links and attachments /=C2=A0Courriel externe:=C2=A0Soyez prudent avec les liens et documents joi= nts

=C2=A0

<= span style=3D"font-size:9.0pt;color:blue">External Email: Please use caution wh= en opening links and attachments / Courrie= l externe: Soyez prudent avec les liens et documents joints

=

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

<= span style=3D"font-size:9.0pt;color:blue">External Email: Please use caution wh= en opening links and attachments / Courrie= l externe: Soyez prudent avec les liens et documents joints

--=_MailMate_136AFBB1-4771-4A9C-AC30-931CB95394FF_=-- From nobody Mon Aug 23 16:37:48 2021 Return-Path: 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 8FBE23A02DC for ; Mon, 23 Aug 2021 16:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, 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 TsJZPXDmWdOg for ; Mon, 23 Aug 2021 16:37:40 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 474EC3A02C1 for ; Mon, 23 Aug 2021 16:37:40 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 23 Aug 2021 16:37:40 -0700 From: "Randall Gellens" To: "Brian Rosen" Cc: "Caron, Guy" , ecrit@ietf.org Date: Mon, 23 Aug 2021 16:37:39 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <75970468-7496-455A-BDD1-78345392EA62@randy.pensive.org> In-Reply-To: References: <8508C216-7FF5-41D2-A78D-EBF475F83C7F@randy.pensive.org> <9FA8CD6B-0DF0-4D30-A182-1AF77A155871@randy.pensive.org> <955D85AF-7FFE-416C-A28B-E4A4C65A1E00@brianrosen.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_749B130F-3D02-440C-85F1-07A2A4C2F39D_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[843, 22336], "plain":[495, 4951], "uuid":"C06F65F5-88AE-4519-9652-F5859759B1F7"}] Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: Locations are not always invalidated X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 23:37:47 -0000 --=_MailMate_749B130F-3D02-440C-85F1-07A2A4C2F39D_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit You mean if only the NAM field changes? Such as if there's a civic address with NAM but no other address elements, and NAM changes? Or a civic address with NAM as well as other elements sufficient to form a valid address on their own? What text would you add to the document to make it clear under what circumstances a LoST server might save a URI and know that the location in the query might be invalidated but not know for sure? --Randall On 23 Aug 2021, at 16:11, Brian Rosen wrote: > Anything that shows up on the unchecked list. An example might be the > NAM element, The US has pretty tight rules on this, so it really > would only be for things like NAM if you had no elements on the > invalid list. But other countries may not have as stringent rules as > the US on how the invalid/unchecked lists are populated. > > Brian > >> On Aug 23, 2021, at 6:29 PM, Randall Gellens >> wrote: >> >> I interpreted it as allowing a server to save URIs but for an >> approximate location rather than an exact one, or not associated with >> a location, and hence it would send a notification if a change might >> invalidate the location in the query that supplied the URI. If that's >> not what we mean, then let's be explicit about what we do mean. Under >> what circumstances would a LoST server save a URI and know that the >> location in the query might be invalidated but not know for sure? >> >> --Randall >> >> On 23 Aug 2021, at 15:22, Brian Rosen wrote: >> >> The MAY is because it may not allow/have room/… for the URI (or not >> implement it). If you think the text would allow it, for example, to >> send a notification where some location other than the one the URI >> was sent on changed, then I would like to prohibit that. I >> especially don’t want a lazy server sending notifications all over >> the place when some change to some location was made, and it sends >> notifications to every URI it has. >> >> Hmmm. We might want to say that if the location was invalid >> (regardless of whether validation was requested), and the LI sent >> matches more than one location, the server MUST NOT save the URI, and >> MUST send the error. The text that says you may get a notification >> even if it’s still valid could be expanded to cover that case as an >> alternative to that. >> >> Brian >> >>> On Aug 23, 2021, at 6:12 PM, Randall Gellens >>> > >>> wrote: >>> >>> In my suggested edits I changed this to add "may". >>> >>> --Randall >>> >>> On 23 Aug 2021, at 15:08, Caron, Guy wrote: >>> >>> Taken from section 3: >>> >>> The URI will be stored by the server against the location in the >>> request for subsequent use with the notification function defined >>> below. >>> >>> Guy >>> >>> De : Randall Gellens >> > >>> Envoyé : 23 août 2021 17:51 >>> À : Caron, Guy > >>> Cc : Brian Rosen >; >>> ecrit@ietf.org >>> Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: Locations are not >>> always invalidated >>> >>> I don't know that that's true. My interpretation is that a LoST >>> server might maintain a list of URIs but not associate each with >>> specific location records, and when there is a change, it would then >>> send a notification to each stored URI. The location that was used >>> for the original validation query might not be impacted. >>> >>> --Randall >>> >>> On 23 Aug 2021, at 14:48, Caron, Guy wrote: >>> >>> I think these locations are impacted in one way or the other >>> otherwise, the LoST server would not be able to determine that it >>> should send notifications; they may just not become invalid in the >>> LoST sense. >>> >>> >>> Thanks, >>> >>> >>> Guy >>> >>> >>> >>> >>> De : Randall Gellens >> > >>> Envoyé : 23 août 2021 17:42 >>> À : Caron, Guy > >>> Cc : Brian Rosen >; >>> ecrit@ietf.org >>> Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: Locations are not >>> always invalidated >>> >>> >>> Using 'impacted' is not really better, because a location may or may >>> not actually be impacted. If we go down the path of precise names we >>> should use something such as 'locationPotentiallyInvalidated', which >>> seems silly. I think the draft makes it clear (especially with my >>> suggested edits) that a notified location is potentially >>> invalidated. >>> >>> --Randall >>> >>> On 23 Aug 2021, at 14:24, Caron, Guy wrote: >>> >>> This new version introduces variability in whether a location is >>> indeed invalidated or not by a change, which I agree with. >>> >>> >>> Given this, the names “locationInvalidated†and >>> “invalidatedAsOf†seem misleading. Should “invalidated†be >>> changed to something like “Impacted� >>> >>> >>> Thanks, >>> >>> >>> Guy >>> >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> External Email: Please use caution when opening links and >>> attachments / Courriel externe: Soyez prudent avec les liens et >>> documents joints >>> >>> External Email: Please use caution when opening links and >>> attachments / Courriel externe: Soyez prudent avec les liens et >>> documents joints >> --=_MailMate_749B130F-3D02-440C-85F1-07A2A4C2F39D_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">You mean if only the NAM field changes? Such as if there'= s a civic address with NAM but no other address elements, and NAM changes= ? Or a civic address with NAM as well as other elements sufficient to fo= rm a valid address on their own?

What text would you add to the document to make it clear = under what circumstances a LoST server might save a URI and know that the= location in the query might be invalidated but not know for sure?

--Randall

On 23 Aug 2021, at 16:11, Brian Rosen wrote:

Anything that shows up on the unchecked li= st.  An example might be the NAM element,   The US has pretty t= ight rules on this, so it really would only be for things like NAM if you= had no elements on the invalid list.  But other countries may not h= ave as stringent rules as the US on how the invalid/unchecked lists are p= opulated.

Brian

On Aug 23, 2021, at 6:29 PM, Randall Gellens <= ;rg+ietf@randy.pe= nsive.org> wrote:

I interpreted it as allow= ing a server to save URIs but for an approximate location rather than an = exact one, or not associated with a location, and hence it would send a n= otification if a change might invalidate the location in the query that s= upplied the URI. If that's not what we mean, then let's be explicit abou= t what we do mean. Under what circumstances would a LoST server save a U= RI and know that the location in the query might be invalidated but not k= now for sure?

--Randall

On 23 Aug 2021, at 15:22, Brian Rosen wrote:

The MAY is because i= t may not allow/have room/=E2=80=A6 for the URI (or not implement it). &n= bsp;If you think the text would allow it, for example, to send a notifica= tion where some location other than the one the URI was sent on changed, = then I would like to prohibit that.  I especially don=E2=80=99t want= a lazy server sending notifications all over the place when some change = to some location was made, and it sends notifications to every URI it has= =2E 

Hmmm.  = ;We might want to say that if the location was invalid (regardless of whe= ther validation was requested), and the LI sent matches more than one loc= ation, the server MUST NOT save the URI, and MUST send the error.  T= he text that says you may get a notification even if it=E2=80=99s still v= alid could be expanded to cover that case as an alternative to that.

Brian

On Aug 23, 2021, at 6:12 PM, Randall Gellens <rg+ietf@randy.pensive.= org> wrote:

In my suggested edits I c= hanged this to add "may".

--Randall

On 23 Aug 2021, at 15:08, Caron, Guy wrote:

Taken from section 3:

 

The URI will be stored by the server against the location in the request= for subsequent use with the notification function defined  below.

 

Guy

 =

De : Randall Gellens <rg+ietf@randy.pensive.org>
Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:51
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : Brian Rosen <br@brianrosen.net>; ecrit@ietf.org
Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: = Locations are not always invalidated

 

I don't know t= hat that's true. My interpretation is that a LoST server might maintain a= list of URIs but not associate each with specific location records, and = when there is a change, it would then send a notification to each stored URI. The location that was used for the original validati= on query might not be impacted.

--Randall

On 23 Aug 2021, at 14:48, Caron, Guy wrote:

I think thes= e locations are impacted in one way or the other otherwise, the LoST serv= er would not be able to determine that it should send notifications; they may just not become invalid in the LoST sense.

 

Thanks,

 <= br class=3D"webkit-block-placeholder">

Guy

 
= &nb= sp;
 

De : Randall Gellens <= rg+ietf@randy.pensive.org>
Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:42
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : Brian Rosen <br@brianrosen.net>; ecrit@ietf.org
Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: = Locations are not always invalidated

 

= Using 'impacted' is not really better, because a location may or may not = actually be impacted. If we go down the path of precise names we should u= se something such as 'locationPotentiallyInvalidated', which seems silly. I think the draft makes it clear (especially with my = suggested edits) that a notified location is potentially invalidated.

--Randall

On 23 Aug 2021, at 14:24, Caron, Guy wrote:

This new ver= sion introduces variability in whether a location is indeed invalidated o= r not by a change, which I agree with.

 

Given this, the names =E2=80=9ClocationInvalidated=E2=80=9D and =E2= =80=9CinvalidatedAsOf=E2=80=9D seem misleading. Should =E2=80=9Cinvalidat= ed=E2=80=9D be changed to something like =E2=80=9CImpacted=E2=80=9D?

 

Thanks,

 =

Guy

&nb= sp;
&nbs= p;

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org<= span style=3D"font-family:"Arial",sans-serif;color:#777777" cla= ss=3D"">
https://www.ietf.org/mailman/listinfo/ecrit

External Email: Please use caution when opening links a= nd attachments / Courriel externe: Soyez prudent a= vec les liens et documents joints

External= Email: Please use caution when opening links and attachm= ents / Courriel externe: Soyez prudent a= vec les liens et documents joints


--=_MailMate_749B130F-3D02-440C-85F1-07A2A4C2F39D_=-- From nobody Mon Aug 23 17:04:10 2021 Return-Path: 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 909453A0891 for ; Mon, 23 Aug 2021 17:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, 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.20150623.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 SiV0jQHiwn3J for ; Mon, 23 Aug 2021 17:03:43 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 1ADE83A084E for ; Mon, 23 Aug 2021 17:03:43 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id y18so8484587ioc.1 for ; Mon, 23 Aug 2021 17:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=m7EsyW2JsSke2CuMjhNYrqdVz9R13cQDHVafjHZLc6A=; b=p9hGiXD/U7AXIFb0JI0n4DLR9q78TmM3VmFfb/QJv8+UoSr8riwNIfXFbUudGDyGPs TLdPG6rOn6pU/PI5VRn4WU4g9dMM7GgLrYdjObumWb1WzjQy8azsnwZOonSQUwBO3fHV EQe08WVMiYUiHZ2hd9unU1LDgMxCbS0WbnpcRKfB+WlsQZ7Kf4IpdFe3XOQfXpaZ/6fo sxZ+4AxWq9XiD0wRtO6usPCALBHuWleS/nLaGS+AewY/8abWbPbiREm8eHlCMuGZL/FG 94dxIK+RK66gZH72JquAiM94s32lKrpnLw/UkKDo1WxefINzDzcbmBVEdM15UL4zA16M QDag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=m7EsyW2JsSke2CuMjhNYrqdVz9R13cQDHVafjHZLc6A=; b=pBOLnMsGpLWJy8qP/ykPzp1RKdaPuZ/cGpeVKqeK/yBLZXBRG8UbHvaB1g8mlS5nbz +zxtIVCRbY9/yJD4O0reKt4Cs+2hurks925FHaIWY/67gZcfybfKGJChL3t/waKhA5p0 rp41qYAmiqC0CNE4yiGuqP3IPnv9vMK3QBnAV2EnVlQY4zbpxOZjKSrJ/LROqg1P8aZW NhyRIuXKGEmZKX/VT2oyaIPW4q/s8C79KVOR6IqdP3ZOyefAIpDvN4IoEtHpXtdkDYl7 IP4wKQAlG9RHvC/aayF9QZl9nq00xnPnPnz8c2TtqwLl88MorIgAxR28ev7ffPLF9/NH Uagw== X-Gm-Message-State: AOAM533mZNWPUCzpSSRFQQ6Gu0jtboWQ3zoq2/aXitBtwuqiAVJ72CYM f7Z+znRZ2knWnXrun5hgEYKE1Q== X-Google-Smtp-Source: ABdhPJyDyJcRsCMBjaLzJ1GqR9d2/IYV93NCWAcq0Nl5HgR2VikvyDVEPj9rdegIJ5DGy9klUhbaxw== X-Received: by 2002:a5d:9693:: with SMTP id m19mr16707126ion.72.1629763421572; Mon, 23 Aug 2021 17:03:41 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id p7sm8936684iln.70.2021.08.23.17.03.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Aug 2021 17:03:41 -0700 (PDT) From: Brian Rosen Message-Id: <81E40A06-65CD-4B97-B581-CE3304FE8072@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_C509796F-A78E-4988-AB6F-B654973BFAEC" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Mon, 23 Aug 2021 20:03:40 -0400 In-Reply-To: <75970468-7496-455A-BDD1-78345392EA62@randy.pensive.org> Cc: "Caron, Guy" , ecrit@ietf.org To: Randall Gellens References: <8508C216-7FF5-41D2-A78D-EBF475F83C7F@randy.pensive.org> <9FA8CD6B-0DF0-4D30-A182-1AF77A155871@randy.pensive.org> <955D85AF-7FFE-416C-A28B-E4A4C65A1E00@brianrosen.net> <75970468-7496-455A-BDD1-78345392EA62@randy.pensive.org> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: Locations are not always invalidated X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 00:04:07 -0000 --Apple-Mail=_C509796F-A78E-4988-AB6F-B654973BFAEC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think the text is clear as is: the server doesn=E2=80=99t save the LI, = and consequently a change could occur that wasn=E2=80=99t in the LI and = still cause a notification. Again, for US addresses, we have rules = about how validation is done that limit how often this could happen. = NAM is an example. It=E2=80=99s not defined, but it could occur in the = LoST server data. If it did, and it was not sent in the LI of a LoST = findService, and it was subsequently changed in the LoST server, there = could be a notification. But other countries could have profiles that, = for example explicitly ignore Neighborhood - any value is valid = regardless of what is in the server=E2=80=99s data. They may send = unchecked for such cases. =20 The implementation for this is simple - revalidate and allow the result = to be valid without choking. I=E2=80=99m just trying to make sure the = client doesn=E2=80=99t assume that if they revalidate it is guaranteed = to fail. Brian > On Aug 23, 2021, at 7:37 PM, Randall Gellens = wrote: >=20 > You mean if only the NAM field changes? Such as if there's a civic = address with NAM but no other address elements, and NAM changes? Or a = civic address with NAM as well as other elements sufficient to form a = valid address on their own? >=20 > What text would you add to the document to make it clear under what = circumstances a LoST server might save a URI and know that the location = in the query might be invalidated but not know for sure? >=20 > --Randall >=20 > On 23 Aug 2021, at 16:11, Brian Rosen wrote: >=20 > Anything that shows up on the unchecked list. An example might be the = NAM element, The US has pretty tight rules on this, so it really would = only be for things like NAM if you had no elements on the invalid list. = But other countries may not have as stringent rules as the US on how the = invalid/unchecked lists are populated. >=20 > Brian >=20 >> On Aug 23, 2021, at 6:29 PM, Randall Gellens = > wrote: >>=20 >> I interpreted it as allowing a server to save URIs but for an = approximate location rather than an exact one, or not associated with a = location, and hence it would send a notification if a change might = invalidate the location in the query that supplied the URI. If that's = not what we mean, then let's be explicit about what we do mean. Under = what circumstances would a LoST server save a URI and know that the = location in the query might be invalidated but not know for sure? >>=20 >> --Randall >>=20 >> On 23 Aug 2021, at 15:22, Brian Rosen wrote: >>=20 >> The MAY is because it may not allow/have room/=E2=80=A6 for the URI = (or not implement it). If you think the text would allow it, for = example, to send a notification where some location other than the one = the URI was sent on changed, then I would like to prohibit that. I = especially don=E2=80=99t want a lazy server sending notifications all = over the place when some change to some location was made, and it sends = notifications to every URI it has.=20 >>=20 >> Hmmm. We might want to say that if the location was invalid = (regardless of whether validation was requested), and the LI sent = matches more than one location, the server MUST NOT save the URI, and = MUST send the error. The text that says you may get a notification even = if it=E2=80=99s still valid could be expanded to cover that case as an = alternative to that. >>=20 >> Brian >>=20 >>> On Aug 23, 2021, at 6:12 PM, Randall Gellens = > wrote: >>>=20 >>> In my suggested edits I changed this to add "may". >>>=20 >>> --Randall >>>=20 >>> On 23 Aug 2021, at 15:08, Caron, Guy wrote: >>>=20 >>> Taken from section 3: >>> =20 >>> The URI will be stored by the server against the location in the = request for subsequent use with the notification function defined = below. >>> =20 >>> Guy >>> =20 >>> De : Randall Gellens >=20 >>> Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:51 >>> =C3=80 : Caron, Guy > >>> Cc : Brian Rosen >; = ecrit@ietf.org >>> Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: Locations are not = always invalidated >>> =20 >>> I don't know that that's true. My interpretation is that a LoST = server might maintain a list of URIs but not associate each with = specific location records, and when there is a change, it would then = send a notification to each stored URI. The location that was used for = the original validation query might not be impacted. >>>=20 >>> --Randall >>>=20 >>> On 23 Aug 2021, at 14:48, Caron, Guy wrote: >>>=20 >>> I think these locations are impacted in one way or the other = otherwise, the LoST server would not be able to determine that it should = send notifications; they may just not become invalid in the LoST sense. >>>=20 >>> =20 >>> Thanks, >>>=20 >>> =20 >>> Guy >>>=20 >>> =20 >>> =20 >>> =20 >>> De : Randall Gellens >=20 >>> Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:42 >>> =C3=80 : Caron, Guy > >>> Cc : Brian Rosen >; = ecrit@ietf.org >>> Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: Locations are not = always invalidated >>>=20 >>> =20 >>> Using 'impacted' is not really better, because a location may or may = not actually be impacted. If we go down the path of precise names we = should use something such as 'locationPotentiallyInvalidated', which = seems silly. I think the draft makes it clear (especially with my = suggested edits) that a notified location is potentially invalidated. >>>=20 >>> --Randall >>>=20 >>> On 23 Aug 2021, at 14:24, Caron, Guy wrote: >>>=20 >>> This new version introduces variability in whether a location is = indeed invalidated or not by a change, which I agree with. >>>=20 >>> =20 >>> Given this, the names =E2=80=9ClocationInvalidated=E2=80=9D and = =E2=80=9CinvalidatedAsOf=E2=80=9D seem misleading. Should = =E2=80=9Cinvalidated=E2=80=9D be changed to something like = =E2=80=9CImpacted=E2=80=9D? >>>=20 >>> =20 >>> Thanks, >>>=20 >>> =20 >>> Guy >>>=20 >>> =20 >>> =20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit = >>> External Email: Please use caution when opening links and = attachments / Courriel externe: Soyez prudent avec les liens et = documents joints >>>=20 >>> External Email: Please use caution when opening links and = attachments / Courriel externe: Soyez prudent avec les liens et = documents joints >>=20 >=20 --Apple-Mail=_C509796F-A78E-4988-AB6F-B654973BFAEC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think the text is clear as is: the server doesn=E2=80=99t save the LI, = and consequently a change could occur that wasn=E2=80=99t in the LI and = still cause a notification.  Again, for US addresses, we have rules = about how validation is done that limit how often this could happen. =  NAM is an example.  It=E2=80=99s not defined, but it could = occur in the LoST server data.  If it did, and it was not sent in = the LI of a LoST findService, and it was subsequently changed in the = LoST server, there could be a notification.  But other countries = could have profiles that, for example explicitly ignore Neighborhood - = any value is valid regardless of what is in the server=E2=80=99s data. =  They may send unchecked for such cases.  

The implementation for this is simple - = revalidate and allow the result to be valid without choking.  I=E2=80= =99m just trying to make sure the client doesn=E2=80=99t assume that if = they revalidate it is guaranteed to fail.

Brian
On = Aug 23, 2021, at 7:37 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

You = mean if only the NAM field changes? Such as if there's a civic address = with NAM but no other address elements, and NAM changes? Or a civic = address with NAM as well as other elements sufficient to form a valid = address on their own?

What text would you = add to the document to make it clear under what circumstances a LoST = server might save a URI and know that the location in the query might be = invalidated but not know for sure?

--Randall

On 23 Aug 2021, at = 16:11, Brian Rosen wrote:

Anything that shows up on the unchecked = list.  An example might be the NAM element,   The US has = pretty tight rules on this, so it really would only be for things like = NAM if you had no elements on the invalid list.  But other = countries may not have as stringent rules as the US on how the = invalid/unchecked lists are populated.

Brian

On Aug 23, 2021, at 6:29 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

I = interpreted it as allowing a server to save URIs but for an approximate = location rather than an exact one, or not associated with a location, = and hence it would send a notification if a change might invalidate the = location in the query that supplied the URI. If that's not what we = mean, then let's be explicit about what we do mean. Under what = circumstances would a LoST server save a URI and know that the location = in the query might be invalidated but not know for sure?

--Randall

On 23 = Aug 2021, at 15:22, Brian Rosen wrote:

The MAY is because it may not allow/have = room/=E2=80=A6 for the URI (or not implement it).  If you think the = text would allow it, for example, to send a notification where some = location other than the one the URI was sent on changed, then I would = like to prohibit that.  I especially don=E2=80=99t want a lazy = server sending notifications all over the place when some change to some = location was made, and it sends notifications to every URI it = has. 

Hmmm. =  We might want to say that if the location was invalid (regardless = of whether validation was requested), and the LI sent matches more than = one location, the server MUST NOT save the URI, and MUST send the error. =  The text that says you may get a notification even if it=E2=80=99s = still valid could be expanded to cover that case as an alternative to = that.

Brian

On Aug = 23, 2021, at 6:12 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

In my = suggested edits I changed this to add "may".

--Randall

On 23 Aug 2021, at = 15:08, Caron, Guy wrote:

Taken from section = 3:

 

The URI will be stored by the server against the location in = the request for subsequent use with the notification function = defined  below.

 

Guy

 

De : Randall Gellens <rg+ietf@randy.pensive.org>
Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:51
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : Brian Rosen <br@brianrosen.net>; = ecrit@ietf.org
Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: = Locations are not always invalidated

 

I don't = know that that's true. My interpretation is that a LoST server might = maintain a list of URIs but not associate each with specific location = records, and when there is a change, it would then send a notification to each stored URI. The location that was used for the original = validation query might not be impacted.

--Randall

On 23 Aug = 2021, at 14:48, Caron, Guy wrote:

I think these locations = are impacted in one way or the other otherwise, the LoST server would = not be able to determine that it should send notifications; they may just not become invalid in the LoST = sense.

 

Thanks,

 

Guy

 
 
 

De : Randall Gellens <rg+ietf@randy.pensive.org>
Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:42
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : Brian Rosen <br@brianrosen.net>; ecrit@ietf.org
Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: = Locations are not always invalidated

 

Using 'impacted' is not really better, because a location may = or may not actually be impacted. If we go down the path of precise names = we should use something such as 'locationPotentiallyInvalidated', which seems silly. I think the draft makes it clear (especially with my = suggested edits) that a notified location is potentially = invalidated.

--Randall

On 23 Aug 2021, at 14:24, Caron, Guy wrote:

This new version = introduces variability in whether a location is indeed invalidated or = not by a change, which I agree with.

 

Given this, the names = =E2=80=9ClocationInvalidated=E2=80=9D and =E2=80=9CinvalidatedAsOf=E2=80=9D= seem misleading. Should =E2=80=9Cinvalidated=E2=80=9D be changed to = something like =E2=80=9CImpacted=E2=80=9D?

 

Thanks,

 

Guy

 
 

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

External = Email: Please use caution when = opening links and attachments / Courriel = externe: Soyez prudent avec les = liens et documents joints

External Email: Please use caution when = opening links and attachments / Courriel = externe: Soyez prudent avec les = liens et documents joints



= --Apple-Mail=_C509796F-A78E-4988-AB6F-B654973BFAEC-- From nobody Mon Aug 23 18:58:56 2021 Return-Path: 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 7FDAA3A00AD for ; Mon, 23 Aug 2021 18:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, 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 3qczrcN5A0Ki for ; Mon, 23 Aug 2021 18:58:48 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 00D0C3A0062 for ; Mon, 23 Aug 2021 18:58:47 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 23 Aug 2021 18:58:47 -0700 From: "Randall Gellens" To: "Brian Rosen" Cc: "Caron, Guy" , ecrit@ietf.org Date: Mon, 23 Aug 2021 18:58:46 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <03DDB6F4-5AB2-42D3-8F1E-6B72D9FC913B@randy.pensive.org> In-Reply-To: <81E40A06-65CD-4B97-B581-CE3304FE8072@brianrosen.net> References: <8508C216-7FF5-41D2-A78D-EBF475F83C7F@randy.pensive.org> <9FA8CD6B-0DF0-4D30-A182-1AF77A155871@randy.pensive.org> <955D85AF-7FFE-416C-A28B-E4A4C65A1E00@brianrosen.net> <75970468-7496-455A-BDD1-78345392EA62@randy.pensive.org> <81E40A06-65CD-4B97-B581-CE3304FE8072@brianrosen.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_9D9AB47E-B363-494A-BF4B-6170A7E9E196_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[901, 24966], "plain":[459, 6603], "uuid":"84CAE56B-4B34-4D33-8916-3EDBEDDCD983"}] Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: Locations are not always invalidated X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 01:58:55 -0000 --=_MailMate_9D9AB47E-B363-494A-BF4B-6170A7E9E196_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit What the text says now: 3. element The URI will be stored by the server against the location in the request 4. object When the server needs to invalidate a location where the client provided a URI in , You don't think it would be helpful to add some explanatory text about how a location is invalidated and yet is still valid? --Randall On 23 Aug 2021, at 17:03, Brian Rosen wrote: > I think the text is clear as is: the server doesn’t save the LI, and > consequently a change could occur that wasn’t in the LI and still > cause a notification. Again, for US addresses, we have rules about > how validation is done that limit how often this could happen. NAM is > an example. It’s not defined, but it could occur in the LoST server > data. If it did, and it was not sent in the LI of a LoST findService, > and it was subsequently changed in the LoST server, there could be a > notification. But other countries could have profiles that, for > example explicitly ignore Neighborhood - any value is valid regardless > of what is in the server’s data. They may send unchecked for such > cases. > > The implementation for this is simple - revalidate and allow the > result to be valid without choking. I’m just trying to make sure > the client doesn’t assume that if they revalidate it is guaranteed > to fail. > > Brian >> On Aug 23, 2021, at 7:37 PM, Randall Gellens >> wrote: >> >> You mean if only the NAM field changes? Such as if there's a civic >> address with NAM but no other address elements, and NAM changes? Or a >> civic address with NAM as well as other elements sufficient to form a >> valid address on their own? >> >> What text would you add to the document to make it clear under what >> circumstances a LoST server might save a URI and know that the >> location in the query might be invalidated but not know for sure? >> >> --Randall >> >> On 23 Aug 2021, at 16:11, Brian Rosen wrote: >> >> Anything that shows up on the unchecked list. An example might be >> the NAM element, The US has pretty tight rules on this, so it >> really would only be for things like NAM if you had no elements on >> the invalid list. But other countries may not have as stringent >> rules as the US on how the invalid/unchecked lists are populated. >> >> Brian >> >>> On Aug 23, 2021, at 6:29 PM, Randall Gellens >>> > >>> wrote: >>> >>> I interpreted it as allowing a server to save URIs but for an >>> approximate location rather than an exact one, or not associated >>> with a location, and hence it would send a notification if a change >>> might invalidate the location in the query that supplied the URI. If >>> that's not what we mean, then let's be explicit about what we do >>> mean. Under what circumstances would a LoST server save a URI and >>> know that the location in the query might be invalidated but not >>> know for sure? >>> >>> --Randall >>> >>> On 23 Aug 2021, at 15:22, Brian Rosen wrote: >>> >>> The MAY is because it may not allow/have room/… for the URI (or >>> not implement it). If you think the text would allow it, for >>> example, to send a notification where some location other than the >>> one the URI was sent on changed, then I would like to prohibit that. >>> I especially don’t want a lazy server sending notifications all >>> over the place when some change to some location was made, and it >>> sends notifications to every URI it has. >>> >>> Hmmm. We might want to say that if the location was invalid >>> (regardless of whether validation was requested), and the LI sent >>> matches more than one location, the server MUST NOT save the URI, >>> and MUST send the error. The text that says you may get a >>> notification even if it’s still valid could be expanded to cover >>> that case as an alternative to that. >>> >>> Brian >>> >>>> On Aug 23, 2021, at 6:12 PM, Randall Gellens >>>> > >>>> wrote: >>>> >>>> In my suggested edits I changed this to add "may". >>>> >>>> --Randall >>>> >>>> On 23 Aug 2021, at 15:08, Caron, Guy wrote: >>>> >>>> Taken from section 3: >>>> >>>> The URI will be stored by the server against the location in the >>>> request for subsequent use with the notification function defined >>>> below. >>>> >>>> Guy >>>> >>>> De : Randall Gellens >>> > >>>> Envoyé : 23 août 2021 17:51 >>>> À : Caron, Guy > >>>> Cc : Brian Rosen >; >>>> ecrit@ietf.org >>>> Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: Locations are not >>>> always invalidated >>>> >>>> I don't know that that's true. My interpretation is that a LoST >>>> server might maintain a list of URIs but not associate each with >>>> specific location records, and when there is a change, it would >>>> then send a notification to each stored URI. The location that was >>>> used for the original validation query might not be impacted. >>>> >>>> --Randall >>>> >>>> On 23 Aug 2021, at 14:48, Caron, Guy wrote: >>>> >>>> I think these locations are impacted in one way or the other >>>> otherwise, the LoST server would not be able to determine that it >>>> should send notifications; they may just not become invalid in the >>>> LoST sense. >>>> >>>> >>>> Thanks, >>>> >>>> >>>> Guy >>>> >>>> >>>> >>>> >>>> De : Randall Gellens >>> > >>>> Envoyé : 23 août 2021 17:42 >>>> À : Caron, Guy > >>>> Cc : Brian Rosen >; >>>> ecrit@ietf.org >>>> Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: Locations are not >>>> always invalidated >>>> >>>> >>>> Using 'impacted' is not really better, because a location may or >>>> may not actually be impacted. If we go down the path of precise >>>> names we should use something such as >>>> 'locationPotentiallyInvalidated', which seems silly. I think the >>>> draft makes it clear (especially with my suggested edits) that a >>>> notified location is potentially invalidated. >>>> >>>> --Randall >>>> >>>> On 23 Aug 2021, at 14:24, Caron, Guy wrote: >>>> >>>> This new version introduces variability in whether a location is >>>> indeed invalidated or not by a change, which I agree with. >>>> >>>> >>>> Given this, the names “locationInvalidated†and >>>> “invalidatedAsOf†seem misleading. Should “invalidated†be >>>> changed to something like “Impacted� >>>> >>>> >>>> Thanks, >>>> >>>> >>>> Guy >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> External Email: Please use caution when opening links and >>>> attachments / Courriel externe: Soyez prudent avec les liens et >>>> documents joints >>>> >>>> External Email: Please use caution when opening links and >>>> attachments / Courriel externe: Soyez prudent avec les liens et >>>> documents joints >>> >> --=_MailMate_9D9AB47E-B363-494A-BF4B-6170A7E9E196_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">What the text says now:

3. <plannedChange> element

The URI will be stored by the server against the locat= ion in the
request

4. <locationInvalidated> object

When the server needs to invalidate a location where t= he client
provided a URI in <plannedChange>,

You don't think it would be helpful to add some explanato= ry text about how a location is invalidated and yet is still valid?

--Randall

On 23 Aug 2021, at 17:03, Brian Rosen wrote:

I think the text is clear as is: the serve= r doesn=E2=80=99t save the LI, and consequently a change could occur that= wasn=E2=80=99t in the LI and still cause a notification.  Again, fo= r US addresses, we have rules about how validation is done that limit how= often this could happen.  NAM is an example.  It=E2=80=99s not= defined, but it could occur in the LoST server data.  If it did, an= d it was not sent in the LI of a LoST findService, and it was subsequentl= y changed in the LoST server, there could be a notification.  But ot= her countries could have profiles that, for example explicitly ignore Nei= ghborhood - any value is valid regardless of what is in the server=E2=80=99= s data.  They may send unchecked for such cases.  

The implementation for this is si= mple - revalidate and allow the result to be valid without choking.  = ;I=E2=80=99m just trying to make sure the client doesn=E2=80=99t assume t= hat if they revalidate it is guaranteed to fail.
Brian
On Aug 23, 2021, at 7:37 PM= , Randall Gellens <rg+ietf@randy.pensive.org> wrote:

You mean if only the NAM = field changes? Such as if there's a civic address with NAM but no other = address elements, and NAM changes? Or a civic address with NAM as well a= s other elements sufficient to form a valid address on their own?

What text would you add to the document to make it= clear under what circumstances a LoST server might save a URI and know t= hat the location in the query might be invalidated but not know for sure?=

--Randall

On= 23 Aug 2021, at 16:11, Brian Rosen wrote:

Anything that shows = up on the unchecked list.  An example might be the NAM element, &nbs= p; The US has pretty tight rules on this, so it really would only be for = things like NAM if you had no elements on the invalid list.  But oth= er countries may not have as stringent rules as the US on how the invalid= /unchecked lists are populated.

Brian

On Aug 23, 2021, = at 6:29 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

I interpreted it as allow= ing a server to save URIs but for an approximate location rather than an = exact one, or not associated with a location, and hence it would send a n= otification if a change might invalidate the location in the query that s= upplied the URI. If that's not what we mean, then let's be explicit abou= t what we do mean. Under what circumstances would a LoST server save a U= RI and know that the location in the query might be invalidated but not k= now for sure?

--Randall

On 23 Aug 2021, at 15:22, Brian Rosen wrote:

The MAY is because i= t may not allow/have room/=E2=80=A6 for the URI (or not implement it). &n= bsp;If you think the text would allow it, for example, to send a notifica= tion where some location other than the one the URI was sent on changed, = then I would like to prohibit that.  I especially don=E2=80=99t want= a lazy server sending notifications all over the place when some change = to some location was made, and it sends notifications to every URI it has= =2E 

Hmmm.  = ;We might want to say that if the location was invalid (regardless of whe= ther validation was requested), and the LI sent matches more than one loc= ation, the server MUST NOT save the URI, and MUST send the error.  T= he text that says you may get a notification even if it=E2=80=99s still v= alid could be expanded to cover that case as an alternative to that.

Brian

On Aug 23, 2021, at 6:12 PM, Randall Gellens <rg+ietf@randy.pensive.= org> wrote:

In my suggested edits I c= hanged this to add "may".

--Randall

On 23 Aug 2021, at 15:08, Caron, Guy wrote:

Taken from section 3:

 

The URI will be stored by the server against the location in the request= for subsequent use with the notification function defined  below.

 

Guy

 =

De : Randall Gellens <rg+ietf@randy.pensive.org>
Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:51
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : Brian Rosen <br@brianrosen.net>; ecrit@ietf.org
Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: = Locations are not always invalidated

 

I don't know t= hat that's true. My interpretation is that a LoST server might maintain a= list of URIs but not associate each with specific location records, and = when there is a change, it would then send a notification to each stored URI. The location that was used for the original validati= on query might not be impacted.

--Randall

On 23 Aug 2021, at 14:48, Caron, Guy wrote:

I think thes= e locations are impacted in one way or the other otherwise, the LoST serv= er would not be able to determine that it should send notifications; they may just not become invalid in the LoST sense.

 

Thanks,

 <= br class=3D"webkit-block-placeholder">

Guy

 
= &nb= sp;
 

De : Randall Gellens <= rg+ietf@randy.pensive.org>
Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:42
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : Brian Rosen <br@brianrosen.net>; ecrit@ietf.org
Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: = Locations are not always invalidated

 

= Using 'impacted' is not really better, because a location may or may not = actually be impacted. If we go down the path of precise names we should u= se something such as 'locationPotentiallyInvalidated', which seems silly. I think the draft makes it clear (especially with my = suggested edits) that a notified location is potentially invalidated.

--Randall

On 23 Aug 2021, at 14:24, Caron, Guy wrote:

This new ver= sion introduces variability in whether a location is indeed invalidated o= r not by a change, which I agree with.

 

Given this, the names =E2=80=9ClocationInvalidated=E2=80=9D and =E2= =80=9CinvalidatedAsOf=E2=80=9D seem misleading. Should =E2=80=9Cinvalidat= ed=E2=80=9D be changed to something like =E2=80=9CImpacted=E2=80=9D?

 

Thanks,

 =

Guy

&nb= sp;
&nbs= p;

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org<= span style=3D"font-family:"Arial",sans-serif;color:#777777" cla= ss=3D"">
https://www.ietf.org/mailman/listinfo/ecrit

External Email: Please use caution when opening links a= nd attachments / Courriel externe: Soyez prudent a= vec les liens et documents joints

External= Email: Please use caution when opening links and attachm= ents / Courriel externe: Soyez prudent a= vec les liens et documents joints



--=_MailMate_9D9AB47E-B363-494A-BF4B-6170A7E9E196_=-- From nobody Mon Aug 23 20:31:29 2021 Return-Path: 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 695643A0C16 for ; Mon, 23 Aug 2021 20:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, 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 YvZ7oP7vOZnh for ; Mon, 23 Aug 2021 20:31:20 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0E15C3A0BF6 for ; Mon, 23 Aug 2021 20:31:19 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 23 Aug 2021 20:31:19 -0700 From: "Randall Gellens" To: "Brian Rosen" Cc: "Caron, Guy" , ecrit@ietf.org Date: Mon, 23 Aug 2021 20:31:18 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: <81E40A06-65CD-4B97-B581-CE3304FE8072@brianrosen.net> References: <8508C216-7FF5-41D2-A78D-EBF475F83C7F@randy.pensive.org> <9FA8CD6B-0DF0-4D30-A182-1AF77A155871@randy.pensive.org> <955D85AF-7FFE-416C-A28B-E4A4C65A1E00@brianrosen.net> <75970468-7496-455A-BDD1-78345392EA62@randy.pensive.org> <81E40A06-65CD-4B97-B581-CE3304FE8072@brianrosen.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: Locations are not always invalidated X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 03:31:28 -0000 Let me try this again. What the text says now: 3. element The URI will be stored by the server against the location in the request 4. object When the server needs to invalidate a location where the client provided a URI in , ... The LoST server is NOT REQUIRED to store the Location Information supplied in the original findService request. This means the server may not know if a planned change will in fact invalidate the location stored in the LoST client, because changes could be made in the LoST server that do not affect validation of the Location Information. The LoST client may find that upon revalidation with the changed I had misunderstood this to mean that the server could store the URI in any way it wants, and so the server may not know if a change to some location information that it has configured would invalidate a location for which it stored a URI. You clarified in email that your intent is to constrain the server so that a notification is only triggered for a change to the underlying location information, even if that change doesn't invalidate the specific location of the query. Based on this, I think we need clarifying text to better explain this (to help a reader understand the intent), and also some normative language added regarding the server, to the effect that if it decides to store the URI, it needs to store it associated with something that if it changes, the location in the query is or is likely affected, even if not invalidated. We obviously don't constrain LoST server implementations, they can store data in any way they like (we only specify a configuration interface in LoST-sync and of course the query interface in LoST). But if we want the draft to reflect your intent, I think we need some kind of normative text about what the server stores. --Randall On 23 Aug 2021, at 17:03, Brian Rosen wrote: > I think the text is clear as is: the server doesn’t save the LI, and > consequently a change could occur that wasn’t in the LI and still > cause a notification. Again, for US addresses, we have rules about > how validation is done that limit how often this could happen. NAM is > an example. It’s not defined, but it could occur in the LoST server > data. If it did, and it was not sent in the LI of a LoST findService, > and it was subsequently changed in the LoST server, there could be a > notification. But other countries could have profiles that, for > example explicitly ignore Neighborhood - any value is valid regardless > of what is in the server’s data. They may send unchecked for such > cases. > > The implementation for this is simple - revalidate and allow the > result to be valid without choking. I’m just trying to make sure > the client doesn’t assume that if they revalidate it is guaranteed > to fail. > > Brian >> On Aug 23, 2021, at 7:37 PM, Randall Gellens >> wrote: >> >> You mean if only the NAM field changes? Such as if there's a civic >> address with NAM but no other address elements, and NAM changes? Or a >> civic address with NAM as well as other elements sufficient to form a >> valid address on their own? >> >> What text would you add to the document to make it clear under what >> circumstances a LoST server might save a URI and know that the >> location in the query might be invalidated but not know for sure? >> >> --Randall >> >> On 23 Aug 2021, at 16:11, Brian Rosen wrote: >> >> Anything that shows up on the unchecked list. An example might be >> the NAM element, The US has pretty tight rules on this, so it >> really would only be for things like NAM if you had no elements on >> the invalid list. But other countries may not have as stringent >> rules as the US on how the invalid/unchecked lists are populated. >> >> Brian >> >>> On Aug 23, 2021, at 6:29 PM, Randall Gellens >>> > >>> wrote: >>> >>> I interpreted it as allowing a server to save URIs but for an >>> approximate location rather than an exact one, or not associated >>> with a location, and hence it would send a notification if a change >>> might invalidate the location in the query that supplied the URI. If >>> that's not what we mean, then let's be explicit about what we do >>> mean. Under what circumstances would a LoST server save a URI and >>> know that the location in the query might be invalidated but not >>> know for sure? >>> >>> --Randall >>> >>> On 23 Aug 2021, at 15:22, Brian Rosen wrote: >>> >>> The MAY is because it may not allow/have room/… for the URI (or >>> not implement it). If you think the text would allow it, for >>> example, to send a notification where some location other than the >>> one the URI was sent on changed, then I would like to prohibit that. >>> I especially don’t want a lazy server sending notifications all >>> over the place when some change to some location was made, and it >>> sends notifications to every URI it has. >>> >>> Hmmm. We might want to say that if the location was invalid >>> (regardless of whether validation was requested), and the LI sent >>> matches more than one location, the server MUST NOT save the URI, >>> and MUST send the error. The text that says you may get a >>> notification even if it’s still valid could be expanded to cover >>> that case as an alternative to that. >>> >>> Brian >>> >>>> On Aug 23, 2021, at 6:12 PM, Randall Gellens >>>> > >>>> wrote: >>>> >>>> In my suggested edits I changed this to add "may". >>>> >>>> --Randall >>>> >>>> On 23 Aug 2021, at 15:08, Caron, Guy wrote: >>>> >>>> Taken from section 3: >>>> >>>> The URI will be stored by the server against the location in the >>>> request for subsequent use with the notification function defined >>>> below. >>>> >>>> Guy >>>> >>>> De : Randall Gellens >>> > >>>> Envoyé : 23 août 2021 17:51 >>>> À : Caron, Guy > >>>> Cc : Brian Rosen >; >>>> ecrit@ietf.org >>>> Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: Locations are not >>>> always invalidated >>>> >>>> I don't know that that's true. My interpretation is that a LoST >>>> server might maintain a list of URIs but not associate each with >>>> specific location records, and when there is a change, it would >>>> then send a notification to each stored URI. The location that was >>>> used for the original validation query might not be impacted. >>>> >>>> --Randall >>>> >>>> On 23 Aug 2021, at 14:48, Caron, Guy wrote: >>>> >>>> I think these locations are impacted in one way or the other >>>> otherwise, the LoST server would not be able to determine that it >>>> should send notifications; they may just not become invalid in the >>>> LoST sense. >>>> >>>> >>>> Thanks, >>>> >>>> >>>> Guy >>>> >>>> >>>> >>>> >>>> De : Randall Gellens >>> > >>>> Envoyé : 23 août 2021 17:42 >>>> À : Caron, Guy > >>>> Cc : Brian Rosen >; >>>> ecrit@ietf.org >>>> Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: Locations are not >>>> always invalidated >>>> >>>> >>>> Using 'impacted' is not really better, because a location may or >>>> may not actually be impacted. If we go down the path of precise >>>> names we should use something such as >>>> 'locationPotentiallyInvalidated', which seems silly. I think the >>>> draft makes it clear (especially with my suggested edits) that a >>>> notified location is potentially invalidated. >>>> >>>> --Randall >>>> >>>> On 23 Aug 2021, at 14:24, Caron, Guy wrote: >>>> >>>> This new version introduces variability in whether a location is >>>> indeed invalidated or not by a change, which I agree with. >>>> >>>> >>>> Given this, the names “locationInvalidated†and >>>> “invalidatedAsOf†seem misleading. Should “invalidated†be >>>> changed to something like “Impacted� >>>> >>>> >>>> Thanks, >>>> >>>> >>>> Guy >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> External Email: Please use caution when opening links and >>>> attachments / Courriel externe: Soyez prudent avec les liens et >>>> documents joints >>>> >>>> External Email: Please use caution when opening links and >>>> attachments / Courriel externe: Soyez prudent avec les liens et >>>> documents joints >>> >> From nobody Tue Aug 24 09:46:03 2021 Return-Path: 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 98DCE3A1CC6 for ; Tue, 24 Aug 2021 09:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01] 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 x7rx1NSmcrP9 for ; Tue, 24 Aug 2021 09:45:57 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id C36DD3A1CBD for ; Tue, 24 Aug 2021 09:45:57 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 24 Aug 2021 09:45:57 -0700 From: "Randall Gellens" To: ecrit@ietf.org Date: Tue, 24 Aug 2021 09:45:56 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <2CEF2781-8679-4350-B8E0-3A6A001A0E7C@randy.pensive.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Archived-At: Subject: [Ecrit] Review of draft-ietf-ecrit-similar-location-09 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 16:46:01 -0000 (1) I think this draft should indicate that it updates RFC 5222. (2) In the Introduction, second paragraph, at the end of the first sentence, delete "during input" as it already says "input civic location". (3) Please replace curly quotes with straight quotes. I see curly quotes in section "Returned Location Information" at the very end of the fourth paragraph, and in the section "XML Schema" at the end of the line: xmlns="urn:ietf:params:xml:ns:lost-rli1†Otherwise, the document looks good to me. --Randall From nobody Tue Aug 24 10:48:51 2021 Return-Path: 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 DDE743A08EB for ; Tue, 24 Aug 2021 10:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=bell.ca 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 CKWd71LxAbVL for ; Tue, 24 Aug 2021 10:48:43 -0700 (PDT) Received: from ESA2-Wyn.bell.ca (esa2-wyn.bell.ca [67.69.243.180]) (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 9B8843A08F6 for ; Tue, 24 Aug 2021 10:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1629827323; x=1661363323; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=E++VYr8+ralnXNLs8DOR4fNK+znd1sqA2OAU7Uo3b3I=; b=GR1Z+MEr2wRytHoN1nFShYWqn6XswM2C3qKwZ2lgzfVDfAApK5ty72u5 uLuH+Ef1Lqsxaf5l9bMBfie7qNv4E/AYKxC+iLgMpslsKhPOSBKjdJPXt pcO2lAiycLwnZWWFvN7a/wcyQzbtDsPIRQlENziEDE8NUtuCtHh4HDBGo QFN7cjldhJVxtTCZY8rzdYPMz6ypCf0hGxnxOFGQI4K6Id2a/lHx6xe0D mPCAjLEu4H12CqqbI+1BY7OeuQWRawCrSWOsGoaaTm8PBtPrpkTu1Ir9z nGrHHt17sLD1He8lWBPzRqh7uMmMM507Wq3IlBnyFfSJHKIQEXYVJyD+O A==; IronPort-SDR: dEy/DbA1f1ZpGrejFZbX88C8wzREo3ic/5DDt9bbMNVc7WyPn65WsIripkDOOcPHs9bEUAlj9F a9lMZMZ+4PZg== Received: from dm5cch-d01.bellca.int.bell.ca (HELO DG3MBX03-WYN.bell.corp.bce.ca) ([198.235.102.31]) by esa02corp-wyn.bell.corp.bce.ca with ESMTP; 24 Aug 2021 13:48:41 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG3MBX03-WYN.bell.corp.bce.ca (142.182.18.25) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Tue, 24 Aug 2021 13:48:41 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Tue, 24 Aug 2021 13:48:41 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Tue, 24 Aug 2021 13:48:41 -0400 From: "Caron, Guy" To: Brian Rosen CC: "ecrit@ietf.org" Thread-Topic: [EXT]Re: lost-planned-changes-04: XML vs RelaxNG Thread-Index: AdeYW610lcAN4DSJTRSUJyajp2ZwpwAJHmmAAAgbylD//8jagP//IDTA Date: Tue, 24 Aug 2021 17:48:41 +0000 Message-ID: <3664c600fa824230906807733dbff5ad@bell.ca> References: <7f40b92699324c7588a8baab528aab36@bell.ca> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.78] Content-Type: multipart/alternative; boundary="_000_3664c600fa824230906807733dbff5adbellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: XML vs RelaxNG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 17:48:50 -0000 --_000_3664c600fa824230906807733dbff5adbellca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciBwb2ludGluZyBtZSB0byB0aGlzIGVtYWlsLiBNeSBzZWFyY2ggc29tZWhvdyBk aWQgbm90IGZpbmQgdGhpcyBvbmUuDQoNClJlYWRpbmcgdGhlIGNvbW1lbnRzLCBpdCBzZWVtcyB0 byBtZSB0aGF0IHRoZSBjb21tZW50ZXIgaXMgbm90IHRvdGFsbHkgYWR2ZXJzZSB0byB0aGUgaWRl YSBvZiBtYWtpbmcgYSBub3JtYXRpdmUgY2hhbmdlIHRvd2FyZHMgdGhlIFhNTCBzY2hlbWEuDQoN CknigJltIG5vdCBmYW1pbGlhciBlbm91Z2ggd2l0aCB0aGUgcHJvY2VzcyB0byBkZXRlcm1pbmUg aWYgb3IgaG93IHRoZSBSZWxheE5HIHZlcnNpb24gb2YgdGhlIExvU1Qgc2NoZW1hIGNhbiBiZSBk ZXByZWNhdGVkLiBJIGNhbiBsaXZlIHdpdGggYSBub3JtYXRpdmUgWE1MIHZlcnNpb24gdG8gd2hp Y2ggYW55IGZ1cnRoZXIgZXh0ZW5zaW9ucyAob3IgdXBkYXRlcykgYXR0YWNoIHRvIGFuZCBsZWF2 ZSB0aGUgaW5pdGlhbCBSZWxheE5HIHNjaGVtYSBiZWNvbWluZyBvcmdhbmljYWxseSBvdXRkYXRl ZCBhbmQgdXNlbGVzcy4NCg0KVGhhbmtzLA0KDQpHdXkNCg0KRGUgOiBCcmlhbiBSb3NlbiA8YnJA YnJpYW5yb3Nlbi5uZXQ+DQpFbnZvecOpIDogMjMgYW/Du3QgMjAyMSAxNzoxMg0Kw4AgOiBDYXJv biwgR3V5IDxnLmNhcm9uQGJlbGwuY2E+DQpDYyA6IGVjcml0QGlldGYub3JnDQpPYmpldCA6IFtF WFRdUmU6IGxvc3QtcGxhbm5lZC1jaGFuZ2VzLTA0OiBYTUwgdnMgUmVsYXhORw0KDQpodHRwczov L21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2Vjcml0L29UUFN6eHNMcDNZTnk4SjZIT3dZ anhkeDFiSS8NCg0KSWYgd2UgZG9u4oCZdCBkZXByZWNhdGUgdGhlIFJlbGF4Tkcgc2NoZW1hLCBz aG91bGRu4oCZdCBleHRlbnNpb25zIGhhdmUgdG8gcHJvdmlkZSBSZWxheCBORz8gICBUaGF04oCZ cyBteSBzZXRmIHNlcnZpbmcgcmVhc29uIHRvIGRlcHJlY2F0ZSBpdC4gICBJIGd1ZXNzIHdlIGNv dWxkIG5vdCBhY3R1YWxseSBkZXByZWNhdGUgaXQsIGJ1dCBub3JtYXRpdmVseSB1cGRhdGUgNTIy MiB0byBzYXkgdGhhdCBleHRlbnNpb25zIHNob3VsZCByZWZlcmVuY2UgdGhlIHhtbCBzY2hlbWEu DQoNCkJyaWFuDQoNCg0KDQoNCk9uIEF1ZyAyMywgMjAyMSwgYXQgNDo1OSBQTSwgQ2Fyb24sIEd1 eSA8Zy5jYXJvbkBiZWxsLmNhPG1haWx0bzpnLmNhcm9uQGJlbGwuY2E+PiB3cm90ZToNCg0KSWYg eW91IHJlZmVyIHRvIGdlbmVyYWwgY29tbWVudHMgbWFkZSBpbiB0aGUgZWFybHkgZGF5cyBvZiBM b1NULCBzb21lIDE1IHllYXJzIGFnbywgSSBndWVzcyB0aW1lIHRlbGxzIHRoYXQgUmVsYXhORyBk aWQgbm90IHJhbXAgdXAgYXMgZXhwZWN0ZWQuDQoNCkkgY2Fu4oCZdCBmaW5kIGNvbW1lbnRzIG9u IHRoZSBFQ1JJVCBsaXN0IHNwZWNpZmljIHRvIHBsYW5uZWQtY2hhbmdlcyBhc2tpbmcgZm9yIFhN TCBzY2hlbWFzIHRvIGJlIGluZm9ybWF0aXZlIHdoaWxlIHVwZGF0aW5nIFJGQzUyMjIuDQoNCkkg YWdyZWUgd2l0aCB5b3VyIHNlbnRpbWVudCB0aGF0IFhNTCBzY2hlbWFzIHNob3VsZCBiZSBhIG5v cm1hdGl2ZSBhbHRlcm5hdGl2ZSAoaS5lLiwgZG9lcyBub3QgZGVwcmVjYXRlcykgdG8gUmVsYXhO Ry4NCg0KQmVzaWRlcywgYnkgbm90IHByb3ZpZGluZyBSZWxheE5HIGVxdWl2YWxlbnRzIGZvciB0 aGUgZXh0ZW5zaW9ucywgaXNu4oCZdCB0aGF0IHdoYXQgeW91IGFyZSBkb2luZyBhbnl3YXk/DQoN ClRoYW5rcywNCg0KR3V5DQoNCkRlIDogQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0PG1h aWx0bzpickBicmlhbnJvc2VuLm5ldD4+DQpFbnZvecOpIDogMjMgYW/Du3QgMjAyMSAxNjozNw0K w4AgOiBDYXJvbiwgR3V5IDxnLmNhcm9uQGJlbGwuY2E8bWFpbHRvOmcuY2Fyb25AYmVsbC5jYT4+ DQpDYyA6IGVjcml0QGlldGYub3JnPG1haWx0bzplY3JpdEBpZXRmLm9yZz4NCk9iamV0IDogW0VY VF1SZTogbG9zdC1wbGFubmVkLWNoYW5nZXMtMDQ6IFhNTCB2cyBSZWxheE5HDQoNCldlIGhhdmUg aGFkIGNvbW1lbnRzIHN1Z2dlc3RpbmcgaXQgYmUgbm9uIG5vcm1hdGl2ZSwgd2hpY2ggaXMgd2h5 IGl0IHNheXMgd2hhdCBpdCBkb2VzIG5vdy4NCg0KTXkgcGVyc29uYWwgdmlldyBpcyB0aGF0IGl0 IHNob3VsZCByZXBsYWNlIHRoZSBSZWxheCBORyBzY2hlbWEsIGFuZCBhbnkgc3Vic2VxdWVudCBj aGFuZ2VzIGFuZCBleHRlbnNpb25zIHNob3VsZCBvbmx5IHJlZmVyZW5jZSB0aGlzIG9uZS4gTm8g b25lIHRoYXQgSSBrbm93IHVzZXMgdGhlIFJlbGF4IE5HIHNjaGVtYSBvbmUgd2F5IG9yIGFub3Ro ZXIgdGhleSBnZXQgYW4geG1sIHNjaGVtYSBhbmQgdXNlIHRoYXQuDQoNCkJ1dCBJIHdpbGwgZ28g d2l0aCB3aGF0ZXZlciB0aGUgY29uc2Vuc3VzIGlzDQoNCkJyaWFuDQoNCk9uIE1vbiwgQXVnIDIz LCAyMDIxIGF0IDQ6MzIgUE0gQ2Fyb24sIEd1eSA8Zy5jYXJvbkBiZWxsLmNhPG1haWx0bzpnLmNh cm9uQGJlbGwuY2E+PiB3cm90ZToNCkluIHNlY3Rpb24gNywgdGhlIHJlcGxhY2VtZW50IFhNTCBz Y2hlbWEgaXMgcXVhbGlmaWVkIGFzIGFuIOKAnGluZm9ybWF0aXZlIGFsdGVybmF0aXZl4oCdIGhv d2V2ZXIsIHRoZSB0ZXh0IGluIHRoZSBJbnRybyBzdGF0ZXMg4oCcQWx0ZXJuYXRpdmUgc2NoZW1h cyBoYXZlIGJlZW4gY2lyY3VsYXRlZCwgd2hpY2ggaXMgdW5kZXNpcmFibGUsIGFzIHRoZXkgbWF5 IG5vdCBiZSBpbiBjb25mb3JtYW5jZSB0byB0aGUgUmVsYXhORyBzY2hlbWEgaW4gW1JGQzUyMjJd LiBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGFuIFhNTCBzY2hlbWEgdGhhdCByZXBsYWNlcyB0aGUg UmVsYXhORyBzY2hlbWEuIEl0IGNhbiBiZSB1c2VkIGJ5IGFueSBpbXBsZW1lbnRhdGlvbiBpbnRl cmNoYW5nZWFibHkgd2l0aCB0aGUgUmVsYXhORyBzY2hlbWEu4oCdDQoNClRoZSBsYXR0ZXIgc2Vl bXMgdG8gaW5kaWNhdGUgdGhhdCB0aGUgWE1MIHNjaGVtYSBpbiBzZWN0aW9uIDcgaXMgYSBub3Jt YXRpdmUgYWx0ZXJuYXRpdmUgcmF0aGVyIHRoYW4gYW4gaW5mb3JtYXRpdmUgb25lLg0KDQpJIHRo aW5rIHRoaXMgaXMgd2hhdCB3ZSB3YW50IGJ1dCB0aGUgdGV4dCBtdXN0IGJlIGFkanVzdGVkIGFj Y29yZGluZ2x5Lg0KDQpUaGFua3MsDQoNCkd1eQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkV4dGVybmFsIEVtYWlsOiBQbGVhc2UgdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxp bmtzIGFuZCBhdHRhY2htZW50cyAvIENvdXJyaWVsIGV4dGVybmU6IFNveWV6IHBydWRlbnQgYXZl YyBsZXMgbGllbnMgZXQgZG9jdW1lbnRzIGpvaW50cw0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KRXh0ZXJuYWwgRW1haWw6IFBsZWFzZSB1c2UgY2F1dGlvbiB3aGVuIG9wZW5p bmcgbGlua3MgYW5kIGF0dGFjaG1lbnRzIC8gQ291cnJpZWwgZXh0ZXJuZTogU295ZXogcHJ1ZGVu dCBhdmVjIGxlcyBsaWVucyBldCBkb2N1bWVudHMgam9pbnRzDQo= --_000_3664c600fa824230906807733dbff5adbellca_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5t c29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFt ZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpz cGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0 ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSLUNBIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rcyBmb3IgcG9pbnRpbmcgbWUgdG8gdGhp cyBlbWFpbC4gTXkgc2VhcmNoIHNvbWVob3cgZGlkIG5vdCBmaW5kIHRoaXMgb25lLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5SZWFkaW5nIHRoZSBjb21tZW50cywgaXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgY29tbWVudGVy IGlzIG5vdCB0b3RhbGx5IGFkdmVyc2UgdG8gdGhlIGlkZWEgb2YgbWFraW5nIGEgbm9ybWF0aXZl IGNoYW5nZQ0KIHRvd2FyZHMgdGhlIFhNTCBzY2hlbWEuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPknigJltIG5vdCBmYW1p bGlhciBlbm91Z2ggd2l0aCB0aGUgcHJvY2VzcyB0byBkZXRlcm1pbmUgaWYgb3IgaG93IHRoZSBS ZWxheE5HIHZlcnNpb24gb2YgdGhlIExvU1Qgc2NoZW1hIGNhbiBiZSBkZXByZWNhdGVkLg0KIEkg Y2FuIGxpdmUgd2l0aCBhIG5vcm1hdGl2ZSBYTUwgdmVyc2lvbiB0byB3aGljaCBhbnkgZnVydGhl ciBleHRlbnNpb25zIChvciB1cGRhdGVzKSBhdHRhY2ggdG8gYW5kIGxlYXZlIHRoZSBpbml0aWFs IFJlbGF4Tkcgc2NoZW1hIGJlY29taW5nIG9yZ2FuaWNhbGx5IG91dGRhdGVkIGFuZCB1c2VsZXNz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkd1eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5n PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkZSIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiBCcmlhbiBSb3NlbiAmbHQ7YnJAYnJpYW5yb3Nlbi5uZXQmZ3Q7DQo8YnI+DQo8Yj5F bnZvecOpJm5ic3A7OjwvYj4gMjMgYW/Du3QgMjAyMSAxNzoxMjxicj4NCjxiPsOAJm5ic3A7Ojwv Yj4gQ2Fyb24sIEd1eSAmbHQ7Zy5jYXJvbkBiZWxsLmNhJmd0Ozxicj4NCjxiPkNjJm5ic3A7Ojwv Yj4gZWNyaXRAaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFtFWFRdUmU6IGxvc3Qt cGxhbm5lZC1jaGFuZ2VzLTA0OiBYTUwgdnMgUmVsYXhORzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0 Zi5vcmcvYXJjaC9tc2cvZWNyaXQvb1RQU3p4c0xwM1lOeThKNkhPd1lqeGR4MWJJLyI+aHR0cHM6 Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9lY3JpdC9vVFBTenhzTHAzWU55OEo2SE93 WWp4ZHgxYkkvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SWYgd2UgZG9u4oCZdCBkZXByZWNhdGUgdGhlIFJlbGF4Tkcgc2NoZW1hLCBzaG91bGRu4oCZ dCBleHRlbnNpb25zIGhhdmUgdG8gcHJvdmlkZSBSZWxheCBORz8gJm5ic3A7IFRoYXTigJlzIG15 IHNldGYgc2VydmluZyByZWFzb24gdG8gZGVwcmVjYXRlIGl0LiAmbmJzcDsgSSBndWVzcyB3ZSBj b3VsZCBub3QgYWN0dWFsbHkgZGVwcmVjYXRlIGl0LCBidXQgbm9ybWF0aXZlbHkgdXBkYXRlIDUy MjIgdG8gc2F5IHRoYXQgZXh0ZW5zaW9ucyBzaG91bGQNCiByZWZlcmVuY2UgdGhlIHhtbCBzY2hl bWEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkJyaWFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gQXVnIDIzLCAyMDIxLCBhdCA0OjU5IFBNLCBDYXJvbiwgR3V5ICZsdDs8YSBocmVmPSJtYWls dG86Zy5jYXJvbkBiZWxsLmNhIj5nLmNhcm9uQGJlbGwuY2E8L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SWYgeW91IHJlZmVyIHRvIGdlbmVyYWwgY29tbWVu dHMgbWFkZSBpbiB0aGUgZWFybHkgZGF5cyBvZiBMb1NULCBzb21lIDE1IHllYXJzIGFnbywgSSBn dWVzcyB0aW1lIHRlbGxzIHRoYXQgUmVsYXhORyBkaWQgbm90IHJhbXAgdXAgYXMgZXhwZWN0ZWQu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgY2Fu4oCZdCBmaW5k IGNvbW1lbnRzIG9uIHRoZSBFQ1JJVCBsaXN0IHNwZWNpZmljIHRvIHBsYW5uZWQtY2hhbmdlcyBh c2tpbmcgZm9yIFhNTCBzY2hlbWFzIHRvIGJlIGluZm9ybWF0aXZlIHdoaWxlIHVwZGF0aW5nIFJG QzUyMjIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUg d2l0aCB5b3VyIHNlbnRpbWVudCB0aGF0IFhNTCBzY2hlbWFzIHNob3VsZCBiZSBhIG5vcm1hdGl2 ZSBhbHRlcm5hdGl2ZSAoaS5lLiwgZG9lcyBub3QgZGVwcmVjYXRlcykgdG8gUmVsYXhORy48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QmVzaWRlcywgYnkgbm90IHBy b3ZpZGluZyBSZWxheE5HIGVxdWl2YWxlbnRzIGZvciB0aGUgZXh0ZW5zaW9ucywgaXNu4oCZdCB0 aGF0IHdoYXQgeW91IGFyZSBkb2luZyBhbnl3YXk/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+R3V5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9 IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwv c3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Ccmlhbg0KIFJvc2VuICZsdDs8YSBocmVm PSJtYWlsdG86YnJAYnJpYW5yb3Nlbi5uZXQiPmJyQGJyaWFucm9zZW4ubmV0PC9hPiZndDs8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+RW52 b3nDqSZuYnNwOzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjIzIGFvw7t0IDIwMjEgMTY6Mzc8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkNhcm9uLCBHdXkgJmx0Ozxh IGhyZWY9Im1haWx0bzpnLmNhcm9uQGJlbGwuY2EiPmcuY2Fyb25AYmVsbC5jYTwvYT4mZ3Q7PGJy Pg0KPGI+Q2MmbmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZWNyaXRAaWV0Zi5vcmciPmVjcml0QGlldGYub3Jn PC9hPjxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+W0VYVF1SZTogbG9zdC1wbGFubmVkLWNoYW5nZXMtMDQ6IFhN TCB2cyBSZWxheE5HPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgaGF2ZSBoYWQgY29tbWVudHMgc3VnZ2VzdGluZyBp dCBiZSBub24gbm9ybWF0aXZlLCB3aGljaCBpcyB3aHkgaXQgc2F5cyB3aGF0IGl0IGRvZXMgbm93 LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBwZXJzb25hbCB2aWV3IGlzIHRo YXQgaXQgc2hvdWxkIHJlcGxhY2UgdGhlIFJlbGF4IE5HIHNjaGVtYSwgYW5kIGFueSBzdWJzZXF1 ZW50IGNoYW5nZXMgYW5kIGV4dGVuc2lvbnMgc2hvdWxkIG9ubHkgcmVmZXJlbmNlIHRoaXMgb25l LiBObyBvbmUgdGhhdCBJIGtub3cgdXNlcyB0aGUgUmVsYXggTkcgc2NoZW1hIG9uZSB3YXkgb3Ig YW5vdGhlciB0aGV5IGdldCBhbiB4bWwgc2NoZW1hIGFuZCB1c2UgdGhhdC4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IEkgd2lsbCBnbyB3aXRoIHdoYXRldmVyIHRoZSBjb25z ZW5zdXMgaXMgJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJyaWFuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBBdWcgMjMsIDIwMjEgYXQgNDozMiBQTSBDYXJvbiwg R3V5ICZsdDs8YSBocmVmPSJtYWlsdG86Zy5jYXJvbkBiZWxsLmNhIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5nLmNhcm9uQGJlbGwuY2E8L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1DQSI+SW4gc2VjdGlvbiA3LCB0aGUgcmVwbGFjZW1lbnQgWE1MIHNj aGVtYSBpcyBxdWFsaWZpZWQgYXMgYW4g4oCcaW5mb3JtYXRpdmUgYWx0ZXJuYXRpdmXigJ0gaG93 ZXZlciwgdGhlIHRleHQgaW4gdGhlIEludHJvIHN0YXRlcyDigJxBbHRlcm5hdGl2ZSBzY2hlbWFz IGhhdmUgYmVlbiBjaXJjdWxhdGVkLCB3aGljaCBpcyB1bmRlc2lyYWJsZSwgYXMgdGhleSBtYXkg bm90IGJlIGluIGNvbmZvcm1hbmNlDQogdG8gdGhlIFJlbGF4Tkcgc2NoZW1hIGluIFtSRkM1MjIy XS4gVGhpcyBkb2N1bWVudCBwcm92aWRlcyBhbiBYTUwgc2NoZW1hIHRoYXQgcmVwbGFjZXMgdGhl IFJlbGF4Tkcgc2NoZW1hLiBJdCBjYW4gYmUgdXNlZCBieSBhbnkgaW1wbGVtZW50YXRpb24gaW50 ZXJjaGFuZ2VhYmx5IHdpdGggdGhlIFJlbGF4Tkcgc2NoZW1hLuKAnTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+VGhlIGxhdHRlciBzZWVtcyB0byBpbmRp Y2F0ZSB0aGF0IHRoZSBYTUwgc2NoZW1hIGluIHNlY3Rpb24gNyBpcyBhIG5vcm1hdGl2ZSBhbHRl cm5hdGl2ZSByYXRoZXIgdGhhbiBhbiBpbmZvcm1hdGl2ZSBvbmUuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t Q0EiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5JIHRoaW5rIHRoaXMgaXMgd2hhdCB3ZSB3 YW50IGJ1dCB0aGUgdGV4dCBtdXN0IGJlIGFkanVzdGVkIGFjY29yZGluZ2x5Ljwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUNBIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+VGhhbmtzLDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1DQSI+R3V5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1h bCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIy IiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6 Ymx1ZSI+RXh0ZXJuYWwgRW1haWw6PC9zcGFuPjwvaT48L3N0cm9uZz48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9y OmJsdWUiPiZuYnNwOzwvc3Bhbj48L2k+PC9zcGFuPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2NvbG9yOmJsdWUiPlBsZWFzZQ0KIHVzZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBsaW5r cyBhbmQgYXR0YWNobWVudHMgLzwvc3Bhbj48L2VtPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+Jm5i c3A7PC9zcGFuPjwvaT48L3NwYW4+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2NvbG9yOmJsdWUiPkNvdXJyaWVsIGV4dGVybmU6PC9zcGFuPjwvaT48L3N0cm9uZz48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48L2k+PC9zcGFuPjxlbT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPlNveWV6DQogcHJ1ZGVudCBhdmVjIGxlcyBs aWVucyBldCBkb2N1bWVudHMgam9pbnRzPC9zcGFuPjwvZW0+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRo PSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHN0 cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPkV4dGVybmFs IEVtYWlsOjwvc3Bhbj48L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Y29sb3I6Ymx1ZSI+IFBsZWFzZSB1c2UgY2F1dGlvbiB3aGVuIG9wZW5pbmcgbGlua3MgYW5k IGF0dGFjaG1lbnRzIC8NCjwvc3Bhbj48L2VtPjxzdHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtjb2xvcjpibHVlIj5Db3VycmllbCBleHRlcm5lOjwvc3Bhbj48L2k+PC9zdHJv bmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+IFNveWV6IHBy dWRlbnQgYXZlYyBsZXMgbGllbnMgZXQgZG9jdW1lbnRzIGpvaW50cw0KPC9zcGFuPjwvZW0+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_3664c600fa824230906807733dbff5adbellca_-- From nobody Tue Aug 24 11:12:26 2021 Return-Path: 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 0CB7A3A0A0A for ; Tue, 24 Aug 2021 11:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, 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.20150623.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 nIvlQoJVEnbA for ; Tue, 24 Aug 2021 11:12:19 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 034EE3A0A07 for ; Tue, 24 Aug 2021 11:12:19 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id y3so21438603ilm.6 for ; Tue, 24 Aug 2021 11:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Wxd13Irgt1QEaJdL/Lib6eTSbtWEKMrv2HnQEoY/F7U=; b=Uo9l7zbNMZ8on9oa3xvZG1wBZwK8PyzbdVOyKF8QUNqGXcksZi2N30dz12Y62ZpPuA AP/P8CG+5nPOda/zFOObEAOwCR5QRveIR3thHS6PjZPMST8vo/s130bZebpEhR7Keb84 VSNyUG8owo7wJH+6W+KScrAPZbEbrX+tIobyk6gUmCxIQxHcvgBAq6mEIxxa6kkO1mr0 0IdAyowZ3n3ZlOxggIHjdEhsNGDCG6IT73po7eMEDthmMDAbXJutmzoVwqQRQynC2NdX NsWmVVlk/x12FilQdudcQLBjkyngsAcY+2NegyukJpIpi2tpjg5Zv8deGoIVNRkpd0bg THfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Wxd13Irgt1QEaJdL/Lib6eTSbtWEKMrv2HnQEoY/F7U=; b=e4VY39wbHJHhzJzZHW7cJk3sVaUkWuO1XzW2nJ9/JNyfC41IB0rhNozVW/+MvpBWzf vL8osLSC9o3r2rK5C7Zo9vk7isRHVQzX6ZkZrrkIbSjSHFHBXlCqFPMZLhr+9LsfzpU6 89bCh4HzKVtJ6boZQQFPVG3HKe+6+c0FT1T8qCO6WWfbzs4pMVbH1KjbuyDJWN3Nxmk1 A0xdHYfuueWu8xYi0u/WpMbPe6eIIDTY9FJNIYhyDI+D1WE4h7SDTcNpC2YzFBpPtdQF e8cVRV/HkVQnMGs/ylzLIWet/gSrWiEQIiqYsMKUF0GW07ZTTIj9KpGFhkckjIDgsd43 FgQw== X-Gm-Message-State: AOAM531ic4w5+friVWtSNoEZwnE4O6NEyXctfR8n94CP6GWR6/LtCj8F HLhdpKmakzjRsxL5gTxCmvepZg== X-Google-Smtp-Source: ABdhPJyDMWRic/9kcYg4ZA6KK20cywamNELPmQp8cuHpjeji6q9O7rOFrykBvyA/gK2aPqK0Gjs5yg== X-Received: by 2002:a92:c94e:: with SMTP id i14mr27558034ilq.143.1629828737445; Tue, 24 Aug 2021 11:12:17 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id h10sm10127933ilj.71.2021.08.24.11.12.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Aug 2021 11:12:16 -0700 (PDT) From: Brian Rosen Message-Id: <83B4F74D-11D0-4AD5-AA6F-B6BFB2E852DB@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_88E90536-82E0-4B96-ABAF-41D83A99CD73" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Tue, 24 Aug 2021 14:12:15 -0400 In-Reply-To: <3664c600fa824230906807733dbff5ad@bell.ca> Cc: "ecrit@ietf.org" To: "Caron, Guy" References: <7f40b92699324c7588a8baab528aab36@bell.ca> <3664c600fa824230906807733dbff5ad@bell.ca> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: XML vs RelaxNG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 18:12:25 -0000 --Apple-Mail=_88E90536-82E0-4B96-ABAF-41D83A99CD73 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In general, I=E2=80=99d like to deprecate it, but I=E2=80=99m having = second thoughts on the difficulty in doing so. If we were to deprecate it, we would have to deal with existing = extensions. I see RFCs 6197, 6451 and 6739 have RelaxNG schemas that = extend LoST. I note that all 3 of these are Experimental. So one = argument is that if we deprecate the RelaxNG schema in 5222, we have to = do that to these extensions, and provide xml schemas to replace them. I = will note that LoST Sync (6739) is going to be heavily deployed soon. =20= So maybe we should normatively update 5222 to say that the RelaxNG is = =E2=80=9Creplaced by=E2=80=9D the xml schema for the purposes of = defining new extensions, but the existing extension definitions in = RelaxNG form are still valid. If someone wanted to help make xml schema = replacements for at least 6739, that would be useful. If we did all 3, = then we probably could deprecate the RelaxNG everywhere. This draft = would have to update those 3 RFCs as well as 5222. If we don=E2=80=99t deprecate the RelaxNG, then there is always the = standards issue of what if there is a discrepancy between the xml schema = and the RelaxNG. I think we would have to say that it=E2=80=99s the = RelaxNG, and we would use the errata process to fix the xml schema. The thing to keep in mind is that every implementor I know is using xml = schemas, however they get them, to build their code. The practical = answer is that everyone needs xml schemas and no one needs RelaxNG. Brian > On Aug 24, 2021, at 1:48 PM, Caron, Guy wrote: >=20 > Thanks for pointing me to this email. My search somehow did not find = this one. > =20 > Reading the comments, it seems to me that the commenter is not totally = adverse to the idea of making a normative change towards the XML schema. > =20 > I=E2=80=99m not familiar enough with the process to determine if or = how the RelaxNG version of the LoST schema can be deprecated. I can live = with a normative XML version to which any further extensions (or = updates) attach to and leave the initial RelaxNG schema becoming = organically outdated and useless. > =20 > Thanks, > =20 > Guy > =20 > De : Brian Rosen =20 > Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:12 > =C3=80 : Caron, Guy > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: XML vs RelaxNG > =20 > = https://mailarchive.ietf.org/arch/msg/ecrit/oTPSzxsLp3YNy8J6HOwYjxdx1bI/ = = > =20 > If we don=E2=80=99t deprecate the RelaxNG schema, shouldn=E2=80=99t = extensions have to provide Relax NG? That=E2=80=99s my setf serving = reason to deprecate it. I guess we could not actually deprecate it, = but normatively update 5222 to say that extensions should reference the = xml schema. > =20 > Brian > =20 > =20 >=20 >=20 > On Aug 23, 2021, at 4:59 PM, Caron, Guy > wrote: > =20 > If you refer to general comments made in the early days of LoST, some = 15 years ago, I guess time tells that RelaxNG did not ramp up as = expected. > =20 > I can=E2=80=99t find comments on the ECRIT list specific to = planned-changes asking for XML schemas to be informative while updating = RFC5222. > =20 > I agree with your sentiment that XML schemas should be a normative = alternative (i.e., does not deprecates) to RelaxNG. > =20 > Besides, by not providing RelaxNG equivalents for the extensions, = isn=E2=80=99t that what you are doing anyway? > =20 > Thanks, > =20 > Guy > =20 > De : Brian Rosen >=20 > Envoy=C3=A9 : 23 ao=C3=BBt 2021 16:37 > =C3=80 : Caron, Guy > > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: XML vs RelaxNG > =20 > We have had comments suggesting it be non normative, which is why it = says what it does now.=20 > =20 > My personal view is that it should replace the Relax NG schema, and = any subsequent changes and extensions should only reference this one. No = one that I know uses the Relax NG schema one way or another they get an = xml schema and use that.=20 > =20 > But I will go with whatever the consensus is =20 > =20 > Brian > =20 > On Mon, Aug 23, 2021 at 4:32 PM Caron, Guy > wrote: > In section 7, the replacement XML schema is qualified as an = =E2=80=9Cinformative alternative=E2=80=9D however, the text in the Intro = states =E2=80=9CAlternative schemas have been circulated, which is = undesirable, as they may not be in conformance to the RelaxNG schema in = [RFC5222]. This document provides an XML schema that replaces the = RelaxNG schema. It can be used by any implementation interchangeably = with the RelaxNG schema.=E2=80=9D > =20 > The latter seems to indicate that the XML schema in section 7 is a = normative alternative rather than an informative one. > =20 > I think this is what we want but the text must be adjusted = accordingly. > =20 > Thanks, > =20 > Guy > External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints > =20 > External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints --Apple-Mail=_88E90536-82E0-4B96-ABAF-41D83A99CD73 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 In = general, I=E2=80=99d like to deprecate it, but I=E2=80=99m having second = thoughts on the difficulty in doing so.

If we were to deprecate it, we would = have to deal with existing extensions.  I see RFCs 6197, 6451 and = 6739 have RelaxNG schemas that extend LoST.  I note that all 3 of = these are Experimental.   So one argument is that if we deprecate = the RelaxNG schema in 5222, we have to do that to these extensions, and = provide xml schemas to replace them.  I will note that LoST Sync = (6739) is going to be heavily deployed soon.  

So maybe we should = normatively update 5222 to say that the RelaxNG is =E2=80=9Creplaced = by=E2=80=9D the xml schema for the purposes of defining new extensions, = but the existing extension definitions in RelaxNG form are still valid. =  If someone wanted to help make xml schema replacements for at = least 6739, that would be useful.  If we did all 3, then we = probably could deprecate the RelaxNG everywhere.  This draft would = have to update those 3 RFCs as well as 5222.

If we don=E2=80=99t deprecate the = RelaxNG, then there is always the standards issue of what if there is a = discrepancy between the xml schema and the RelaxNG.  I think we = would have to say that it=E2=80=99s the RelaxNG, and we would use the = errata process to fix the xml schema.

The thing to keep in mind is that every = implementor I know is using xml schemas, however they get them, to build = their code. The practical answer is that everyone needs xml schemas and = no one needs RelaxNG.

Brian


On Aug = 24, 2021, at 1:48 PM, Caron, Guy <g.caron@bell.ca> wrote:

Thanks for pointing me = to this email. My search somehow did not find this one.
 
Reading the comments, it seems to me that the commenter is = not totally adverse to the idea of making a normative change towards the = XML schema.
 
I=E2=80=99m not familiar enough with the process to determine = if or how the RelaxNG version of the LoST schema can be deprecated. I = can live with a normative XML version to which any further extensions = (or updates) attach to and leave the initial RelaxNG schema becoming = organically outdated and useless.
 
Thanks,
 
Guy
 
De : Brian = Rosen <br@brianrosen.net> 
Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:12
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : ecrit@ietf.org
Objet : [EXT]Re: = lost-planned-changes-04: XML vs RelaxNG
 
https://mailarchive.ietf.org/arch/msg/ecrit/oTPSzxsLp3YNy8J6HOw= Yjxdx1bI/
 
If we don=E2=80=99t deprecate the = RelaxNG schema, shouldn=E2=80=99t extensions have to provide Relax NG? =   That=E2=80=99s my setf serving reason to deprecate it.   I = guess we could not actually deprecate it, but normatively update 5222 to = say that extensions should reference the xml schema.
 
Brian
 
 


On Aug 23, 2021, at 4:59 PM, Caron, Guy = <g.caron@bell.ca> = wrote:
 
If you refer to general = comments made in the early days of LoST, some 15 years ago, I guess time = tells that RelaxNG did not ramp up as expected.
 
I can=E2=80=99t find = comments on the ECRIT list specific to planned-changes asking for XML = schemas to be informative while updating RFC5222.
 
I agree with your = sentiment that XML schemas should be a normative alternative (i.e., does = not deprecates) to RelaxNG.
 
Besides, by not providing RelaxNG equivalents for the = extensions, isn=E2=80=99t that what you are doing anyway?
 
Thanks,
 
Guy
 
De : Brian Rosen <br@brianrosen.net> 
Envoy=C3=A9 : 23 ao=C3=BBt 2021 16:37
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : ecrit@ietf.org
Objet : [EXT]Re: = lost-planned-changes-04: XML vs RelaxNG
 
We have had comments suggesting it be non normative, which is = why it says what it does now. 
 
My personal view is that = it should replace the Relax NG schema, and any subsequent changes and = extensions should only reference this one. No one that I know uses the = Relax NG schema one way or another they get an xml schema and use = that. 
 
But I will go with = whatever the consensus is  
 
Brian
 
On Mon, Aug = 23, 2021 at 4:32 PM Caron, Guy <g.caron@bell.ca> = wrote:
In section 7, the replacement XML schema is = qualified as an =E2=80=9Cinformative alternative=E2=80=9D however, the = text in the Intro states =E2=80=9CAlternative schemas have been = circulated, which is undesirable, as they may not be in conformance to = the RelaxNG schema in [RFC5222]. This document provides an XML schema = that replaces the RelaxNG schema. It can be used by any implementation = interchangeably with the RelaxNG schema.=E2=80=9D
 
The latter seems to = indicate that the XML schema in section 7 is a normative alternative = rather than an informative one.
 
I think this is what = we want but the text must be adjusted accordingly.
 
Thanks,
 
Guy
External Email: Please use caution = when opening links and attachments / Courriel externe: Soyez prudent avec = les liens et documents joints
 
External Email: Please use caution when = opening links and attachments / Courriel externe: Soyez prudent avec les = liens et documents = joints

= --Apple-Mail=_88E90536-82E0-4B96-ABAF-41D83A99CD73-- From nobody Tue Aug 24 11:25:11 2021 Return-Path: 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 CB9853A0ABD for ; Tue, 24 Aug 2021 11:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=bell.ca 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 mMbPnGC0dVNT for ; Tue, 24 Aug 2021 11:25:01 -0700 (PDT) Received: from ESA2-Wyn.bell.ca (esa2-wyn.bell.ca [67.69.243.180]) (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 89B0E3A0ABA for ; Tue, 24 Aug 2021 11:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1629829501; x=1661365501; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=5pvbZRKmJjqEjuKC6wGeE6sZtT7MIRTPrukS2HvPBlU=; b=GK3qOkQ0c486kUZkDOCvhTVnNDM/yqzdLfGBMIt6N3Ao4b3Fgr3sI0BX CBmeONls6+G7abVEc9n7ozR3RFJfEQXSu4tihH2U/jFuAPWX1MaY1CdpA NAszLRrZYIQzza6Re/1LMo4IF9dG9hXZlT+JM8UrPpDHx6uM0m8QJp1pd yrUCG1FG91sM5XOiGKRYqc6iMX71OD720H0lVWbF0QOLOTzP3me/Nzah5 YmLANmgO9olj9I8hZL9DGepoO1lz3nwtxi7JwiUJL0klYG7D9mHX4CZDo kmf6Lt79j+q56t8PRiI1QLhkf5/oJZqONyOIVskWFUPQ8vTF16VV/TZX+ w==; IronPort-SDR: CuIUQjCnZNFhdq5cPJvT5/BkuhR0THrl0sYiYkADpuJwzBmOWBPWJt6sx98VSlerFHz3P/kPCC xXRZ4C/SKUCQ== Received: from dm5czo-d01.bellca.int.bell.ca (HELO DG4MBX04-WYN.bell.corp.bce.ca) ([198.235.102.33]) by esa02corp-wyn.bell.corp.bce.ca with ESMTP; 24 Aug 2021 14:25:00 -0400 Received: from DG12MBX02-WYN.bell.corp.bce.ca (142.182.18.47) by DG4MBX04-WYN.bell.corp.bce.ca (142.182.18.30) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Tue, 24 Aug 2021 14:24:59 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX02-WYN.bell.corp.bce.ca (142.182.18.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Tue, 24 Aug 2021 14:24:59 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Tue, 24 Aug 2021 14:24:59 -0400 From: "Caron, Guy" To: Randall Gellens CC: Brian Rosen , "ecrit@ietf.org" Thread-Topic: [EXT]Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation? Thread-Index: AQHXmG6diYrOvVeBqkq3ZlL20BGRLauBrHuggABFQoCAAQeCAA== Date: Tue, 24 Aug 2021 18:24:59 +0000 Message-ID: References: <8bdda7ea7d004b4591ff715526d93a73@bell.ca> <791ea34f628d48d3addeb04613d5721a@bell.ca> <9158D09E-770E-4E65-BE46-E39060EAC884@brianrosen.net> <0b81d439e4824aec8a3476906ce5cbc1@bell.ca> <7C21F96F-E238-4DA2-82BB-D7C731A84D53@brianrosen.net> <038dcfc4405d4ebe8930d6225f09ea83@bell.ca> <6EC6E0D3-B9E8-476D-A6F7-E1D20817B58E@brianrosen.net> <64E97C26-36C8-4024-89E3-E23379E614B5@randy.pensive.org> <794ed22ebe3e48cdb0e72cf3f0a91429@bell.ca> <2B6FB05F-6A89-4680-893F-06584E7EFAF8@randy.pensive.org> In-Reply-To: <2B6FB05F-6A89-4680-893F-06584E7EFAF8@randy.pensive.org> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.78] Content-Type: multipart/alternative; boundary="_000_bae4a816c98f4df4b672b265a988df99bellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 18:25:08 -0000 --_000_bae4a816c98f4df4b672b265a988df99bellca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QnV0IHlvdSBhcmUgYWR2b2NhdGluZyBmb3IgYSBtb2RlbCB0aGF0IGlzIHVzZWxlc3MuIFdoeSBu b3QgYmUgY2xlYXIgb24gd2hhdCB0aGlzIGlzIGRvaW5nIGFuZCB3aGF0IGl0IGlzIG5vdD8NCg0K R3V5DQoNCkRlIDogUmFuZGFsbCBHZWxsZW5zIDxyZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnPg0K RW52b3nDqSA6IDIzIGFvw7t0IDIwMjEgMTg6NDANCsOAIDogQ2Fyb24sIEd1eSA8Zy5jYXJvbkBi ZWxsLmNhPg0KQ2MgOiBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ+OyBlY3JpdEBpZXRm Lm9yZw0KT2JqZXQgOiBbRVhUXVJlOiBbRWNyaXRdIGxvc3QtcGxhbm5lZC1jaGFuZ2VzLTA0OiBw bGFubmVkQ2hhbmdlIGJvdW5kIHRvIHZhbGlkYXRlTG9jYXRpb24/DQoNCg0KSSdtIHRyeWluZyB0 byB1bmRlcnN0YW5kIHRoZSBoYXJtIG9mIGFsbG93aW5nIGEgY2xpZW50IHRvIHJlcXVlc3Qgbm90 aWZpY2F0aW9uIHdoZXRoZXIgaXQgaXMgYXNraW5nIGZvciB2YWxpZGF0aW9uIG9yIG5vdC4gV2Ug YWxyZWFkeSBzYXkgdGhhdCBzZXJ2ZXIgcG9saWN5IGNhbiByZWZ1c2UgdG8gc3RvcmUgYSBVUkkg Zm9yIGFueSByZWFzb24sIHNvIGEgc2VydmVyIGNvdWxkIHByb2hpYml0IHRoaXMgaWYgaXQgd2Fu dHMgdG8gKGUuZy4sIHRvIHNhdmUgcmVzb3VyY2VzKS4gSWYgYSBzZXJ2ZXIgaXMgT0sgcHJvdmlk aW5nIHRoaXMgc2VydmVyLCB3aGF0IGRvIHdlIGNhcmU/IEl0IGRvZXNuJ3QgaGFybSBpbnRlcm9w ZXJhYmlsaXR5Lg0KDQotLVJhbmRhbGwNCg0KT24gMjMgQXVnIDIwMjEsIGF0IDE1OjM0LCBDYXJv biwgR3V5IHdyb3RlOg0KDQpJ4oCZbSBub3QgY29uY2VybmVkIGFib3V0IGEgY2xpZW50IHRoYXQg d2lsbGZ1bGx5IGFuZCBrbm93aW5nbHkgYXNrcyBmb3IgaXQuDQoNCg0KDQpUaGlzIHdob2xlIGRy YWZ0IHJldm9sdmVzIGFyb3VuZCBsb2NhdGlvbiB2YWxpZGF0aW9uLiBJ4oCZbSBub3QgdW5kZXJz dGFuZGluZyB0aGUgcHVzaGJhY2sgaGVyZS4NCg0KDQoNCkd1eQ0KDQoNCg0KRGUgOiBSYW5kYWxs IEdlbGxlbnMgPHJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmc8bWFpbHRvOnJnK2lldGZAcmFuZHku cGVuc2l2ZS5vcmc+Pg0KRW52b3nDqSA6IDIzIGFvw7t0IDIwMjEgMTg6MzENCsOAIDogQ2Fyb24s IEd1eSA8Zy5jYXJvbkBiZWxsLmNhPG1haWx0bzpnLmNhcm9uQGJlbGwuY2E+Pg0KQ2MgOiBCcmlh biBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ8bWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0Pj47IGVj cml0QGlldGYub3JnPG1haWx0bzplY3JpdEBpZXRmLm9yZz4NCk9iamV0IDogW0VYVF1SZTogW0Vj cml0XSBsb3N0LXBsYW5uZWQtY2hhbmdlcy0wNDogcGxhbm5lZENoYW5nZSBib3VuZCB0byB2YWxp ZGF0ZUxvY2F0aW9uPw0KDQoNCg0KSWYgYSBjbGllbnQgd2FudHMgdG8gZ2V0IG5vdGlmaWVkIHRo YXQgYSBsb2NhdGlvbiBtYXkgaGF2ZSBiZWNvbWUgaW52YWxpZGF0ZWQsIHdoeSBkbyB3ZSBjYXJl IHdoeSBvciB3aGF0IHR5cGUgb2YgY2xpZW50IGl0IGlzPw0KDQotLVJhbmRhbGwNCg0KT24gMjMg QXVnIDIwMjEsIGF0IDE1OjI2LCBDYXJvbiwgR3V5IHdyb3RlOg0KDQpJIHVuZGVyc3RhbmQgYW5k IHdoYXQgSeKAmW0gc3VnZ2VzdGluZyBpcyB0byBiZSBjbGVhciBhYm91dCB3aGF0IExvU1QgY2xp ZW50cyBhcmUgZXhwZWN0ZWQgdG8gZG8uIFdlIGRvIG5vdCB3YW50IGEgbGVhc3kgaW1wbGVtZW50 YXRpb24gc2VuZGluZyA8cGxhbm5lZENoYW5nZT4gYWNyb3NzIHRoZSBib2FyZCwgZG9u4oCZdCB3 ZT8gSSB0aGluayBpdCBpcyBlYXN5IGFuZCBjaGVlcCB0byBmaXggaW4gdGhlIGRyYWZ0IHJhdGhl ciB0byB0cnkgdG8gZml4IGltcGxlbWVudGF0aW9ucyBsYXRlci4NCg0KDQoNCkd1eQ0KDQoNCg0K RGUgOiBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ8bWFpbHRvOmJyQGJyaWFucm9zZW4u bmV0Pj4NCkVudm95w6kgOiAyMyBhb8O7dCAyMDIxIDE4OjE0DQrDgCA6IENhcm9uLCBHdXkgPGcu Y2Fyb25AYmVsbC5jYTxtYWlsdG86Zy5jYXJvbkBiZWxsLmNhPj4NCkNjIDogZWNyaXRAaWV0Zi5v cmc8bWFpbHRvOmVjcml0QGlldGYub3JnPg0KT2JqZXQgOiBbRVhUXVJlOiBsb3N0LXBsYW5uZWQt Y2hhbmdlcy0wNDogcGxhbm5lZENoYW5nZSBib3VuZCB0byB2YWxpZGF0ZUxvY2F0aW9uPw0KDQoN Cg0KU3VyZSwgUFNBUHMgY291bGQgYmUgYSBMb1NUIGNsaWVudCBmb3IgZXhhbXBsZS4gIEEgcm91 dGluZyBwcm94eSBjYW4gYmUgYSBMb1NUIGNsaWVudC4gIEJ1dCB0aGV5IHdvdWxkbuKAmXQgYXNr IHRvIHN0b3JlIHRoZSBVUkkuICBZb3UgaGF2ZSB0byBhc2sgZm9yIGl0IHRvIGdldCB0aGUgbm90 aWZpY2F0aW9uLg0KDQoNCg0KQnJpYW4NCg0KDQoNCk9uIEF1ZyAyMywgMjAyMSwgYXQgNjoxMCBQ TSwgQ2Fyb24sIEd1eSA8Zy5jYXJvbkBiZWxsLmNhPG1haWx0bzpnLmNhcm9uQGJlbGwuY2E+PiB3 cm90ZToNCg0KDQoNCllvdSBtaXNzIG15IHBvaW50LiBUaGUgTG9TVCBjbGllbnQgbWF5IG5vdCBi ZSBhIExJUy4gSWYgd2UgbWFrZSBpdCBleHBsaWNpdCB0aGF0IG9ubHkgTElTZXMgYXJlIExvU1Qg Y2xpZW50cyBpbiB0aGUgY29udGV4dCBvZiB0aGlzIGRyYWZ0LCBJIG1heSBub3QgaGF2ZSBhcyBz dHJvbmcgb2JqZWN0aW9ucy4NCg0KDQoNCkd1eQ0KDQoNCg0KRGUgOiBCcmlhbiBSb3NlbiA8YnJA YnJpYW5yb3Nlbi5uZXQ8bWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0Pj4NCkVudm95w6kgOiAyMyBh b8O7dCAyMDIxIDE4OjA2DQrDgCA6IENhcm9uLCBHdXkgPGcuY2Fyb25AYmVsbC5jYTxtYWlsdG86 Zy5jYXJvbkBiZWxsLmNhPj4NCkNjIDogZWNyaXRAaWV0Zi5vcmc8bWFpbHRvOmVjcml0QGlldGYu b3JnPg0KT2JqZXQgOiBbRVhUXVJlOiBsb3N0LXBsYW5uZWQtY2hhbmdlcy0wNDogcGxhbm5lZENo YW5nZSBib3VuZCB0byB2YWxpZGF0ZUxvY2F0aW9uPw0KDQoNCg0KT25seSBpZiBpdCBhc2tlZCBm b3IgaXQsIHBlciBsb2NhdGlvbi4gIEl0IGFza2VkIGZvciBpdCwgaXQgZ290IGl0Lg0KDQoNCg0K SXQgaGFzIE5PVEhJTkcgdG8gZG8gd2l0aCBhY3R1YWwgY2FsbHMuICBJdOKAmXMganVzdCBhbiBh bHRlcm5hdGl2ZSB0byBwZXJpb2RpYyByZXZhbGlkYXRpb24gZm9yIHJlY29yZHMgaW4gdGhlIExJ Uy4NCg0KDQoNCkEgbW9yZSBpbnRlcmVzdGluZyBpc3N1ZSBpcyB3aGF0IGRvZXMgYSBMSVMgZG8g d2hlbiBpdCBkZWxldGVzIGEgcmVjb3JkIGZvciB3aGljaCBhIFVSSSBpcyBzdG9yZWQgaW4gdGhl IHNlcnZlci4gIFByb2JhYmx5IGl0IG1hcmtzIHRoYXQgVVJJIGlzIE9CRS4gQW5vdGhlciBwb3Nz aWJpbGl0eSBpcyB0aGF0IGl0IHN0b3JlcyBhIG5ldyBVUkkgdGhhdCBpcyBhIGNhdGNoLWFsbCDi gJxpZ25vcmUgbWXigJ0NCg0KDQoNCkhtbW0uICBJIHdvbmRlciBpZiB3ZSBzaG91bGQgaGF2ZSBh biBleHBsaWNpdCBkZWxldGUuICBOdWxsIFVSSSA9IGRlbGV0ZS4NCg0KDQoNCkJyaWFuDQoNCg0K DQoNCg0KT24gQXVnIDIzLCAyMDIxLCBhdCA2OjAxIFBNLCBDYXJvbiwgR3V5IDxnLmNhcm9uQGJl bGwuY2E8bWFpbHRvOmcuY2Fyb25AYmVsbC5jYT4+IHdyb3RlOg0KDQoNCg0KQSBMb1NUIGNsaWVu dCB0aGF0IHNlbmRzIHJvdXRpbmcgcmVxdWVzdHMgdG8gdGhlIHNlcnZlciB3b3VsZCByZWNlaXZl LCB3YXkgYWZ0ZXIgY2FsbHMgaGF2ZSBiZWVuIGRlbGl2ZXJlZCwgYSBub3RpZmljYXRpb24gd2l0 aCBhIDxsb2NhdGlvbkludmFsaWQ+IGJvZHkuIFdoYXQgd291bGQgaXQgZG8gd2l0aCB0aGlzPw0K DQoNCg0KTWFrZXMgbm8gc2Vuc2UgdG8gbWUuDQoNCg0KDQpHdXkNCg0KDQoNCkRlIDogQnJpYW4g Um9zZW4gPGJyQGJyaWFucm9zZW4ubmV0PG1haWx0bzpickBicmlhbnJvc2VuLm5ldD4+DQpFbnZv ecOpIDogMjMgYW/Du3QgMjAyMSAxNzo1NQ0Kw4AgOiBDYXJvbiwgR3V5IDxnLmNhcm9uQGJlbGwu Y2E8bWFpbHRvOmcuY2Fyb25AYmVsbC5jYT4+DQpDYyA6IGVjcml0QGlldGYub3JnPG1haWx0bzpl Y3JpdEBpZXRmLm9yZz4NCk9iamV0IDogW0VYVF1SZTogbG9zdC1wbGFubmVkLWNoYW5nZXMtMDQ6 IHBsYW5uZWRDaGFuZ2UgYm91bmQgdG8gdmFsaWRhdGVMb2NhdGlvbj8NCg0KDQoNCkkgZG9u4oCZ dCB1bmRlcnN0YW5kIHRoZSByZWFzb25pbmcgb24g4oCcY3JlYXRpbmcgaGF2b2PigJ0uICBJIGRv buKAmXQga25vdyB3aHkgYSBjbGllbnQgd291bGQgZXZlciBkbyBpdCwgYnV0IGl0IOKAnHdvcmtz 4oCdIGluIHRoYXQgdGhlIHNlcnZlciBkb2VzbuKAmXQgaGF2ZSB0byB2YWxpZGF0ZSB0byBzYXZl IHRoZSBVUkkuICBJZiBJIGNsaWVudCBzZW5kcyB0aGUgVVJJIGFuZCBkb2VzbuKAmXQgdmFsaWRh dGUsIGl04oCZcyB3ZWlyZCwgYnV0IG5vdCB3cm9uZy4NCg0KDQoNCldlIGNhbiBkZWNpZGUgdG8g cHJvaGliaXQgaXQuICBCdXQgd2UgZG9u4oCZdCByZWFsbHkgaGF2ZSBhIGp1c3RpZmljYXRpb24u DQoNCg0KDQpCcmlhbg0KDQoNCg0KT24gQXVnIDIzLCAyMDIxLCBhdCA1OjQ0IFBNLCBDYXJvbiwg R3V5IDxnLmNhcm9uQGJlbGwuY2E8bWFpbHRvOmcuY2Fyb25AYmVsbC5jYT4+IHdyb3RlOg0KDQoN Cg0KSSBhZ3JlZSB0aGF0IGFjY29tbW9kYXRpbmcgdGhpcyBjb21tZW50IHdvdWxkIHJlcXVpcmUg ZGVlcGVyIFhNTCBjaGFuZ2VzLg0KDQoNCg0KSWYgd2UgZG8gbm90IHdhbnQgdG8gZ28gdGhlcmUs IEkgdGhpbmsgdGhlIGRyYWZ0IHNob3VsZCBiZSBjbGVhciB0aGF0IHRoZXJlIGlzIG5vIHVzZWNh c2UgZm9yIHNlbmRpbmcgPHBsYW5uZWRDaGFuZ2U+IG91dHNpZGUgb2YgYSBsb2NhdGlvbiB2YWxp ZGF0aW9uIHJlcXVlc3QgYW5kIGFzIHN1Y2gsIHNob3VsZCBub3JtYXRpdmVseSByZWNvbW1lbmQg bm90IGRvaW5nIHNvLg0KDQoNCg0KSSBkbyBub3QgYWdyZWUgdGhhdCBhIExvU1Qgc2VydmVyIHJl Y2VpdmluZyA8cGxhbm5lZENoYW5nZT4gb3V0c2lkZSBvZiBhIGxvY2F0aW9uIHZhbGlkYXRpb24g cmVxdWVzdCB3b3VsZCByZXRhaW4gdGhlIFVSSSBhbmQgc2VuZCBub3RpZmljYXRpb24gaWYgdGhl IHJlY29yZCBjaGFuZ2VkIGFmdGVyd2FyZC4gSSB0aGluayB0aGlzIHdvdWxkIGNyZWF0ZSBoYXZv YyBvbiB0aGUgY2xpZW504oCZIHNpZGUuDQoNCg0KDQpUaGFua3MsDQoNCg0KDQpHdXkNCg0KDQoN CkRlIDogQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0PG1haWx0bzpickBicmlhbnJvc2Vu Lm5ldD4+DQpFbnZvecOpIDogMjMgYW/Du3QgMjAyMSAxNzoyMg0Kw4AgOiBDYXJvbiwgR3V5IDxn LmNhcm9uQGJlbGwuY2E8bWFpbHRvOmcuY2Fyb25AYmVsbC5jYT4+DQpDYyA6IGVjcml0QGlldGYu b3JnPG1haWx0bzplY3JpdEBpZXRmLm9yZz4NCk9iamV0IDogW0VYVF1SZTogbG9zdC1wbGFubmVk LWNoYW5nZXMtMDQ6IHBsYW5uZWRDaGFuZ2UgYm91bmQgdG8gdmFsaWRhdGVMb2NhdGlvbj8NCg0K DQoNCnZhbGlkYXRlTG9jYXRpb24gaXMgYW4gYXR0cmlidXRlLCBub3QgYW4gZWxlbWVudCwgc28g SSBjYW7igJl0IGV4dGVuZCBpdC4NCg0KDQoNClRoZXJlIGlzbuKAmXQgYW4gYWN0dWFsIHJlcXVp cmVtZW50IHRvIHRpZSBwbGFubmVkQ2hhbmdlIHRvIHZhbGlkYXRlTG9jYXRpb24uICBJdCBtYXkg bm90IG1ha2UgYSBsb3Qgb2Ygc2Vuc2UsIGJ1dCBpZiB5b3UgZGlkIGl0LCB0aGUgTG9TVCBzZXJ2 ZXIgd291bGQgbm90IHJldHVybiB2YWxpZGF0aW9uIGRhdGEsIHdvdWxkIHJldGFpbiB0aGUgVVJJ IGFuZCB3b3VsZCBzZW5kIHRoZSBub3RpZmljYXRpb24gaWYgdGhlIHJlY29yZCBjaGFuZ2VkLiAg Tm90ZSBteSB0ZXh0IHRoYXQgdGhlIExvU1Qgc2VydmVyIGRvZXNu4oCZdCBzdG9yZSB0aGUgTEkg LSB0aGUgbm90aWZpY2F0aW9uIGlzIOKAnHNvbWV0aGluZyBjaGFuZ2Vk4oCdIG5vdCDigJx3aGF0 IHlvdSBzZW50IGlzIGd1YXJhbnRlZWQgdG8gYmUgaW52YWxpZOKAnSBvciBldmVuIOKAnG9uZSBv ciBtb3JlIG9mIHRoZSBlbGVtZW50cyB5b3Ugc2VudCBjaGFuZ2VkIi4gIEkgdGhvdWdodCBhYm91 dCBjaGFuZ2luZyB0aGUgbmFtZSBvZiB0aGUgbm90aWZpY2F0aW9uLCBidXQgSSBkaWRu4oCZdCBk byB0aGF0LiAgVGhlIHByYWN0aWNhbCB1c2UgY2FzZSByZW1haW5zIHRoZSBzYW1lLg0KDQoNCg0K QnJpYW4NCg0KDQoNCg0KT24gQXVnIDIzLCAyMDIxLCBhdCA1OjA3IFBNLCBDYXJvbiwgR3V5IDxn LmNhcm9uQGJlbGwuY2E8bWFpbHRvOmcuY2Fyb25AYmVsbC5jYT4+IHdyb3RlOg0KDQoNCg0KTm90 IGFsbCBMb1NUIHNlcnZlciBpbXBsZW1lbnRhdGlvbnMgcGVyZm9ybSBsb2NhdGlvbiB2YWxpZGF0 aW9ucy4gV2hlbiBsb2NhdGlvbiB2YWxpZGF0aW9uIGlzIHJlcXVlc3RlZCBieSB0aGUgY2xpZW50 LCBpdCBhZGRzIHRoZSDigJx2YWxpZGF0ZUxvY2F0aW9u4oCdIGF0dHJpYnV0ZSB0byB0aGUgPGZp bmRTZXJ2aWNlPiBlbGVtZW50Lg0KDQoNCg0KU28gdGhlIHF1ZXN0aW9uIGlzOiBTaG91bGQg4oCc cGxhbm5lZENoYW5nZeKAnSBiZSBib3VuZCB0byDigJx2YWxpZGF0ZUxvY2F0aW9u4oCdPw0KDQoN Cg0KSWYgeW91IGJlbGlldmUgbm90LCB3aGF0IHdvdWxkIGJlIHRoZSBleHBlY3RlZCBiZWhhdmlv dXIgb2YgYSBMb1NUIHNlcnZlciByZWNlaXZpbmcgYSA8cGxhbm5lZENoYW5nZT4gZWxlbWVudCBv dXRzaWRlIG9mIGEgdmFsaWRhdGlvbiByZXF1ZXN0Pw0KDQoNCg0KVGhhbmtzLA0KDQoNCg0KR3V5 DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpFeHRlcm5hbCBFbWFp bDogUGxlYXNlIHVzZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQgYXR0YWNobWVudHMg LyBDb3VycmllbCBleHRlcm5lOiBTb3lleiBwcnVkZW50IGF2ZWMgbGVzIGxpZW5zIGV0IGRvY3Vt ZW50cyBqb2ludHMNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkV4 dGVybmFsIEVtYWlsOiBQbGVhc2UgdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxpbmtzIGFuZCBh dHRhY2htZW50cyAvIENvdXJyaWVsIGV4dGVybmU6IFNveWV6IHBydWRlbnQgYXZlYyBsZXMgbGll bnMgZXQgZG9jdW1lbnRzIGpvaW50cw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCg0KRXh0ZXJuYWwgRW1haWw6IFBsZWFzZSB1c2UgY2F1dGlvbiB3aGVuIG9wZW5pbmcg bGlua3MgYW5kIGF0dGFjaG1lbnRzIC8gQ291cnJpZWwgZXh0ZXJuZTogU295ZXogcHJ1ZGVudCBh dmVjIGxlcyBsaWVucyBldCBkb2N1bWVudHMgam9pbnRzDQoNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQpFeHRlcm5hbCBFbWFpbDogUGxlYXNlIHVzZSBjYXV0aW9uIHdo ZW4gb3BlbmluZyBsaW5rcyBhbmQgYXR0YWNobWVudHMgLyBDb3VycmllbCBleHRlcm5lOiBTb3ll eiBwcnVkZW50IGF2ZWMgbGVzIGxpZW5zIGV0IGRvY3VtZW50cyBqb2ludHMNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkVjcml0IG1haWxpbmcgbGlz dA0KRWNyaXRAaWV0Zi5vcmc8bWFpbHRvOkVjcml0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQpFeHRlcm5hbCBFbWFpbDogUGxlYXNlIHVzZSBjYXV0aW9uIHdoZW4gb3Blbmlu ZyBsaW5rcyBhbmQgYXR0YWNobWVudHMgLyBDb3VycmllbCBleHRlcm5lOiBTb3lleiBwcnVkZW50 IGF2ZWMgbGVzIGxpZW5zIGV0IGRvY3VtZW50cyBqb2ludHMNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkV4dGVybmFsIEVtYWlsOiBQbGVhc2UgdXNlIGNhdXRpb24gd2hlbiBv cGVuaW5nIGxpbmtzIGFuZCBhdHRhY2htZW50cyAvIENvdXJyaWVsIGV4dGVybmU6IFNveWV6IHBy dWRlbnQgYXZlYyBsZXMgbGllbnMgZXQgZG9jdW1lbnRzIGpvaW50cw0K --_000_bae4a816c98f4df4b672b265a988df99bellca_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJ e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSLUNB IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkJ1dCB5b3UgYXJlIGFkdm9jYXRp bmcgZm9yIGEgbW9kZWwgdGhhdCBpcyB1c2VsZXNzLiBXaHkgbm90IGJlIGNsZWFyIG9uIHdoYXQg dGhpcyBpcyBkb2luZyBhbmQgd2hhdCBpdCBpcyBub3Q/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkd1eTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBSYW5kYWxsIEdlbGxlbnMgJmx0O3JnJiM0MztpZXRmQHJh bmR5LnBlbnNpdmUub3JnJmd0Ow0KPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IDIzIGFvw7t0 IDIwMjEgMTg6NDA8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IENhcm9uLCBHdXkgJmx0O2cuY2Fyb25A YmVsbC5jYSZndDs8YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IEJyaWFuIFJvc2VuICZsdDtickBicmlh bnJvc2VuLm5ldCZndDs7IGVjcml0QGlldGYub3JnPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBb RVhUXVJlOiBbRWNyaXRdIGxvc3QtcGxhbm5lZC1jaGFuZ2VzLTA0OiBwbGFubmVkQ2hhbmdlIGJv dW5kIHRvIHZhbGlkYXRlTG9jYXRpb24/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZiI+SSdtIHRyeWluZyB0byB1bmRlcnN0YW5kIHRoZSBoYXJtIG9mIGFsbG93aW5nIGEg Y2xpZW50IHRvIHJlcXVlc3Qgbm90aWZpY2F0aW9uIHdoZXRoZXIgaXQgaXMgYXNraW5nIGZvciB2 YWxpZGF0aW9uIG9yIG5vdC4gV2UgYWxyZWFkeSBzYXkgdGhhdCBzZXJ2ZXIgcG9saWN5IGNhbiBy ZWZ1c2UgdG8gc3RvcmUgYSBVUkkgZm9yIGFueSByZWFzb24sIHNvIGEgc2VydmVyDQogY291bGQg cHJvaGliaXQgdGhpcyBpZiBpdCB3YW50cyB0byAoZS5nLiwgdG8gc2F2ZSByZXNvdXJjZXMpLiBJ ZiBhIHNlcnZlciBpcyBPSyBwcm92aWRpbmcgdGhpcyBzZXJ2ZXIsIHdoYXQgZG8gd2UgY2FyZT8g SXQgZG9lc24ndCBoYXJtIGludGVyb3BlcmFiaWxpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi Pi0tUmFuZGFsbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5PbiAyMyBBdWcgMjAyMSwgYXQgMTU6 MzQsIENhcm9uLCBHdXkgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgIzc3Nzc3NyAxLjVw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0O21hcmdpbi1sZWZ0OjBjbTttYXJnaW4tcmlnaHQ6 MGNtO21hcmdpbi1ib3R0b206My43NXB0Ij4NCjxkaXYgaWQ9IjcyMjJERjNFLTVFM0QtNDI1My04 OUQxLUYxMDI2NDlEQjdBRSI+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5J4oCZbSBub3QgY29u Y2VybmVkIGFib3V0IGEgY2xpZW50IHRoYXQgd2lsbGZ1bGx5IGFuZCBrbm93aW5nbHkgYXNrcyBm b3IgaXQuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGlzIHdo b2xlIGRyYWZ0IHJldm9sdmVzIGFyb3VuZCBsb2NhdGlvbiB2YWxpZGF0aW9uLiBJ4oCZbSBub3Qg dW5kZXJzdGFuZGluZyB0aGUgcHVzaGJhY2sgaGVyZS48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkd1eTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xv cjojNzc3Nzc3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cD48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiM3Nzc3NzciPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojNzc3Nzc3Ij4gUmFuZGFsbCBHZWxsZW5zICZsdDs8YSBocmVmPSJtYWlsdG86cmcm IzQzO2lldGZAcmFuZHkucGVuc2l2ZS5vcmciPnJnJiM0MztpZXRmQHJhbmR5LnBlbnNpdmUub3Jn PC9hPiZndDsNCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiAyMyBhb8O7dCAyMDIxIDE4OjMx PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBDYXJvbiwgR3V5ICZsdDs8YSBocmVmPSJtYWlsdG86Zy5j YXJvbkBiZWxsLmNhIj5nLmNhcm9uQGJlbGwuY2E8L2E+Jmd0Ozxicj4NCjxiPkNjJm5ic3A7Ojwv Yj4gQnJpYW4gUm9zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpickBicmlhbnJvc2VuLm5ldCI+YnJA YnJpYW5yb3Nlbi5uZXQ8L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzplY3JpdEBpZXRmLm9yZyI+ ZWNyaXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBbRVhUXVJlOiBbRWNy aXRdIGxvc3QtcGxhbm5lZC1jaGFuZ2VzLTA0OiBwbGFubmVkQ2hhbmdlIGJvdW5kIHRvIHZhbGlk YXRlTG9jYXRpb24/PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3 NzciPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3 Nzc3NyI+SWYgYSBjbGllbnQgd2FudHMgdG8gZ2V0IG5vdGlmaWVkIHRoYXQgYSBsb2NhdGlvbiBt YXkgaGF2ZSBiZWNvbWUgaW52YWxpZGF0ZWQsIHdoeSBkbyB3ZSBjYXJlIHdoeSBvciB3aGF0IHR5 cGUgb2YgY2xpZW50IGl0IGlzPzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+LS1SYW5kYWxsPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3 Nzc3Ij5PbiAyMyBBdWcgMjAyMSwgYXQgMTU6MjYsIENhcm9uLCBHdXkgd3JvdGU6PC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjNzc3Nzc3 IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQ7bWFyZ2luLWxlZnQ6MGNtO21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjMuNzVwdCI+DQo8ZGl2IGlk PSJEOTlFRDRDOS1DMDQ2LTQ1QjEtQUIzQy0yMUQxN0RDREMxNUQiPg0KPGRpdj4NCjxwPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+SSB1bmRlcnN0YW5kIGFuZCB3aGF0IEnigJltIHN1Z2dlc3RpbmcgaXMgdG8gYmUg Y2xlYXIgYWJvdXQgd2hhdCBMb1NUIGNsaWVudHMgYXJlIGV4cGVjdGVkIHRvIGRvLiBXZSBkbyBu b3Qgd2FudCBhIGxlYXN5IGltcGxlbWVudGF0aW9uIHNlbmRpbmcNCiAmbHQ7cGxhbm5lZENoYW5n ZSZndDsgYWNyb3NzIHRoZSBib2FyZCwgZG9u4oCZdCB3ZT8gSSB0aGluayBpdCBpcyBlYXN5IGFu ZCBjaGVlcCB0byBmaXggaW4gdGhlIGRyYWZ0IHJhdGhlciB0byB0cnkgdG8gZml4IGltcGxlbWVu dGF0aW9ucyBsYXRlci48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi Pkd1eTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjojNzc3Nzc3O21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3 NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cD48Yj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPkRl Jm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3 Nzc3Ij4gQnJpYW4gUm9zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpickBicmlhbnJvc2VuLm5ldCI+ YnJAYnJpYW5yb3Nlbi5uZXQ8L2E+Jmd0Ow0KPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IDIz IGFvw7t0IDIwMjEgMTg6MTQ8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IENhcm9uLCBHdXkgJmx0Ozxh IGhyZWY9Im1haWx0bzpnLmNhcm9uQGJlbGwuY2EiPmcuY2Fyb25AYmVsbC5jYTwvYT4mZ3Q7PGJy Pg0KPGI+Q2MmbmJzcDs6PC9iPiA8YSBocmVmPSJtYWlsdG86ZWNyaXRAaWV0Zi5vcmciPmVjcml0 QGlldGYub3JnPC9hPjxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gW0VYVF1SZTogbG9zdC1wbGFu bmVkLWNoYW5nZXMtMDQ6IHBsYW5uZWRDaGFuZ2UgYm91bmQgdG8gdmFsaWRhdGVMb2NhdGlvbj88 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cD48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOiM3Nzc3 NzciPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij5T dXJlLCBQU0FQcyBjb3VsZCBiZSBhIExvU1QgY2xpZW50IGZvciBleGFtcGxlLiAmbmJzcDtBIHJv dXRpbmcgcHJveHkgY2FuIGJlIGEgTG9TVCBjbGllbnQuICZuYnNwO0J1dCB0aGV5IHdvdWxkbuKA mXQgYXNrIHRvIHN0b3JlIHRoZSBVUkkuICZuYnNwO1lvdSBoYXZlIHRvIGFzayBmb3IgaXQgdG8g Z2V0IHRoZSBub3RpZmljYXRpb24uJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3 Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3 Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+QnJpYW48L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBzdHlsZT0i bWFyZ2luLXRvcDowY20iPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cD48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNv bG9yOiM3Nzc3NzciPk9uIEF1ZyAyMywgMjAyMSwgYXQgNjoxMCBQTSwgQ2Fyb24sIEd1eSAmbHQ7 PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48YSBocmVmPSJtYWlsdG86Zy5jYXJv bkBiZWxsLmNhIj48c3BhbiBsYW5nPSJFTi1DQSI+Zy5jYXJvbkBiZWxsLmNhPC9zcGFuPjwvYT48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij4mZ3Q7IHdyb3Rl Ojwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cD48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOiM3Nzc3NzciPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cD48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPllvdSBtaXNzIG15IHBvaW50LiBUaGUgTG9TVCBjbGllbnQgbWF5IG5vdCBiZSBh IExJUy4gSWYgd2UgbWFrZSBpdCBleHBsaWNpdCB0aGF0IG9ubHkgTElTZXMgYXJlIExvU1QgY2xp ZW50cyBpbiB0aGUgY29udGV4dCBvZiB0aGlzIGRyYWZ0LCBJIG1heSBub3QgaGF2ZSBhcyBzdHJv bmcNCiBvYmplY3Rpb25zLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3 Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+R3V5PC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cD48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOiM3Nzc3NzciPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdj4NCjxwPjxiPjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPiZuYnNwO0JyaWFuIFJv c2VuICZsdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxhIGhyZWY9Im1haWx0 bzpickBicmlhbnJvc2VuLm5ldCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+YnJAYnJp YW5yb3Nlbi5uZXQ8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM3Nzc3NzciPiZndDsmbmJzcDs8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4mbmJz cDsyMyBhb8O7dCAyMDIxIDE4OjA2PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiZuYnNwO0Nhcm9uLCBH dXkgJmx0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PGEgaHJlZj0ibWFpbHRv OmcuY2Fyb25AYmVsbC5jYSI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Zy5jYXJvbkBi ZWxsLmNhPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNzc3Nzc3Ij4mZ3Q7PGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6Izc3Nzc3NyI+PGEgaHJlZj0ibWFpbHRvOmVjcml0QGlldGYub3JnIj48c3Bh biBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5lY3JpdEBpZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFu PjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+PGJyPg0KPGI+T2Jq ZXQmbmJzcDs6PC9iPiZuYnNwO1tFWFRdUmU6IGxvc3QtcGxhbm5lZC1jaGFuZ2VzLTA0OiBwbGFu bmVkQ2hhbmdlIGJvdW5kIHRvIHZhbGlkYXRlTG9jYXRpb24/PC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij4m bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6 Izc3Nzc3NyI+T25seSBpZiBpdCBhc2tlZCBmb3IgaXQsIHBlciBsb2NhdGlvbi4gJm5ic3A7SXQg YXNrZWQgZm9yIGl0LCBpdCBnb3QgaXQuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4g bGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6Izc3Nzc3 NyI+SXQgaGFzIE5PVEhJTkcgdG8gZG8gd2l0aCBhY3R1YWwgY2FsbHMuICZuYnNwO0l04oCZcyBq dXN0IGFuIGFsdGVybmF0aXZlIHRvIHBlcmlvZGljIHJldmFsaWRhdGlvbiBmb3IgcmVjb3JkcyBp biB0aGUgTElTLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+QSBt b3JlIGludGVyZXN0aW5nIGlzc3VlIGlzIHdoYXQgZG9lcyBhIExJUyBkbyB3aGVuIGl0IGRlbGV0 ZXMgYSByZWNvcmQgZm9yIHdoaWNoIGEgVVJJIGlzIHN0b3JlZCBpbiB0aGUgc2VydmVyLiAmbmJz cDtQcm9iYWJseSBpdCBtYXJrcyB0aGF0IFVSSSBpcyBPQkUuIEFub3RoZXIgcG9zc2liaWxpdHkg aXMgdGhhdCBpdCBzdG9yZXMgYSBuZXcgVVJJIHRoYXQgaXMgYSBjYXRjaC1hbGwNCiDigJxpZ25v cmUgbWXigJ08L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cD48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOiM3Nzc3NzciPkhtbW0u ICZuYnNwO0kgd29uZGVyIGlmIHdlIHNob3VsZCBoYXZlIGFuIGV4cGxpY2l0IGRlbGV0ZS4gJm5i c3A7TnVsbCBVUkkgPSBkZWxldGUuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cD48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOiM3Nzc3NzciPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjoj Nzc3Nzc3Ij5Ccmlhbjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21h cmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjBjbSI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 Izc3Nzc3NyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij5PbiBBdWcg MjMsIDIwMjEsIGF0IDY6MDEgUE0sIENhcm9uLCBHdXkgJmx0Ozwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6Izc3Nzc3NyI+PGEgaHJlZj0ibWFpbHRvOmcuY2Fyb25AYmVsbC5jYSI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmcuY2Fyb25AYmVsbC5jYTwvc3Bhbj48L2E+ PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+Jmd0Ow0KIHdy b3RlOjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cD48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImNvbG9yOiM3Nzc3NzciPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cD48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkEgTG9TVCBjbGllbnQg dGhhdCBzZW5kcyByb3V0aW5nIHJlcXVlc3RzIHRvIHRoZSBzZXJ2ZXIgd291bGQgcmVjZWl2ZSwg d2F5IGFmdGVyIGNhbGxzIGhhdmUgYmVlbiBkZWxpdmVyZWQsIGEgbm90aWZpY2F0aW9uIHdpdGgg YSAmbHQ7bG9jYXRpb25JbnZhbGlkJmd0OyBib2R5LiBXaGF0IHdvdWxkDQogaXQgZG8gd2l0aCB0 aGlzPzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TWFr ZXMgbm8gc2Vuc2UgdG8gbWUuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cD48c3Bh biBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5HdXk8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PGI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij5EZSZuYnNwOzo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+Jm5ic3A7QnJp YW4gUm9zZW4gJmx0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PGEgaHJlZj0i bWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOnB1cnBsZSI+YnJAYnJpYW5yb3Nlbi5uZXQ8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPiZndDsmbmJzcDs8YnI+DQo8Yj5FbnZv ecOpJm5ic3A7OjwvYj4mbmJzcDsyMyBhb8O7dCAyMDIxIDE3OjU1PGJyPg0KPGI+w4AmbmJzcDs6 PC9iPiZuYnNwO0Nhcm9uLCBHdXkgJmx0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3 NyI+PGEgaHJlZj0ibWFpbHRvOmcuY2Fyb25AYmVsbC5jYSI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpwdXJwbGUiPmcuY2Fyb25AYmVsbC5jYTwvc3Bhbj48L2E+PC9zcGFuPjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+Jmd0Ozxicj4NCjxiPkNj Jm5ic3A7OjwvYj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxhIGhy ZWY9Im1haWx0bzplY3JpdEBpZXRmLm9yZyI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpwdXJwbGUiPmVjcml0QGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij48YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+ Jm5ic3A7W0VYVF1SZTogbG9zdC1wbGFubmVkLWNoYW5nZXMtMDQ6IHBsYW5uZWRDaGFuZ2UgYm91 bmQgdG8gdmFsaWRhdGVMb2NhdGlvbj88L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3Nzci PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cD48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOiM3Nzc3Nzci PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij5JIGRvbuKAmXQgdW5kZXJzdGFuZCB0aGUgcmVhc29u aW5nIG9uIOKAnGNyZWF0aW5nIGhhdm9j4oCdLiAmbmJzcDtJIGRvbuKAmXQga25vdyB3aHkgYSBj bGllbnQgd291bGQgZXZlciBkbyBpdCwgYnV0IGl0IOKAnHdvcmtz4oCdIGluIHRoYXQgdGhlIHNl cnZlciBkb2VzbuKAmXQgaGF2ZSB0byB2YWxpZGF0ZSB0byBzYXZlIHRoZSBVUkkuICZuYnNwO0lm IEkgY2xpZW50IHNlbmRzIHRoZSBVUkkgYW5kIGRvZXNu4oCZdA0KIHZhbGlkYXRlLCBpdOKAmXMg d2VpcmQsIGJ1dCBub3Qgd3JvbmcuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHA+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+V2UgY2FuIGRlY2lkZSB0byBwcm9oaWJpdCBp dC4gJm5ic3A7QnV0IHdlIGRvbuKAmXQgcmVhbGx5IGhhdmUgYSBqdXN0aWZpY2F0aW9uLjwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29s b3I6Izc3Nzc3NyI+QnJpYW48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdo dDowY207bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MGNtIj4NCjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cD48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNv bG9yOiM3Nzc3NzciPk9uIEF1ZyAyMywgMjAyMSwgYXQgNTo0NCBQTSwgQ2Fyb24sIEd1eSAmbHQ7 PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48YSBocmVmPSJtYWlsdG86Zy5jYXJv bkBiZWxsLmNhIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOnB1cnBsZSI+Zy5jYXJv bkBiZWxsLmNhPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xv cjojNzc3Nzc3Ij4mZ3Q7DQogd3JvdGU6PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB0aGF0IGFjY29tbW9k YXRpbmcgdGhpcyBjb21tZW50IHdvdWxkIHJlcXVpcmUgZGVlcGVyIFhNTCBjaGFuZ2VzLjwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+SWYgd2UgZG8gbm90IHdhbnQgdG8gZ28gdGhlcmUsIEkgdGhpbmsg dGhlIGRyYWZ0IHNob3VsZCBiZSBjbGVhciB0aGF0IHRoZXJlIGlzIG5vIHVzZWNhc2UgZm9yIHNl bmRpbmcgJmx0O3BsYW5uZWRDaGFuZ2UmZ3Q7IG91dHNpZGUgb2YgYSBsb2NhdGlvbiB2YWxpZGF0 aW9uIHJlcXVlc3QgYW5kDQogYXMgc3VjaCwgc2hvdWxkIG5vcm1hdGl2ZWx5IHJlY29tbWVuZCBu b3QgZG9pbmcgc28uPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cD48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGRvIG5vdCBhZ3JlZSB0aGF0IGEg TG9TVCBzZXJ2ZXIgcmVjZWl2aW5nICZsdDtwbGFubmVkQ2hhbmdlJmd0OyBvdXRzaWRlIG9mIGEg bG9jYXRpb24gdmFsaWRhdGlvbiByZXF1ZXN0IHdvdWxkIHJldGFpbiB0aGUgVVJJIGFuZCBzZW5k IG5vdGlmaWNhdGlvbiBpZiB0aGUgcmVjb3JkIGNoYW5nZWQNCiBhZnRlcndhcmQuIEkgdGhpbmsg dGhpcyB3b3VsZCBjcmVhdGUgaGF2b2Mgb24gdGhlIGNsaWVudOKAmSBzaWRlLjwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+VGhhbmtzLDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+R3V5PC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cD48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImNvbG9yOiM3Nzc3NzciPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3 Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxi PjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+RGUmbmJzcDs6PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPiZuYnNw O0JyaWFuIFJvc2VuICZsdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxhIGhy ZWY9Im1haWx0bzpickBicmlhbnJvc2VuLm5ldCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpwdXJwbGUiPmJyQGJyaWFucm9zZW4ubmV0PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4g bGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij4mZ3Q7Jm5ic3A7PGJyPg0KPGI+ RW52b3nDqSZuYnNwOzo8L2I+Jm5ic3A7MjMgYW/Du3QgMjAyMSAxNzoyMjxicj4NCjxiPsOAJm5i c3A7OjwvYj4mbmJzcDtDYXJvbiwgR3V5ICZsdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3 Nzc3NzciPjxhIGhyZWY9Im1haWx0bzpnLmNhcm9uQGJlbGwuY2EiPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj5nLmNhcm9uQGJlbGwuY2E8L3NwYW4+PC9hPjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPiZndDs8YnI+DQo8 Yj5DYyZuYnNwOzo8L2I+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48 YSBocmVmPSJtYWlsdG86ZWNyaXRAaWV0Zi5vcmciPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6cHVycGxlIj5lY3JpdEBpZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+PGJyPg0KPGI+T2JqZXQmbmJzcDs6 PC9iPiZuYnNwO1tFWFRdUmU6IGxvc3QtcGxhbm5lZC1jaGFuZ2VzLTA0OiBwbGFubmVkQ2hhbmdl IGJvdW5kIHRvIHZhbGlkYXRlTG9jYXRpb24/PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3 Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3 NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6Izc3Nzc3 NyI+dmFsaWRhdGVMb2NhdGlvbiBpcyBhbiBhdHRyaWJ1dGUsIG5vdCBhbiBlbGVtZW50LCBzbyBJ IGNhbuKAmXQgZXh0ZW5kIGl0LiAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3 NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cD48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9y OiM3Nzc3NzciPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjoj Nzc3Nzc3Ij5UaGVyZSBpc27igJl0IGFuIGFjdHVhbCByZXF1aXJlbWVudCB0byB0aWUgcGxhbm5l ZENoYW5nZSB0byB2YWxpZGF0ZUxvY2F0aW9uLiAmbmJzcDtJdCBtYXkgbm90IG1ha2UgYSBsb3Qg b2Ygc2Vuc2UsIGJ1dCBpZiB5b3UgZGlkIGl0LCB0aGUgTG9TVCBzZXJ2ZXIgd291bGQgbm90IHJl dHVybiB2YWxpZGF0aW9uIGRhdGEsIHdvdWxkIHJldGFpbiB0aGUgVVJJIGFuZCB3b3VsZCBzZW5k DQogdGhlIG5vdGlmaWNhdGlvbiBpZiB0aGUgcmVjb3JkIGNoYW5nZWQuICZuYnNwO05vdGUgbXkg dGV4dCB0aGF0IHRoZSBMb1NUIHNlcnZlciBkb2VzbuKAmXQgc3RvcmUgdGhlIExJIC0gdGhlIG5v dGlmaWNhdGlvbiBpcyDigJxzb21ldGhpbmcgY2hhbmdlZOKAnSBub3Qg4oCcd2hhdCB5b3Ugc2Vu dCBpcyBndWFyYW50ZWVkIHRvIGJlIGludmFsaWTigJ0gb3IgZXZlbiDigJxvbmUgb3IgbW9yZSBv ZiB0aGUgZWxlbWVudHMgeW91IHNlbnQgY2hhbmdlZCZxdW90Oy4gJm5ic3A7SSB0aG91Z2h0IGFi b3V0DQogY2hhbmdpbmcgdGhlIG5hbWUgb2YgdGhlIG5vdGlmaWNhdGlvbiwgYnV0IEkgZGlkbuKA mXQgZG8gdGhhdC4gJm5ic3A7VGhlIHByYWN0aWNhbCB1c2UgY2FzZSByZW1haW5zIHRoZSBzYW1l Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+QnJpYW48L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNt O21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjBjbSI+DQo8c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxicj4NCjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij5PbiBBdWcgMjMsIDIwMjEsIGF0IDU6MDcgUE0s IENhcm9uLCBHdXkgJmx0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PGEgaHJl Zj0ibWFpbHRvOmcuY2Fyb25AYmVsbC5jYSI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xv cjpwdXJwbGUiPmcuY2Fyb25AYmVsbC5jYTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+Jmd0Ow0KIHdyb3RlOjwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cD48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImNvbG9yOiM3Nzc3NzciPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cD48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk5vdCBhbGwgTG9TVCBzZXJ2ZXIgaW1wbGVtZW50YXRp b25zIHBlcmZvcm0gbG9jYXRpb24gdmFsaWRhdGlvbnMuIFdoZW4gbG9jYXRpb24gdmFsaWRhdGlv biBpcyByZXF1ZXN0ZWQgYnkgdGhlIGNsaWVudCwgaXQgYWRkcyB0aGUg4oCcdmFsaWRhdGVMb2Nh dGlvbuKAnSBhdHRyaWJ1dGUgdG8NCiB0aGUgJmx0O2ZpbmRTZXJ2aWNlJmd0OyBlbGVtZW50Ljwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHA+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U28gdGhl IHF1ZXN0aW9uIGlzOiBTaG91bGQg4oCccGxhbm5lZENoYW5nZeKAnSBiZSBib3VuZCB0byDigJx2 YWxpZGF0ZUxvY2F0aW9u4oCdPzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SWYgeW91IGJlbGlldmUgbm90LCB3aGF0IHdvdWxkIGJlIHRoZSBleHBl Y3RlZCBiZWhhdmlvdXIgb2YgYSBMb1NUIHNlcnZlciByZWNlaXZpbmcgYSAmbHQ7cGxhbm5lZENo YW5nZSZndDsgZWxlbWVudCBvdXRzaWRlIG9mIGEgdmFsaWRhdGlvbiByZXF1ZXN0Pzwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHA+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw PjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHA+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+R3V5PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWdu OmNlbnRlciI+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPg0KPGhyIHNpemU9IjIiIHdpZHRo PSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwPjxzdHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVl Ij5FeHRlcm5hbCBFbWFpbDo8L3NwYW4+PC9pPjwvc3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+Jm5ic3A7PGVtPlBsZWFzZSB1c2UgY2F1dGlvbiB3aGVu IG9wZW5pbmcgbGlua3MgYW5kIGF0dGFjaG1lbnRzIC88L2VtPiZuYnNwOzxzdHJvbmc+Q291cnJp ZWwgZXh0ZXJuZTo8L3N0cm9uZz4mbmJzcDs8ZW0+U295ZXogcHJ1ZGVudCBhdmVjDQogbGVzIGxp ZW5zIGV0IGRvY3VtZW50cyBqb2ludHM8L2VtPjwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImNvbG9y OiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIHN0 eWxlPSJjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJjb2xv cjojNzc3Nzc3Ij4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8 L3NwYW4+PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzdHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj5FeHRlcm5hbCBFbWFpbDo8L3NwYW4+PC9pPjwvc3Ry b25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+Jm5ic3A7PGVt PlBsZWFzZSB1c2UgY2F1dGlvbiB3aGVuIG9wZW5pbmcgbGlua3MgYW5kIGF0dGFjaG1lbnRzIC88 L2VtPiZuYnNwOzxzdHJvbmc+Q291cnJpZWwgZXh0ZXJuZTo8L3N0cm9uZz4mbmJzcDs8ZW0+U295 ZXogcHJ1ZGVudCBhdmVjDQogbGVzIGxpZW5zIGV0IGRvY3VtZW50cyBqb2ludHM8L2VtPjwvc3Bh bj48L2k+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxw PjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBz dHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij4NCjxo ciBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8 ZGl2Pg0KPHA+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJs dWUiPkV4dGVybmFsIEVtYWlsOjwvc3Bhbj48L2k+PC9zdHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj4mbmJzcDs8ZW0+UGxlYXNlIHVzZSBjYXV0aW9uIHdo ZW4gb3BlbmluZyBsaW5rcyBhbmQgYXR0YWNobWVudHMgLzwvZW0+Jm5ic3A7PHN0cm9uZz5Db3Vy cmllbCBleHRlcm5lOjwvc3Ryb25nPiZuYnNwOzxlbT5Tb3lleiBwcnVkZW50IGF2ZWMNCiBsZXMg bGllbnMgZXQgZG9jdW1lbnRzIGpvaW50czwvZW0+PC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iY29s b3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJjb2xvcjoj Nzc3Nzc3Ij4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3Nw YW4+PC9kaXY+DQo8cD48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29s b3I6Ymx1ZSI+RXh0ZXJuYWwgRW1haWw6PC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj4gUGxlYXNlIHVzZSBjYXV0aW9uIHdoZW4g b3BlbmluZyBsaW5rcyBhbmQgYXR0YWNobWVudHMgLw0KPC9zcGFuPjwvZW0+PHN0cm9uZz48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPkNvdXJyaWVsIGV4dGVybmU6 PC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xv cjpibHVlIj4gU295ZXogcHJ1ZGVudCBhdmVjIGxlcyBsaWVucyBldCBkb2N1bWVudHMgam9pbnRz DQo8L3NwYW4+PC9lbT48c3BhbiBzdHlsZT0iY29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgIzc3Nzc3NyAxLjVwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDQuMHB0O21hcmdpbi1sZWZ0OjBjbTttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTozLjc1cHQiPg0KPHA+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpFY3JpdCBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86RWNyaXRAaWV0Zi5vcmciPkVjcml0QGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZWNyaXQiPjxzcGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxl PSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gc3R5bGU9ImNvbG9yOiM3Nzc3NzciPg0KPGhyIHNp emU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxwPjxz dHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj5FeHRlcm5h bCBFbWFpbDo8L3NwYW4+PC9pPjwvc3Ryb25nPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2NvbG9yOmJsdWUiPiBQbGVhc2UgdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxpbmtzIGFu ZCBhdHRhY2htZW50cyAvDQo8L3NwYW4+PC9lbT48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+Q291cnJpZWwgZXh0ZXJuZTo8L3NwYW4+PC9pPjwvc3Ry b25nPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPiBTb3lleiBw cnVkZW50IGF2ZWMgbGVzIGxpZW5zIGV0IGRvY3VtZW50cyBqb2ludHMNCjwvc3Bhbj48L2VtPjxz cGFuIHN0eWxlPSJjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFs aWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lk dGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+RXh0ZXJu YWwgRW1haWw6PC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtjb2xvcjpibHVlIj4gUGxlYXNlIHVzZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBh bmQgYXR0YWNobWVudHMgLw0KPC9zcGFuPjwvZW0+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPkNvdXJyaWVsIGV4dGVybmU6PC9zcGFuPjwvaT48L3N0 cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj4gU295ZXog cHJ1ZGVudCBhdmVjIGxlcyBsaWVucyBldCBkb2N1bWVudHMgam9pbnRzDQo8L3NwYW4+PC9lbT48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_bae4a816c98f4df4b672b265a988df99bellca_-- From nobody Tue Aug 24 11:50:23 2021 Return-Path: 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 D00383A0BF0 for ; Tue, 24 Aug 2021 11:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, 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 WbKLD26B0biQ for ; Tue, 24 Aug 2021 11:50:16 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id CCB893A0BED for ; Tue, 24 Aug 2021 11:50:15 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 24 Aug 2021 11:50:15 -0700 From: "Randall Gellens" To: "Caron, Guy" Cc: "Brian Rosen" , ecrit@ietf.org Date: Tue, 24 Aug 2021 11:50:14 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: References: <8bdda7ea7d004b4591ff715526d93a73@bell.ca> <791ea34f628d48d3addeb04613d5721a@bell.ca> <9158D09E-770E-4E65-BE46-E39060EAC884@brianrosen.net> <0b81d439e4824aec8a3476906ce5cbc1@bell.ca> <7C21F96F-E238-4DA2-82BB-D7C731A84D53@brianrosen.net> <038dcfc4405d4ebe8930d6225f09ea83@bell.ca> <6EC6E0D3-B9E8-476D-A6F7-E1D20817B58E@brianrosen.net> <64E97C26-36C8-4024-89E3-E23379E614B5@randy.pensive.org> <794ed22ebe3e48cdb0e72cf3f0a91429@bell.ca> <2B6FB05F-6A89-4680-893F-06584E7EFAF8@randy.pensive.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_7F8389D4-46D9-4EF4-AB5B-B8382CECB811_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[437, 47783], "plain":[106, 7997], "uuid":"3962422D-961E-4E53-867E-8A72989155A1"}] Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: plannedChange bound to validateLocation? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 18:50:22 -0000 --=_MailMate_7F8389D4-46D9-4EF4-AB5B-B8382CECB811_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit In my suggested wording edits I make it clear. --Randall On 24 Aug 2021, at 11:24, Caron, Guy wrote: > But you are advocating for a model that is useless. Why not be clear > on what this is doing and what it is not? > > Guy > > De : Randall Gellens > Envoyé : 23 août 2021 18:40 > À : Caron, Guy > Cc : Brian Rosen ; ecrit@ietf.org > Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: plannedChange bound > to validateLocation? > > > I'm trying to understand the harm of allowing a client to request > notification whether it is asking for validation or not. We already > say that server policy can refuse to store a URI for any reason, so a > server could prohibit this if it wants to (e.g., to save resources). > If a server is OK providing this server, what do we care? It doesn't > harm interoperability. > > --Randall > > On 23 Aug 2021, at 15:34, Caron, Guy wrote: > > I’m not concerned about a client that willfully and knowingly asks > for it. > > > > This whole draft revolves around location validation. I’m not > understanding the pushback here. > > > > Guy > > > > De : Randall Gellens > > > Envoyé : 23 août 2021 18:31 > À : Caron, Guy > > Cc : Brian Rosen >; > ecrit@ietf.org > Objet : [EXT]Re: [Ecrit] lost-planned-changes-04: plannedChange bound > to validateLocation? > > > > If a client wants to get notified that a location may have become > invalidated, why do we care why or what type of client it is? > > --Randall > > On 23 Aug 2021, at 15:26, Caron, Guy wrote: > > I understand and what I’m suggesting is to be clear about what LoST > clients are expected to do. We do not want a leasy implementation > sending across the board, don’t we? I think it is > easy and cheep to fix in the draft rather to try to fix > implementations later. > > > > Guy > > > > De : Brian Rosen > > Envoyé : 23 août 2021 18:14 > À : Caron, Guy > > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to > validateLocation? > > > > Sure, PSAPs could be a LoST client for example. A routing proxy can > be a LoST client. But they wouldn’t ask to store the URI. You have > to ask for it to get the notification. > > > > Brian > > > > On Aug 23, 2021, at 6:10 PM, Caron, Guy > > wrote: > > > > You miss my point. The LoST client may not be a LIS. If we make it > explicit that only LISes are LoST clients in the context of this > draft, I may not have as strong objections. > > > > Guy > > > > De : Brian Rosen > > Envoyé : 23 août 2021 18:06 > À : Caron, Guy > > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to > validateLocation? > > > > Only if it asked for it, per location. It asked for it, it got it. > > > > It has NOTHING to do with actual calls. It’s just an alternative to > periodic revalidation for records in the LIS. > > > > A more interesting issue is what does a LIS do when it deletes a > record for which a URI is stored in the server. Probably it marks > that URI is OBE. Another possibility is that it stores a new URI that > is a catch-all “ignore me†> > > > Hmmm. I wonder if we should have an explicit delete. Null URI = > delete. > > > > Brian > > > > > > On Aug 23, 2021, at 6:01 PM, Caron, Guy > > wrote: > > > > A LoST client that sends routing requests to the server would receive, > way after calls have been delivered, a notification with a > body. What would it do with this? > > > > Makes no sense to me. > > > > Guy > > > > De : Brian Rosen > > Envoyé : 23 août 2021 17:55 > À : Caron, Guy > > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to > validateLocation? > > > > I don’t understand the reasoning on “creating havocâ€. I don’t > know why a client would ever do it, but it “works†in that the > server doesn’t have to validate to save the URI. If I client sends > the URI and doesn’t validate, it’s weird, but not wrong. > > > > We can decide to prohibit it. But we don’t really have a > justification. > > > > Brian > > > > On Aug 23, 2021, at 5:44 PM, Caron, Guy > > wrote: > > > > I agree that accommodating this comment would require deeper XML > changes. > > > > If we do not want to go there, I think the draft should be clear that > there is no usecase for sending outside of a location > validation request and as such, should normatively recommend not doing > so. > > > > I do not agree that a LoST server receiving outside of > a location validation request would retain the URI and send > notification if the record changed afterward. I think this would > create havoc on the client’ side. > > > > Thanks, > > > > Guy > > > > De : Brian Rosen > > Envoyé : 23 août 2021 17:22 > À : Caron, Guy > > Cc : ecrit@ietf.org > Objet : [EXT]Re: lost-planned-changes-04: plannedChange bound to > validateLocation? > > > > validateLocation is an attribute, not an element, so I can’t extend > it. > > > > There isn’t an actual requirement to tie plannedChange to > validateLocation. It may not make a lot of sense, but if you did it, > the LoST server would not return validation data, would retain the URI > and would send the notification if the record changed. Note my text > that the LoST server doesn’t store the LI - the notification is > “something changed†not “what you sent is guaranteed to be > invalid†or even “one or more of the elements you sent changed". > I thought about changing the name of the notification, but I didn’t > do that. The practical use case remains the same. > > > > Brian > > > > > On Aug 23, 2021, at 5:07 PM, Caron, Guy > > wrote: > > > > Not all LoST server implementations perform location validations. When > location validation is requested by the client, it adds the > “validateLocation†attribute to the element. > > > > So the question is: Should “plannedChange†be bound to > “validateLocationâ€? > > > > If you believe not, what would be the expected behaviour of a LoST > server receiving a element outside of a validation > request? > > > > Thanks, > > > > Guy > > > > ________________________________ > > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints > > > > ________________________________ > > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints > > > > ________________________________ > > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints > > > > ________________________________ > > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > ________________________________ > > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints > > ________________________________ > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints --=_MailMate_7F8389D4-46D9-4EF4-AB5B-B8382CECB811_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">In my suggested wording edits I make it clear.

--Randall

On 24 Aug 2021, at 11:24, Caron, Guy wrote:

But you are advocating for a model th= at is useless. Why not be clear on what this is doing and what it is not?=

=C2=A0

Guy

=C2=A0

De=C2= =A0: Randall Gellens <rg+ietf@randy.pensive.org>
Envoy=C3=A9=C2=A0: 23 ao=C3=BBt 2021 18:40
=C3=80=C2=A0: Caron, Guy <g.caron@bell.ca>
Cc=C2=A0: Brian Rosen <br@brianrosen.net>; ecrit@ietf.org Objet=C2=A0: [EXT]Re: [Ecrit] lost-planned-changes-04: plannedChan= ge bound to validateLocation?

=C2=A0

I'm trying to understand the harm of allowing a client to request notifi= cation whether it is asking for validation or not. We already say that se= rver policy can refuse to store a URI for any reason, so a server could prohibit this if it wants to (e.g., to save resources). If a serve= r is OK providing this server, what do we care? It doesn't harm interoper= ability.

--Randall

On 23 Aug 2021, at 15:34, Caron, Guy wrote:

=

I=E2=80=99m not concerned about a client that willfully and knowingly = asks for it.

=C2=A0

This whole draft revolves around location validation. I=E2=80=99m not = understanding the pushback here.

=C2=A0

Guy

=C2=A0

De=C2=A0: Randall Gellens <rg+ietf@randy.pensive.org>
Envoy=C3=A9=C2=A0: 23 ao=C3=BBt 2021 18:31
=C3=80=C2=A0: Caron, Guy <g.= caron@bell.ca>
Cc=C2=A0: Brian Rosen <br@= brianrosen.net>; ecrit@ietf.org
Objet=C2=A0: [EXT]Re: [Ecrit] lost-planned-changes-04: plannedChan= ge bound to validateLocation?=

=C2=A0

If a client wants to get notified that a location may have= become invalidated, why do we care why or what type of client it is?

--Randall

On 23 Aug 2021, at 15:26, Caron, Guy wrote:

I understand and what I=E2=80=99m suggesting is to be clear about what= LoST clients are expected to do. We do not want a leasy implementation s= ending <plannedChange> across the board, don=E2=80=99t we? I think it is = easy and cheep to fix in the draft rather to try to fix implementations l= ater.

=C2=A0

Guy

=C2=A0

De=C2=A0:<= span lang=3D"EN-CA" style=3D'font-size:11.0pt;font-family:"Calibri",sans-= serif;color:#777777'> Brian Rosen <br@brianrosen.net>
Envoy=C3=A9=C2=A0: 23 ao=C3=BBt 2021 18:14
=C3=80=C2=A0: Caron, Guy <g.= caron@bell.ca>
Cc=C2=A0: ecrit@ietf.org
= Objet=C2=A0: [EXT]Re: lost-planned-changes-04: plannedChange bound= to validateLocation?

=C2= =A0

S= ure, PSAPs could be a LoST client for example. =C2=A0A routing proxy can = be a LoST client. =C2=A0But they wouldn=E2=80=99t ask to store the URI. =C2= =A0You have to ask for it to get the notification.=C2=A0

=C2= =A0

B= rian

=C2= =A0

O= n Aug 23, 2021, at 6:10 PM, Caron, Guy <g.caron@be= ll.ca> = wrote:

=C2= =A0

You miss my point. The L= oST client may not be a LIS. If we make it explicit that only LISes are L= oST clients in the context of this draft, I may not have as strong objections.

=C2=A0

Guy

=C2= =A0

De=C2=A0:<= span lang=3D"EN-CA" style=3D'font-size:11.0pt;font-family:"Calibri",sans-= serif;color:#777777'>=C2=A0Brian Rosen <br@brianrosen.net>=C2=A0
Envoy=C3=A9=C2=A0:=C2=A023 ao=C3=BBt 2021 18:06
=C3=80=C2=A0:=C2=A0Caron, Guy <g.caron@bell.ca>
Cc=C2=A0:=C2=A0ecrit@ietf.org
Objet=C2=A0:=C2=A0[EXT]Re: lost-planned-changes-04: plannedChange = bound to validateLocation?

=C2= =A0

O= nly if it asked for it, per location. =C2=A0It asked for it, it got it.

=C2= =A0

I= t has NOTHING to do with actual calls. =C2=A0It=E2=80=99s just an alterna= tive to periodic revalidation for records in the LIS.

=C2= =A0

A= more interesting issue is what does a LIS do when it deletes a record fo= r which a URI is stored in the server. =C2=A0Probably it marks that URI i= s OBE. Another possibility is that it stores a new URI that is a catch-al= l =E2=80=9Cignore me=E2=80=9D<= /p>

=C2= =A0

H= mmm. =C2=A0I wonder if we should have an explicit delete. =C2=A0Null URI = =3D delete.

=C2= =A0

B= rian

=C2= =A0

=C2=A0

O= n Aug 23, 2021, at 6:01 PM, Caron, Guy <g.caron@bell.ca> wrote:

=C2= =A0

A LoST client that sends= routing requests to the server would receive, way after calls have been = delivered, a notification with a <locationInvalid> body. What would= it do with this?

=C2=A0

Makes no sense to me.

=C2=A0

Guy

=C2= =A0

De=C2=A0:<= span lang=3D"EN-CA" style=3D'font-size:11.0pt;font-family:"Calibri",sans-= serif;color:#777777'>=C2=A0Brian Rosen <br@brian= rosen.net>=C2=A0
Envoy=C3=A9=C2=A0:=C2=A023 ao=C3=BBt 2021 17:55
=C3=80=C2=A0:=C2=A0Caron, Guy <g.caron@bell= =2Eca>
Cc=C2=A0:=C2=A0ecrit@ietf.org=
Objet=C2=A0:=C2=A0[EXT]Re: lost-planned-changes-04: plannedChange = bound to validateLocation?

=C2= =A0

I= don=E2=80=99t understand the reasoning on =E2=80=9Ccreating havoc=E2=80=9D= =2E =C2=A0I don=E2=80=99t know why a client would ever do it, but it =E2=80= =9Cworks=E2=80=9D in that the server doesn=E2=80=99t have to validate to = save the URI. =C2=A0If I client sends the URI and doesn=E2=80=99t validate, it=E2=80=99s weird, but not wrong.

=C2= =A0

W= e can decide to prohibit it. =C2=A0But we don=E2=80=99t really have a jus= tification.

=C2= =A0

B= rian



O= n Aug 23, 2021, at 5:44 PM, Caron, Guy <g.caron@bell.ca> wrote:

=C2= =A0

I agree that accommodati= ng this comment would require deeper XML changes.

=C2=A0

If we do not want to go = there, I think the draft should be clear that there is no usecase for sen= ding <plannedChange> outside of a location validation request and as such, should normatively recommend not doing so.

=C2=A0

I do not agree that a Lo= ST server receiving <plannedChange> outside of a location validatio= n request would retain the URI and send notification if the record change= d afterward. I think this would create havoc on the client=E2=80=99 side.<= /span>

=C2=A0

Thanks,

=C2=A0

Guy

=C2= =A0

De=C2=A0:<= span lang=3D"EN-CA" style=3D'font-size:11.0pt;font-family:"Calibri",sans-= serif;color:#777777'>=C2=A0Brian Rosen <br@brian= rosen.net>=C2=A0
Envoy=C3=A9=C2=A0:=C2=A023 ao=C3=BBt 2021 17:22
=C3=80=C2=A0:=C2=A0Caron, Guy <g.caron@bell= =2Eca>
Cc=C2=A0:=C2=A0ecrit@ietf.org=
Objet=C2=A0:=C2=A0[EXT]Re: lost-planned-changes-04: plannedChange = bound to validateLocation?

=C2= =A0

v= alidateLocation is an attribute, not an element, so I can=E2=80=99t exten= d it. =C2=A0

=C2= =A0

T= here isn=E2=80=99t an actual requirement to tie plannedChange to validate= Location. =C2=A0It may not make a lot of sense, but if you did it, the Lo= ST server would not return validation data, would retain the URI and woul= d send the notification if the record changed. =C2=A0Note my text that the LoST= server doesn=E2=80=99t store the LI - the notification is =E2=80=9Csomet= hing changed=E2=80=9D not =E2=80=9Cwhat you sent is guaranteed to be inva= lid=E2=80=9D or even =E2=80=9Cone or more of the elements you sent change= d". =C2=A0I thought about changing the name of the notification, but I didn=E2=80=99t do that. =C2= =A0The practical use case remains the same.

=C2= =A0

B= rian




O= n Aug 23, 2021, at 5:07 PM, Caron, Guy <g.caron@bell.ca> wrote:

=C2= =A0

Not all LoST server impl= ementations perform location validations. When location validation is req= uested by the client, it adds the =E2=80=9CvalidateLocation=E2=80=9D attr= ibute to the <findService> element.

=C2=A0

So the question is: Shou= ld =E2=80=9CplannedChange=E2=80=9D be bound to =E2=80=9CvalidateLocation=E2= =80=9D?

=C2=A0

If you believe not, what= would be the expected behaviour of a LoST server receiving a <planned= Change> element outside of a validation request?

=C2=A0

Thanks,

=C2=A0

Guy

=C2=A0

External Email:=C2=A0Please use caution when opening links and attac= hments /=C2=A0Courriel externe:=C2=A0Soyez prud= ent avec les liens et documents joints

=C2=A0

External Email:=C2=A0Please use caution when opening links and attac= hments /=C2=A0Courriel externe:=C2=A0Soyez prud= ent avec les liens et documents joints

=C2=A0

External Email:=C2=A0Please use caution when opening links and attac= hments /=C2=A0Courriel externe:=C2=A0Soyez prud= ent avec les liens et documents joints

=C2=A0

External Email: Please use caution when opening links and attachments= / Courrie= l externe: Soyez prudent avec les liens et documents joints

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

External Email: Please use caution when opening links and attachments= / Courrie= l externe: Soyez prudent avec les liens et documents joints

<= span style=3D"font-size:9.0pt;color:blue">External Email: Please use caution wh= en opening links and attachments / Courrie= l externe: Soyez prudent avec les liens et documents joints

--=_MailMate_7F8389D4-46D9-4EF4-AB5B-B8382CECB811_=-- From nobody Tue Aug 24 12:40:25 2021 Return-Path: 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 CC90F3A0EB5 for ; Tue, 24 Aug 2021 12:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-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=bell.ca 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 khjhItGc4kXh for ; Tue, 24 Aug 2021 12:40:18 -0700 (PDT) Received: from ESA1-Dor.bell.ca (esa1-dor.bell.ca [204.101.223.58]) (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 165FC3A0EAF for ; Tue, 24 Aug 2021 12:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1629834018; x=1661370018; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=Jb8jC3MQwU6ER8ErSUAsymXt0KaFL2TrycetHoFlcR8=; b=QlrmDB+wMkWCnHnU5tAdzFeYo1NuLiYejoX7XQcHWgDo6nYJWOOB/U4I +acUSrUM5ejUiQTUDHyxlkaiqa6+j+QhygjtLtuGMVWRW9FhhPKO3Kfs5 OZrzSsyFw5R86cT9QdD1bvZZQ78UX/RF7KXFZ3sxty9XR1XdBvSxwLfsw aK7DrKC9hfwtDnt/ofBJKmVl0w/sLZW3m4DePdK0PveXfE8m/oQVjAZIX WKA6UQho76TtdjVuo1w3hGldph0B+v1Y3Z7biJmNLmWd6okGiLcUHkOY+ csdiLnsJDZEnWkF/Aq4+yKRwPyhf4+ycRN167KEqJlMeaLppAHzac2hA6 g==; IronPort-SDR: YPG2cmgzg30hDD7/1rkq2zaHuzaP1Xqi6yLxC94d5e2K1xrk3ln5ROXcOpNA+VP5GpW/K0ep1I JhLQnD+4Fn7w== Received: from dc5cmy-d00.bellca.int.bell.ca (HELO DG6MBX02-WYN.bell.corp.bce.ca) ([198.235.121.229]) by esa01corp-dor.bell.corp.bce.ca with ESMTP; 24 Aug 2021 15:40:08 -0400 Received: from DG12MBX04-WYN.bell.corp.bce.ca (142.182.18.49) by DG6MBX02-WYN.bell.corp.bce.ca (142.182.18.37) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Tue, 24 Aug 2021 15:40:08 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX04-WYN.bell.corp.bce.ca (142.182.18.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Tue, 24 Aug 2021 15:40:08 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Tue, 24 Aug 2021 15:40:08 -0400 From: "Caron, Guy" To: Randall Gellens , "ecrit@ietf.org" Thread-Topic: [EXT][Ecrit] [EDIT] Review of draft-ietf-ecrit-lost-planned-changes-04 Thread-Index: AQHXmGwbTx48c+Z5tk+EajDJmoM+9KuDDiwA Date: Tue, 24 Aug 2021 19:40:08 +0000 Message-ID: <8240b50f33a848bb8c3783133bfcfb4c@bell.ca> References: <82C4B705-5044-493E-9969-B75D060A95B9@randy.pensive.org> In-Reply-To: <82C4B705-5044-493E-9969-B75D060A95B9@randy.pensive.org> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.78] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] [EDIT] Review of draft-ietf-ecrit-lost-planned-changes-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 19:40:24 -0000 I can't get securely to these resources (NET::ERR_SSL_OBSOLETE_VERSION), pe= rhaps because the web site is using TLS 1.0 or 1.1? Guy -----Message d'origine----- De=A0: Ecrit De la part de Randall Gellens Envoy=E9=A0: 23 ao=FBt 2021 18:13 =C0=A0: ecrit@ietf.org Objet=A0: [EXT][Ecrit] [EDIT] Review of draft-ietf-ecrit-lost-planned-chang= es-04 The list server has too aggressive editing, so I'm resending this message w= ith the attachments changed to links. (1) Should the Time to Live information in a validation response be an attr= ibute rather than an element? Logically, it seems more an attribute of the= response, and also it mirrors the 'expires' attribute on which it is model= ed. (2) In the extension schema, are 'invalidAsOf' and 'asOf' swapped?=20 ('AsOf' should be part of the element but looks like maybe = it is part of the response, while 'invalidAsOf' is part of )= . (3) I'm not sure that "The server MUST have policy that limits use of this = mechanism by a given client" is warranted; I think using "SHOULD"=20 is more easily justified. I have a number of suggested edits for clarification or language. =20 Linked are four files: The XML uploaded by Brian, with my edits. draft-ietf-ecrit-lost-planned-changes-04-rg.xml https://turing.pensive.org/ecrit/draft-ietf-ecrit-lost-planned-changes-04-r= g.xml The TXT generated from the XML with my edits. draft-ietf-ecrit-lost-planned-changes-04-rg.txt https://turing.pensive.org/ecrit/draft-ietf-ecrit-lost-planned-changes-04-r= g.txt An IETF tools diff showing my edits to the TXT, side by side. Diff-txt.html https://turing.pensive.org/ecrit/Diff-txt.html An IETF tools diff showing my edits to the XML, side by side. Diff-xml.html https://turing.pensive.org/ecrit/Diff-xml.html --Randall _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --- External Email: Please use caution when opening links and attachments / Cou= rriel externe: Soyez prudent avec les liens et documents joints From nobody Tue Aug 24 13:08:58 2021 Return-Path: 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 9787A3A1050 for ; Tue, 24 Aug 2021 13:08:55 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.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 RUT4CPzRRgNh for ; Tue, 24 Aug 2021 13:08:50 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 4FED83A104F for ; Tue, 24 Aug 2021 13:08:50 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id s16so21710007ilo.9 for ; Tue, 24 Aug 2021 13:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=+73C9y+hTt1KnrtBxriJI6p6L6YWZp+cfaEHZFPWOow=; b=WQ3PWWG5OmhELY+uYxRixBsbz1KXmt/NLGrUMUX7JBajMA+aLkSTzrsOf6ClO0oZM5 fAD/5Y4r+38pVLydV5Mvj+1RkSSbskPoFqsXaLL9DxH2jEJZwrBFcHeaye3JgaZH/ALw 23HvhT/EPGhxc0YkxHG3HJBFKKqt2oJNTYsutyv7uibQtMp7xSYlhlPcTJV+H8Sqtw1G i3DvZq7GhpMRKK8rGpRzlz9rBZxtl7ruZTb5nKKmL8ZLvjpCzAPgqaZz3Oefcghgkn4n 9FGUlmbcQpL8BN+gGql4fltHex+Dc09d0GACKliO3vtCsW4uvR5tcXt39uKJiW94beFM GgLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=+73C9y+hTt1KnrtBxriJI6p6L6YWZp+cfaEHZFPWOow=; b=cUGo10BmwtolffaLLTUhWHsPfTIXMIGiR1PH1VZo/F+fq6IUDPJMl2BDpfmXCPOOxV +QGlBiUuPfbhlxJJQWR1Hvkpuigxzh0kje6+NWfe87+FJEOkcgUMdyhqn69kXlwrpyX4 YLWbh+I63g54hXiwLPCzEhH14LmPUfBvQLMHkJGS6eemN1fU2gSHtVwOwpmD+vHVz48X vN31oRGNfwMm8rsHIzOuC6Bd1BCT6uUycR80OqQG6U0oBNQbqe6ZHTjqXXehWp3nQSQ6 HuuvNxPiBFgcLvYvE7Lu1/I0LwIqsHgbxfRCJjbn5hCGTgVNXlIQbb27kKsgLfMUtroP xLJg== X-Gm-Message-State: AOAM532h0A0G0hrmUOAh5OHE6ZuO+frR01r+3Ors8/AaOGjkl3Zw6r/8 Mk4+vj0UTP1yEBMnSlRZWUx63nzDForMUpvX X-Google-Smtp-Source: ABdhPJw9WUE9eqEdb64rp9z0dZq2Or1jaP7mw4HZxzAz35KcYwAo5W2ABGXr8KyyJSXcSHJaynxmmA== X-Received: by 2002:a92:730d:: with SMTP id o13mr28050933ilc.183.1629835728988; Tue, 24 Aug 2021 13:08:48 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id a11sm10206957ilf.79.2021.08.24.13.08.48 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Aug 2021 13:08:48 -0700 (PDT) From: Brian Rosen Content-Type: multipart/alternative; boundary="Apple-Mail=_172961D8-4A03-44DC-83E8-C63B8615F45C" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Message-Id: Date: Tue, 24 Aug 2021 16:08:47 -0400 To: ECRIT X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 20:08:56 -0000 --Apple-Mail=_172961D8-4A03-44DC-83E8-C63B8615F45C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I realized we have a problem with -planned-changes. The text notes: Each client of the server may only store one URI against a location, = where =E2=80=9Clocation=E2=80=9D is defined by policy at the server, = since a given unique location may have many combinations of location = elements that resolve to the same location. If the server receives a = =E2=80=98uri=E2=80=99 for the same location from the same client, the = URI in the request replaces the URI it previously retained. But this means that multiple records in the LIS may be one record in the = LoST server and when the LIS associates unique URIs with what it thinks = is multiple records, only one is retained and it doesn=E2=80=99t know = that. The easiest fix is to return the replaced URI. The client would then be = able to spot that the records are linked and do the book keeping to = track what it should do. Another way to fix this is to return a unique ID of the record in the = LoST server when you use the extension. The LIS can then keep an = internal record of all the related entries it has that are one record to = the server. =20 Brian --Apple-Mail=_172961D8-4A03-44DC-83E8-C63B8615F45C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = realized we have a problem with -planned-changes.  The text = notes:
Each client of the = server may only store one URI against a location, where =E2=80=9Clocation=E2= =80=9D is defined by policy at the server, since a given unique location = may have many combinations of location elements that resolve to the same = location.  If the server receives a =E2=80=98uri=E2=80=99 for the = same location from the same client, the URI in the request replaces the = URI it previously retained.

But this means that multiple records in = the LIS may be one record in the LoST server and when the LIS associates = unique URIs with what it thinks is multiple records, only one is = retained and it doesn=E2=80=99t know that.

The easiest fix is to return the = replaced URI.  The client would then be able to spot that the = records are linked and do the book keeping to track what it should = do.
Another way to fix this is to return a unique = ID of the record in the LoST server when you use the extension. =  The LIS can then keep an internal record of all the related = entries it has that are one record to the server.  

Brian

= --Apple-Mail=_172961D8-4A03-44DC-83E8-C63B8615F45C-- From nobody Tue Aug 24 13:21:33 2021 Return-Path: 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 001DC3A10FE for ; Tue, 24 Aug 2021 13:21:31 -0700 (PDT) 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.20150623.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 7Dn1c1iNFxp6 for ; Tue, 24 Aug 2021 13:21:26 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 6111F3A10FC for ; Tue, 24 Aug 2021 13:21:26 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id q3so10543380iot.3 for ; Tue, 24 Aug 2021 13:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=H9UEuN+l3MF2HfxeSpH5qy9IJYQq3jats2PeLtc/8NM=; b=M6vh439UHRHhydb49ZtliHDgg4xcPl281/ZFwVhyor7O3p/cMV1TZs5GZ1jdSsbZ1F EG2syyE7WOHeVqr9O30eogejA5ST5g3ez8uezc0HAq+SBO324zp7r6RfnWyPMaUTF9rU I42LvJq94ca3Dddv3yqiZ/+6wrVTcHpDwPDCsIbBqDDPGEuhoXogZtDU9y0VMK9QE9hj E925xYDxRGJrLUvaGfI4MCHceQU3gWRDv4pWHV32Lrxo5fkTn/SFbCAx+ybvi4SdgfK/ f5zhEtk/u3Y1OEIzvzLb8LdGL95/eQ7zOhu+q69dDEHfszDx7Dzrz/kJqLHL2AH0jPhi ln+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=H9UEuN+l3MF2HfxeSpH5qy9IJYQq3jats2PeLtc/8NM=; b=r91hqNs6baAK1hUT6XY930E2XLs/l79NX0bXAevmMJSnOakCxBwHN7vVeFUUQKddwp Tg2+Bo+5hNpmTcMDfOE3wXTH3R/eHNxsG4D2QmLHXUtXAA7hCFvzsioAjVojeBmKmGZ8 H4P/+4P32jIReSjR+0f+aQ5SrcYjG/xNAR4VJuQKUkxQjL4UavP63XKAd6t6vhCuR5p/ GED45lPCXlraX84bjiGXr2nQRowBGOJN1vRBizSezbz5jSOYaLm/XR0uBValUUGBsb0Z AthV5HMbXUf+JcPdOBkEeewAqIG0LzGjPE5Dh7iQLepK1e91JziXTF5xwBq0vkJf9z82 IdWQ== X-Gm-Message-State: AOAM530ER4OYGaNJS4U2pB7pR32YwbrIDt1WE9nLoYXnWPJWIuybBTad Hxy5IguXvUKLdw52+iGa7Uhnd6JxgKe34xWJ X-Google-Smtp-Source: ABdhPJx7ED8nOUT8D+f2fwvQEZ1JSMew5wExoZc0ZEq9Slwk00k9g7kaaOqW/JySGkcVB3qlW+rB9Q== X-Received: by 2002:a02:2307:: with SMTP id u7mr36607345jau.28.1629836484999; Tue, 24 Aug 2021 13:21:24 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id f6sm10552761ilr.77.2021.08.24.13.21.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Aug 2021 13:21:24 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Brian Rosen In-Reply-To: <8240b50f33a848bb8c3783133bfcfb4c@bell.ca> Date: Tue, 24 Aug 2021 16:21:22 -0400 Cc: "ecrit@ietf.org" , "Caron, Guy" Content-Transfer-Encoding: quoted-printable Message-Id: References: <82C4B705-5044-493E-9969-B75D060A95B9@randy.pensive.org> <8240b50f33a848bb8c3783133bfcfb4c@bell.ca> To: Randall Gellens X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Ecrit] [EDIT] Review of draft-ietf-ecrit-lost-planned-changes-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 20:21:32 -0000 I=E2=80=99m getting the same response. I can bypass it, but your server = needs an update! Comments The changes to the abstract and introduction lose the point that you can = ask for validation AsOf some date independent of whether you supply a = URI to be notified of a change. The draft adds two related, but independent capabilities. In the intro, you reworded: "that is retained by the server associated = =E2=80=9C to: "may retain and may associate=E2=80=9D. I think that = confuses more than it helps. Among other things that edit allows it to = not do either. The extension may not be implemented at all, but if it = implements it, it may retain (because it has limits on how = many/uniqueness/etc), but it always =E2=80=9Cassociates=E2=80=9D. The same problem occurs with the edits in Section 3. I=E2=80=99m okay with your other suggested edits. Brian > On Aug 24, 2021, at 3:40 PM, Caron, Guy = wrote: >=20 > I can't get securely to these resources = (NET::ERR_SSL_OBSOLETE_VERSION), perhaps because the web site is using = TLS 1.0 or 1.1? >=20 > Guy >=20 > -----Message d'origine----- > De : Ecrit De la part de Randall Gellens > Envoy=C3=A9 : 23 ao=C3=BBt 2021 18:13 > =C3=80 : ecrit@ietf.org > Objet : [EXT][Ecrit] [EDIT] Review of = draft-ietf-ecrit-lost-planned-changes-04 >=20 > The list server has too aggressive editing, so I'm resending this = message with the attachments changed to links. >=20 > (1) Should the Time to Live information in a validation response be an = attribute rather than an element? Logically, it seems more an attribute = of the response, and also it mirrors the 'expires' attribute on which it = is modeled. >=20 > (2) In the extension schema, are 'invalidAsOf' and 'asOf' swapped?=20 > ('AsOf' should be part of the element but looks like = maybe it is part of the response, while 'invalidAsOf' is part of = ). >=20 > (3) I'm not sure that "The server MUST have policy that limits use of = this mechanism by a given client" is warranted; I think using "SHOULD"=20= > is more easily justified. >=20 > I have a number of suggested edits for clarification or language. =20 > Linked are four files: >=20 > The XML uploaded by Brian, with my edits. > draft-ietf-ecrit-lost-planned-changes-04-rg.xml > = https://turing.pensive.org/ecrit/draft-ietf-ecrit-lost-planned-changes-04-= rg.xml >=20 > The TXT generated from the XML with my edits. > draft-ietf-ecrit-lost-planned-changes-04-rg.txt > = https://turing.pensive.org/ecrit/draft-ietf-ecrit-lost-planned-changes-04-= rg.txt >=20 > An IETF tools diff showing my edits to the TXT, side by side. > Diff-txt.html > https://turing.pensive.org/ecrit/Diff-txt.html >=20 > An IETF tools diff showing my edits to the XML, side by side. > Diff-xml.html > https://turing.pensive.org/ecrit/Diff-xml.html >=20 >=20 > --Randall >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = --------------------------------------------------------------------------= ---- > External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Tue Aug 24 13:26:26 2021 Return-Path: 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 A70573A1136 for ; Tue, 24 Aug 2021 13:26:24 -0700 (PDT) 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.20150623.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 fSwqNP8KJocd for ; Tue, 24 Aug 2021 13:26:19 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 2BAE43A112E for ; Tue, 24 Aug 2021 13:26:19 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id n24so27986616ion.10 for ; Tue, 24 Aug 2021 13:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uZmb2sz/cu967CqvZw7XOIvUdsmfREMLP1E6hXIbJZY=; b=iQx79NqrE5XOBFvZUy6Il/Uvd5PcZ+tYxtH9OUJYfh1sN7zayi2FtHh7Uhszm+UdMw iZocWtyNAfdF8TQRI2/wiAwdGg0J47gsO3tGh9uLF5fpL2O+0iwY6AKko7UWnoxcy8BK 25fO4+hY7twaWVEdYPfrHvYaYHvYOHEI97b5d9v7m93SYqxk8EW3ta7n9A7gJ82VG5S4 AxbjDkxnp+i48CQ3qs2nRRxD3LBowm0nvXhIg9MepayRoj3BHFgU2Q0H+3V6QPtHh24o MSyUWYMY/DO0Tped/xlWkZyuwYo9DS2uAlDoAdODgWMQyXFtvzHiy3mg4JbhVhRAIA+G 6Vbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uZmb2sz/cu967CqvZw7XOIvUdsmfREMLP1E6hXIbJZY=; b=KRTfdntvi5vB3EEKILhAYsPMxLqPsOKvJTacOzVB/OG6hRrVYr56sW7Vma06CRnkbS 4OdLJrxK4Kr+kGSTYmAwBQRJn/31/mSkTnGFUtd7JbX8fpcTHXMpDGcffPAufbw+cAOd uTW+GgmnhDcaz8U4wnCBxfae2ZXC1MM/UOCWkkI9m83eFLCYMwIAsbPWGcwPTfc/Dq8M OfeK5HrCDWw6a5bd2YosHTKOH62c/ZpqoWwRJ5w7a6Ds/xzF7rtWhZ/F/gB88hjKQ0sE h4CweUZ/0FBBQSKV/P6uwpaxy2EwkL+IzSuoe35/sE0E+WJYAzdR2vlslmZVHWYkkuDr sS0A== X-Gm-Message-State: AOAM5302r3MGZ+ibZZNKNlFVFsH3rrAYjvh7g94taKMl8MtxTFzQmCHl C7zzu9++dLIJRLxZlSG8EXFFkew49Y5WP/kn X-Google-Smtp-Source: ABdhPJzK5X1mragPs19MSd5E7Y92vbl1rXSEbfSqLGjWaTQoP6cdQu5L9pZAKK42VrtH0rCFEcEovQ== X-Received: by 2002:a02:a81a:: with SMTP id f26mr36042755jaj.79.1629836777252; Tue, 24 Aug 2021 13:26:17 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id l15sm11144874ilt.45.2021.08.24.13.26.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Aug 2021 13:26:16 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Brian Rosen In-Reply-To: Date: Tue, 24 Aug 2021 16:26:15 -0400 Cc: ECRIT Content-Transfer-Encoding: quoted-printable Message-Id: References: <162941926169.9620.8527061840228167005@ietfa.amsl.com> <35C2A468-9290-4DC8-9A77-8A67CA73630B@brianrosen.net> To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-lost-planned-changes-04.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 20:26:25 -0000 I=E2=80=99ll fix 1-8 and 10. The reason I did the schemas the way I did them was to provide an = authoritative xml schema to an implementation that doesn=E2=80=99t (yet) = implement the planned-changes extensions. Lots of implementations use = non authoritative schemas they either built themselves or got from = somewhere else. This allows those implementations to switch to this = authoritative schema. The extensions work the way all the other extensions to LoST have been = specified. Brian > On Aug 21, 2021, at 1:33 PM, Gunnar Hellstr=C3=B6m = wrote: >=20 > Brian, >=20 > I think this one looks good and mature. >=20 > I have only found a few editorials and traditional xml mistakes ( if I = got it right ): >=20 > 1. In Abstract, "" s.b. "" >=20 > 2. In Abstract, in the middle, ", and add a date" s.b. ", and a date" >=20 > 3. In Abstract: Full stop missing at the end. >=20 > 4. In 1. Introduction, second line, "" s.b. = "" >=20 > 5. In 1. Introduction, third paragraph: Full stop missing at the end. >=20 > 6. In 4. second paragraph, second line: findService s.b. = >=20 > 7. In 7. first line "The Relax" s.b. "the Relax" >=20 > 8. In 8. In the "plannedChange" element, "invalidAsOf" got its = leading quoutation mark changed to a curly leading double quote instead = of a straight double quote. Was that intentional, and is that safe, or = should you return to using straight double quote? >=20 > 9. In 8. Section 8 contains extensions to the schema presented in = section 7. Is the editing instruction notations formal enough to = reliably create the extended schema correctly. Would it not be safer, = and more convenient for developers if you provided the completed schema, = with easily found comments around the extensions, so that anyone = interested in creating the schema in section 7 could do that? > Please explain why it is the schema in section 7 that is provided as a = complete schema and 8 just as editing instructions and not the other way = around, when it is the schema resulting from section 8 that is the = purpose of the specification. >=20 > 10. In 9. I think the following two lines are missing before the last = line: > > >=20 >=20 > Regards >=20 > Gunnar >=20 > --=20 > Gunnar Hellstr=C3=B6m > GHAccess > gunnar.hellstrom@ghaccess.se >=20 >=20 >=20 > Den 2021-08-20 kl. 02:34, skrev Brian Rosen: >> This too, finally, is redone. I believe all comments were addressed. = XML should be checked, but I THINK it=E2=80=99s right now. There is a = bit of new text that explains the LoST server doesn=E2=80=99t have to = save the Location Information that was sent in the findService request. = That means that the notification, if requested, will be sent for any = change, which means the client could get a notification to revalidate = only to find they got the same result. >>=20 >> I did specify the Content-Type as application/xml instead of defining = a new media type. I think that=E2=80=99s okay, comments welcome. >>=20 >> Brian >>=20 >>> On Aug 19, 2021, at 8:27 PM, 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 : Validation of Locations Around a Planned = Change >>> Author : Brian Rosen >>> Filename : draft-ietf-ecrit-lost-planned-changes-04.txt >>> Pages : 19 >>> Date : 2021-08-19 >>>=20 >>> Abstract: >>> This document defines an extension to LoST (RFC5222) that allows a >>> planned change to the data in the LoST server to occur. Records = that >>> previously were valid will become invalid at a date in the future, >>> and new locations will become valid after the date. The extension >>> adds two elements to the request: A URI to be used = to >>> inform the LIS that previously valid locations will be invalid = after >>> the planned change date, and add a date which requests the server = to >>> perform validation as of the date specified. It also adds an >>> optional Time-To-Live element to the response, which informs = clients >>> about the current expected lifetime of the validation. This = document >>> also provides a conventional XML schema for LoST, as backwards >>> compatible alternative to the RelaxNG schema in RFC5222 >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> = https://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-planned-changes/ >>>=20 >>> There is also an htmlized version available at: >>> = https://datatracker.ietf.org/doc/html/draft-ietf-ecrit-lost-planned-change= s-04 >>>=20 >>> A diff from the previous version is available at: >>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-lost-planned-changes-= 04 >>>=20 >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>>=20 >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > --=20 > Gunnar Hellstr=C3=B6m > GHAccess > gunnar.hellstrom@ghaccess.se >=20 From nobody Tue Aug 24 14:38:31 2021 Return-Path: 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 B30E63A1465 for ; Tue, 24 Aug 2021 14:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 rC5oi8EG45Mu for ; Tue, 24 Aug 2021 14:38:24 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D33BF3A1464 for ; Tue, 24 Aug 2021 14:38:23 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 24 Aug 2021 14:38:23 -0700 From: "Randall Gellens" To: "Brian Rosen" Cc: ecrit@ietf.org, "Caron, Guy" Date: Tue, 24 Aug 2021 14:38:22 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <8E039374-70F6-4980-B899-11D5576BC191@randy.pensive.org> In-Reply-To: References: <82C4B705-5044-493E-9969-B75D060A95B9@randy.pensive.org> <8240b50f33a848bb8c3783133bfcfb4c@bell.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ecrit] [EDIT] Review of draft-ietf-ecrit-lost-planned-changes-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 21:38:30 -0000 On 24 Aug 2021, at 13:21, Brian Rosen wrote: > I=E2=80=99m getting the same response. I can bypass it, but your serve= r = > needs an update! [rg] Sorry about that. I sent the files in the response to Guy just = now. > > Comments > > The changes to the abstract and introduction lose the point that you = > can ask for validation AsOf some date independent of whether you = > supply a URI to be notified of a change. > The draft adds two related, but independent capabilities. [rg] You're referring to this: This extension adds two elements to the request: A URI that the LoST server can use to inform the LoST client (e.g., a Location Information Server [LIS]) that previously valid locations will be invalid after a planned change date, and a date that allows the LoST client to request that the server perform validation as of the date specified. [rg] How about adding "These two elements can be used independently" at = the end, or just add "independent" between "two" and "elements"? > In the intro, you reworded: "that is retained by the server associated = > =E2=80=9C to: "may retain and may associate=E2=80=9D. I think that con= fuses more = > than it helps. Among other things that edit allows it to not do = > either. The extension may not be implemented at all, but if it = > implements it, it may retain (because it has limits on how = > many/uniqueness/etc), but it always =E2=80=9Cassociates=E2=80=9D. > > The same problem occurs with the edits in Section 3. [rg] That came from my misunderstanding of your intent. Please see my = email from last night about the need for new explanatory text to help a = reader understand the intent, and new normative text regarding what a = LoST server can do if it implements this. > I=E2=80=99m okay with your other suggested edits. [rg Thanks. > Brian > > > >> On Aug 24, 2021, at 3:40 PM, Caron, Guy = >> wrote: >> >> I can't get securely to these resources = >> (NET::ERR_SSL_OBSOLETE_VERSION), perhaps because the web site is = >> using TLS 1.0 or 1.1? >> >> Guy >> >> -----Message d'origine----- >> De : Ecrit De la part de Randall Gellens >> Envoy=C3=A9 : 23 ao=C3=BBt 2021 18:13 >> =C3=80 : ecrit@ietf.org >> Objet : [EXT][Ecrit] [EDIT] Review of = >> draft-ietf-ecrit-lost-planned-changes-04 >> >> The list server has too aggressive editing, so I'm resending this = >> message with the attachments changed to links. >> >> (1) Should the Time to Live information in a validation response be = >> an attribute rather than an element? Logically, it seems more an = >> attribute of the response, and also it mirrors the 'expires' = >> attribute on which it is modeled. >> >> (2) In the extension schema, are 'invalidAsOf' and 'asOf' swapped? >> ('AsOf' should be part of the element but looks like = >> maybe it is part of the response, while 'invalidAsOf' is part of = >> ). >> >> (3) I'm not sure that "The server MUST have policy that limits use of = >> this mechanism by a given client" is warranted; I think using = >> "SHOULD" >> is more easily justified. >> >> I have a number of suggested edits for clarification or language. >> Linked are four files: >> >> The XML uploaded by Brian, with my edits. >> draft-ietf-ecrit-lost-planned-changes-04-rg.xml >> https://turing.pensive.org/ecrit/draft-ietf-ecrit-lost-planned-changes= -04-rg.xml >> >> The TXT generated from the XML with my edits. >> draft-ietf-ecrit-lost-planned-changes-04-rg.txt >> https://turing.pensive.org/ecrit/draft-ietf-ecrit-lost-planned-changes= -04-rg.txt >> >> An IETF tools diff showing my edits to the TXT, side by side. >> Diff-txt.html >> https://turing.pensive.org/ecrit/Diff-txt.html >> >> An IETF tools diff showing my edits to the XML, side by side. >> Diff-xml.html >> https://turing.pensive.org/ecrit/Diff-xml.html >> >> >> --Randall >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> ----------------------------------------------------------------------= -------- >> External Email: Please use caution when opening links and attachments = >> / Courriel externe: Soyez prudent avec les liens et documents joints >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit From nobody Tue Aug 24 14:40:47 2021 Return-Path: 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 82C8F3A1428 for ; Tue, 24 Aug 2021 14:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.62 X-Spam-Level: X-Spam-Status: No, score=0.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CONTENT_AFTER_HTML=2.499, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, T_HTML_ATTACH=0.01, 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 m4Sm2BxZ3oLf for ; Tue, 24 Aug 2021 14:30:56 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 326943A1426 for ; Tue, 24 Aug 2021 14:30:55 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 24 Aug 2021 14:30:54 -0700 From: "Randall Gellens" To: "Caron, Guy" Cc: ecrit@ietf.org Date: Tue, 24 Aug 2021 14:30:53 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <6974AABD-AC99-4330-9C63-27D4DFBDBAE6@randy.pensive.org> In-Reply-To: <8240b50f33a848bb8c3783133bfcfb4c@bell.ca> References: <82C4B705-5044-493E-9969-B75D060A95B9@randy.pensive.org> <8240b50f33a848bb8c3783133bfcfb4c@bell.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_MailMate_377DAA09-F515-441D-9F06-024008E3CEEA_=" Archived-At: X-Mailman-Approved-At: Tue, 24 Aug 2021 14:40:46 -0700 Subject: Re: [Ecrit] [EDIT] Review of draft-ietf-ecrit-lost-planned-changes-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 21:31:07 -0000 --=_MailMate_377DAA09-F515-441D-9F06-024008E3CEEA_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable My apologies. It is pretty out of date. Attached are the files. --Randall On 24 Aug 2021, at 12:40, Caron, Guy wrote: > I can't get securely to these resources = > (NET::ERR_SSL_OBSOLETE_VERSION), perhaps because the web site is using = > TLS 1.0 or 1.1? > > Guy > > -----Message d'origine----- > De=C2=A0: Ecrit De la part de Randall Gellens > Envoy=C3=A9=C2=A0: 23 ao=C3=BBt 2021 18:13 > =C3=80=C2=A0: ecrit@ietf.org > Objet=C2=A0: [EXT][Ecrit] [EDIT] Review of = > draft-ietf-ecrit-lost-planned-changes-04 > > The list server has too aggressive editing, so I'm resending this = > message with the attachments changed to links. > > (1) Should the Time to Live information in a validation response be an = > attribute rather than an element? Logically, it seems more an = > attribute of the response, and also it mirrors the 'expires' attribute = > on which it is modeled. > > (2) In the extension schema, are 'invalidAsOf' and 'asOf' swapped? > ('AsOf' should be part of the element but looks like = > maybe it is part of the response, while 'invalidAsOf' is part of = > ). > > (3) I'm not sure that "The server MUST have policy that limits use of = > this mechanism by a given client" is warranted; I think using "SHOULD" > is more easily justified. > > I have a number of suggested edits for clarification or language. > Linked are four files: > > The XML uploaded by Brian, with my edits. > draft-ietf-ecrit-lost-planned-changes-04-rg.xml > https://turing.pensive.org/ecrit/draft-ietf-ecrit-lost-planned-changes-= 04-rg.xml > > The TXT generated from the XML with my edits. > draft-ietf-ecrit-lost-planned-changes-04-rg.txt > https://turing.pensive.org/ecrit/draft-ietf-ecrit-lost-planned-changes-= 04-rg.txt > > An IETF tools diff showing my edits to the TXT, side by side. > Diff-txt.html > https://turing.pensive.org/ecrit/Diff-txt.html > > An IETF tools diff showing my edits to the XML, side by side. > Diff-xml.html > https://turing.pensive.org/ecrit/Diff-xml.html > > > --Randall > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > -----------------------------------------------------------------------= ------- > External Email: Please use caution when opening links and attachments = > / Courriel externe: Soyez prudent avec les liens et documents joints --=_MailMate_377DAA09-F515-441D-9F06-024008E3CEEA_= Content-Disposition: attachment; filename=Diff-xml.html Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = = = = = = = = = = Diff: draft-ietf-ecrit-lost-planned-changes-04.xml - draft-ietf-= ecrit-lost-planned-changes-04-rg.xml = = = = = = = = = = change date, and a date that al= lows the LoST client to request that the <= td class=3D"rblock">optional Time-To-Live element to the response, which = informs clients of<= td class=3D"rblock">the current expected lifetime of a validation. This document also <= td class=3D"rblock">provides a conventional XML schema for LoST, as a backwards compatible <= td class=3D"rblock">alternative to the RelaxNG schema in RFC5222<= /tr> <= td class=3D"lineno"><= td class=3D"rblock">future date, and new locations= may become valid after the date. If <= td class=3D"rblock">specified, the URI may be retained by the LoST server and may be <= /td><= td class=3D"rblock">associated with the data record that was validated, a= nd used to notify <= td class=3D"rblock">the the LoST client (e.g., a Location Information Server [LIS]) wh= en a <= td class=3D"rblock">location which was previously valid will become inval= id. The date may <= td class=3D"rblock">be used by a client to ask a server to= perform validation as of a <= td class=3D"rblock">future date. In addition to this mechanism, the = = <= td class=3D"rblock">part of the county/province. This kind of annexation= has an effective <= td class=3D"rblock">date and time (typically 00:00 on the first or last d= ay of a month), <= td class=3D"rblock">known in advance. Other kinds= of changes may also occur, and these <= td class=3D"rblock">will almost always also have a= n effective date that is known in <= /tr> <= td class=3D"rblock">advance.</t>= <= td class=3D"rblock">revalidation.</t>= circumstance where the location = in the original request may become = = = <= td class=3D"rblock">the location may become invalid.</t><= td class=3D"rblock"><= td class=3D"rblock"><t>In situations where it is not practical or advisable for the LIS to <= td class=3D"rblock">maintain a stable URI for each of it= s records, periodic revalidation <= td class=3D"rblock">can still be used to ma= intain the data in the LIS. However, the LoST <= td class=3D"rblock">server should be able to influ= ence the rate of such revalidation. For <= td class=3D"rblock">this purpose, this extension a= dds a Time to Live (TTL) element to the <= td class=3D"rblock">&lt;findServiceResponse&am= p;gt; which provides advice from the server to <= td class=3D"rblock">the LIS of when validation is suggested.</t><t>There are quite a few implementations of LoST. = Experience with <section anchor=3D"conventions" title=3D"Conventi= ons used in this = = <= td class=3D"lineno">= If the server receives a 'uri' for the same location from the same = = operation fails, the server MAY retry the operation imm= ediately, and if <= td class=3D"right"><t>The LoST server is NOT REQUIRED to store the = Location Information server that do not affect validation of the client's specific Location <= td class=3D"rblock"><t>The &lt;locationI= nvalidated&gt; object does not contain information <= td class=3D"rblock">about the location, as the URI= to which it is sent is determined by the <= td class=3D"rblock">requesting client and can be u= nique for each of the client's location <= td class=3D"rblock">records.</t>= policy at the server limits how many URIs will be stor= ed against a server has some other restriction on the feature.</t= ><= td> <= /tr> = = <= td> = <= td class=3D"rblock">advisable to revalidate data eventually.</t>= &lt;xs:import namespace=3D"urn:ietf:params:xml= :ns:lost1"/&gt;= = &lt;xs:element ref=3D"uri" type=3D"xs:= anyURI" /&gt; &lt;xs:any namespace=3D"##other" proc= essContents=3D"lax" = = <section anchor=3D"security" title=3D"Security Co= nsiderations">= = safety system operating the LoST server may have a cred= ential traceable =
< dra= ft-ietf-ecrit-lost-planned-changes-04.xml  &nb= sp;draft-ietf-ecrit-lost-planned-chan= ges-04-rg.xml >= ;
skipping to= change at line 44 &= para; skipping to change at line 44
<email&= gt;br@brianrosen.net</email> = <email>br@brianrosen.net</email>
</address= > </address>
</author>= ; </author>
<date year=3D= "2021"/> <date year=3D"2021"/= >
<area>AR= T</area> <area>ART</= area>
<workgroup&= gt;=C3=A9crit</workgroup> <= ;workgroup>=C3=A9crit</workgroup>
<keyword>= ;Internet-Draft</keyword> <= ;keyword>Internet-Draft</keyword>
<abstract&g= t; <abstract>
<t>T= his document defines an extension to LoST (= RFC5222) that <t>This doc= ument defines an extension to the Location to Serv= ice
allows a planned= change to the data = in the LoST server to occur. Translation (LoST) protocol (RFC5222) that allows a LoST server to
Records that previously were valid w= ill become invalid at a date in the = notify a clien= t of planned changes to the data. This extension is only
future, and new locations will become valid after the date. The useful with th= e validation function of LoST. It is beneficial f= or LoST
extension adds t= wo elements to the &lt;findservice&gt; request: A URI validation clients to be aware of plan= ned changes, as records that
to be used to inform the LIS = that previously valid locations will be previously were valid may become invalid= at a known future date, and
invalid after the planned change date, and add a date which requests new locations may= become valid after the date. This = extension adds two
the server to perform validation as of the date specified. I= t also elements to the &lt;findService&gt; request: A URI that the LoST server
adds an optional= Time-To-Live element to the response, which informs can use to inform the LoST client (e.g., a Location Information Server
clients about the current expected lifetime of the validation. This [LIS]) that previously valid locations wil= l be invalid after a planned
document also pr= ovides a conventional XML schema for LoST, as backwards
compatible alter= native to the RelaxNG schema in RFC5222 server perform validation as of the date = specified. It also adds an
</t> </t>
</abstract&= gt; </abstract>
</front> </front>
<middle> <middle>
<section ti= tle=3D"Introduction"> <sectio= n title=3D"Introduction">
<t>T= his document describes an update to the LoST protocol + which <t>This document describes an extension to the Location to
allows a &lt;findservice&gt; request to optionally add a URI and a date Service Translation (LoST) protocol = <xref target=3D"RFC5222"/> to assist<= /span>
to be used with planned changes to the underlying location i= nformation with planned changes to th= e underlying location information in the
in the server. = The URI is retained by the LoST server, associated with server. The extension allows a &lt;find= Service&gt; request to
the data record = that was validated, and used to notify the LIS (th= e optio= nally contain a URI, and optionally a date. This extension is
LoST client) when a location which was previously valid wil= l become usefu= l in the context of the validation function of LoST. It is
invalid. The da= te is used by the client to ask the server to perform beneficial for L= oST validation clients to be aware of planned changes,
validation as of= a future date. In addition to this mechanism, the as records that previously were vali= d may become invalid at a known
&lt;findservic= eResponse&gt; is also extended to provide a Time-To-Live &lt;findserviceResponse&gt; is also extend= ed to provide a Time-To-Live
(TTL) for validati= on, after which the client should revalidate the (TTL) for validation, after which the client should revalidate= the
location.= location.
</t> </t>
<t>Val= idation of civic locations involves dealing with data that <t>Validation of civic locations involve= s dealing with data that
changes over time. A typical example is a portion of a cou= nty or may cha= nge over time. A typical example is when a portion of a county
province that wa= s not part of a municipality is =E2=80=9Cannexed=E2= =80=9D to a or province that w= as not part of a municipality is "annexed" = to a
municipality. P= rior to the change, the content of the PIDF-LO A3 = municipality. Prior to the ch= ange, a Presence Information Data Format
element would be blank, or represent some other v= alue and after the Location Object (PIDF-LO) specifying a civic location in the affected <= /td>
change would be the municipal= ity that annexed that part of the area would have a blank= A3 element, or would contain some o= ther value;
county/province.= This kind of annexation has an effective date and after the change, a PIDF-LO specify= ing the same location would contain =
time (typically = 00:00 on the first or last day of a month).</t&= gt; an A= 3 element set to the name of the municipality that annexed that
<= /td>
<t>Records i= n a LIS must change around these kinds of events. The old <t>Records in a LIS must change around these k= inds of events. The old
record must be dis= carded, and a new, validated record must be loaded record must be discarded, and a new, validated record must b= e loaded
into the LIS. It = is often difficult for the LIS operator to know that into the LIS. It is often difficult for the LIS operator = to know that
records must be ch= anged around such events. There are other records must be changed around such events. There are other
circumstances wher= e locations that were previously valid become circumstances where locations that were previously valid become <= /td>
invalid, such as= a street renaming or renumbering event. As RFC52= 22 invalid, such as a street r= enaming or renumbering event. Using <xref
defines validation, the only way for a LIS to discover such= changes was target=3D"RFC5222"/> validation, t= he only way for a LIS to discover such
to periodically = revalidate its entire database. Of course, this w= ould changes is to periodically revalidate its entire database. Of cours= e,
not facilitate t= imely changes, is not coordinated with the actual this does not facilitate timel= y changes, is not coordinated with the
change event, an= d also adds significant load to the LoST server. Even actual change event, and = also adds significant load to the LoST server
if re-validation= is contemplated, the server has no mechanism to as well as the LIS. Even if re= -validation is contemplated, the server
control, or even= suggest the time period for revalidation</t>= ; has no mechanism to control, = or even suggest the time period for
<t>This ex= tension allows the client to provide a stab= le URI that is <t>This extension allows a LoST client to provide a stable URI that the
retained by the server associated with the location information used in LoST server ma= y retain and may associate with the location information
the request. In= the event of a planned change, or any other used in the request. In the event of a planned change, or any ot= her
circumstance whe= re the location may become invalid, the server sends a
notification to = the URI informing it of a change. The noti= fication invalid, the server sends a = notification to the URI to inform the
contains the dat= e and time when the location may become invalid.</t> client of a change. T= he notification contains the date and time when
<t>Ideally, following such a notification, the LIS will prepare a new <t>When a LIS receives such = a notification, it may prepare a new record=
record to be inserted in its active database, that becomes active<= /span> at so t= hat, at the precise planned event date and time, it may insert the
the precise plan= ned event date and time, at which point it = would also new record into in its active database and delete the old record. As
delete the old r= ecord. However, the new record has to be valid, and part of preparing the new record, the LIS may use the= "as of" date
the LIS would like to validate it prior to the planned change event. component of this extension to perform a LoST validation of the new
If it requests validation before the planned event, the server (wi= thout r= ecord as of the effective date.</t>
this extension) would inform the client that the location was inva= lid.
This extension includes an optional = =E2=80=9Cas of=E2=80=9D date and time in the
request that allows the LoST server to provide validation as of the
date and time specified, as opposed = to the =E2=80=9Cas of now=E2=80=9D implied = in <= /td>
the current LoST protocol.</t>
<t>When it is not practical or advisable for the LIS = to maintain stable <t>The notification URI and "as of" date components of this ex= tension
URIs for all of its records, = periodic revalidation can be still used to = allow a LIS to= be prepared for and smoothly transition to planned
maintain the dat= a in the LIS. However, the server should be able to changes, without the overhead and = delay inherent in performing periodic
control the rate of such revalidation. For this purpose, a= new TTL revalidation of each location. The notification= URI allows a LIS to be
element is included in the &lt;f= indserviceResponse&gt; which provides alerted to planned changes, while the = "as of" date allows the LIS to
advice from the = server to the LIS of when revalidation is s= uggested.</t> verify the validity of locations before they become active.</t>= ;
<t>There are= quite a few implementations of LoST. Experience with
these implementati= ons indicates that the RelaxNG schema is very these implementations indicates that the RelaxNG schema is very <= /td>
difficult to dea= l with, because the tools that the implementors use difficult to deal with, both because many commonly used development
don=E2=80=99t support it, and their<= /span> staff is unfamiliar with it. Alternative tools do= n't support it, and development staf= f is often unfamiliar with
schemas have bee= n circulated, which is undesirable, as they= may not be it. Informal alternative schemas have been circulated, which is
in conformance <= span class=3D"delete">to the RelaxNG schema in <xref target=3D"= RFC5222"/>. This undesirable as they may not be in conformance with the RelaxNG schema
document provide= s an XML schema that replaces the RelaxNG schema. It in <xref target=3D"RFC5222"/>. This document prov= ides an XML schema that
can be used by a= ny implementation interchangeably with the RelaxNG replaces the RelaxNG schema. It can be used by any impleme= ntation
schema. </t&g= t; interchangeably with the RelaxNG sc= hema. </t>
</section&g= t; </section>
<section an= chor=3D"conventions" title=3D"Conventions used in this
document"> document">
<t>The= key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>The key words "MUST", "MUST NOT", "RE= QUIRED", "SHALL", "SHALL
NOT", "SHOULD", "S= HOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OP= TIONAL" in
this document are = to be interpreted as described in <xref this document are to be interpreted as described in <xref
target=3D"RFC2119"= />. target=3D"RFC2119"/>.
</t> </t>
<t>=E2=80=9DServer=E2=80=9D in this document re= fers to the LoST server and <t>"Server" in this document refers to t= he LoST server and
=E2=80=9CClient=E2=80=9D is the LoST client, even when the = server is performing an "Client" is the LoST client, even when the server is perf= orming an
operation on the c= lient.</t> operation on the clien= t.</t>
</section&g= t; </section>
<section ti= tle=3D"&lt;plannedChange&gt; element"> <section title=3D"&lt;plannedChange&gt; element= ">
<t>T= his document defines a new element to &= lt;findService&gt; <t>= ;This document defines a new element in the= &lt;findService&gt;
called =E2=80=9CplannedChange=E2=80=9D. This element conta= ins two attributes: request called "plannedChange". This element contains two optional
=E2=80=98uri=E2=80=99 and =E2=80=98a= sOf=E2=80=99. The =E2=80=98uri=E2=80=99 attribute MUST be a URI w= ith a attributes: 'uri' and 'asOf'. When present, the 'u= ri' attribute MUST
scheme of HTTPS.= The URI will be stored by the server against the = be a URI with a scheme of HTTPS. If the ser= ver supports this extension,
location in the = request for subsequent use with the notific= ation it may s= tore the URI and may associate it with the location in the
function defined= below. To minimize storage requirements of at the reque= st. The server uses the URI with the notification function
server, the leng= th of the URI MUST be 256 bytes or less. Each client defined below. To minimize storage requirements at the server, the <= /td>
of the server ma= y only store one URI against a location, where length of the URI MUST not exceed = 256 bytes. Each client of the server
=E2=80=9Clocation=E2=80=9D is defined by policy at the serv= er, since a given unique may only sto= re one URI against a location, where "location" is defined
location may hav= e many combinations of location elements that resolve by policy at the server, since a given unique location m= ay have many
to the same loca= tion. If the server receives a =E2=80=98uri=E2=80= =99 for the same combinations = of location elements that resolve to the same location.
location from th= e same client, the URI in the request replaces the URI
it previously re= tained. Policy at the server may limit how many URIs client, the URI in the request replaces the URI it previ= ously retained.
it retains for a= given location. A new warning is defined below to be Policy at the server may = limit how many URIs it retains for a given
used to indicate that the URI has not been stored. If the = location in location. A new warning i= s defined below to indicate that the URI has
the request is i= nvalid, the URI will not be stored and the warning will = not been stored. If the location in = the request is invalid, the URI is
be returned. not stored = and the warning is returned.
</t> </t>
<t>The =E2=80=98asOf=E2=80=99 attribute contains a da= te and time. The server will <t>The 'asOf' = attribute contains a date and time. The server va= lidates
validate the location in the request as of the date specifi= ed, taking the location in the reques= t as of the date and time specified, taking=
into account pla= nned changes. This allows the client to ve= rify that it into account planned cha= nges. This allows a client to verify that = it
can make changes i= n the LIS commensurate with changes in the LoST can make changes in the LIS commensurate with changes in the LoST=
server by validati= ng locations in advance of a change.</t> server by validating locations in advance of a change.</t><= /td>
</section&g= t; </section>
<section tit= le=3D"&lt;locationInvalidated&gt; object"> <section title=3D"&lt;locationInvalidated&gt= ; object">
<t>When the server needs to invalidate a location where the client <t>When a server needs to inva= lidate a location that has one or more
provided a URI in &lt;plannedCha= nge&gt;, associated client-supplied URIs (provided in a &lt;plannedChange&gt; <= /td>
the server executes an HTTPS POST co= ntaining element),
&lt;locationInvalidated&gt;, with a Content-Type of= 'application/xml' it transmits an HTTPS POST with a Content-Type of 'applicatio= n/xml'
to the URI previously provided. containing a &lt;locationInvalidated&am= p;gt; object to each associated URI.=
This is the notice= from the server to the client that the location may This is the notice from the server to the client that the = location may
be invalid and sho= uld be revalidated. be invalid and shou= ld be revalidated.
&lt;location= Invalidated&gt; contains an =E2=80=98invalidAsOf=E2=80=98 attribute The &lt;locationInvalidated&gt; object contains an =E2=80=98invalidAsOf=E2=80=98
that specifies when the location may become invalid.attribute, which specifies a date and time when the locat= ion may become
If the date/time in =E2=80=98invalidAsOf=E2=80=98 is earlier= than the time the invalid.
&lt;locationInvalidated&gt; was If this is earlier than the= current time, the location may already be =
sent, the location may already be invalid and the LIS shoul= d take invalid and the LIS should tak= e immediate action. If the POST
immediate action= =2E If the POST operation fails, the server MAY retry
the operation im= mediately, and if it fails again, retry the operation it fails again, retry the operation later. Retry timing and duration
at a later time.</t> or number of attempts is determined by the serv= er.</t>
<t>The LoST = server is NOT REQUIRED to store the Location Information
supplied in the or= iginal findService request. This means the server supplied in the original findService request. This means th= e server
may not know if a = planned change will in fact invalidate the location may not know if a planned change will in fact invalidate th= e location
stored in the LoST= client, because changes could be made in the LoST stored in the LoST client, because changes could be made in = the LoST
server that do n= ot affect validation of the Location Information. The <= /td>
LoST client may = find that upon revalidation with the changed server Information. The LoST client may find that upon revalidat= ion with the
state, the valid= ation data is the same as it was before the changed server state, the validation data is the same as it was be= fore
notification was= received. </t> the notification= was received. </t>
=
</section>= ; </section>
<section title=3D= "URI Not Stored Warning"> <sectio= n title=3D"URI Not Stored Warning">
<t>A new warning is added to the exceptionContainer, <t>This extension adds a new warning to the = exceptionContainer,
=E2=80=99uriNotStored=E2=80=99. This warning MUST NOT be r= eturned unless the 'uriNotStored'. This warning MUST NOT be returned unless the= request
&lt;plannedC= hange&gt; element was found in the correspondi= ng request. contains a &lt;plannedChange&gt; element with a 'uri' attribute. The
The warning is r= eturned when the server decides not to store the U= RI warning is returned when th= e server decides not to store the URI. As =
found in the &lt;plannedChange&gt; element. As dis= cussed above, this discussed above, t= his may occur because, among other reasons, the
may occur becaus= e, among other reasons, the policy at the server limits
how many URIs wi= ll be stored against a specific location, the URI is specific location, the URI is not well formed or the poli= cy at the
not well formed = or the policy at the server has some other restriction
on the feature.&= lt;/t>
</section>= ; </section>
<section title=3D= "Time-To-Live (TTL) in Response"> &l= t;section title=3D"Time-To-Live (TTL) in Response">
<t>A new &lt;ttl&gt; element is added to the <t>This extension adds the &lt;ttl&g= t; element to the
&lt;findserviceResponse&gt;. The &lt;ttl&g= t; element &= ;lt;findServiceResponse&gt;. The &lt;ttl&gt; element<= /td>
contains a date an= d time after which the client may wish to revalidate contains a date and time after which the client may wish t= o revalidate
the locationthe location
at the server. = This element MAY be = added by the server if validation at the server. = A server MAY add this element to the= response if
is requested validation i= s requested. This element takes the form o= f the 'expires' <= /td>
in the response. The form of= the element is the =E2=80=98expires=E2=80=99 attribute p= attern of <xref target=3D"RFC5222"/>, which allows
attribute pattern, which allows the values '= NO CACHE' or 'NO EXPIRATION' to be returned instead of a
explicit =E2=80=98NO CACHE=E2=80=99 and =E2=80=98NO EXPIRATION=E2=80= =99 values to be returned dateTime value. However, for the &lt;ttl&a= mp;gt; element 'NO CACHE' has no
in the &lt;ttl&gt; element. = =E2=80=98NO CACHE=E2=80=99 has no meaning and MUST NOT be returned. 'NO EXPIRAT= ION' means the server does
meaning and MUST= NOT be returned in TTL. =E2=80=98NO EXPIRATION=E2= =80=99 means the not have a suggested revalidation period.</t>
server does
not have any suggested revalidation period.</t>
<t>Selecting= a revalidation interval is a complex balancing of <t>Selecting a revalidation interval is a complex bala= ncing of
timeliness, server= load, stability of the underlying data, and policy timeliness, server load, stability of the underlying data, = and policy
of the LoST server= =2E Too short, and load on the server may overwhelm of the LoST server. Too short, and load on the server may= overwhelm
it. Too long an= d invalid data may persist in the server for too l= ong. it. Too long and invali= d data may persist in the server for
The URI mechanis= m provides timely notice to coordinate changes, but unacceptable lengths of time. The URI notification mechanism provides =
even with it, it= is often advisable to revalidate data eventually.</t> timely notice to coordinate changes, but even with= it, it is often
<t>In areas = that have little change in data, such as fully built out, <t>In areas that have little change in data, su= ch as fully built out,
stable communities= already part of a municipality, it may be reasonable stable communities already part of a municipality, it may= be reasonable
to set revalidatio= n periods of 6 months or longer, especially if the to set revalidation periods of 6 months or longer, especiall= y if the
URI mechanism is w= idely deployed at both the server and the clients. URI mechanism is widely deployed at both the server and the= clients.
In areas that are = quickly growing, 20-30 day revalidation may be more In areas that are quickly growing, 20-30 day revalidation m= ay be more
appropriate even t= hough such revalidation would be the majority of the appropriate even though such revalidation would be the maj= ority of the
traffic on the LoS= T server.</t> traffic on the LoST= server.</t>
<t>When a pl= anned change is made, typically the TTL value for the <t>When a planned change is made, typically the TTL= value for the
affected records i= s lowered, so that revalidation is forced soon after affected records is lowered, so that revalidation is force= d soon after
the change is impl= emented. It is not advisable to set the expiration the change is implemented. It is not advisable to set th= e expiration
skipping to= change at line 679 = ¶ skipping to change at line 702<= /em>
&lt;xs:im= port namespace=3D"urn:ietf:params:xml:ns:lost1"/&gt;
&lt;!-- extend= the extensionPoint of commonRequestPattern of findService &lt;!-- extend the extensionPoint of commonReques= tPattern of findService
= to include: to inc= lude:
--&gt;--&gt;
xs:group r= ef=3D"plannedChange" minOccurs=3D"1"/&gt; xs:group ref=3D"plannedChange" minOccurs=3D"1"/&gt;
&lt;!-- where = --&gt; &lt;!-- where --&gt;=
&lt;xs:= group name=3D"plannedChange"&gt; = &lt;xs:group name=3D"plannedChange"&gt;
&lt= ;xs:sequence&gt; &lt= ;xs:sequence&gt;
&= ;lt;xs:element ref=3D"uri" type=3D"xs:anyURI" /&gt;
&a= mp;lt;xs:element ref=3D=E2=80=9CinvalidAsOf" type=3D"xs:dateTime" = &lt;xs:element ref=3D"invalidAsOf" type= =3D"xs:dateTime" /&gt;
/&gt;
&= ;lt;xs:any namespace=3D"##other" processContents=3D"lax"
m= inOccurs=3D"0" maxOccurs=3D"unbounded"/&gt; minOccurs=3D"0" maxOccurs=3D"unbounded"/&gt;=
&lt= ;/xs:sequence&gt; &l= t;/xs:sequence&gt;
&lt;/x= s:group&gt; &lt;/xs:gro= up&gt;
&lt;!-- extend= the extensionPoint of commonResponsePattern in &lt;!-- extend the extensionPoint of commonResponsePattern in=
= findServiceResponse to include: --&gt; findServiceResponse to include: --&= amp;gt;
&lt= ;xs:atttribute name=3D"asOf" type=3D"xs:dateTime" &lt;xs:atttribute name=3D"asOf" type=3D"xs:dat= eTime"
minOccurs=3D"0"/&a= mp;gt; minOccurs=3D"0"/&gt;
&lt= ;xs:element ref=3D"ttl" type=3D"expires" minOccurs=3D"0" /&gt; &lt;xs:element ref=3D"ttl" typ= e=3D"expires" minOccurs=3D"0" /&gt;
skipping to= change at line 702 = ¶ skipping to change at line 724<= /em>
&lt;!-- extend= the extensionPoint of extensionContainer to include: &lt;!-- extend the extensionPoint of extensionContain= er to include:
--&gt;--&gt;
&lt= ;xs:element ref=3D"uriNotStored"/&gt; &lt;xs:element ref=3D"uriNotStored"/&gt;
&lt;!-- where = --&gt; &lt;!-- where --&gt;=
&lt= ;xs:element name=3D"uriNotStored" type=3D"basicException"/&gt; &lt;xs:element name=3D"uriNotS= tored" type=3D"basicException"/&gt;
&lt;/xs:schema= &gt; &lt;/xs:schema&gt;
</artwork>&l= t;/figure></section> </artw= ork></figure></section>
<section an= chor=3D"locationInvalidated" title=3D"locationInvalidated <section anchor=3D"locationInvalidated" title=3D= "locationInvalidated
Schema">Schema">
<t>This sc= hema defines the object used for the notification = of <t>This schema define= s the object used for the notification that a
(potential) invalidated location by = the LoST server to a client that location is potentially invalidated sent= by a LoST server to a client
requested it.<= ;/t> that requested it.</t>
<figure><= artwork> <figure><artwork&g= t;
&lt;?xml versi= on=3D"1.0" encoding=3D"UTF-8"?&gt; = &lt;?xml version=3D"1.0" encoding=3D"UTF-8"?&gt;
&lt;xs:schema = xmlns:xs=3D"http://www.w3.org/2001/XMLSchema" &lt;xs:schema xmlns:xs=3D"http://www.w3.org/2001/XMLSchema"
xmlns=3D"urn:i= etf:params:xml:ns:lostLocationInvalidated1" xmlns=3D"urn:ietf:params:xml:ns:lostLocationInvalidated1"
targetNamespac= e=3D"urn:ietf:params:xml:ns:lostLocationInvalidated1" targetNamespace=3D"urn:ietf:params:xml:ns:lostLocation= Invalidated1"
elementFormDef= ault=3D"qualified"&gt; elementF= ormDefault=3D"qualified"&gt;
&lt;xs:elemen= t name=3D"locationInvalidated"&gt; = &lt;xs:element name=3D"locationInvalidated"&gt;
&lt;xs:anno= tation&gt; &lt;xs:annotation= &gt;
&lt;xs:do= cumentation&gt; &lt;xs:doc= umentation&gt;
A point whe= re future extensions A point whe= re future extensions
skipping to= change at line 739 = ¶ skipping to change at line 761<= /em>
<section an= chor=3D"security" title=3D"Security Considerations">
<t>As = an extension to LoST, this document inherits the security <t>As an extension to LoST, this document= inherits the security
issues raised in &= lt;xref target=3D"RFC5222"/>. The server could be tricked <= /td>issues raised in <xref target=3D"RFC5222"/>= =2E The server could be tricked
into storing a mal= icious URI which, when sent the locationInvalidated into storing a malicious URI which, when sent the locationI= nvalidated
object could trigg= er something untoward. The server MUST NOT accept object could trigger something untoward. The server MUST NO= T accept
any data from the = client in response to POSTing the any = data from the client in response to POSTing the
locationInvalidate= d.</t> locationInvalidated.</t= >
<t>The= server is subject to abuse by clients because it is being <t>The server is subject to abuse by cli= ents because it is being
asked to store som= ething and may need to send data to an uncontrolled asked to store something and may need to send data to an un= controlled
URI. Clients co= uld request many URIs for the same location for URI. Clients could request many URIs for the same location, for
example. The serv= er MUST have policy that limits use of this mechanism example. The server MUST have policy that limits use of = this mechanism
by a given client.= If the policy is exceeded, the server returns the by a given client. If the policy is exceeded, the server r= eturns the
=E2=80=98uriNotStored=E2=80=98 warning. The server MUST va= lidate that the content 'uriNotStored' warning. The server MUST validate that th= e content of
of the =E2=80=98uri=E2=80=98 attribute sent is syntacticall= y valid and meets the the 'uri' attribute sent is syntactically valid and meets = the 256 bytes
256 bytes limit.= When sending the locationInvalidated object to the limit. When sending the locationInvalidated object to th= e URI stored,
URI stored, the = server MUST protect itself against common HTTP the server MUST protect itself against common HTTP vulnerabiliti= es.
vulnerabilities.=
</t> </t>
<t>The m= utual authentication between client and server is <t>The mutual authentication between client and ser= ver is
RECOMMENDED for bo= th the initial &lt;findService&gt; operation that RECOMMENDED for both the initial &lt;findService&= amp;gt; operation that
requests storing= the URI and the sending of the reque= sts storing the URI and the sending of the 'locati= onInvalidated'
=E2=80=98locationInvalidated=E2=80=98 object. The server s= hould be well known to object. The s= erver should be well known to the client, and its
the client, and = its credential should be learned in a reliable way. credential should be learned in a reliable way. For exam= ple, a public
For example, a p= ublic safety system operating the LoST server may have
a credential tra= ceable to a well known Certificate Authority known to to a well known Certificate Authority known to provide c= redentials for
provide credenti= als for public safety agencies. Many of the clien= ts public safety agencies. Clients may be operated by local ISPs or othe= r
will be operated by local ISPs or other service providers <= span class=3D"delete">where the service providers that can reasonably obt= ain a good credential to use
server operator can reasonably obtain a good credential to = use for the for the server side of the LoST server's POST transaction using the =
URI. Where the = server does not recognize the client, its policy MAY URI. Where the loST server= does not recognize the client, its policy
limit the use of= this feature beyond what it would limit a client it MAY limit the use of this feature beyond what it would li= mit a client
recognized.</t> it= recognizes.</t>
</section&g= t; </section>
<section an= chor=3D"iana" title=3D"IANA Considerations"> <section anchor=3D"iana" title=3D"IANA Considerations">=
<section ti= tle=3D"Replacement XML Schema Registration"> <section title=3D"Replacement XML Schema Registration">=
<figure>= <artwork><![CDATA[ <fig= ure><artwork><![CDATA[
URI: urn:ietf:= params:xml:schema:lost3 URI: urn:ie= tf:params:xml:schema:lost3
Registrant Cont= act: IETF ECRIT Working Group, Brian Rosen Registrant Contact: IETF ECRIT Working Group, Brian Rosen
(br@brianros= en.net). (br@brianrosen.net).
XML: <= /td> XML:
BEGIN BEGIN
<?xml ver= sion=3D"2.0"?> <?xml versio= n=3D"2.0"?>
<= /td>
&= nbsp;End of changes. 23 change blocks. 
148 lines changed or deleted= 169 lines changed or added

This htm= l diff was produced by rfcdiff 1.48. The latest version is available from= http://tools.ietf.= org/tools/rfcdiff/
--=_MailMate_377DAA09-F515-441D-9F06-024008E3CEEA_= Content-Disposition: attachment; filename=Diff-txt.html Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = = = = = = = = = = Diff: draft-ietf-ecrit-lost-planned-changes-04.txt - draft-ietf-= ecrit-lost-planned-changes-04-rg.txt = = = = = = = <= td class=3D"lineno"> the LoST server can use to inform the LoST client (e.g., a Location<= td class=3D"rblock"> specified. It also adds an optional Time-To-Live = element to the<= td class=3D"rblock"> response, which informs clients of the current expected lifetime of a<= /span><= td class=3D"rblock"> validation. This document also provides a convent= ional XML schema<= td class=3D"rblock"> for LoST, as a backw= ards compatible alternative to the RelaxNG schema<= td class=3D"rblock"> in RFC5222 publication of this document. Please review these = documents to this document. Code Components extracted from t= his document must the Trust Legal Provisions and are provided without= warranty as<= td class=3D"rblock"> described in the Simplified BSD License.<= td class=3D"rblock"> locations may become valid = after the date. If specified, the URI may<= td class=3D"rblock"> (e.g., a Location Informati= on Server [LIS]) when a location which was<= td class=3D"rblock"> previously valid will become invalid. The date may be used by a<= td class=3D"rblock"> client to ask a serv= er to perform validation as of a future date. In<= td class=3D"rblock"> addition to this mechanism, the <findserviceRes= ponse> is also<= td class=3D"rblock"> extended to provide a Time-To-Live (TTL) for valid= ation, after which<= td class=3D"rblock"> the client should revalidate the location.<= td class=3D"rblock"> Format Location Object (PID= F-LO) specifying a civic location in the affected area would <= span class=3D"insert">have a blank A3 element, or would contain some other value; after th= e change, a PIDF-LO specifying the same location= <= td class=3D"rblock"> annexed that part of the county/province. This ki= nd of annexation<= td class=3D"rblock"> has an effective date and time (typically 00:00 on= the first or last<= td class=3D"rblock"> day of a month), known in a= dvance. Other kinds of changes may also<= td class=3D"rblock"> occur, and these will almos= t always also have an effective date that<= td class=3D"rblock"> is known in advance.= or any other circumstance where the location in the original request<= td class=3D"rblock"> and time when the location may become invalid. changes, without the overhead= and delay inherent in performing<= td class=3D"rblock"> active.<= td class=3D"rblock"><= td class=3D"rblock"> In situations where = it is not practical or advisable for the LIS to<= td class=3D"rblock"> maintain a stable URI for each of= its records, periodic revalidation<= td class=3D"rblock"> can still be used to= maintain the data in the LIS. However, the LoST<= /span><= td class=3D"rblock"> server should be able to in= fluence the rate of such revalidation.<= td class=3D"rblock"> For this purpose, this exte= nsion adds a Time to Live (TTL) elem= ent to<= td class=3D"rblock"> the <findServiceResponse= > which provides advice from the server to<= td class=3D"rblock"> the LIS of when validation<= /span> is suggested.<= td class=3D"rblock"> with the RelaxNG schema.<= td class=3D"lineno"> requirements at the server, the length of the URI M= UST not exceed 256<= /tr> location, where "location" is defined by policy at t= he server, since<= td class=3D"rblock"> stored and the warning is returned. can make changes in the LIS commensurate with change= s in the LoST<= td class=3D"lineno"><= /tr> <= td class=3D"rblock"> duration or number of attem= pts is determined by the server.<= td class=3D"rblock"> = <= td class=3D"rblock"> The <locationInvalidated= > object does not contain information about<= td class=3D"rblock"> the location, as the URI to= which it is sent is determined by the<= td class=3D"rblock"> requesting client and can b= e unique for each of the client's location<= td class=3D"rblock"> records. policy at the server limits how many URIs will be s= tored against a specific location, the URI is not well formed or th= e policy at the= = to include: --><= td class=3D"lineno"> = = <!-- extend the extensionPoint of extensionContainer= to include: -->= <= td class=3D"rblock"> = = targetNamespace=3D"urn:ietf:params:xml:ns:lostLo= cationInvalidated1"<= td class=3D"right"> for both the initial <findService> operation = that requests storing<= /tr> = <= td class=3D"rblock"> it recognizes.<= td class=3D"lineno"> = <= td class=3D"lineno">= =
< dra= ft-ietf-ecrit-lost-planned-changes-04.txt  &nb= sp;draft-ietf-ecrit-lost-planned-chan= ges-04-rg.txt >= ;
ecrit = B. Rosen ecrit = B. Rosen
Internet-Draft = 19 Augus= t 2021 Internet-Draft = August 23,= 2021
Updates: RFC5222 (= if approved) Updates: RFC5222 (if appro= ved)
Intended status: S= tandards Track Intended status: Standar= ds Track
Expires: 20 February 2022 Expires: February 24, 2022
Valida= tion of Locations Around a Planned Change Validation of Locations Around a Planned Change
dr= aft-ietf-ecrit-lost-planned-changes-04 = draft-ietf-ecrit-lost-planned-changes-04
Abstract = Abstract
This document= defines an extension to LoST (RFC5222) tha= t allows a This document defines an= extension to the Location to Service
planned change to the data in the LoST server to occur. Records that Translation (LoST) protocol (RFC5222) that allo= ws a LoST server to
previously we= re valid will become invalid at a date in the future, notify a client of planned changes to the data. This ext= ension is
and new locat= ions will become valid after the date. The extension only useful with the validation function of LoST. It is beneficial
adds two elem= ents to the <findservice> request: A = URI to be used to for LoST validation clients to be aware of planned = changes, as
inform the LIS that previously valid locations will be i= nvalid after = records that previously were valid may become invalid at a known
the planned change date, and add a date which requests the server to future date, and new locations may become valid after the date. This=
perform valid= ation as of the date specified. It also adds an extension adds two elements to the <= ;findService> request: A URI that=
optional Time= -To-Live element to the response, which informs clients
about the current expected lifetime of the validation. This document Information Server [LIS]) that prev= iously valid locations will be
also provides= a conventional XML schema for LoST, as backwards invalid after a planned chan= ge date, and a date that allows the LoST
compatible al= ternative to the RelaxNG schema in RFC5222 client to re= quest that the server perform validation as of the date
Status of This Mem= o Status of This Memo
This Internet-D= raft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the<= /td>
provisions of B= CP 78 and BCP 79. provisions of BCP = 78 and BCP 79.
Internet-Drafts= are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engi= neering
Task Force (IET= F). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute=
working documen= ts as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of curr= ent Internet-
Drafts is at = https://datatracker.ietf.org/drafts/current= /. Drafts is at http://datatracker.= ietf.org/drafts/current/.
Internet-Drafts= are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximu= m of six months
and may be upda= ted, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other doc= uments at any
time. It is in= appropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference=
material or to = cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet= -Draft will expire on 20 February 2022. This Internet-Draft will expire on February 24, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2= 021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as th= e
document author= s. All rights reserved. document au= thors. All rights reserved.
This document i= s subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal<= /td>
Provisions Re= lating to IETF Documents (https://trustee.ietf.org= / Provisions Relating to IET= F Documents
license-info) in effect on the date of publication of th= is document. (http://trustee.ietf.org/license-info) in effect on the date of
Please review= these documents carefully, as they describe your rights
and restricti= ons with respect to this document. Code Components carefully, as they describe your rights and restrictions= with respect
extracted fro= m this document must include Simplified BSD License text
as described = in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Sec= tion 4.e of
provided with= out warranty as described in the Simplified BSD License.
Table of Contents<= /td> Table of Contents
1. Introductio= n . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . = =2E . . . . . 2
2. Conventions= used in this document . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . = =2E . . . . . 4
3. <planned= Change> element . . . . . . . . . . . . . . . . . . . 4 3. <plannedChange> element . . . . . . . = =2E . . . . . . . . . . . 4
4. <locatio= nInvalidated> object . . . . . . . . . . . . . . . . 5 4. <locationInvalidated> object . . . . = =2E . . . . . . . . . . . 5
5. URI Not S= tored Warning . . . . . . . . . . . . . . . . . . . 5 5. URI Not Stored Wa= rning . . . . . . . . . . . . . . . . . . . 6
6. Time-To-L= ive (TTL) in Response . . . . . . . . . . . . . . . 5 6. Time-To-Live (TTL= ) in Response . . . . . . . . . . . . . . . 6
7. Replaceme= nt XML schema . . . . . . . . . . . . . . . . . . . 6 7. Replacement XML s= chema . . . . . . . . . . . . . . . . . . . 7
8. Extension X= ML Schema . . . . . . . . . . . . . . . . . . . . 15 8. Extension XML Schema . . . . . . . . . . . . . . = =2E . . . . . 15
9. locationInv= alidated Schema . . . . . . . . . . . . . . . . . 16 9. locationInvalidated Schema . . . . . . . . . . . = =2E . . . . . 16
10. Security = Considerations . . . . . . . . . . . . . . . . . . . 16 10. Security Consider= ations . . . . . . . . . . . . . . . . . . . 17
11. IANA Cons= iderations . . . . . . . . . . . . . . . . . . . . . 17 11. IANA Consideratio= ns . . . . . . . . . . . . . . . . . . . . . 18
11.1. Repl= acement XML Schema Registration . . . . . . . . . . 17 11.1. Replacement = XML Schema Registration . . . . . . . . . . 18
11.2. Plan= ned Change Extension XML Schema Registration . . . . 17 11.2. Planned Chan= ge Extension XML Schema Registration . . . . 18
11.3. loca= tionInvalidated XML Schema Registration . . . . . . 18 11.3. locationInva= lidated XML Schema Registration . . . . . . 19
12. Normative= References . . . . . . . . . . . . . . . . . . . . 19 12. Normative Referen= ces . . . . . . . . . . . . . . . . . . . . 20
Author's Addr= ess . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . .= . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
This document= describes an update to the LoST protocol + which allows This document describes an extension to the Location to Service
a <findservice> request to = optionally add a URI and a date to be used<= /span> Trans= lation (LoST) protocol [RFC5222] to assist<= /span> with planned changes
with planned = changes to the underlying location information in the to the underlying location information in the server. = The extension
server. The = URI is retained by the LoST server, associated with the allows a <findService> request to op= tionally contain a URI, and
data record t= hat was validated, and used to notify the LIS (the= LoST = optionally a date. This extension is useful in the context of the
client) when a location which was previously valid will b= ecome valida= tion function of LoST. It is beneficial fo= r LoST validation
invalid. The= date is used by the= client to ask the server to perform= clients to = be aware of planned changes, as records that previously
validation as= of a future date. In addition to this mechanism, the were valid may become invalid = at a known future date, and new
<findservi= ceResponse> is also extended to provide a Time-To-Live
(TTL) for val= idation, after which the client should revalidate the be retained by the LoST = server and may be associated with the data<= /td>
location. record that was validated, and used to= notify the the LoST client
Validation of= civic locations involves dealing with data that c= hanges Validation of civic l= ocations involves dealing with data that may
over time. A= typical example is a portion of a county or province change over time. A typ= ical example is when a portion of a county = or
that was not = part of a municipality is "annexed" to a municipality. province that was not part of a municipality is "anne= xed" to a
Prior to the = change, the content of the PIDF-LO A3 element would be municipality. Prior to the change, a Prese= nce Information Data
blank, or represent some o= ther value and after the change would be =
the municipal= ity that annexed that part of the county/province. This
kind of annex= ation has an effective date and time (typically 00:00 on
the first or = last day of a month). would contain an A3 element set t= o the name of the municipality that
=
Records in a LI= S must change around these kinds of events. The old Records in a LIS must change around these kinds of event= s. The old
record must be = discarded, and a new, validated record must be loaded record must be discarded, and a new, validated record m= ust be loaded
into the LIS. = It is often difficult for the LIS operator to know into the LIS. It is often difficult for the LIS operator = to know
that records mu= st be changed around such events. There are other that records must be changed around such events. There ar= e other
circumstances w= here locations that were previously valid become circumstances where locations that were previously valid becom= e
invalid, such= as a street renaming or renumbering event. As RF= C5222 invalid, such as a str= eet renaming or renumbering event. Using
defines validation, the only way for a LIS to discover s= uch changes = [RFC5222] validation, the only way for a LIS to discover such chan= ges
was to periodically revalidate its entire database. Of c= ourse, this = is to periodically revalidate its entire database. Of course, thi= s
would not facilitate timely changes, is not coordinated w= ith the does= not facilitate timely changes, is not coordinated with the
actual change e= vent, and also adds significant load to the LoST actual change event, and also adds significant load to the LoS= T
server. Even if re-validation is contemplated, the serve= r has no ser= ver as well as the LIS. Even if re-validation is contemplated,
mechanism to = control, or even suggest the time period for the server has no mechanism to control, or even suggest the tim= e
revalidation period= for revalidation.
This extensio= n allows the client to provide a stable URI= that is This extension allows a LoST client to = provide a stable URI that the
retained by the server associated= with the location information used LoST server = may retain and may associate with the location
in the reques= t. In the event of a planned change, or any other information used in the request. In the event of a plann= ed change,
circumstance = where the location may become invalid, the server sends <= /td>
a notificatio= n to the URI informing it of a change. The= notification may become invalid, t= he server sends a notification to the URI to
contains the = date and time when the location may become invalid. inform the client of a cha= nge. The notification contains the date
Ideally, following such a notification, the LIS will prepare a new When a LIS receives such a notificatio= n, it may prepare a new record
record to be inserted in its active database, that becomes acti= ve at so that, at the precise planned event date and time, it may insert
the precise p= lanned event date and time, at which point = it would also the new record into in its active databas= e and delete the old record.
delete the ol= d record. However, the new record has to be valid, and As part of preparing the new record, the LIS may use the "as of" date
the LIS would like to validate it prior to the planned change event. component of this extension to perform a LoST validation of the new
If it requests validation before the planned event, the server<= /span> recor= d as of the effective date.
(without this extension) would inform the client that the locat= ion <= /td>
was invalid. This extension includes an optional "as of= " date and
time in the request that allows the LoST server to provide validation
as of the date and time specified,= as opposed to the "as of now"
implied in the current LoST proto= col. =
When it is not practical or advisable for the LIS to main= tain stable = The notification URI and "as of" date components of this extension=
URIs for all of its records= , periodic revalidation can be still used allow a LIS t= o be prepared for and smoothly transition to planned
to maintain t= he data in the LIS. However, the server should be able
to control the rate of such revalidation. For this purp= ose, a new periodic revalidation of each location. The= notification URI allows
TTL element is included in= the <findserviceResponse> which prov= ides a LIS t= o be alerted to planned changes, while the "as of" date allows
advice from t= he server to the LIS of when revalidation i= s suggested. = the LIS to verify the validity of locations before they become
=
There are quite= a few implementations of LoST. Experience with these There are quite a few implementations of LoST. Experi= ence with these
implementations= indicates that the RelaxNG schema is very difficult implementations indicates that the RelaxNG schema is ver= y difficult
to deal with,= because the tools t= hat the implementors use don't = to deal with, both because many commonly used development tools don't
support it, a= nd their staff is unfamiliar with it. Alternative = support it, and development staff is often unfamiliar with it.
schemas have = been circulated, which is undesirable, as t= hey may not = Informal alternative schemas have been circulated, which is
be in conform= ance to the RelaxNG schema in [RFC5222]. T= his document undesirable as they may not be in conformance with the RelaxNG schema
provides an X= ML schema that replaces the RelaxNG schema. It can be in [RFC5222]. This document provides an XML schema t= hat replaces the
used by any i= mplementation interchangeably with the RelaxNG schema. RelaxNG schema. It can be used by any implementation= interchangeably
=
2. Conventions us= ed in this document 2. Conventions use= d in this document
The key words "= MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "= SHALL NOT",
"SHOULD", "SHOU= LD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTI= ONAL" in this
document are to= be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
"Server" in thi= s document refers to the LoST server and "Client" is "Server" in this document refers to the LoST server and = "Client" is
the LoST client= , even when the server is performing an operation on the LoST client, even when the server is performing an o= peration on
the client. the client.
3. <plannedCha= nge> element 3. <plannedChange&g= t; element
This document= defines a new element to <findService&g= t; called This document defines a n= ew element in the <findService> request
"plannedChang= e". This element contains two attributes: 'uri' and called "plannedChange". This element contains two optional
'asOf'. The 'uri' attribute MUST be a URI with a scheme= of HTTPS. attributes: 'uri' and 'a= sOf'. When present, the 'uri' attribute MU= ST
The URI will be stored by the server against the location in the = be a URI with a scheme of HTTPS. If the= server supports this
request for subsequent use with the notification function= defined ext= ension, it may store the URI and may associate it with the
below. To mi= nimize storage requirements of at the serve= r, the length location in the request. The server uses the URI with the
of the URI MU= ST be 256 bytes or l= ess. Each client of the server may notification function defined below. To minimize storage
only store on= e URI against a location, where "location" is defined by
policy at the= server, since a given unique location may have many bytes. Each client of th= e server may only store one URI against a
combinations = of location elements that resolve to the same location.
If the server= receives a 'uri' for the same location from the same a given unique location may have many combinations of = location
client, the U= RI in the request replaces the URI it previously elements that resolve to the same location. If the server re= ceives a
retained. Po= licy at the server may limit how many URIs it retains 'uri' for the same location from the same client, the = URI in the
for a given l= ocation. A new warning is defined below to be use= d to request replaces the UR= I it previously retained. Policy at the
indicate that= the URI has not been stored. If the location in the server may limit how many URIs it retains for a given = location. A
request is in= valid, the URI will not be stored and the warning will new warning is defined below to indi= cate that the URI has not been
be returned. store= d. If the location in the request is invalid, the URI is not
The 'asOf' at= tribute contains a date and time. The server will= The 'asOf' attribute contai= ns a date and time. The server validates
validate the location in the request as of the date spec= ified, taking the location in the r= equest as of the date and time specified, t= aking
into account = planned changes. This allows the client to= verify that into account planned c= hanges. This allows a client to verify tha= t it
it can make c= hanges in the LIS commensurate with changes in the LoST
server by valid= ating locations in advance of a change. server by validating locations in advance of a change.
4. <locationIn= validated> object 4. <locationIn= validated> object
When the server needs to invalidate a location where the client = When a server needs to invalidate a loca= tion that has one or more
provided a URI in <plannedChan= ge>, the server executes an HTTPS POST associated client-supplied URIs (provi= ded in a <plannedChange>
containing <locationInvalidated>, with a Content-Ty= pe of elemen= t), it transmits an HTTPS POST with a Content-Type of
'application/= xml' to the URI previously provided. This = is the notice 'application/xml' containing a <locationInvalidated> object to each
from the serv= er to the client that the location may be invalid and associated URI. This is= the notice from the server to the client
should be rev= alidated. <locationInvalidated> contains an that the location may be invalid and should be revalidated= =2E The
'invalidAsOf'= attribute that specifies when the location= may become <locationInvalidated= > object contains an 'invalidAsOf' attribute,
invalid. If = the date/time in 'invalidAsOf' is earlier t= han the time which specifies a date and time when the location may become invalid.
the <locationInvalidated> was sent, the location m= ay already be If this is earlier than the current time,= the location may already be
invalid and the= LIS should take immediate action. If the POST invalid and the LIS should take immediate action. If the POST=
operation fails= , the server MAY retry the operation immediately, and operation fails, the server MAY retry the operation imm= ediately, and
if it fails a= gain, retry the operation at a later time.<= /td> if it fails again, retry the operat= ion later. Retry timing and
The LoST server= is NOT REQUIRED to store the Location Information The LoST server is NOT REQUIRED to store the Location Info= rmation
supplied in the= original findService request. This means the server supplied in the original findService request. This mea= ns the server
may not know if= a planned change will in fact invalidate the location may not know if a planned change will in fact invalida= te the location
stored in the L= oST client, because changes could be made in the LoST stored in the LoST client, because changes could be mad= e in the LoST
server that d= o not affect validation of the Location Information. server that do not affect validation of the client's specific
The LoST clie= nt may find that upon revalidation with the changed Location Information. The LoST client may find that upo= n
server state,= the validation data is the same as it was before the revalidation with the changed server state, the valida= tion data is
notification = was received. the same as it was be= fore the notification was received.
5. URI Not Stored= Warning 5. URI Not Stored Warning
A new warning is added to t= he exceptionContainer, 'uriNotStored'. This extension adds a new warning to th= e exceptionContainer,
This warning = MUST NOT be returned unless the <plannedChange> element 'uriNotStored'. This warning MUST NOT be retu= rned unless the request
was found in the corresponding request. The warning is r= eturned when = contains a <plannedChange> element w= ith a 'uri' attribute. The
the server de= cides not to store the URI found in the <planne= dChange> warning is retur= ned when the server decides not to store the URI.<= /span> As
element. As discussed above, this may occur because, am= ong other discussed above, this may= occur because, among other reasons, the
reasons, the = policy at the server limits how many URIs will be stored
against a spe= cific location, the URI is not well formed or the policy
at the server= has some other restriction on the feature. server has some other restriction on the feature.
6. Time-To-Live (= TTL) in Response 6. Time-To-Live (TTL)= in Response
A new <ttl> element is added= to the <findserviceResponse>.= The <ttl> This extension adds the <ttl> element to the <findServiceResponse>.
element conta= ins a date and time after which the client may wish to The <ttl> element contains a date and time afte= r which the client may
revalidate th= e location at the server. This element MAY= be added by wish to revalidate the location at the server. A server MAY add this
the server if validation is reque= sted in the response. The form of element to the response if validation is requested. This element<= /td>
the element is the 'expires' attribute pattern, which allows explicit= takes the form of the 'expires' attribute pattern of [= RFC5222], which
'NO CACHE' and 'NO EXPIRATION' va= lues to be returned in the <ttl&g= t; allows th= e values 'NO CACHE' or 'NO EXPIRATIO= N' to be returned
element. 'NO CACHE' has no meaning and MUST NOT be returned in TTL. instead of a dateTime value. However, for<= /span> the <ttl> element 'NO
'NO EXPIRATIO= N' means the server does not have any sugge= sted CACHE' has no meaning and MUST= NOT be returned. 'NO EXPIRATION'
revalidation = period. means the server does not h= ave a suggested revalidation period.
Selecting a rev= alidation interval is a complex balancing of Selecting a revalidation interval is a complex balancing of
timeliness, ser= ver load, stability of the underlying data, and policy timeliness, server load, stability of the underlying d= ata, and policy
of the LoST ser= ver. Too short, and load on the server may overwhelm of the LoST server. Too short, and load on the server = may overwhelm
it. Too long= and invalid data may persist in the server for to= o it. Too long and invalid = data may persist in the server for
long. The URI mechanism provides timely notice to coord= inate unacce= ptable lengths of time. The URI notificati= on mechanism
changes, but = even with it, it is often advisable to revalidate data provides timely notice to coordinate changes, but eve= n with it, it is
eventually. often advisable to revalidate data e= ventually.
In areas that h= ave little change in data, such as fully built out, In areas that have little change in data, such as fully b= uilt out,
stable communit= ies already part of a municipality, it may be stable communities already part of a municipality, it may be
reasonable to s= et revalidation periods of 6 months or longer, reasonable to set revalidation periods of 6 months or longer,<= /td>
especially if t= he URI mechanism is widely deployed at both the server especially if the URI mechanism is widely deployed at = both the server
and the clients= =2E In areas that are quickly growing, 20-30 day and the clients. In areas that are quickly growing, 20-30 = day
revalidation ma= y be more appropriate even though such revalidation revalidation may be more appropriate even though such rev= alidation
would be the ma= jority of the traffic on the LoST server. would be the majority of the traffic on the LoST server.
When a planned = change is made, typically the TTL value for the When a planned change is made, typically the TTL value for the=
skipping to= change at page 15, line 30 skipping to chang= e at page 16, line 20
<!-- Impor= t base Lost --> <!-- Import = base Lost -->
<xs:import= namespace=3D"urn:ietf:params:xml:ns:lost1"/> <xs:import namespace=3D"urn:ietf:params:xml:ns:lost1"/>= ;
<!-- extend the= extensionPoint of commonRequestPattern of findService <!-- extend the extensionPoint of commonRequestPattern= of findService
= to include: -->
xs:group r= ef=3D"plannedChange" minOccurs=3D"1"/> xs:group ref=3D"plannedChange" minOccurs=3D"1"/>
<!-- where --&g= t; <!-- where -->
<xs:grou= p name=3D"plannedChange"> <= ;xs:group name=3D"plannedChange">
<xs:= sequence> <xs:sequence= >
<= xs:element ref=3D"uri" type=3D"xs:anyURI" /> <xs:element ref=3D"uri" type=3D"xs:anyURI" />=
&l= t;xs:element ref=3D=E2=80=9CinvalidAsOf" ty= pe=3D"xs:dateTime" /> = <xs:element ref=3D"invalidAsOf" type=3D= "xs:dateTime" />
<= xs:any namespace=3D"##other" processContents=3D"lax" <xs:any namespace=3D"##other" processConte= nts=3D"lax"
m= inOccurs=3D"0" maxOccurs=3D"unbounded"/> minOccurs=3D"0" maxOccurs=3D"unbounded"/>
</xs= :sequence> </xs:sequen= ce>
</xs:gr= oup> </xs:group>
<!-- extend the= extensionPoint of commonResponsePattern in <!-- extend the extensionPoint of commonResponsePattern in
= findServiceResponse to include: --> findServiceResponse to include: --><= /td>
<xs:= atttribute name=3D"asOf" type=3D"xs:dateTime" minOccurs=3D"0"/> <xs:atttribute name=3D"asOf" ty= pe=3D"xs:dateTime" minOccurs=3D"0"/>
<xs:= element ref=3D"ttl" type=3D"expires" minOccurs=3D"0" /> <xs:element ref=3D"ttl" type=3D"expires= " minOccurs=3D"0" />
skipping to= change at page 16, line 4 skipping to change= at page 16, line 37= ¶
= findServiceResponse to include: --> findServiceResponse to include: --><= /td>
<xs:= atttribute name=3D"asOf" type=3D"xs:dateTime" minOccurs=3D"0"/> <xs:atttribute name=3D"asOf" ty= pe=3D"xs:dateTime" minOccurs=3D"0"/>
<xs:= element ref=3D"ttl" type=3D"expires" minOccurs=3D"0" /> <xs:element ref=3D"ttl" type=3D"expires= " minOccurs=3D"0" />
<!-- extend the= extensionPoint of extensionContainer to include: -->
<xs:= element ref=3D"uriNotStored"/> = <xs:element ref=3D"uriNotStored"/><= /td>
<!-- where --&g= t; <!-- where -->
<xs:= element name=3D"uriNotStored" type=3D"basicException"/> <xs:element name=3D"uriNotStored" type=3D= "basicException"/>
</xs:schema>= </xs:schema>
9. locationInvali= dated Schema 9. locationInvalidated Sc= hema
This schema d= efines the object used for the notification of This schema defines the object = used for the notification that a
(potential) invalidated location by the LoST server to a client that location is potentially invalidated sent by a LoST server to a client
requested it.= that requested it.
<?xml versio= n=3D"1.0" encoding=3D"UTF-8"?> &l= t;?xml version=3D"1.0" encoding=3D"UTF-8"?><= /td>
<xs:schema x= mlns:xs=3D"http://www.w3.org/2001/XMLSchema" <xs:schema xmlns:xs=3D"http://www.w3.org/2001/XMLSchema"
xmlns=3D"ur= n:ietf:params:xml:ns:lostLocationInvalidated1" xmlns=3D"urn:ietf:params:xml:ns:lostLocationInvalidated1"<= /td>
targetNames= pace=3D"urn:ietf:params:xml:ns:lostLocationInvalidated1"
elementForm= Default=3D"qualified"> elemen= tFormDefault=3D"qualified">
<xs:element= name=3D"locationInvalidated"> &= lt;xs:element name=3D"locationInvalidated"><= /td>
<xs:annot= ation> <xs:annotation>
<xs:doc= umentation> <xs:documenta= tion>
A point = where future extensions A poi= nt where future extensions
skipping to= change at page 16, line 42 skipping to chang= e at page 17, line 37
10. Security Cons= iderations 10. Security Considerations=
As an extension= to LoST, this document inherits the security issues As an extension to LoST, this document inherits the secu= rity issues
raised in [RFC5= 222]. The server could be tricked into storing a raised in [RFC5222]. The server could be tricked into stor= ing a
malicious URI w= hich, when sent the locationInvalidated object could malicious URI which, when sent the locationInvalidated o= bject could
trigger somethi= ng untoward. The server MUST NOT accept any data from trigger something untoward. The server MUST NOT accep= t any data from
the client in r= esponse to POSTing the locationInvalidated. the client in response to POSTing the locationInvalidated.
The server is s= ubject to abuse by clients because it is being asked The server is subject to abuse by clients because it is = being asked
to store someth= ing and may need to send data to an uncontrolled URI. to store something and may need to send data to an unco= ntrolled URI.
Clients could= request many URIs for the same location for example. Clients could request many URIs for the same location<= span class=3D"insert">, for example.
The server MUST= have policy that limits use of this mechanism by a The server MUST have policy that limits use of this mecha= nism by a
given client. = If the policy is exceeded, the server returns the given client. If the policy is exceeded, the server return= s the
'uriNotStored' = warning. The server MUST validate that the content of 'uriNotStored' warning. The server MUST validate that= the content of
the 'uri' attri= bute sent is syntactically valid and meets the 256 the 'uri' attribute sent is syntactically valid and meets = the 256
bytes limit. W= hen sending the locationInvalidated object to the URI bytes limit. When sending the locationInvalidated obje= ct to the URI
stored, the ser= ver MUST protect itself against common HTTP stored, the server MUST protect itself against common HTTP
vulnerabilities= =2E vulnerabilities.
The mutual auth= entication between client and server is RECOMMENDED The mutual authentication between client and server is RE= COMMENDED
for both the in= itial <findService> operation that requests storing
the URI and the= sending of the 'locationInvalidated' object. The the URI and the sending of the 'locationInvalidated' objec= t. The
server should b= e well known to the client, and its credential should server should be well known to the client, and its cred= ential should
be learned in a= reliable way. For example, a public safety system be learned in a reliable way. For example, a public safe= ty system
operating the L= oST server may have a credential traceable to a well operating the LoST server may have a credential traceabl= e to a well
known Certifica= te Authority known to provide credentials for public known Certificate Authority known to provide credentials= for public
safety agenci= es. Many of the clients will be operated b= y local ISPs safety agencies. Clients may be operated by local ISPs or other<= /td>
or other serv= ice providers where the server operator can= reasonably service providers that can reasonably obtain a good credential to = use
obtain a good= credential to use for the URI. Where the server does for the server side of the LoS= T server's POST transaction using the
not recognize= the client, its policy MAY limit the use of this URI. Where the loST server = does not recognize the client, its policy
feature beyon= d what it would limit a client it recognized. MAY limit the use of this featur= e beyond what it would limit a client
11. IANA Consider= ations 11. IANA Considerations
11.1. Replacement= XML Schema Registration 11.1. Replace= ment XML Schema Registration
URI: urn:ie= tf:params:xml:schema:lost3 URI: = urn:ietf:params:xml:schema:lost3
Registrant C= ontact: IETF ECRIT Working Group, Brian Rosen Registrant Contact: IETF ECRIT Working Group, Brian Rosen<= /td>
(br@brian= rosen.net). (br@brianrosen.net= ).
XML: XML:
BEGIN BEGIN
skipping to= change at page 19, line 34 skipping to chang= e at page 20, line 34
</body> </body>
</html> </html>
END END
The XML Schema = is found in Section 9. The XML Schem= a is found in Section 9.
12. Normative Ref= erences 12. Normative References
[RFC2119] Brad= ner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=
Requ= irement Levels", BCP 14, RFC 2119, = Requirement Levels", BCP 14, RFC 2119,
DO= I 10.17487/RFC2119, March 1997, = DOI 10.17487/RFC2119, March 1997, <http= s://www.rfc-
<https://www.rfc-editor.org/info/rfc2119>. = editor.org/info/rfc2119>.
[RFC5222] Hard= ie, T., Newton, A., Schulzrinne, H., and H. [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tsch= ofenig, "LoST: A Location-to-Service Translation Tschofenig, "LoST: A Location-to-Service Translatio= n
Prot= ocol", RFC 5222, DOI 10.17487/RFC5222, August 2008, Protocol", RFC 5222, DOI 10.17487/RFC5222, Aug= ust 2008,
<= https://www.rfc-editor.org/info/rfc5222>. <https://www.rfc-editor.org/info/rfc5222>.
Author's Address Author's Address
Brian Rosen Brian Rosen
470 Conrad Dr 470 Conrad Dr
Mars, PA 1604= 6 Mars, PA 16046
United States of America US
Email: br@brianrosen.net EMail: br@brianrosen.net
<= /td>
&= nbsp;End of changes. 32 change blocks. 
158 lines changed or deleted= 190 lines changed or added

This htm= l diff was produced by rfcdiff 1.48. The latest version is available from= http://tools.ietf.= org/tools/rfcdiff/
--=_MailMate_377DAA09-F515-441D-9F06-024008E3CEEA_= Content-Disposition: attachment; filename=draft-ietf-ecrit-lost-planned-changes-04-rg.txt Content-Type: text/plain Content-Transfer-Encoding: quoted-printable ecrit B. Rosen Internet-Draft August 23, 2021 Updates: RFC5222 (if approved) Intended status: Standards Track Expires: February 24, 2022 Validation of Locations Around a Planned Change draft-ietf-ecrit-lost-planned-changes-04 Abstract This document defines an extension to the Location to Service Translation (LoST) protocol (RFC5222) that allows a LoST server to notify a client of planned changes to the data. This extension is only useful with the validation function of LoST. It is beneficial for LoST validation clients to be aware of planned changes, as records that previously were valid may become invalid at a known future date, and new locations may become valid after the date. This extension adds two elements to the request: A URI that the LoST server can use to inform the LoST client (e.g., a Location Information Server [LIS]) that previously valid locations will be invalid after a planned change date, and a date that allows the LoST client to request that the server perform validation as of the date specified. It also adds an optional Time-To-Live element to the response, which informs clients of the current expected lifetime of a validation. This document also provides a conventional XML schema for LoST, as a backwards compatible alternative to the RelaxNG schema in RFC5222 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 24, 2022. Rosen Expires February 24, 2022 [Page 1] =0C Internet-Draft LoST Planned Changes August 2021 Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. element . . . . . . . . . . . . . . . . . . . 4 4. object . . . . . . . . . . . . . . . . 5 5. URI Not Stored Warning . . . . . . . . . . . . . . . . . . . 6 6. Time-To-Live (TTL) in Response . . . . . . . . . . . . . . . 6 7. Replacement XML schema . . . . . . . . . . . . . . . . . . . 7 8. Extension XML Schema . . . . . . . . . . . . . . . . . . . . 15 9. locationInvalidated Schema . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11.1. Replacement XML Schema Registration . . . . . . . . . . 18 11.2. Planned Change Extension XML Schema Registration . . . . 18 11.3. locationInvalidated XML Schema Registration . . . . . . 19 12. Normative References . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction This document describes an extension to the Location to Service Translation (LoST) protocol [RFC5222] to assist with planned changes to the underlying location information in the server. The extension allows a request to optionally contain a URI, and optionally a date. This extension is useful in the context of the validation function of LoST. It is beneficial for LoST validation clients to be aware of planned changes, as records that previously were valid may become invalid at a known future date, and new locations may become valid after the date. If specified, the URI may be retained by the LoST server and may be associated with the data record that was validated, and used to notify the the LoST client (e.g., a Location Information Server [LIS]) when a location which was Rosen Expires February 24, 2022 [Page 2] =0C Internet-Draft LoST Planned Changes August 2021 previously valid will become invalid. The date may be used by a client to ask a server to perform validation as of a future date. In addition to this mechanism, the is also extended to provide a Time-To-Live (TTL) for validation, after which the client should revalidate the location. Validation of civic locations involves dealing with data that may change over time. A typical example is when a portion of a county or province that was not part of a municipality is "annexed" to a municipality. Prior to the change, a Presence Information Data Format Location Object (PIDF-LO) specifying a civic location in the affected area would have a blank A3 element, or would contain some other value; after the change, a PIDF-LO specifying the same location would contain an A3 element set to the name of the municipality that annexed that part of the county/province. This kind of annexation has an effective date and time (typically 00:00 on the first or last day of a month), known in advance. Other kinds of changes may also occur, and these will almost always also have an effective date that is known in advance. Records in a LIS must change around these kinds of events. The old record must be discarded, and a new, validated record must be loaded into the LIS. It is often difficult for the LIS operator to know that records must be changed around such events. There are other circumstances where locations that were previously valid become invalid, such as a street renaming or renumbering event. Using [RFC5222] validation, the only way for a LIS to discover such changes is to periodically revalidate its entire database. Of course, this does not facilitate timely changes, is not coordinated with the actual change event, and also adds significant load to the LoST server as well as the LIS. Even if re-validation is contemplated, the server has no mechanism to control, or even suggest the time period for revalidation. This extension allows a LoST client to provide a stable URI that the LoST server may retain and may associate with the location information used in the request. In the event of a planned change, or any other circumstance where the location in the original request may become invalid, the server sends a notification to the URI to inform the client of a change. The notification contains the date and time when the location may become invalid. When a LIS receives such a notification, it may prepare a new record so that, at the precise planned event date and time, it may insert the new record into in its active database and delete the old record. As part of preparing the new record, the LIS may use the "as of" date component of this extension to perform a LoST validation of the new record as of the effective date. Rosen Expires February 24, 2022 [Page 3] =0C Internet-Draft LoST Planned Changes August 2021 The notification URI and "as of" date components of this extension allow a LIS to be prepared for and smoothly transition to planned changes, without the overhead and delay inherent in performing periodic revalidation of each location. The notification URI allows a LIS to be alerted to planned changes, while the "as of" date allows the LIS to verify the validity of locations before they become active. In situations where it is not practical or advisable for the LIS to maintain a stable URI for each of its records, periodic revalidation can still be used to maintain the data in the LIS. However, the LoST server should be able to influence the rate of such revalidation. For this purpose, this extension adds a Time to Live (TTL) element to the which provides advice from the server to the LIS of when validation is suggested. There are quite a few implementations of LoST. Experience with these implementations indicates that the RelaxNG schema is very difficult to deal with, both because many commonly used development tools don't support it, and development staff is often unfamiliar with it. Informal alternative schemas have been circulated, which is undesirable as they may not be in conformance with the RelaxNG schema in [RFC5222]. This document provides an XML schema that replaces the RelaxNG schema. It can be used by any implementation interchangeably with the RelaxNG schema. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. "Server" in this document refers to the LoST server and "Client" is the LoST client, even when the server is performing an operation on the client. 3. element This document defines a new element in the request called "plannedChange". This element contains two optional attributes: 'uri' and 'asOf'. When present, the 'uri' attribute MUST be a URI with a scheme of HTTPS. If the server supports this extension, it may store the URI and may associate it with the location in the request. The server uses the URI with the notification function defined below. To minimize storage requirements at the server, the length of the URI MUST not exceed 256 bytes. Each client of the server may only store one URI against a location, where "location" is defined by policy at the server, since Rosen Expires February 24, 2022 [Page 4] =0C Internet-Draft LoST Planned Changes August 2021 a given unique location may have many combinations of location elements that resolve to the same location. If the server receives a 'uri' for the same location from the same client, the URI in the request replaces the URI it previously retained. Policy at the server may limit how many URIs it retains for a given location. A new warning is defined below to indicate that the URI has not been stored. If the location in the request is invalid, the URI is not stored and the warning is returned. The 'asOf' attribute contains a date and time. The server validates the location in the request as of the date and time specified, taking into account planned changes. This allows a client to verify that it can make changes in the LIS commensurate with changes in the LoST server by validating locations in advance of a change. 4. object When a server needs to invalidate a location that has one or more associated client-supplied URIs (provided in a element), it transmits an HTTPS POST with a Content-Type of 'application/xml' containing a object to each associated URI. This is the notice from the server to the client that the location may be invalid and should be revalidated. The object contains an 'invalidAsOf' attribute, which specifies a date and time when the location may become invalid. If this is earlier than the current time, the location may already be invalid and the LIS should take immediate action. If the POST operation fails, the server MAY retry the operation immediately, and if it fails again, retry the operation later. Retry timing and duration or number of attempts is determined by the server. The LoST server is NOT REQUIRED to store the Location Information supplied in the original findService request. This means the server may not know if a planned change will in fact invalidate the location stored in the LoST client, because changes could be made in the LoST server that do not affect validation of the client's specific Location Information. The LoST client may find that upon revalidation with the changed server state, the validation data is the same as it was before the notification was received. The object does not contain information about the location, as the URI to which it is sent is determined by the requesting client and can be unique for each of the client's location records. Rosen Expires February 24, 2022 [Page 5] =0C Internet-Draft LoST Planned Changes August 2021 5. URI Not Stored Warning This extension adds a new warning to the exceptionContainer, 'uriNotStored'. This warning MUST NOT be returned unless the request contains a element with a 'uri' attribute. The warning is returned when the server decides not to store the URI. As discussed above, this may occur because, among other reasons, the policy at the server limits how many URIs will be stored against a specific location, the URI is not well formed or the policy at the server has some other restriction on the feature. 6. Time-To-Live (TTL) in Response This extension adds the element to the . The element contains a date and time after which the client may wish to revalidate the location at the server. A server MAY add this element to the response if validation is requested. This element takes the form of the 'expires' attribute pattern of [RFC5222], which allows the values 'NO CACHE' or 'NO EXPIRATION' to be returned instead of a dateTime value. However, for the element 'NO CACHE' has no meaning and MUST NOT be returned. 'NO EXPIRATION' means the server does not have a suggested revalidation period. Selecting a revalidation interval is a complex balancing of timeliness, server load, stability of the underlying data, and policy of the LoST server. Too short, and load on the server may overwhelm it. Too long and invalid data may persist in the server for unacceptable lengths of time. The URI notification mechanism provides timely notice to coordinate changes, but even with it, it is often advisable to revalidate data eventually. In areas that have little change in data, such as fully built out, stable communities already part of a municipality, it may be reasonable to set revalidation periods of 6 months or longer, especially if the URI mechanism is widely deployed at both the server and the clients. In areas that are quickly growing, 20-30 day revalidation may be more appropriate even though such revalidation would be the majority of the traffic on the LoST server. When a planned change is made, typically the TTL value for the affected records is lowered, so that revalidation is forced soon after the change is implemented. It is not advisable to set the expiration precisely at the planned change time if a large number of records will be changed, since that would cause a large spike in traffic at the change time. Rather, the expiration time should have a random additional time added to it to spread out the load. Rosen Expires February 24, 2022 [Page 6] =0C Internet-Draft LoST Planned Changes August 2021 7. Replacement XML schema This schema is an informative alternative to The Relax NG schema in [RFC5222] Rosen Expires February 24, 2022 [Page 7] =0C Internet-Draft LoST Planned Changes August 2021 Rosen Expires February 24, 2022 [Page 8] =0C Internet-Draft LoST Planned Changes August 2021 = Rosen Expires February 24, 2022 [Page 9] =0C Internet-Draft LoST Planned Changes August 2021 Rosen Expires February 24, 2022 [Page 10] =0C Internet-Draft LoST Planned Changes August 2021 Rosen Expires February 24, 2022 [Page 11] =0C Internet-Draft LoST Planned Changes August 2021 Rosen Expires February 24, 2022 [Page 12] =0C Internet-Draft LoST Planned Changes August 2021 Exception pattern. type=3D"basicException"/> Rosen Expires February 24, 2022 [Page 13] =0C Internet-Draft LoST Planned Changes August 2021 Any element not in the LoST namespace. A wildcard pattern for including any element from any other namespace. Rosen Expires February 24, 2022 [Page 14] =0C Internet-Draft LoST Planned Changes August 2021 A wildcard pattern for including any element from any other namespace. A point where future extensions (elements from other namespaces) can be added. 8. Extension XML Schema This schema provides the extension to the prior section schema for planned changes: Rosen Expires February 24, 2022 [Page 15] =0C Internet-Draft LoST Planned Changes August 2021 xs:group ref=3D"plannedChange" minOccurs=3D"1"/> 9. locationInvalidated Schema This schema defines the object used for the notification that a location is potentially invalidated sent by a LoST server to a client that requested it. Rosen Expires February 24, 2022 [Page 16] =0C Internet-Draft LoST Planned Changes August 2021 A point where future extensions (elements from other namespaces) can be added. 10. Security Considerations As an extension to LoST, this document inherits the security issues raised in [RFC5222]. The server could be tricked into storing a malicious URI which, when sent the locationInvalidated object could trigger something untoward. The server MUST NOT accept any data from the client in response to POSTing the locationInvalidated. The server is subject to abuse by clients because it is being asked to store something and may need to send data to an uncontrolled URI. Clients could request many URIs for the same location, for example. The server MUST have policy that limits use of this mechanism by a given client. If the policy is exceeded, the server returns the 'uriNotStored' warning. The server MUST validate that the content of the 'uri' attribute sent is syntactically valid and meets the 256 bytes limit. When sending the locationInvalidated object to the URI stored, the server MUST protect itself against common HTTP vulnerabilities. The mutual authentication between client and server is RECOMMENDED for both the initial operation that requests storing the URI and the sending of the 'locationInvalidated' object. The server should be well known to the client, and its credential should be learned in a reliable way. For example, a public safety system operating the LoST server may have a credential traceable to a well known Certificate Authority known to provide credentials for public Rosen Expires February 24, 2022 [Page 17] =0C Internet-Draft LoST Planned Changes August 2021 safety agencies. Clients may be operated by local ISPs or other service providers that can reasonably obtain a good credential to use for the server side of the LoST server's POST transaction using the URI. Where the loST server does not recognize the client, its policy MAY limit the use of this feature beyond what it would limit a client it recognizes. 11. IANA Considerations 11.1. Replacement XML Schema Registration URI: urn:ietf:params:xml:schema:lost3 Registrant Contact: IETF ECRIT Working Group, Brian Rosen (br@brianrosen.net). XML: BEGIN LoST Namespace

Namespace for LoST

urn:ietf:params:xml:ns:lost3

See RFC????.

END The XML Schema is found in Section 7. 11.2. Planned Change Extension XML Schema Registration Rosen Expires February 24, 2022 [Page 18] =0C Internet-Draft LoST Planned Changes August 2021 URI: urn:ietf:params:xml:schema:lostPlannedChange1 Registrant Contact: IETF ECRIT Working Group, Brian Rosen (br@brianrosen.net). XML: BEGIN LoST Planned Change Namespace

Namespace for LoST

urn:ietf:params:xml:ns:lostPlannedChange1

See RFC????.

END The XML Schema is found in Section 8. 11.3. locationInvalidated XML Schema Registration Rosen Expires February 24, 2022 [Page 19] =0C Internet-Draft LoST Planned Changes August 2021 URI: urn:ietf:params:xml:schema:lostLocationInvalidated1 Registrant Contact: IETF ECRIT Working Group, Brian Rosen (br@brianrosen.net). XML: BEGIN LoST Location Invalided Namespace

Namespace for LoST Location Invalidated notification

urn:ietf:params:xml:ns:lostLocationInvalidated1

See RFC????.

END The XML Schema is found in Section 9. 12. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008, . Author's Address Brian Rosen 470 Conrad Dr Mars, PA 16046 US EMail: br@brianrosen.net Rosen Expires February 24, 2022 [Page 20] --=_MailMate_377DAA09-F515-441D-9F06-024008E3CEEA_= Content-Disposition: attachment; filename=draft-ietf-ecrit-lost-planned-changes-04-rg.xml Content-Type: application/xml Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIj8+Cjw/eG1sLXN0eWxlc2hlZXQgdHlwZT0idGV4dC94c2wiIGhy ZWY9InJmYzI2MjkueHNsdCI/Pgo8IURPQ1RZUEUgcmZjIFNZU1RFTSAicmZjMjYyOS5kdGQiIFsK PCFFTlRJVFkgUkZDMjExOSBQVUJMSUMgIiIgImh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1Ymxp Yy9yZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMuMjExOS54bWwiPgo8IUVOVElUWSBSRkM1MjIyIFBV QkxJQyAiIiAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJl bmNlLlJGQy41MjIyLnhtbCI+Cl0+Cgo8P3JmYyByZmNlZHN0eWxlPSJ5ZXMiPz4KPD9yZmMgc3lt cmVmcz0ieWVzIj8+Cjw/cmZjIHNvcnRyZWZzPSJubyI/Pgo8P3JmYyBpcHJub3RpZmllZD0ieWVz Ij8+Cjw/cmZjIHN0cmljdD0ieWVzIj8+Cjw/cmZjIHRvYz0ieWVzIj8+Cjw/cmZjIHRvY2luZGVu dD0ieWVzIj8+Cgo8cmZjIGNhdGVnb3J5PSJzdGQiIGlwcj0idHJ1c3QyMDA5MDIiIHVwZGF0ZXM9 IlJGQzUyMjIiIGRvY05hbWU9ImRyYWZ0LWlldGYtZWNyaXQtbG9zdC1wbGFubmVkLWNoYW5nZXMt MDQiPgogIDxmcm9udD4KICAgIDx0aXRsZSBhYmJyZXY9IkxvU1QgUGxhbm5lZCBDaGFuZ2VzIj4K ICAgICAgVmFsaWRhdGlvbiBvZiBMb2NhdGlvbnMgQXJvdW5kIGEgUGxhbm5lZCBDaGFuZ2UKICAg IDwvdGl0bGU+CgogICAgPGF1dGhvciBpbml0aWFscz0iQi4iIHN1cm5hbWU9IlJvc2VuIiBmdWxs bmFtZT0iQnJpYW4gUm9zZW4iPgogICAgICAgPGFkZHJlc3M+CiAgICAgICAgPHBvc3RhbD4KICAg ICAgICAgIDxzdHJlZXQ+NDcwIENvbnJhZCBEcjwvc3RyZWV0PgogICAgICAgICAgPGNpdHk+TWFy czwvY2l0eT4KICAgICAgICAgIDxyZWdpb24+UEE8L3JlZ2lvbj4KICAgICAgICAgIDxjb2RlPjE2 MDQ2PC9jb2RlPgogICAgICAgICAgPGNvdW50cnk+VVM8L2NvdW50cnk+CiAgICAgICAgPC9wb3N0 YWw+CiAgICAgICAgPGVtYWlsPmJyQGJyaWFucm9zZW4ubmV0PC9lbWFpbD4KICAgICAgPC9hZGRy ZXNzPgogICAgPC9hdXRob3I+CgoKICAgIDxkYXRlIHllYXI9IjIwMjEiLz4KICAgIDxhcmVhPkFS VDwvYXJlYT4KICAgIDx3b3JrZ3JvdXA+w6ljcml0PC93b3JrZ3JvdXA+CiAgICA8a2V5d29yZD5J bnRlcm5ldC1EcmFmdDwva2V5d29yZD4KIAogICAgPGFic3RyYWN0PgogICAgICA8dD5UaGlzIGRv Y3VtZW50IGRlZmluZXMgYW4gZXh0ZW5zaW9uIHRvIHRoZSBMb2NhdGlvbiB0byBTZXJ2aWNlIFRy YW5zbGF0aW9uIChMb1NUKSBwcm90b2NvbCAoUkZDNTIyMikgdGhhdCBhbGxvd3MgYSBMb1NUIHNl cnZlciB0byBub3RpZnkgYSBjbGllbnQgb2YgcGxhbm5lZCBjaGFuZ2VzIHRvIHRoZSBkYXRhLiAg VGhpcyBleHRlbnNpb24gaXMgb25seSB1c2VmdWwgd2l0aCB0aGUgdmFsaWRhdGlvbiBmdW5jdGlv biBvZiBMb1NULiAgSXQgaXMgYmVuZWZpY2lhbCBmb3IgTG9TVCB2YWxpZGF0aW9uIGNsaWVudHMg dG8gYmUgYXdhcmUgb2YgcGxhbm5lZCBjaGFuZ2VzLCBhcyByZWNvcmRzIHRoYXQgcHJldmlvdXNs eSB3ZXJlIHZhbGlkIG1heSBiZWNvbWUgaW52YWxpZCBhdCBhIGtub3duIGZ1dHVyZSBkYXRlLCBh bmQgbmV3IGxvY2F0aW9ucyBtYXkgYmVjb21lIHZhbGlkIGFmdGVyIHRoZSBkYXRlLiAgVGhpcyBl eHRlbnNpb24gYWRkcyB0d28gZWxlbWVudHMgdG8gdGhlICZsdDtmaW5kU2VydmljZSZndDsgcmVx dWVzdDogQSBVUkkgdGhhdCB0aGUgTG9TVCBzZXJ2ZXIgY2FuIHVzZSB0byBpbmZvcm0gdGhlIExv U1QgY2xpZW50IChlLmcuLCBhIExvY2F0aW9uIEluZm9ybWF0aW9uIFNlcnZlciBbTElTXSkgdGhh dCBwcmV2aW91c2x5IHZhbGlkIGxvY2F0aW9ucyB3aWxsIGJlIGludmFsaWQgYWZ0ZXIgYSBwbGFu bmVkIGNoYW5nZSBkYXRlLCBhbmQgYSBkYXRlIHRoYXQgYWxsb3dzIHRoZSBMb1NUIGNsaWVudCB0 byByZXF1ZXN0IHRoYXQgdGhlIHNlcnZlciBwZXJmb3JtIHZhbGlkYXRpb24gYXMgb2YgdGhlIGRh dGUgc3BlY2lmaWVkLiAgSXQgYWxzbyBhZGRzIGFuIG9wdGlvbmFsIFRpbWUtVG8tTGl2ZSBlbGVt ZW50IHRvIHRoZSByZXNwb25zZSwgd2hpY2ggaW5mb3JtcyBjbGllbnRzIG9mIHRoZSBjdXJyZW50 IGV4cGVjdGVkIGxpZmV0aW1lIG9mIGEgdmFsaWRhdGlvbi4gIFRoaXMgZG9jdW1lbnQgYWxzbyBw cm92aWRlcyBhIGNvbnZlbnRpb25hbCBYTUwgc2NoZW1hIGZvciBMb1NULCBhcyBhIGJhY2t3YXJk cyBjb21wYXRpYmxlIGFsdGVybmF0aXZlIHRvIHRoZSBSZWxheE5HIHNjaGVtYSBpbiBSRkM1MjIy CiAgICAgIDwvdD4KICAgIDwvYWJzdHJhY3Q+CiAgPC9mcm9udD4KCiAgPG1pZGRsZT4KICAgIDxz ZWN0aW9uIHRpdGxlPSJJbnRyb2R1Y3Rpb24iPgogICAgICA8dD5UaGlzIGRvY3VtZW50IGRlc2Ny aWJlcyBhbiBleHRlbnNpb24gdG8gdGhlIExvY2F0aW9uIHRvIFNlcnZpY2UgVHJhbnNsYXRpb24g KExvU1QpIHByb3RvY29sIDx4cmVmIHRhcmdldD0iUkZDNTIyMiIvPiB0byBhc3Npc3Qgd2l0aCBw bGFubmVkIGNoYW5nZXMgdG8gdGhlIHVuZGVybHlpbmcgbG9jYXRpb24gaW5mb3JtYXRpb24gaW4g dGhlIHNlcnZlci4gIFRoZSBleHRlbnNpb24gYWxsb3dzIGEgJmx0O2ZpbmRTZXJ2aWNlJmd0OyBy ZXF1ZXN0IHRvIG9wdGlvbmFsbHkgY29udGFpbiBhIFVSSSwgYW5kIG9wdGlvbmFsbHkgYSBkYXRl LiAgVGhpcyBleHRlbnNpb24gaXMgdXNlZnVsIGluIHRoZSBjb250ZXh0IG9mIHRoZSB2YWxpZGF0 aW9uIGZ1bmN0aW9uIG9mIExvU1QuICBJdCBpcyBiZW5lZmljaWFsIGZvciBMb1NUIHZhbGlkYXRp b24gY2xpZW50cyB0byBiZSBhd2FyZSBvZiBwbGFubmVkIGNoYW5nZXMsIGFzIHJlY29yZHMgdGhh dCBwcmV2aW91c2x5IHdlcmUgdmFsaWQgbWF5IGJlY29tZSBpbnZhbGlkIGF0IGEga25vd24gZnV0 dXJlIGRhdGUsIGFuZCBuZXcgbG9jYXRpb25zIG1heSBiZWNvbWUgdmFsaWQgYWZ0ZXIgdGhlIGRh dGUuICBJZiBzcGVjaWZpZWQsIHRoZSBVUkkgbWF5IGJlIHJldGFpbmVkIGJ5IHRoZSBMb1NUIHNl cnZlciBhbmQgbWF5IGJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgZGF0YSByZWNvcmQgdGhhdCB3YXMg dmFsaWRhdGVkLCBhbmQgdXNlZCB0byBub3RpZnkgdGhlIHRoZSBMb1NUIGNsaWVudCAoZS5nLiwg YSBMb2NhdGlvbiBJbmZvcm1hdGlvbiBTZXJ2ZXIgW0xJU10pIHdoZW4gYSBsb2NhdGlvbiB3aGlj aCB3YXMgcHJldmlvdXNseSB2YWxpZCB3aWxsIGJlY29tZSBpbnZhbGlkLiAgVGhlIGRhdGUgbWF5 IGJlIHVzZWQgYnkgYSBjbGllbnQgdG8gYXNrIGEgc2VydmVyIHRvIHBlcmZvcm0gdmFsaWRhdGlv biBhcyBvZiBhIGZ1dHVyZSBkYXRlLiBJbiBhZGRpdGlvbiB0byB0aGlzIG1lY2hhbmlzbSwgdGhl ICZsdDtmaW5kc2VydmljZVJlc3BvbnNlJmd0OyBpcyBhbHNvIGV4dGVuZGVkIHRvIHByb3ZpZGUg YSBUaW1lLVRvLUxpdmUgKFRUTCkgZm9yIHZhbGlkYXRpb24sIGFmdGVyIHdoaWNoIHRoZSBjbGll bnQgc2hvdWxkIHJldmFsaWRhdGUgdGhlIGxvY2F0aW9uLgogICAgICA8L3Q+CiAgICAgIDx0PlZh bGlkYXRpb24gb2YgY2l2aWMgbG9jYXRpb25zIGludm9sdmVzIGRlYWxpbmcgd2l0aCBkYXRhIHRo YXQgbWF5IGNoYW5nZSBvdmVyIHRpbWUuICBBIHR5cGljYWwgZXhhbXBsZSBpcyB3aGVuIGEgcG9y dGlvbiBvZiBhIGNvdW50eSBvciBwcm92aW5jZSB0aGF0IHdhcyBub3QgcGFydCBvZiBhIG11bmlj aXBhbGl0eSBpcyAiYW5uZXhlZCIgdG8gYSBtdW5pY2lwYWxpdHkuICBQcmlvciB0byB0aGUgY2hh bmdlLCBhIFByZXNlbmNlIEluZm9ybWF0aW9uIERhdGEgRm9ybWF0IExvY2F0aW9uIE9iamVjdCAo UElERi1MTykgc3BlY2lmeWluZyBhIGNpdmljIGxvY2F0aW9uIGluIHRoZSBhZmZlY3RlZCBhcmVh IHdvdWxkIGhhdmUgYSBibGFuayBBMyBlbGVtZW50LCBvciB3b3VsZCBjb250YWluIHNvbWUgb3Ro ZXIgdmFsdWU7IGFmdGVyIHRoZSBjaGFuZ2UsIGEgUElERi1MTyBzcGVjaWZ5aW5nIHRoZSBzYW1l IGxvY2F0aW9uIHdvdWxkIGNvbnRhaW4gYW4gQTMgZWxlbWVudCBzZXQgdG8gdGhlIG5hbWUgb2Yg dGhlIG11bmljaXBhbGl0eSB0aGF0IGFubmV4ZWQgdGhhdCBwYXJ0IG9mIHRoZSBjb3VudHkvcHJv dmluY2UuICBUaGlzIGtpbmQgb2YgYW5uZXhhdGlvbiBoYXMgYW4gZWZmZWN0aXZlIGRhdGUgYW5k IHRpbWUgKHR5cGljYWxseSAwMDowMCBvbiB0aGUgZmlyc3Qgb3IgbGFzdCBkYXkgb2YgYSBtb250 aCksIGtub3duIGluIGFkdmFuY2UuICBPdGhlciBraW5kcyBvZiBjaGFuZ2VzIG1heSBhbHNvIG9j Y3VyLCBhbmQgdGhlc2Ugd2lsbCBhbG1vc3QgYWx3YXlzIGFsc28gaGF2ZSBhbiBlZmZlY3RpdmUg ZGF0ZSB0aGF0IGlzIGtub3duIGluIGFkdmFuY2UuPC90PgoKPHQ+UmVjb3JkcyBpbiBhIExJUyBt dXN0IGNoYW5nZSBhcm91bmQgdGhlc2Uga2luZHMgb2YgZXZlbnRzLiAgVGhlIG9sZCByZWNvcmQg bXVzdCBiZSBkaXNjYXJkZWQsIGFuZCBhIG5ldywgdmFsaWRhdGVkIHJlY29yZCBtdXN0IGJlIGxv YWRlZCBpbnRvIHRoZSBMSVMuICBJdCBpcyBvZnRlbiBkaWZmaWN1bHQgZm9yIHRoZSBMSVMgb3Bl cmF0b3IgdG8ga25vdyB0aGF0IHJlY29yZHMgbXVzdCBiZSBjaGFuZ2VkIGFyb3VuZCBzdWNoIGV2 ZW50cy4gIFRoZXJlIGFyZSBvdGhlciBjaXJjdW1zdGFuY2VzIHdoZXJlIGxvY2F0aW9ucyB0aGF0 IHdlcmUgcHJldmlvdXNseSB2YWxpZCBiZWNvbWUgaW52YWxpZCwgc3VjaCBhcyBhIHN0cmVldCBy ZW5hbWluZyBvciByZW51bWJlcmluZyBldmVudC4gIFVzaW5nIDx4cmVmIHRhcmdldD0iUkZDNTIy MiIvPiB2YWxpZGF0aW9uLCB0aGUgb25seSB3YXkgZm9yIGEgTElTIHRvIGRpc2NvdmVyIHN1Y2gg Y2hhbmdlcyBpcyB0byBwZXJpb2RpY2FsbHkgcmV2YWxpZGF0ZSBpdHMgZW50aXJlIGRhdGFiYXNl LiAgT2YgY291cnNlLCB0aGlzIGRvZXMgbm90IGZhY2lsaXRhdGUgdGltZWx5IGNoYW5nZXMsIGlz IG5vdCBjb29yZGluYXRlZCB3aXRoIHRoZSBhY3R1YWwgY2hhbmdlIGV2ZW50LCBhbmQgYWxzbyBh ZGRzIHNpZ25pZmljYW50IGxvYWQgdG8gdGhlIExvU1Qgc2VydmVyIGFzIHdlbGwgYXMgdGhlIExJ Uy4gIEV2ZW4gaWYgcmUtdmFsaWRhdGlvbiBpcyBjb250ZW1wbGF0ZWQsIHRoZSBzZXJ2ZXIgaGFz IG5vIG1lY2hhbmlzbSB0byBjb250cm9sLCBvciBldmVuIHN1Z2dlc3QgdGhlIHRpbWUgcGVyaW9k IGZvciByZXZhbGlkYXRpb24uPC90PgoKPHQ+VGhpcyBleHRlbnNpb24gYWxsb3dzIGEgTG9TVCBj bGllbnQgdG8gcHJvdmlkZSBhIHN0YWJsZSBVUkkgdGhhdCB0aGUgTG9TVCBzZXJ2ZXIgbWF5IHJl dGFpbiBhbmQgbWF5IGFzc29jaWF0ZSB3aXRoIHRoZSBsb2NhdGlvbiBpbmZvcm1hdGlvbiB1c2Vk IGluIHRoZSByZXF1ZXN0LiAgSW4gdGhlIGV2ZW50IG9mIGEgcGxhbm5lZCBjaGFuZ2UsIG9yIGFu eSBvdGhlciBjaXJjdW1zdGFuY2Ugd2hlcmUgdGhlIGxvY2F0aW9uIGluIHRoZSBvcmlnaW5hbCBy ZXF1ZXN0IG1heSBiZWNvbWUgaW52YWxpZCwgdGhlIHNlcnZlciBzZW5kcyBhIG5vdGlmaWNhdGlv biB0byB0aGUgVVJJIHRvIGluZm9ybSB0aGUgY2xpZW50IG9mIGEgY2hhbmdlLiAgVGhlIG5vdGlm aWNhdGlvbiBjb250YWlucyB0aGUgZGF0ZSBhbmQgdGltZSB3aGVuIHRoZSBsb2NhdGlvbiBtYXkg YmVjb21lIGludmFsaWQuPC90PgoKPHQ+V2hlbiBhIExJUyByZWNlaXZlcyBzdWNoIGEgbm90aWZp Y2F0aW9uLCBpdCBtYXkgcHJlcGFyZSBhIG5ldyByZWNvcmQgc28gdGhhdCwgYXQgdGhlIHByZWNp c2UgcGxhbm5lZCBldmVudCBkYXRlIGFuZCB0aW1lLCBpdCBtYXkgaW5zZXJ0IHRoZSBuZXcgcmVj b3JkIGludG8gaW4gaXRzIGFjdGl2ZSBkYXRhYmFzZSBhbmQgZGVsZXRlIHRoZSBvbGQgcmVjb3Jk LiAgQXMgcGFydCBvZiBwcmVwYXJpbmcgdGhlIG5ldyByZWNvcmQsIHRoZSBMSVMgbWF5IHVzZSB0 aGUgImFzIG9mIiBkYXRlIGNvbXBvbmVudCBvZiB0aGlzIGV4dGVuc2lvbiB0byBwZXJmb3JtIGEg TG9TVCB2YWxpZGF0aW9uIG9mIHRoZSBuZXcgcmVjb3JkIGFzIG9mIHRoZSBlZmZlY3RpdmUgZGF0 ZS48L3Q+Cgo8dD5UaGUgbm90aWZpY2F0aW9uIFVSSSBhbmQgImFzIG9mIiBkYXRlIGNvbXBvbmVu dHMgb2YgdGhpcyBleHRlbnNpb24gYWxsb3cgYSBMSVMgdG8gYmUgcHJlcGFyZWQgZm9yIGFuZCBz bW9vdGhseSB0cmFuc2l0aW9uIHRvIHBsYW5uZWQgY2hhbmdlcywgd2l0aG91dCB0aGUgb3Zlcmhl YWQgYW5kIGRlbGF5IGluaGVyZW50IGluIHBlcmZvcm1pbmcgcGVyaW9kaWMgcmV2YWxpZGF0aW9u IG9mIGVhY2ggbG9jYXRpb24uICBUaGUgbm90aWZpY2F0aW9uIFVSSSBhbGxvd3MgYSBMSVMgdG8g YmUgYWxlcnRlZCB0byBwbGFubmVkIGNoYW5nZXMsIHdoaWxlIHRoZSAiYXMgb2YiIGRhdGUgYWxs b3dzIHRoZSBMSVMgdG8gdmVyaWZ5IHRoZSB2YWxpZGl0eSBvZiBsb2NhdGlvbnMgYmVmb3JlIHRo ZXkgYmVjb21lIGFjdGl2ZS48L3Q+Cgo8dD5JbiBzaXR1YXRpb25zIHdoZXJlIGl0IGlzIG5vdCBw cmFjdGljYWwgb3IgYWR2aXNhYmxlIGZvciB0aGUgTElTIHRvIG1haW50YWluIGEgc3RhYmxlIFVS SSBmb3IgZWFjaCBvZiBpdHMgcmVjb3JkcywgcGVyaW9kaWMgcmV2YWxpZGF0aW9uIGNhbiBzdGls bCBiZSB1c2VkIHRvIG1haW50YWluIHRoZSBkYXRhIGluIHRoZSBMSVMuICBIb3dldmVyLCB0aGUg TG9TVCBzZXJ2ZXIgc2hvdWxkIGJlIGFibGUgdG8gaW5mbHVlbmNlIHRoZSByYXRlIG9mIHN1Y2gg cmV2YWxpZGF0aW9uLiAgRm9yIHRoaXMgcHVycG9zZSwgdGhpcyBleHRlbnNpb24gYWRkcyBhICBU aW1lIHRvIExpdmUgKFRUTCkgZWxlbWVudCB0byB0aGUgJmx0O2ZpbmRTZXJ2aWNlUmVzcG9uc2Um Z3Q7IHdoaWNoIHByb3ZpZGVzIGFkdmljZSBmcm9tIHRoZSBzZXJ2ZXIgdG8gdGhlIExJUyBvZiB3 aGVuIHZhbGlkYXRpb24gaXMgc3VnZ2VzdGVkLjwvdD4KCjx0PlRoZXJlIGFyZSBxdWl0ZSBhIGZl dyBpbXBsZW1lbnRhdGlvbnMgb2YgTG9TVC4gIEV4cGVyaWVuY2Ugd2l0aCB0aGVzZSBpbXBsZW1l bnRhdGlvbnMgaW5kaWNhdGVzIHRoYXQgdGhlIFJlbGF4Tkcgc2NoZW1hIGlzIHZlcnkgZGlmZmlj dWx0IHRvIGRlYWwgd2l0aCwgYm90aCBiZWNhdXNlIG1hbnkgY29tbW9ubHkgdXNlZCBkZXZlbG9w bWVudCB0b29scyBkb24ndCBzdXBwb3J0IGl0LCBhbmQgZGV2ZWxvcG1lbnQgc3RhZmYgaXMgb2Z0 ZW4gdW5mYW1pbGlhciB3aXRoIGl0LiAgSW5mb3JtYWwgYWx0ZXJuYXRpdmUgc2NoZW1hcyBoYXZl IGJlZW4gY2lyY3VsYXRlZCwgd2hpY2ggaXMgdW5kZXNpcmFibGUgYXMgdGhleSBtYXkgbm90IGJl IGluIGNvbmZvcm1hbmNlIHdpdGggdGhlIFJlbGF4Tkcgc2NoZW1hIGluIDx4cmVmIHRhcmdldD0i UkZDNTIyMiIvPi4gIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYW4gWE1MIHNjaGVtYSB0aGF0IHJl cGxhY2VzIHRoZSBSZWxheE5HIHNjaGVtYS4gIEl0IGNhbiBiZSB1c2VkIGJ5IGFueSBpbXBsZW1l bnRhdGlvbiBpbnRlcmNoYW5nZWFibHkgd2l0aCB0aGUgUmVsYXhORyBzY2hlbWEuIDwvdD4KCiAg ICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gYW5jaG9yPSJjb252ZW50aW9ucyIgdGl0bGU9IkNv bnZlbnRpb25zIHVzZWQgaW4gdGhpcyBkb2N1bWVudCI+CiAgICAgIDx0PlRoZSBrZXkgd29yZHMg Ik1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwgIlNI T1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwi IGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiA8 eHJlZiB0YXJnZXQ9IlJGQzIxMTkiLz4uCiAgICAgIDwvdD4KICAgICAgPHQ+IlNlcnZlciIgaW4g dGhpcyBkb2N1bWVudCByZWZlcnMgdG8gdGhlIExvU1Qgc2VydmVyIGFuZCAiQ2xpZW50IiBpcyB0 aGUgTG9TVCBjbGllbnQsIGV2ZW4gd2hlbiB0aGUgc2VydmVyIGlzIHBlcmZvcm1pbmcgYW4gb3Bl cmF0aW9uIG9uIHRoZSBjbGllbnQuPC90PgogICAgPC9zZWN0aW9uPgogICAgPHNlY3Rpb24gdGl0 bGU9IiZsdDtwbGFubmVkQ2hhbmdlJmd0OyBlbGVtZW50Ij4KICAgICAgPHQ+VGhpcyBkb2N1bWVu dCBkZWZpbmVzIGEgbmV3IGVsZW1lbnQgaW4gdGhlICZsdDtmaW5kU2VydmljZSZndDsgcmVxdWVz dCBjYWxsZWQgInBsYW5uZWRDaGFuZ2UiLiAgVGhpcyBlbGVtZW50IGNvbnRhaW5zIHR3byBvcHRp b25hbCBhdHRyaWJ1dGVzOiAndXJpJyBhbmQgJ2FzT2YnLiAgV2hlbiBwcmVzZW50LCB0aGUgJ3Vy aScgYXR0cmlidXRlIE1VU1QgYmUgYSBVUkkgd2l0aCBhIHNjaGVtZSBvZiBIVFRQUy4gSWYgdGhl IHNlcnZlciBzdXBwb3J0cyB0aGlzIGV4dGVuc2lvbiwgaXQgbWF5IHN0b3JlIHRoZSBVUkkgYW5k IG1heSBhc3NvY2lhdGUgaXQgd2l0aCB0aGUgbG9jYXRpb24gaW4gdGhlIHJlcXVlc3QuICBUaGUg c2VydmVyIHVzZXMgdGhlIFVSSSB3aXRoIHRoZSBub3RpZmljYXRpb24gZnVuY3Rpb24gZGVmaW5l ZCBiZWxvdy4gIFRvIG1pbmltaXplIHN0b3JhZ2UgcmVxdWlyZW1lbnRzIGF0IHRoZSBzZXJ2ZXIs IHRoZSBsZW5ndGggb2YgdGhlIFVSSSBNVVNUIG5vdCBleGNlZWQgMjU2IGJ5dGVzLiAgRWFjaCBj bGllbnQgb2YgdGhlIHNlcnZlciBtYXkgb25seSBzdG9yZSBvbmUgVVJJIGFnYWluc3QgYSBsb2Nh dGlvbiwgd2hlcmUgImxvY2F0aW9uIiBpcyBkZWZpbmVkIGJ5IHBvbGljeSBhdCB0aGUgc2VydmVy LCBzaW5jZSBhIGdpdmVuIHVuaXF1ZSBsb2NhdGlvbiBtYXkgaGF2ZSBtYW55IGNvbWJpbmF0aW9u cyBvZiBsb2NhdGlvbiBlbGVtZW50cyB0aGF0IHJlc29sdmUgdG8gdGhlIHNhbWUgbG9jYXRpb24u ICBJZiB0aGUgc2VydmVyIHJlY2VpdmVzIGEgJ3VyaScgZm9yIHRoZSBzYW1lIGxvY2F0aW9uIGZy b20gdGhlIHNhbWUgY2xpZW50LCB0aGUgVVJJIGluIHRoZSByZXF1ZXN0IHJlcGxhY2VzIHRoZSBV UkkgaXQgcHJldmlvdXNseSByZXRhaW5lZC4gIFBvbGljeSBhdCB0aGUgc2VydmVyIG1heSBsaW1p dCBob3cgbWFueSBVUklzIGl0IHJldGFpbnMgZm9yIGEgZ2l2ZW4gbG9jYXRpb24uIEEgbmV3IHdh cm5pbmcgaXMgZGVmaW5lZCBiZWxvdyB0byBpbmRpY2F0ZSB0aGF0IHRoZSBVUkkgaGFzIG5vdCBi ZWVuIHN0b3JlZC4gIElmIHRoZSBsb2NhdGlvbiBpbiB0aGUgcmVxdWVzdCBpcyBpbnZhbGlkLCB0 aGUgVVJJIGlzIG5vdCBzdG9yZWQgYW5kIHRoZSB3YXJuaW5nIGlzIHJldHVybmVkLgogICAgICA8 L3Q+Cjx0PlRoZSAnYXNPZicgYXR0cmlidXRlIGNvbnRhaW5zIGEgZGF0ZSBhbmQgdGltZS4gIFRo ZSBzZXJ2ZXIgdmFsaWRhdGVzIHRoZSBsb2NhdGlvbiBpbiB0aGUgcmVxdWVzdCBhcyBvZiB0aGUg ZGF0ZSBhbmQgdGltZSBzcGVjaWZpZWQsIHRha2luZyBpbnRvIGFjY291bnQgcGxhbm5lZCBjaGFu Z2VzLiAgVGhpcyBhbGxvd3MgYSBjbGllbnQgdG8gdmVyaWZ5IHRoYXQgaXQgY2FuIG1ha2UgY2hh bmdlcyBpbiB0aGUgTElTIGNvbW1lbnN1cmF0ZSB3aXRoIGNoYW5nZXMgaW4gdGhlIExvU1Qgc2Vy dmVyIGJ5IHZhbGlkYXRpbmcgbG9jYXRpb25zIGluIGFkdmFuY2Ugb2YgYSBjaGFuZ2UuPC90Pgog ICAgPC9zZWN0aW9uPgogICA8c2VjdGlvbiB0aXRsZT0iJmx0O2xvY2F0aW9uSW52YWxpZGF0ZWQm Z3Q7IG9iamVjdCI+Cjx0PldoZW4gYSBzZXJ2ZXIgbmVlZHMgdG8gaW52YWxpZGF0ZSBhIGxvY2F0 aW9uIHRoYXQgaGFzIG9uZSBvciBtb3JlIGFzc29jaWF0ZWQgY2xpZW50LXN1cHBsaWVkIFVSSXMg KHByb3ZpZGVkIGluIGEgJmx0O3BsYW5uZWRDaGFuZ2UmZ3Q7IGVsZW1lbnQpLAppdCB0cmFuc21p dHMgYW4gSFRUUFMgUE9TVCB3aXRoIGEgQ29udGVudC1UeXBlIG9mICdhcHBsaWNhdGlvbi94bWwn IGNvbnRhaW5pbmcgYSAmbHQ7bG9jYXRpb25JbnZhbGlkYXRlZCZndDsgb2JqZWN0IHRvIGVhY2gg YXNzb2NpYXRlZCBVUkkuClRoaXMgaXMgdGhlIG5vdGljZSBmcm9tIHRoZSBzZXJ2ZXIgdG8gdGhl IGNsaWVudCB0aGF0IHRoZSBsb2NhdGlvbiBtYXkgYmUgaW52YWxpZCBhbmQgc2hvdWxkIGJlIHJl dmFsaWRhdGVkLgpUaGUgJmx0O2xvY2F0aW9uSW52YWxpZGF0ZWQmZ3Q7IG9iamVjdCBjb250YWlu cyBhbiDigJhpbnZhbGlkQXNPZuKAmCBhdHRyaWJ1dGUsIHdoaWNoIHNwZWNpZmllcyBhIGRhdGUg YW5kIHRpbWUgd2hlbiB0aGUgbG9jYXRpb24gbWF5IGJlY29tZSBpbnZhbGlkLgpJZiB0aGlzIGlz IGVhcmxpZXIgdGhhbiB0aGUgY3VycmVudCB0aW1lLCB0aGUgbG9jYXRpb24gbWF5IGFscmVhZHkg YmUgaW52YWxpZCBhbmQgdGhlIExJUyBzaG91bGQgdGFrZSBpbW1lZGlhdGUgYWN0aW9uLiAgSWYg dGhlIFBPU1Qgb3BlcmF0aW9uIGZhaWxzLCB0aGUgc2VydmVyIE1BWSByZXRyeSB0aGUgb3BlcmF0 aW9uIGltbWVkaWF0ZWx5LCBhbmQgaWYgaXQgZmFpbHMgYWdhaW4sIHJldHJ5IHRoZSBvcGVyYXRp b24gbGF0ZXIuICBSZXRyeSB0aW1pbmcgYW5kIGR1cmF0aW9uIG9yIG51bWJlciBvZiBhdHRlbXB0 cyBpcyBkZXRlcm1pbmVkIGJ5IHRoZSBzZXJ2ZXIuPC90Pgo8dD5UaGUgTG9TVCBzZXJ2ZXIgaXMg Tk9UIFJFUVVJUkVEIHRvIHN0b3JlIHRoZSBMb2NhdGlvbiBJbmZvcm1hdGlvbiBzdXBwbGllZCBp biB0aGUgb3JpZ2luYWwgZmluZFNlcnZpY2UgcmVxdWVzdC4gIFRoaXMgbWVhbnMgdGhlIHNlcnZl ciBtYXkgbm90IGtub3cgaWYgYSBwbGFubmVkIGNoYW5nZSB3aWxsIGluIGZhY3QgaW52YWxpZGF0 ZSB0aGUgbG9jYXRpb24gc3RvcmVkIGluIHRoZSBMb1NUIGNsaWVudCwgYmVjYXVzZSBjaGFuZ2Vz IGNvdWxkIGJlIG1hZGUgaW4gdGhlIExvU1Qgc2VydmVyIHRoYXQgZG8gbm90IGFmZmVjdCB2YWxp ZGF0aW9uIG9mIHRoZSBjbGllbnQncyBzcGVjaWZpYyBMb2NhdGlvbiBJbmZvcm1hdGlvbi4gIFRo ZSBMb1NUIGNsaWVudCBtYXkgZmluZCB0aGF0IHVwb24gcmV2YWxpZGF0aW9uIHdpdGggdGhlIGNo YW5nZWQgc2VydmVyIHN0YXRlLCB0aGUgdmFsaWRhdGlvbiBkYXRhIGlzIHRoZSBzYW1lIGFzIGl0 IHdhcyBiZWZvcmUgdGhlIG5vdGlmaWNhdGlvbiB3YXMgcmVjZWl2ZWQuIDwvdD4KPHQ+VGhlICZs dDtsb2NhdGlvbkludmFsaWRhdGVkJmd0OyBvYmplY3QgZG9lcyBub3QgY29udGFpbiBpbmZvcm1h dGlvbiBhYm91dCB0aGUgbG9jYXRpb24sIGFzIHRoZSBVUkkgdG8gd2hpY2ggaXQgaXMgc2VudCBp cyBkZXRlcm1pbmVkIGJ5IHRoZSByZXF1ZXN0aW5nIGNsaWVudCBhbmQgY2FuIGJlIHVuaXF1ZSBm b3IgZWFjaCBvZiB0aGUgY2xpZW50J3MgbG9jYXRpb24gcmVjb3Jkcy48L3Q+CiAgIDwvc2VjdGlv bj4KPHNlY3Rpb24gdGl0bGU9IlVSSSBOb3QgU3RvcmVkIFdhcm5pbmciPgo8dD5UaGlzIGV4dGVu c2lvbiBhZGRzIGEgbmV3IHdhcm5pbmcgdG8gdGhlIGV4Y2VwdGlvbkNvbnRhaW5lciwgJ3VyaU5v dFN0b3JlZCcuICBUaGlzIHdhcm5pbmcgTVVTVCBOT1QgYmUgcmV0dXJuZWQgdW5sZXNzIHRoZSBy ZXF1ZXN0IGNvbnRhaW5zIGEgJmx0O3BsYW5uZWRDaGFuZ2UmZ3Q7IGVsZW1lbnQgd2l0aCBhICd1 cmknIGF0dHJpYnV0ZS4gIFRoZSB3YXJuaW5nIGlzIHJldHVybmVkIHdoZW4gdGhlIHNlcnZlciBk ZWNpZGVzIG5vdCB0byBzdG9yZSB0aGUgVVJJLiAgQXMgZGlzY3Vzc2VkIGFib3ZlLCB0aGlzIG1h eSBvY2N1ciBiZWNhdXNlLCBhbW9uZyBvdGhlciByZWFzb25zLCB0aGUgcG9saWN5IGF0IHRoZSBz ZXJ2ZXIgbGltaXRzIGhvdyBtYW55IFVSSXMgd2lsbCBiZSBzdG9yZWQgYWdhaW5zdCBhIHNwZWNp ZmljIGxvY2F0aW9uLCB0aGUgVVJJIGlzIG5vdCB3ZWxsIGZvcm1lZCBvciB0aGUgcG9saWN5IGF0 IHRoZSBzZXJ2ZXIgaGFzIHNvbWUgb3RoZXIgcmVzdHJpY3Rpb24gb24gdGhlIGZlYXR1cmUuPC90 PgogICA8L3NlY3Rpb24+CjxzZWN0aW9uIHRpdGxlPSJUaW1lLVRvLUxpdmUgKFRUTCkgaW4gUmVz cG9uc2UiPgo8dD5UaGlzIGV4dGVuc2lvbiBhZGRzIHRoZSAmbHQ7dHRsJmd0OyBlbGVtZW50IHRv IHRoZSAmbHQ7ZmluZFNlcnZpY2VSZXNwb25zZSZndDsuICBUaGUgJmx0O3R0bCZndDsgZWxlbWVu dApjb250YWlucyBhIGRhdGUgYW5kIHRpbWUgYWZ0ZXIgd2hpY2ggdGhlIGNsaWVudCBtYXkgd2lz aCB0byByZXZhbGlkYXRlIHRoZSBsb2NhdGlvbgphdCB0aGUgc2VydmVyLiAgQSBzZXJ2ZXIgTUFZ IGFkZCB0aGlzIGVsZW1lbnQgdG8gdGhlIHJlc3BvbnNlIGlmIHZhbGlkYXRpb24gaXMgcmVxdWVz dGVkLiAgVGhpcyBlbGVtZW50IHRha2VzIHRoZSBmb3JtIG9mIHRoZSAnZXhwaXJlcycgYXR0cmli dXRlIHBhdHRlcm4gb2YgPHhyZWYgdGFyZ2V0PSJSRkM1MjIyIi8+LCB3aGljaCBhbGxvd3MKdGhl IHZhbHVlcyAnTk8gQ0FDSEUnIG9yICdOTyBFWFBJUkFUSU9OJyB0byBiZSByZXR1cm5lZCBpbnN0 ZWFkIG9mIGEgZGF0ZVRpbWUgdmFsdWUuICBIb3dldmVyLCBmb3IgdGhlICZsdDt0dGwmZ3Q7IGVs ZW1lbnQgJ05PIENBQ0hFJyBoYXMgbm8KbWVhbmluZyBhbmQgTVVTVCBOT1QgYmUgcmV0dXJuZWQu ICAnTk8gRVhQSVJBVElPTicgbWVhbnMgdGhlIHNlcnZlciBkb2VzCm5vdCBoYXZlIGEgc3VnZ2Vz dGVkIHJldmFsaWRhdGlvbiBwZXJpb2QuPC90Pgo8dD5TZWxlY3RpbmcgYSByZXZhbGlkYXRpb24g aW50ZXJ2YWwgaXMgYSBjb21wbGV4IGJhbGFuY2luZyBvZiB0aW1lbGluZXNzLCBzZXJ2ZXIgbG9h ZCwgc3RhYmlsaXR5IG9mIHRoZSB1bmRlcmx5aW5nIGRhdGEsIGFuZCBwb2xpY3kgb2YgdGhlIExv U1Qgc2VydmVyLiAgVG9vIHNob3J0LCBhbmQgbG9hZCBvbiB0aGUgc2VydmVyIG1heSBvdmVyd2hl bG0gaXQuICBUb28gbG9uZyBhbmQgaW52YWxpZCBkYXRhIG1heSBwZXJzaXN0IGluIHRoZSBzZXJ2 ZXIgZm9yIHVuYWNjZXB0YWJsZSBsZW5ndGhzIG9mIHRpbWUuICBUaGUgVVJJIG5vdGlmaWNhdGlv biBtZWNoYW5pc20gcHJvdmlkZXMgdGltZWx5IG5vdGljZSB0byBjb29yZGluYXRlIGNoYW5nZXMs IGJ1dCBldmVuIHdpdGggaXQsIGl0IGlzIG9mdGVuIGFkdmlzYWJsZSB0byByZXZhbGlkYXRlIGRh dGEgZXZlbnR1YWxseS48L3Q+Cjx0PkluIGFyZWFzIHRoYXQgaGF2ZSBsaXR0bGUgY2hhbmdlIGlu IGRhdGEsIHN1Y2ggYXMgZnVsbHkgYnVpbHQgb3V0LCBzdGFibGUgY29tbXVuaXRpZXMgYWxyZWFk eSBwYXJ0IG9mIGEgbXVuaWNpcGFsaXR5LCBpdCBtYXkgYmUgcmVhc29uYWJsZSB0byBzZXQgcmV2 YWxpZGF0aW9uIHBlcmlvZHMgb2YgNiBtb250aHMgb3IgbG9uZ2VyLCBlc3BlY2lhbGx5IGlmIHRo ZSBVUkkgbWVjaGFuaXNtIGlzIHdpZGVseSBkZXBsb3llZCBhdCBib3RoIHRoZSBzZXJ2ZXIgYW5k IHRoZSBjbGllbnRzLiAgSW4gYXJlYXMgdGhhdCBhcmUgcXVpY2tseSBncm93aW5nLCAyMC0zMCBk YXkgcmV2YWxpZGF0aW9uIG1heSBiZSBtb3JlIGFwcHJvcHJpYXRlIGV2ZW4gdGhvdWdoIHN1Y2gg cmV2YWxpZGF0aW9uIHdvdWxkIGJlIHRoZSBtYWpvcml0eSBvZiB0aGUgdHJhZmZpYyBvbiB0aGUg TG9TVCBzZXJ2ZXIuPC90Pgo8dD5XaGVuIGEgcGxhbm5lZCBjaGFuZ2UgaXMgbWFkZSwgdHlwaWNh bGx5IHRoZSBUVEwgdmFsdWUgZm9yIHRoZSBhZmZlY3RlZCByZWNvcmRzIGlzIGxvd2VyZWQsIHNv IHRoYXQgcmV2YWxpZGF0aW9uIGlzIGZvcmNlZCBzb29uIGFmdGVyIHRoZSBjaGFuZ2UgaXMgaW1w bGVtZW50ZWQuICAgSXQgaXMgbm90IGFkdmlzYWJsZSB0byBzZXQgdGhlIGV4cGlyYXRpb24gcHJl Y2lzZWx5IGF0IHRoZSBwbGFubmVkIGNoYW5nZSB0aW1lIGlmIGEgbGFyZ2UgbnVtYmVyIG9mIHJl Y29yZHMgd2lsbCBiZSBjaGFuZ2VkLCBzaW5jZSB0aGF0IHdvdWxkIGNhdXNlIGEgbGFyZ2Ugc3Bp a2UgaW4gdHJhZmZpYyBhdCB0aGUgY2hhbmdlIHRpbWUuICBSYXRoZXIsIHRoZSBleHBpcmF0aW9u IHRpbWUgc2hvdWxkIGhhdmUgYSByYW5kb20gYWRkaXRpb25hbCB0aW1lIGFkZGVkIHRvIGl0IHRv IHNwcmVhZCBvdXQgdGhlIGxvYWQuPC90Pgo8L3NlY3Rpb24+CiAgICA8c2VjdGlvbiBhbmNob3I9 InNjaGVtYSIgdGl0bGU9IlJlcGxhY2VtZW50IFhNTCBzY2hlbWEiPgo8dD5UaGlzIHNjaGVtYSBp cyBhbiBpbmZvcm1hdGl2ZSBhbHRlcm5hdGl2ZSB0byBUaGUgUmVsYXggTkcgc2NoZW1hIGluIDx4 cmVmIHRhcmdldD0iUkZDNTIyMiIvPiA8L3Q+CjxmaWd1cmU+PGFydHdvcms+CiZsdDs/eG1sIHZl cnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8mZ3Q7CiZsdDt4czpzY2hlbWEgeG1sbnM6eHM9 Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIgogICAgICAgICAgIHhtbG5zPSJ1cm46 aWV0ZjpwYXJhbXM6eG1sOm5zOmxvc3QxIgogICAgICAgICAgIHRhcmdldE5hbWVzcGFjZT0idXJu OmlldGY6cGFyYW1zOnhtbDpuczpsb3N0MSIKICAgICAgICAgICBlbGVtZW50Rm9ybURlZmF1bHQ9 InF1YWxpZmllZCImZ3Q7CgogICZsdDt4czplbGVtZW50IG5hbWU9ImZpbmRTZXJ2aWNlIiZndDsK ICAgICZsdDt4czpjb21wbGV4VHlwZSZndDsKICAgICAgJmx0O3hzOnNlcXVlbmNlJmd0OwogICAg ICAgICZsdDt4czpncm91cCByZWY9InJlcXVlc3RMb2NhdGlvbiIvJmd0OwogICAgICAgICZsdDt4 czpncm91cCByZWY9ImNvbW1vblJlcXVlc3RQYXR0ZXJuIi8mZ3Q7CiAgICAgICZsdDsveHM6c2Vx dWVuY2UmZ3Q7CiAgICAgICZsdDt4czphdHRyaWJ1dGUgbmFtZT0idmFsaWRhdGVMb2NhdGlvbiIg dHlwZT0ieHM6Ym9vbGVhbiIvJmd0OwogICAgICAmbHQ7eHM6YXR0cmlidXRlIG5hbWU9InNlcnZp Y2VCb3VuZGFyeSImZ3Q7CiAgICAgICAgJmx0O3hzOnNpbXBsZVR5cGUmZ3Q7CiAgICAgICAgICAm bHQ7eHM6cmVzdHJpY3Rpb24gYmFzZT0ieHM6dG9rZW4iJmd0OwogICAgICAgICAgICAmbHQ7eHM6 ZW51bWVyYXRpb24gdmFsdWU9InJlZmVyZW5jZSIvJmd0OwogICAgICAgICAgICAmbHQ7eHM6ZW51 bWVyYXRpb24gdmFsdWU9InZhbHVlIi8mZ3Q7CiAgICAgICAgICAmbHQ7L3hzOnJlc3RyaWN0aW9u Jmd0OwogICAgICAgICZsdDsveHM6c2ltcGxlVHlwZSZndDsKICAgICAgJmx0Oy94czphdHRyaWJ1 dGUmZ3Q7CiAgICAgICZsdDt4czphdHRyaWJ1dGUgbmFtZT0icmVjdXJzaXZlIiB0eXBlPSJ4czpi b29sZWFuIi8mZ3Q7CiAgICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwogICZsdDsveHM6ZWxlbWVu dCZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ibGlzdFNlcnZpY2VzIiZndDsKICAgICZsdDt4 czpjb21wbGV4VHlwZSZndDsKICAgICAgJmx0O3hzOmdyb3VwIHJlZj0iY29tbW9uUmVxdWVzdFBh dHRlcm4iLyZndDsKICAgICZsdDsveHM6Y29tcGxleFR5cGUmZ3Q7CiAgJmx0Oy94czplbGVtZW50 Jmd0OwoKICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJsaXN0U2VydmljZXNCeUxvY2F0aW9uIiZndDsK ICAgICZsdDt4czpjb21wbGV4VHlwZSZndDsKICAgICAgJmx0O3hzOnNlcXVlbmNlJmd0OwogICAg ICAgICZsdDt4czpncm91cCByZWY9InJlcXVlc3RMb2NhdGlvbiIvJmd0OwogICAgICAgICZsdDt4 czpncm91cCByZWY9ImNvbW1vblJlcXVlc3RQYXR0ZXJuIi8mZ3Q7CiAgICAgICZsdDsveHM6c2Vx dWVuY2UmZ3Q7CiAgICAgICZsdDt4czphdHRyaWJ1dGUgbmFtZT0icmVjdXJzaXZlIiB0eXBlPSJ4 czpib29sZWFuIi8mZ3Q7CiAgICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwogICZsdDsveHM6ZWxl bWVudCZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iZ2V0U2VydmljZUJvdW5kYXJ5IiZndDsK ICAgICZsdDt4czpjb21wbGV4VHlwZSZndDsKICAgICAgJmx0O3hzOmdyb3VwIHJlZj0iZXh0ZW5z aW9uUG9pbnQiLyZndDsKICAgICAgJmx0O3hzOmF0dHJpYnV0ZUdyb3VwIHJlZj0ic2VydmljZUJv dW5kYXJ5S2V5Ii8mZ3Q7CiAgICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwogICZsdDsveHM6ZWxl bWVudCZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iZmluZFNlcnZpY2VSZXNwb25zZSImZ3Q7 CiAgICAmbHQ7eHM6Y29tcGxleFR5cGUmZ3Q7CiAgICAgICZsdDt4czpzZXF1ZW5jZSZndDsKICAg ICAgICAmbHQ7eHM6ZWxlbWVudCByZWY9Im1hcHBpbmciIG1heE9jY3Vycz0idW5ib3VuZGVkIi8m Z3Q7CiAgICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJsb2NhdGlvblZhbGlkYXRpb24iIG1pbk9j Y3Vycz0iMCIvJmd0OwogICAgICAgICZsdDt4czpncm91cCByZWY9ImNvbW1vblJlc3BvbnNlUGF0 dGVybiIvJmd0OwogICAgICAgICZsdDt4czpncm91cCByZWY9ImxvY2F0aW9uVXNlZCIvJmd0Owog ICAgICAmbHQ7L3hzOnNlcXVlbmNlJmd0OwogICAgJmx0Oy94czpjb21wbGV4VHlwZSZndDsKICAm bHQ7L3hzOmVsZW1lbnQmZ3Q7CgogICZsdDt4czplbGVtZW50IG5hbWU9Imxpc3RTZXJ2aWNlc1Jl c3BvbnNlIiZndDsKICAgICZsdDt4czpjb21wbGV4VHlwZSZndDsKICAgICAgJmx0O3hzOnNlcXVl bmNlJmd0OwogICAgICAgICZsdDt4czplbGVtZW50IHJlZj0ic2VydmljZUxpc3QiLyZndDsKICAg ICAgICAmbHQ7eHM6Z3JvdXAgcmVmPSJjb21tb25SZXNwb25zZVBhdHRlcm4iLyZndDsKICAgICAg Jmx0Oy94czpzZXF1ZW5jZSZndDsKICAgICZsdDsveHM6Y29tcGxleFR5cGUmZ3Q7CiAgJmx0Oy94 czplbGVtZW50Jmd0OwoKICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJsaXN0U2VydmljZXNCeUxvY2F0 aW9uUmVzcG9uc2UiJmd0OwogICAgJmx0O3hzOmNvbXBsZXhUeXBlJmd0OwogICAgICAmbHQ7eHM6 c2VxdWVuY2UmZ3Q7CiAgICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJzZXJ2aWNlTGlzdCIvJmd0 OwogICAgICAgICZsdDt4czpncm91cCByZWY9ImNvbW1vblJlc3BvbnNlUGF0dGVybiIvJmd0Owog ICAgICAgICZsdDt4czpncm91cCByZWY9ImxvY2F0aW9uVXNlZCIvJmd0OwogICAgICAmbHQ7L3hz OnNlcXVlbmNlJmd0OwogICAgJmx0Oy94czpjb21wbGV4VHlwZSZndDsKICAmbHQ7L3hzOmVsZW1l bnQmZ3Q7CgogICZsdDt4czplbGVtZW50IG5hbWU9ImdldFNlcnZpY2VCb3VuZGFyeVJlc3BvbnNl IiZndDsKICAgICZsdDt4czpjb21wbGV4VHlwZSZndDsKICAgICAgJmx0O3hzOnNlcXVlbmNlJmd0 OwogICAgICAgICZsdDt4czpncm91cCByZWY9InNlcnZpY2VCb3VuZGFyeSIvJmd0OwogICAgICAg ICZsdDt4czpncm91cCByZWY9ImNvbW1vblJlc3BvbnNlUGF0dGVybiIvJmd0OwogICAgICAmbHQ7 L3hzOnNlcXVlbmNlJmd0OwogICAgJmx0Oy94czpjb21wbGV4VHlwZSZndDsKICAmbHQ7L3hzOmVs ZW1lbnQmZ3Q7CgogICZsdDt4czpncm91cCBuYW1lPSJjb21tb25SZXF1ZXN0UGF0dGVybiImZ3Q7 CiAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7CiAgICAgICZsdDt4czpncm91cCByZWY9InNlcnZpY2Ui LyZndDsKICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJwYXRoIiBtaW5PY2N1cnM9IjAiLyZndDsK ICAgICAgJmx0O3hzOmdyb3VwIHJlZj0iZXh0ZW5zaW9uUG9pbnQiLyZndDsKICAgICZsdDsveHM6 c2VxdWVuY2UmZ3Q7CiAgJmx0Oy94czpncm91cCZndDsKCiAgJmx0O3hzOmdyb3VwIG5hbWU9ImNv bW1vblJlc3BvbnNlUGF0dGVybiImZ3Q7CiAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7CiAgICAgICZs dDt4czplbGVtZW50IHJlZj0id2FybmluZ3MiIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJv dW5kZWQiLyZndDsKICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJwYXRoIi8mZ3Q7CiAgICAgICZs dDt4czpncm91cCByZWY9ImV4dGVuc2lvblBvaW50Ii8mZ3Q7CiAgICAmbHQ7L3hzOnNlcXVlbmNl Jmd0OwogICZsdDsveHM6Z3JvdXAmZ3Q7CgogICZsdDt4czpncm91cCBuYW1lPSJyZXF1ZXN0TG9j YXRpb24iJmd0OwogICAgJmx0O3hzOnNlcXVlbmNlJmd0OwogICAgICAmbHQ7eHM6ZWxlbWVudCBy ZWY9ImxvY2F0aW9uIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvJmd0OwogICAgJmx0Oy94czpzZXF1 ZW5jZSZndDsKICAmbHQ7L3hzOmdyb3VwJmd0OwoKICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJsb2Nh dGlvbiImZ3Q7CiAgICAmbHQ7eHM6Y29tcGxleFR5cGUmZ3Q7CiAgICAgICZsdDt4czpjb21wbGV4 Q29udGVudCZndDsKICAgICAgICAmbHQ7eHM6ZXh0ZW5zaW9uIGJhc2U9ImxvY2F0aW9uSW5mb3Jt YXRpb24iJmd0OwogICAgICAgICAgJmx0O3hzOmF0dHJpYnV0ZSBuYW1lPSJpZCIgdHlwZT0ieHM6 dG9rZW4iIHVzZT0icmVxdWlyZWQiLyZndDsKICAgICAgICAmbHQ7L3hzOmV4dGVuc2lvbiZndDsK ICAgICAgJmx0Oy94czpjb21wbGV4Q29udGVudCZndDsKICAgICZsdDsveHM6Y29tcGxleFR5cGUm Z3Q7CiAgJmx0Oy94czplbGVtZW50Jmd0OwoKICAmbHQ7eHM6Y29tcGxleFR5cGUgbmFtZT0ibG9j YXRpb25JbmZvcm1hdGlvbiImZ3Q7CiAgICAmbHQ7eHM6Z3JvdXAgcmVmPSJleHRlbnNpb25Qb2lu dCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLyZndDsKICAgICZsdDt4czphdHRyaWJ1dGUgbmFtZT0i cHJvZmlsZSIgdHlwZT0ieHM6Tk1UT0tFTiIvJmd0OwogICZsdDsveHM6Y29tcGxleFR5cGUmZ3Q7 CgogICZsdDt4czpncm91cCBuYW1lPSJzZXJ2aWNlQm91bmRhcnkiJmd0OwogICAgJmx0O3hzOnNl cXVlbmNlJmd0OwogICAgICAmbHQ7eHM6ZWxlbWVudCByZWY9InNlcnZpY2VCb3VuZGFyeSIgbWF4 T2NjdXJzPSJ1bmJvdW5kZWQiLyZndDsKICAgICZsdDsveHM6c2VxdWVuY2UmZ3Q7CiAgJmx0Oy94 czpncm91cCZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ic2VydmljZUJvdW5kYXJ5IiB0eXBl PSJsb2NhdGlvbkluZm9ybWF0aW9uIi8mZ3Q7CgogICZsdDt4czplbGVtZW50IG5hbWU9InNlcnZp Y2VCb3VuZGFyeVJlZmVyZW5jZSImZ3Q7CiAgICAmbHQ7eHM6Y29tcGxleFR5cGUmZ3Q7CiAgICAg ICZsdDt4czpncm91cCByZWY9ImV4dGVuc2lvblBvaW50Ii8mZ3Q7CiAgICAgICZsdDt4czphdHRy aWJ1dGVHcm91cCByZWY9InNvdXJjZSIvJmd0OwogICAgICAmbHQ7eHM6YXR0cmlidXRlR3JvdXAg cmVmPSJzZXJ2aWNlQm91bmRhcnlLZXkiLyZndDsKICAgICZsdDsveHM6Y29tcGxleFR5cGUmZ3Q7 CiAgJmx0Oy94czplbGVtZW50Jmd0OwoKICAmbHQ7eHM6YXR0cmlidXRlR3JvdXAgbmFtZT0ic2Vy dmljZUJvdW5kYXJ5S2V5IiZndDsKICAgICZsdDt4czphdHRyaWJ1dGUgbmFtZT0ia2V5IiB0eXBl PSJ4czp0b2tlbiIgdXNlPSJyZXF1aXJlZCIvJmd0OwogICZsdDsveHM6YXR0cmlidXRlR3JvdXAm Z3Q7CgogICZsdDt4czplbGVtZW50IG5hbWU9InBhdGgiJmd0OwogICAgJmx0O3hzOmNvbXBsZXhU eXBlJmd0OwogICAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7CiAgICAgICAgJmx0O3hzOmVsZW1lbnQg cmVmPSJ2aWEiIG1heE9jY3Vycz0idW5ib3VuZGVkIi8mZ3Q7CiAgICAgICZsdDsveHM6c2VxdWVu Y2UmZ3Q7CiAgICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwogICZsdDsveHM6ZWxlbWVudCZndDsK CiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0idmlhIiZndDsKICAgICZsdDt4czpjb21wbGV4VHlwZSZn dDsKICAgICAgJmx0O3hzOmdyb3VwIHJlZj0iZXh0ZW5zaW9uUG9pbnQiLyZndDsKICAgICAgJmx0 O3hzOmF0dHJpYnV0ZUdyb3VwIHJlZj0ic291cmNlIi8mZ3Q7CiAgICAmbHQ7L3hzOmNvbXBsZXhU eXBlJmd0OwogICZsdDsveHM6ZWxlbWVudCZndDsKCiAgJmx0O3hzOmdyb3VwIG5hbWU9ImxvY2F0 aW9uVXNlZCImZ3Q7CiAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7CiAgICAgICZsdDt4czplbGVtZW50 IHJlZj0ibG9jYXRpb25Vc2VkIiBtaW5PY2N1cnM9IjAiLyZndDsKICAgICZsdDsveHM6c2VxdWVu Y2UmZ3Q7CiAgJmx0Oy94czpncm91cCZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ibG9jYXRp b25Vc2VkIiZndDsKICAgICZsdDt4czpjb21wbGV4VHlwZSZndDsKICAgICAgJmx0O3hzOmF0dHJp YnV0ZSBuYW1lPSJpZCIgdHlwZT0ieHM6dG9rZW4iIHVzZT0icmVxdWlyZWQiLyZndDsKICAgICZs dDsveHM6Y29tcGxleFR5cGUmZ3Q7CiAgJmx0Oy94czplbGVtZW50Jmd0OwoKICAmbHQ7eHM6YXR0 cmlidXRlR3JvdXAgbmFtZT0iZXhwaXJlcyImZ3Q7CiAgICAmbHQ7eHM6YXR0cmlidXRlIG5hbWU9 ImV4cGlyZXMiIHVzZT0icmVxdWlyZWQiJmd0OwogICAgICAmbHQ7eHM6c2ltcGxlVHlwZSZndDsK ICAgICAgICAmbHQ7eHM6dW5pb24gbWVtYmVyVHlwZXM9InhzOmRhdGVUaW1lIiZndDsKICAgICAg ICAgICZsdDt4czpzaW1wbGVUeXBlJmd0OwogICAgICAgICAgICAmbHQ7eHM6cmVzdHJpY3Rpb24g YmFzZT0ieHM6dG9rZW4iJmd0OwogICAgICAgICAgICAgICZsdDt4czplbnVtZXJhdGlvbiB2YWx1 ZT0iTk8tQ0FDSEUiLyZndDsKICAgICAgICAgICAgJmx0Oy94czpyZXN0cmljdGlvbiZndDsKICAg ICAgICAgICZsdDsveHM6c2ltcGxlVHlwZSZndDsKICAgICAgICAgICZsdDt4czpzaW1wbGVUeXBl Jmd0OwogICAgICAgICAgICAmbHQ7eHM6cmVzdHJpY3Rpb24gYmFzZT0ieHM6dG9rZW4iJmd0Owog ICAgICAgICAgICAgICZsdDt4czplbnVtZXJhdGlvbiB2YWx1ZT0iTk8tRVhQSVJBVElPTiIvJmd0 OwogICAgICAgICAgICAmbHQ7L3hzOnJlc3RyaWN0aW9uJmd0OwogICAgICAgICAgJmx0Oy94czpz aW1wbGVUeXBlJmd0OwogICAgICAgICZsdDsveHM6dW5pb24mZ3Q7CiAgICAgICZsdDsveHM6c2lt cGxlVHlwZSZndDsKICAgICZsdDsveHM6YXR0cmlidXRlJmd0OwogICZsdDsveHM6YXR0cmlidXRl R3JvdXAmZ3Q7CgogICZsdDt4czpzaW1wbGVUeXBlIG5hbWU9InFuYW1lTGlzdCImZ3Q7CiAgICAm bHQ7eHM6bGlzdCBpdGVtVHlwZT0ieHM6UU5hbWUiLyZndDsKICAmbHQ7L3hzOnNpbXBsZVR5cGUm Z3Q7CgogICZsdDt4czplbGVtZW50IG5hbWU9Im1hcHBpbmciJmd0OwogICAgJmx0O3hzOmNvbXBs ZXhUeXBlJmd0OwogICAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7CiAgICAgICAgJmx0O3hzOmVsZW1l bnQgcmVmPSJkaXNwbGF5TmFtZSIKICAgICAgICAgICAgIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJz PSJ1bmJvdW5kZWQiLyZndDsKICAgICAgICAmbHQ7eHM6Z3JvdXAgcmVmPSJzZXJ2aWNlIi8mZ3Q7 CiAgICAgICAgJmx0O3hzOmNob2ljZSBtaW5PY2N1cnM9IjAiJmd0OwogICAgICAgICAgJmx0O3hz Omdyb3VwIHJlZj0ic2VydmljZUJvdW5kYXJ5Ii8mZ3Q7CiAgICAgICAgICAmbHQ7eHM6ZWxlbWVu dCByZWY9InNlcnZpY2VCb3VuZGFyeVJlZmVyZW5jZSIvJmd0OwogICAgICAgICZsdDsveHM6Y2hv aWNlJmd0OwogICAgICAgICZsdDt4czplbGVtZW50IHJlZj0idXJpIgogICAgICAgICAgICAgbWlu T2NjdXJzPSIwIiBtYXhPY2N1cnM9InVuYm91bmRlZCIvJmd0OwogICAgICAgICZsdDt4czplbGVt ZW50IHJlZj0ic2VydmljZU51bWJlciIgbWluT2NjdXJzPSIwIi8mZ3Q7CiAgICAgICAgJmx0O3hz Omdyb3VwIHJlZj0iZXh0ZW5zaW9uUG9pbnQiLyZndDsKICAgICAgJmx0Oy94czpzZXF1ZW5jZSZn dDsKICAgICAgJmx0O3hzOmF0dHJpYnV0ZUdyb3VwIHJlZj0iZXhwaXJlcyIvJmd0OwogICAgICAm bHQ7eHM6YXR0cmlidXRlIG5hbWU9Imxhc3RVcGRhdGVkIiB0eXBlPSJ4czpkYXRlVGltZSIKICAg ICAgICAgICAgdXNlPSJyZXF1aXJlZCIvJmd0OwogICAgICAmbHQ7eHM6YXR0cmlidXRlR3JvdXAg cmVmPSJzb3VyY2UiLyZndDsKICAgICAgJmx0O3hzOmF0dHJpYnV0ZSBuYW1lPSJzb3VyY2VJZCIg dHlwZT0ieHM6dG9rZW4iCiAgICAgICAgICAgIHVzZT0icmVxdWlyZWQiLyZndDsKICAgICAgJmx0 O3hzOmF0dHJpYnV0ZUdyb3VwIHJlZj0ibWVzc2FnZSIvJmd0OwogICAgJmx0Oy94czpjb21wbGV4 VHlwZSZndDsKICAmbHQ7L3hzOmVsZW1lbnQmZ3Q7CgogICZsdDt4czplbGVtZW50IG5hbWU9ImRp c3BsYXlOYW1lIiZndDsKICAgICZsdDt4czpjb21wbGV4VHlwZSZndDsKICAgICAgJmx0O3hzOnNp bXBsZUNvbnRlbnQmZ3Q7CiAgICAgICAgJmx0O3hzOmV4dGVuc2lvbiBiYXNlPSJ4czpzdHJpbmci Jmd0OwogICAgICAgICAgJmx0O3hzOmF0dHJpYnV0ZSByZWY9InhtbDpsYW5nIiB1c2U9InJlcXVp cmVkIi8mZ3Q7CiAgICAgICAgJmx0Oy94czpleHRlbnNpb24mZ3Q7CiAgICAgICZsdDsveHM6c2lt cGxlQ29udGVudCZndDsKICAgICZsdDsveHM6Y29tcGxleFR5cGUmZ3Q7CiAgJmx0Oy94czplbGVt ZW50Jmd0OwoKICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJ1cmkiIHR5cGU9InhzOmFueVVSSSIvJmd0 OwoKICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJzZXJ2aWNlTnVtYmVyIiZndDsKICAgICZsdDt4czpz aW1wbGVUeXBlJmd0OwogICAgICAmbHQ7eHM6cmVzdHJpY3Rpb24gYmFzZT0ieHM6dG9rZW4iJmd0 OwogICAgICAgICZsdDt4czpwYXR0ZXJuIHZhbHVlPSJbMC05KiNdKyIvJmd0OwogICAgICAmbHQ7 L3hzOnJlc3RyaWN0aW9uJmd0OwogICAgJmx0Oy94czpzaW1wbGVUeXBlJmd0OwogICZsdDsveHM6 ZWxlbWVudCZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ibG9jYXRpb25WYWxpZGF0aW9uIiZn dDsKICAgICZsdDt4czpjb21wbGV4VHlwZSZndDsKICAgICAgJmx0O3hzOnNlcXVlbmNlJmd0Owog ICAgICAgICZsdDt4czplbGVtZW50IHJlZj0idmFsaWQiIG1pbk9jY3Vycz0iMCIvJmd0OwogICAg ICAgICZsdDt4czplbGVtZW50IHJlZj0iaW52YWxpZCIgbWluT2NjdXJzPSIwIi8mZ3Q7CiAgICAg ICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJ1bmNoZWNrZWQiIG1pbk9jY3Vycz0iMCIvJmd0OwogICAg ICAgICZsdDt4czpncm91cCByZWY9ImV4dGVuc2lvblBvaW50Ii8mZ3Q7CiAgICAgICZsdDsveHM6 c2VxdWVuY2UmZ3Q7CiAgICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwogICZsdDsveHM6ZWxlbWVu dCZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0idmFsaWQiIHR5cGU9InFuYW1lTGlzdCIvJmd0 OwoKICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJpbnZhbGlkIiB0eXBlPSJxbmFtZUxpc3QiLyZndDsK CiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0idW5jaGVja2VkIiB0eXBlPSJxbmFtZUxpc3QiLyZndDsK CiAgJmx0O3hzOmNvbXBsZXhUeXBlIG5hbWU9ImV4Y2VwdGlvbkNvbnRhaW5lciImZ3Q7CiAgICAm bHQ7eHM6c2VxdWVuY2UmZ3Q7CiAgICAgICZsdDt4czpjaG9pY2UgbWluT2NjdXJzPSIwIiBtYXhP Y2N1cnM9InVuYm91bmRlZCImZ3Q7CiAgICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJiYWRSZXF1 ZXN0Ii8mZ3Q7CiAgICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJpbnRlcm5hbEVycm9yIi8mZ3Q7 CiAgICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJzZXJ2aWNlU3Vic3RpdHV0aW9uIi8mZ3Q7CiAg ICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJkZWZhdWx0TWFwcGluZ1JldHVybmVkIi8mZ3Q7CiAg ICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJmb3JiaWRkZW4iLyZndDsKICAgICAgICAmbHQ7eHM6 ZWxlbWVudCByZWY9Im5vdEZvdW5kIi8mZ3Q7CiAgICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJs b29wIi8mZ3Q7CiAgICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJzZXJ2aWNlTm90SW1wbGVtZW50 ZWQiLyZndDsKICAgICAgICAmbHQ7eHM6ZWxlbWVudCByZWY9InNlcnZlclRpbWVvdXQiLyZndDsK ICAgICAgICAmbHQ7eHM6ZWxlbWVudCByZWY9InNlcnZlckVycm9yIi8mZ3Q7CiAgICAgICAgJmx0 O3hzOmVsZW1lbnQgcmVmPSJsb2NhdGlvbkludmFsaWQiLyZndDsKICAgICAgICAmbHQ7eHM6ZWxl bWVudCByZWY9ImxvY2F0aW9uUHJvZmlsZVVucmVjb2duaXplZCIvJmd0OwogICAgICAmbHQ7L3hz OmNob2ljZSZndDsKICAgICAgJmx0O3hzOmdyb3VwIHJlZj0iZXh0ZW5zaW9uUG9pbnQiLyZndDsK ICAgICZsdDsveHM6c2VxdWVuY2UmZ3Q7CiAgICAmbHQ7eHM6YXR0cmlidXRlR3JvdXAgcmVmPSJz b3VyY2UiLyZndDsKICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0OwoKICAmbHQ7eHM6ZWxlbWVudCBu YW1lPSJlcnJvcnMiIHR5cGU9ImV4Y2VwdGlvbkNvbnRhaW5lciIvJmd0OwoKICAmbHQ7eHM6ZWxl bWVudCBuYW1lPSJ3YXJuaW5ncyIgdHlwZT0iZXhjZXB0aW9uQ29udGFpbmVyIi8mZ3Q7CgogICZs dDt4czpjb21wbGV4VHlwZSBuYW1lPSJiYXNpY0V4Y2VwdGlvbiImZ3Q7CiAgICAmbHQ7eHM6YW5u b3RhdGlvbiZndDsKICAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgRXhjZXB0 aW9uIHBhdHRlcm4uCiAgICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICZsdDsveHM6 YW5ub3RhdGlvbiZndDsKICAgICZsdDt4czpncm91cCByZWY9ImV4dGVuc2lvblBvaW50Ii8mZ3Q7 CiAgICAmbHQ7eHM6YXR0cmlidXRlR3JvdXAgcmVmPSJtZXNzYWdlIi8mZ3Q7CiAgJmx0Oy94czpj b21wbGV4VHlwZSZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iYmFkUmVxdWVzdCIgdHlwZT0i YmFzaWNFeGNlcHRpb24iLyZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iaW50ZXJuYWxFcnJv ciIgdHlwZT0iYmFzaWNFeGNlcHRpb24iLyZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ic2Vy dmljZVN1YnN0aXR1dGlvbiIgdHlwZT0iYmFzaWNFeGNlcHRpb24iLyZndDsKCiAgJmx0O3hzOmVs ZW1lbnQgbmFtZT0iZGVmYXVsdE1hcHBpbmdSZXR1cm5lZCIgdHlwZT0iYmFzaWNFeGNlcHRpb24i LyZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0iZm9yYmlkZGVuIiB0eXBlPSJiYXNpY0V4Y2Vw dGlvbiIvJmd0OwoKICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJub3RGb3VuZCIgdHlwZT0iYmFzaWNF eGNlcHRpb24iLyZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ibG9vcCIgdHlwZT0iYmFzaWNF eGNlcHRpb24iLyZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ic2VydmljZU5vdEltcGxlbWVu dGVkIiB0eXBlPSJiYXNpY0V4Y2VwdGlvbiIvJmd0OwoKICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJz ZXJ2ZXJUaW1lb3V0IiB0eXBlPSJiYXNpY0V4Y2VwdGlvbiIvJmd0OwoKICAmbHQ7eHM6ZWxlbWVu dCBuYW1lPSJzZXJ2ZXJFcnJvciIgdHlwZT0iYmFzaWNFeGNlcHRpb24iLyZndDsKCiAgJmx0O3hz OmVsZW1lbnQgbmFtZT0iU1JTaW52YWxpZCIgdHlwZT0iYmFzaWNFeGNlcHRpb24iLyZndDsKCiAg Jmx0O3hzOmVsZW1lbnQgbmFtZT0ibG9jYXRpb25JbnZhbGlkIiB0eXBlPSJiYXNpY0V4Y2VwdGlv biIvJmd0OwoKICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJsb2NhdGlvblZhbGlkYXRpb25VbmF2YWls YWJsZSIKICAgICAgICAgIHR5cGU9ImJhc2ljRXhjZXB0aW9uIi8mZ3Q7CgogICZsdDt4czplbGVt ZW50IG5hbWU9ImxvY2F0aW9uUHJvZmlsZVVucmVjb2duaXplZCImZ3Q7CiAgICAgICAgICB0eXBl PSJiYXNpY0V4Y2VwdGlvbiIvJmd0OwoKICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJyZWRpcmVjdCIm Z3Q7CiAgICAmbHQ7eHM6Y29tcGxleFR5cGUmZ3Q7CiAgICAgICZsdDt4czpncm91cCByZWY9ImV4 dGVuc2lvblBvaW50Ii8mZ3Q7CiAgICAgICZsdDt4czphdHRyaWJ1dGUgbmFtZT0idGFyZ2V0IiB0 eXBlPSJhcHBVbmlxdWVTdHJpbmciCiAgICAgICAgICB1c2U9InJlcXVpcmVkIi8mZ3Q7CiAgICAg ICZsdDt4czphdHRyaWJ1dGVHcm91cCByZWY9InNvdXJjZSIvJmd0OwogICAgICAmbHQ7eHM6YXR0 cmlidXRlR3JvdXAgcmVmPSJtZXNzYWdlIi8mZ3Q7CiAgICAmbHQ7L3hzOmNvbXBsZXhUeXBlJmd0 OwogICZsdDsveHM6ZWxlbWVudCZndDsKCiAgJmx0O3hzOmF0dHJpYnV0ZUdyb3VwIG5hbWU9Im1l c3NhZ2UiJmd0OwogICAgJmx0O3hzOmF0dHJpYnV0ZSBuYW1lPSJtZXNzYWdlIiB0eXBlPSJ4czp0 b2tlbiIvJmd0OwogICAgJmx0O3hzOmF0dHJpYnV0ZSByZWY9InhtbDpsYW5nIi8mZ3Q7CiAgJmx0 Oy94czphdHRyaWJ1dGVHcm91cCZndDsKCiAgJmx0O3hzOmdyb3VwIG5hbWU9InNlcnZpY2UiJmd0 OwogICAgJmx0O3hzOnNlcXVlbmNlJmd0OwogICAgICAmbHQ7eHM6ZWxlbWVudCByZWY9InNlcnZp Y2UiIG1pbk9jY3Vycz0iMCIvJmd0OwogICAgJmx0Oy94czpzZXF1ZW5jZSZndDsKICAmbHQ7L3hz Omdyb3VwJmd0OwoKICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJzZXJ2aWNlIiB0eXBlPSJ4czphbnlV UkkiLyZndDsKCiAgJmx0O3hzOnNpbXBsZVR5cGUgbmFtZT0iYXBwVW5pcXVlU3RyaW5nIiZndDsK ICAgICZsdDt4czpyZXN0cmljdGlvbiBiYXNlPSJ4czp0b2tlbiImZ3Q7CiAgICAgICZsdDt4czpw YXR0ZXJuIHZhbHVlPSIoW2EtekEtWjAtOVwtXStcLikrW2EtekEtWjAtOV0rIi8mZ3Q7CiAgICAm bHQ7L3hzOnJlc3RyaWN0aW9uJmd0OwogICZsdDsveHM6c2ltcGxlVHlwZSZndDsKCiAgJmx0O3hz OmF0dHJpYnV0ZUdyb3VwIG5hbWU9InNvdXJjZSImZ3Q7CiAgICAmbHQ7eHM6YXR0cmlidXRlIG5h bWU9InNvdXJjZSIgdHlwZT0iYXBwVW5pcXVlU3RyaW5nIiB1c2U9InJlcXVpcmVkIi8mZ3Q7CiAg Jmx0Oy94czphdHRyaWJ1dGVHcm91cCZndDsKCiAgJmx0O3hzOmVsZW1lbnQgbmFtZT0ic2Vydmlj ZUxpc3QiJmd0OwogICAgJmx0O3hzOnNpbXBsZVR5cGUmZ3Q7CiAgICAgICZsdDt4czpsaXN0IGl0 ZW1UeXBlPSJ4czphbnlVUkkiLyZndDsKICAgICZsdDsveHM6c2ltcGxlVHlwZSZndDsKICAmbHQ7 L3hzOmVsZW1lbnQmZ3Q7CgogICZsdDt4czpncm91cCBuYW1lPSJub3RMb3N0IiZndDsKICAgICZs dDt4czphbm5vdGF0aW9uJmd0OwogICAgICAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAg ICBBbnkgZWxlbWVudCBub3QgaW4gdGhlIExvU1QgbmFtZXNwYWNlLgogICAgICAmbHQ7L3hzOmRv Y3VtZW50YXRpb24mZ3Q7CiAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAmbHQ7eHM6Y2hv aWNlJmd0OwogICAgICAmbHQ7eHM6YW55IG5hbWVzcGFjZT0iIyNvdGhlciIgcHJvY2Vzc0NvbnRl bnRzPSJza2lwIi8mZ3Q7CiAgICAgICZsdDt4czphbnkgbmFtZXNwYWNlPSIjI2xvY2FsIiBwcm9j ZXNzQ29udGVudHM9InNraXAiLyZndDsKICAgICZsdDsveHM6Y2hvaWNlJmd0OwogICZsdDsveHM6 Z3JvdXAmZ3Q7CgogICZsdDt4czpncm91cCBuYW1lPSJhbnlFbGVtZW50IiZndDsKICAgICZsdDt4 czphbm5vdGF0aW9uJmd0OwogICAgICAmbHQ7eHM6ZG9jdW1lbnRhdGlvbiZndDsKICAgICAgICBB IHdpbGRjYXJkIHBhdHRlcm4gZm9yIGluY2x1ZGluZyBhbnkgZWxlbWVudAogICAgICAgIGZyb20g YW55IG90aGVyIG5hbWVzcGFjZS4KICAgICAgJmx0Oy94czpkb2N1bWVudGF0aW9uJmd0OwogICAg Jmx0Oy94czphbm5vdGF0aW9uJmd0OwogICAgJmx0O3hzOnNlcXVlbmNlJmd0OwogICAgICAmbHQ7 eHM6YW55IHByb2Nlc3NDb250ZW50cz0ic2tpcCIKICAgICAgICAgIG1pbk9jY3Vycz0iMCIgbWF4 T2NjdXJzPSJ1bmJvdW5kZWQiLyZndDsKICAgICZsdDsveHM6c2VxdWVuY2UmZ3Q7CiAgJmx0Oy94 czpncm91cCZndDsKCiAgJmx0O3hzOmF0dHJpYnV0ZUdyb3VwIG5hbWU9ImFueUVsZW1lbnQiJmd0 OwogICAgJmx0O3hzOmFubm90YXRpb24mZ3Q7CiAgICAgICZsdDt4czpkb2N1bWVudGF0aW9uJmd0 OwogICAgICAgIEEgd2lsZGNhcmQgcGF0dGVybiBmb3IgaW5jbHVkaW5nIGFueSBlbGVtZW50CiAg ICAgICAgZnJvbSBhbnkgb3RoZXIgbmFtZXNwYWNlLgogICAgICAmbHQ7L3hzOmRvY3VtZW50YXRp b24mZ3Q7CiAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAmbHQ7eHM6YW55QXR0cmlidXRl IHByb2Nlc3NDb250ZW50cz0ic2tpcCIvJmd0OwogICZsdDsveHM6YXR0cmlidXRlR3JvdXAmZ3Q7 CgogICZsdDt4czpncm91cCBuYW1lPSJleHRlbnNpb25Qb2ludCImZ3Q7CiAgICAmbHQ7eHM6YW5u b3RhdGlvbiZndDsKICAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICAgQSBwb2lu dCB3aGVyZSBmdXR1cmUgZXh0ZW5zaW9ucwogICAgICAgIChlbGVtZW50cyBmcm9tIG90aGVyIG5h bWVzcGFjZXMpCiAgICAgICAgY2FuIGJlIGFkZGVkLgogICAgICAmbHQ7L3hzOmRvY3VtZW50YXRp b24mZ3Q7CiAgICAmbHQ7L3hzOmFubm90YXRpb24mZ3Q7CiAgICAmbHQ7eHM6c2VxdWVuY2UmZ3Q7 CiAgICAgICZsdDt4czpncm91cCByZWY9Im5vdExvc3QiCiAgICAgICAgICAgbWluT2NjdXJzPSIw IiBtYXhPY2N1cnM9InVuYm91bmRlZCIvJmd0OwogICAgJmx0Oy94czpzZXF1ZW5jZSZndDsKICAm bHQ7L3hzOmdyb3VwJmd0OwoKJmx0Oy94czpzY2hlbWEmZ3Q7CjwvYXJ0d29yaz48L2ZpZ3VyZT48 L3NlY3Rpb24+CiAgICA8c2VjdGlvbiBhbmNob3I9ImV4dFNjaGVtYSIgdGl0bGU9IkV4dGVuc2lv biBYTUwgU2NoZW1hIj4KPHQ+VGhpcyBzY2hlbWEgcHJvdmlkZXMgdGhlIGV4dGVuc2lvbiB0byB0 aGUgcHJpb3Igc2VjdGlvbiBzY2hlbWEgZm9yIHBsYW5uZWQgY2hhbmdlczo8L3Q+CjxmaWd1cmU+ PGFydHdvcms+CiZsdDs/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8mZ3Q7CiZs dDt4czpzY2hlbWEgeG1sbnM6eHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIgog ICAgICAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmxvc3RQbGFubmVkQ2hhbmdl MSIKICAgICAgICAgICB0YXJnZXROYW1lc3BhY2U9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bG9z dFBsYW5uZWRDaGFuZ2UxIgogICAgICAgICAgIGVsZW1lbnRGb3JtRGVmYXVsdD0icXVhbGlmaWVk IiZndDsKICAgICAmbHQ7IS0tIEltcG9ydCBiYXNlIExvc3QgLS0mZ3Q7CiAgICAgJmx0O3hzOmlt cG9ydCBuYW1lc3BhY2U9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bG9zdDEiLyZndDsKJmx0OyEt LSBleHRlbmQgdGhlIGV4dGVuc2lvblBvaW50IG9mIGNvbW1vblJlcXVlc3RQYXR0ZXJuIG9mIGZp bmRTZXJ2aWNlCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB0byBpbmNsdWRlOiAgLS0mZ3Q7CiAgICAgICAgeHM6Z3JvdXAgcmVmPSJwbGFubmVk Q2hhbmdlIiBtaW5PY2N1cnM9IjEiLyZndDsKCiZsdDshLS0gd2hlcmUgLS0mZ3Q7CiAgICAgICAm bHQ7eHM6Z3JvdXAgbmFtZT0icGxhbm5lZENoYW5nZSImZ3Q7CiAgICAgICAgICAgJmx0O3hzOnNl cXVlbmNlJmd0OwogICAgICAgICAgICAgICZsdDt4czplbGVtZW50IHJlZj0idXJpIiB0eXBlPSJ4 czphbnlVUkkiIC8mZ3Q7CiAgICAgICAgICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJpbnZhbGlk QXNPZiIgdHlwZT0ieHM6ZGF0ZVRpbWUiIC8mZ3Q7CiAgICAgICAgICAgICAgJmx0O3hzOmFueSBu YW1lc3BhY2U9IiMjb3RoZXIiIHByb2Nlc3NDb250ZW50cz0ibGF4IgogICAgICAgICAgICAgICAg IG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLyZndDsKICAgICAgICAgICAmbHQ7 L3hzOnNlcXVlbmNlJmd0OwogICAgICAgICZsdDsveHM6Z3JvdXAmZ3Q7CgombHQ7IS0tIGV4dGVu ZCB0aGUgZXh0ZW5zaW9uUG9pbnQgb2YgY29tbW9uUmVzcG9uc2VQYXR0ZXJuIGluCiAgICAgICAg ICAgICAgICAgICAgICAgICAgZmluZFNlcnZpY2VSZXNwb25zZSB0byBpbmNsdWRlOiAtLSZndDsK ICAgICAgICAgICAmbHQ7eHM6YXR0dHJpYnV0ZSBuYW1lPSJhc09mIiB0eXBlPSJ4czpkYXRlVGlt ZSIgbWluT2NjdXJzPSIwIi8mZ3Q7CiAgICAgICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJ0dGwi IHR5cGU9ImV4cGlyZXMiIG1pbk9jY3Vycz0iMCIgLyZndDsKCiZsdDshLS0gZXh0ZW5kIHRoZSBl eHRlbnNpb25Qb2ludCBvZiBleHRlbnNpb25Db250YWluZXIgdG8gaW5jbHVkZTogLS0mZ3Q7CiAg ICAgICAgICAgJmx0O3hzOmVsZW1lbnQgcmVmPSJ1cmlOb3RTdG9yZWQiLyZndDsKJmx0OyEtLSB3 aGVyZSAtLSZndDsKICAgICAgICAgICAmbHQ7eHM6ZWxlbWVudCBuYW1lPSJ1cmlOb3RTdG9yZWQi IHR5cGU9ImJhc2ljRXhjZXB0aW9uIi8mZ3Q7CiAgICAgICAgICAgCgoKJmx0Oy94czpzY2hlbWEm Z3Q7CjwvYXJ0d29yaz48L2ZpZ3VyZT48L3NlY3Rpb24+CiAgICA8c2VjdGlvbiBhbmNob3I9Imxv Y2F0aW9uSW52YWxpZGF0ZWQiIHRpdGxlPSJsb2NhdGlvbkludmFsaWRhdGVkIFNjaGVtYSI+Cjx0 PlRoaXMgc2NoZW1hIGRlZmluZXMgdGhlIG9iamVjdCB1c2VkIGZvciB0aGUgbm90aWZpY2F0aW9u IHRoYXQgYSBsb2NhdGlvbiBpcyBwb3RlbnRpYWxseSBpbnZhbGlkYXRlZCBzZW50IGJ5IGEgTG9T VCBzZXJ2ZXIgdG8gYSBjbGllbnQgdGhhdCByZXF1ZXN0ZWQgaXQuPC90Pgo8ZmlndXJlPjxhcnR3 b3JrPgombHQ7P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/Jmd0OwombHQ7eHM6 c2NoZW1hIHhtbG5zOnhzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIKICAgIHht bG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmxvc3RMb2NhdGlvbkludmFsaWRhdGVkMSIKICAg IHRhcmdldE5hbWVzcGFjZT0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpsb3N0TG9jYXRpb25JbnZh bGlkYXRlZDEiCiAgICBlbGVtZW50Rm9ybURlZmF1bHQ9InF1YWxpZmllZCImZ3Q7CiAmbHQ7eHM6 ZWxlbWVudCBuYW1lPSJsb2NhdGlvbkludmFsaWRhdGVkIiZndDsKICAgJmx0O3hzOmFubm90YXRp b24mZ3Q7CiAgICAgJmx0O3hzOmRvY3VtZW50YXRpb24mZ3Q7CiAgICAgICBBIHBvaW50IHdoZXJl IGZ1dHVyZSBleHRlbnNpb25zCiAgICAgICAoZWxlbWVudHMgZnJvbSBvdGhlciBuYW1lc3BhY2Vz KQogICAgICAgY2FuIGJlIGFkZGVkLgogICAgICZsdDsveHM6ZG9jdW1lbnRhdGlvbiZndDsKICAg Jmx0Oy94czphbm5vdGF0aW9uJmd0OwogICAgICZsdDt4czpjb21wbGV4VHlwZSZndDsKICAgICAg Jmx0O3hzOnNlcXVlbmNlJmd0OwogICAgICAgICZsdDt4czpncm91cCByZWY9Im5vdExvc3QiCiAg ICAgICAgICAgIG1pbk9jY3Vycz0iMCIgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiLyZndDsKICAgICAg Jmx0Oy94czpzZXF1ZW5jZSZndDsKICAgICAgJmx0O3hzOmF0dHJpYnV0ZSBuYW1lPSJhc09mIiB0 eXBlPSJ4czpkYXRlVGltZSIvJmd0OwoKJmx0Oy94czpzY2hlbWEmZ3Q7CjwvYXJ0d29yaz48L2Zp Z3VyZT48L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gYW5jaG9yPSJzZWN1cml0eSIgdGl0bGU9IlNl Y3VyaXR5IENvbnNpZGVyYXRpb25zIj4KICAgICAgPHQ+QXMgYW4gZXh0ZW5zaW9uIHRvIExvU1Qs IHRoaXMgZG9jdW1lbnQgaW5oZXJpdHMgdGhlIHNlY3VyaXR5IGlzc3VlcyByYWlzZWQgaW4gPHhy ZWYgdGFyZ2V0PSJSRkM1MjIyIi8+LiAgVGhlIHNlcnZlciBjb3VsZCBiZSB0cmlja2VkIGludG8g c3RvcmluZyBhIG1hbGljaW91cyBVUkkgd2hpY2gsIHdoZW4gc2VudCB0aGUgbG9jYXRpb25JbnZh bGlkYXRlZCBvYmplY3QgY291bGQgdHJpZ2dlciBzb21ldGhpbmcgdW50b3dhcmQuICBUaGUgc2Vy dmVyIE1VU1QgTk9UIGFjY2VwdCBhbnkgZGF0YSBmcm9tIHRoZSBjbGllbnQgaW4gcmVzcG9uc2Ug dG8gUE9TVGluZyB0aGUgbG9jYXRpb25JbnZhbGlkYXRlZC48L3Q+CgogICAgICA8dD5UaGUgc2Vy dmVyIGlzIHN1YmplY3QgdG8gYWJ1c2UgYnkgY2xpZW50cyBiZWNhdXNlIGl0IGlzIGJlaW5nIGFz a2VkIHRvIHN0b3JlIHNvbWV0aGluZyBhbmQgbWF5IG5lZWQgdG8gc2VuZCBkYXRhIHRvIGFuIHVu Y29udHJvbGxlZCBVUkkuICBDbGllbnRzIGNvdWxkIHJlcXVlc3QgbWFueSBVUklzIGZvciB0aGUg c2FtZSBsb2NhdGlvbiwgZm9yIGV4YW1wbGUuICBUaGUgc2VydmVyIE1VU1QgaGF2ZSBwb2xpY3kg dGhhdCBsaW1pdHMgdXNlIG9mIHRoaXMgbWVjaGFuaXNtIGJ5IGEgZ2l2ZW4gY2xpZW50LiAgSWYg dGhlIHBvbGljeSBpcyBleGNlZWRlZCwgdGhlIHNlcnZlciByZXR1cm5zIHRoZSAndXJpTm90U3Rv cmVkJyB3YXJuaW5nLiAgVGhlIHNlcnZlciBNVVNUIHZhbGlkYXRlIHRoYXQgdGhlIGNvbnRlbnQg b2YgdGhlICd1cmknIGF0dHJpYnV0ZSBzZW50IGlzIHN5bnRhY3RpY2FsbHkgdmFsaWQgYW5kIG1l ZXRzIHRoZSAyNTYgYnl0ZXMgbGltaXQuICBXaGVuIHNlbmRpbmcgdGhlIGxvY2F0aW9uSW52YWxp ZGF0ZWQgb2JqZWN0IHRvIHRoZSBVUkkgc3RvcmVkLCB0aGUgc2VydmVyIE1VU1QgcHJvdGVjdCBp dHNlbGYgYWdhaW5zdCBjb21tb24gSFRUUCB2dWxuZXJhYmlsaXRpZXMuCiAgICAgIDwvdD4KICAg IDx0PlRoZSBtdXR1YWwgYXV0aGVudGljYXRpb24gYmV0d2VlbiBjbGllbnQgYW5kIHNlcnZlciBp cyBSRUNPTU1FTkRFRCBmb3IgYm90aCB0aGUgaW5pdGlhbCAmbHQ7ZmluZFNlcnZpY2UmZ3Q7IG9w ZXJhdGlvbiB0aGF0IHJlcXVlc3RzIHN0b3JpbmcgdGhlIFVSSSBhbmQgdGhlIHNlbmRpbmcgb2Yg dGhlICdsb2NhdGlvbkludmFsaWRhdGVkJyBvYmplY3QuICBUaGUgc2VydmVyIHNob3VsZCBiZSB3 ZWxsIGtub3duIHRvIHRoZSBjbGllbnQsIGFuZCBpdHMgY3JlZGVudGlhbCBzaG91bGQgYmUgbGVh cm5lZCBpbiBhIHJlbGlhYmxlIHdheS4gIEZvciBleGFtcGxlLCBhIHB1YmxpYyBzYWZldHkgc3lz dGVtIG9wZXJhdGluZyB0aGUgTG9TVCBzZXJ2ZXIgbWF5IGhhdmUgYSBjcmVkZW50aWFsIHRyYWNl YWJsZSB0byBhIHdlbGwga25vd24gQ2VydGlmaWNhdGUgQXV0aG9yaXR5IGtub3duIHRvIHByb3Zp ZGUgY3JlZGVudGlhbHMgZm9yIHB1YmxpYyBzYWZldHkgYWdlbmNpZXMuICBDbGllbnRzIG1heSBi ZSBvcGVyYXRlZCBieSBsb2NhbCBJU1BzIG9yIG90aGVyIHNlcnZpY2UgcHJvdmlkZXJzIHRoYXQg Y2FuIHJlYXNvbmFibHkgb2J0YWluIGEgZ29vZCBjcmVkZW50aWFsIHRvIHVzZSBmb3IgdGhlIHNl cnZlciBzaWRlIG9mIHRoZSBMb1NUIHNlcnZlcidzIFBPU1QgdHJhbnNhY3Rpb24gdXNpbmcgdGhl IFVSSS4gIFdoZXJlIHRoZSBsb1NUIHNlcnZlciBkb2VzIG5vdCByZWNvZ25pemUgdGhlIGNsaWVu dCwgaXRzIHBvbGljeSBNQVkgbGltaXQgdGhlIHVzZSBvZiB0aGlzIGZlYXR1cmUgYmV5b25kIHdo YXQgaXQgd291bGQgbGltaXQgYSBjbGllbnQgaXQgcmVjb2duaXplcy48L3Q+CiAgICA8L3NlY3Rp b24+CiAgICA8c2VjdGlvbiBhbmNob3I9ImlhbmEiIHRpdGxlPSJJQU5BIENvbnNpZGVyYXRpb25z Ij4KICAgIDxzZWN0aW9uIHRpdGxlPSJSZXBsYWNlbWVudCBYTUwgU2NoZW1hIFJlZ2lzdHJhdGlv biI+CiAgICA8ZmlndXJlPjxhcnR3b3JrPjwhW0NEQVRBWwogICBVUkk6ICB1cm46aWV0ZjpwYXJh bXM6eG1sOnNjaGVtYTpsb3N0MwogICBSZWdpc3RyYW50IENvbnRhY3Q6ICBJRVRGIEVDUklUIFdv cmtpbmcgR3JvdXAsIEJyaWFuIFJvc2VuCiAgICAgIChickBicmlhbnJvc2VuLm5ldCkuCiAgIFhN TDoKICAgICAgQkVHSU4KICAgICAgPD94bWwgdmVyc2lvbj0iMi4wIj8+CiAgICAgIDwhRE9DVFlQ RSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgWEhUTUwgQmFzaWMgMS4wLy9FTiIKICAgICAgImh0 dHA6Ly93d3cudzMub3JnL1RSL3hodG1sLWJhc2ljL3hodG1sLWJhc2ljMTAuZHRkIj4KICAgICAg PGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiPgogICAgICA8aGVhZD4K ICAgICAgPG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIgogICAgICAgICAgY29udGVudD0i dGV4dC9odG1sO2NoYXJzZXQ9aXNvLTg4NTktMSIvPgogICAgICA8dGl0bGU+TG9TVCBOYW1lc3Bh Y2U8L3RpdGxlPgogICAgICA8L2hlYWQ+CiAgICAgIDxib2R5PgogICAgICA8aDE+TmFtZXNwYWNl IGZvciBMb1NUPC9oMT4KICAgICAgPGgyPnVybjppZXRmOnBhcmFtczp4bWw6bnM6bG9zdDM8L2gy PgogICAgICA8cD5TZWUgPGEgaHJlZj0iaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZj Pz8/Py50eHQiPgogICAgICBSRkM/Pz8/PC9hPi48L3A+CiAgICAgIDwvYm9keT4KICAgICAgPC9o dG1sPgogICAgICBFTkQKICBdXT48L2FydHdvcms+PC9maWd1cmU+CiAgPHQ+ICBUaGUgWE1MIFNj aGVtYSBpcyBmb3VuZCBpbiA8eHJlZiB0YXJnZXQ9InNjaGVtYSIvPi48L3Q+CiA8L3NlY3Rpb24+ CiAgICA8c2VjdGlvbiB0aXRsZT0iUGxhbm5lZCBDaGFuZ2UgRXh0ZW5zaW9uIFhNTCBTY2hlbWEg UmVnaXN0cmF0aW9uIj4KICAgIDxmaWd1cmU+PGFydHdvcms+PCFbQ0RBVEFbCiAgIFVSSTogIHVy bjppZXRmOnBhcmFtczp4bWw6c2NoZW1hOmxvc3RQbGFubmVkQ2hhbmdlMQogICBSZWdpc3RyYW50 IENvbnRhY3Q6ICBJRVRGIEVDUklUIFdvcmtpbmcgR3JvdXAsIEJyaWFuIFJvc2VuCiAgICAgIChi ckBicmlhbnJvc2VuLm5ldCkuCiAgIFhNTDoKCiAgIEJFR0lOCiAgIDw/eG1sIHZlcnNpb249IjIu MCI/PgogICA8IURPQ1RZUEUgaHRtbCBQVUJMSUMgIi0vL1czQy8vRFREIFhIVE1MIEJhc2ljIDEu MC8vRU4iCiAgICAgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sLWJhc2ljL3hodG1sLWJhc2lj MTAuZHRkIj4KICAgPGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiPgog ICA8aGVhZD4KICAgICA8bWV0YSBodHRwLWVxdWl2PSJjb250ZW50LXR5cGUiCiAgICAgICAgICAg Y29udGVudD0idGV4dC9odG1sO2NoYXJzZXQ9aXNvLTg4NTktMSIvPgogICAgIDx0aXRsZT5Mb1NU IFBsYW5uZWQgQ2hhbmdlIE5hbWVzcGFjZTwvdGl0bGU+CiAgIDwvaGVhZD4KICAgPGJvZHk+CiAg ICAgPGgxPk5hbWVzcGFjZSBmb3IgTG9TVCA8L2gxPgogICAgIDxoMj51cm46aWV0ZjpwYXJhbXM6 eG1sOm5zOmxvc3RQbGFubmVkQ2hhbmdlMTwvaDI+CiAgIDxwPlNlZSA8YSBocmVmPSJodHRwOi8v d3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM/Pz8/LnR4dCI+CiAgICAgIFJGQz8/Pz88L2E+Ljwv cD4KICAgPC9ib2R5PgogICA8L2h0bWw+CiAgIEVORAoKICBdXT48L2FydHdvcms+PC9maWd1cmU+ CiAgPHQ+ICBUaGUgWE1MIFNjaGVtYSBpcyBmb3VuZCBpbiA8eHJlZiB0YXJnZXQ9ImV4dFNjaGVt YSIvPi48L3Q+Cjwvc2VjdGlvbj4KCjxzZWN0aW9uIHRpdGxlPSJsb2NhdGlvbkludmFsaWRhdGVk IFhNTCBTY2hlbWEgUmVnaXN0cmF0aW9uIj4KPGZpZ3VyZT48YXJ0d29yaz48IVtDREFUQVsKVVJJ OiAgdXJuOmlldGY6cGFyYW1zOnhtbDpzY2hlbWE6bG9zdExvY2F0aW9uSW52YWxpZGF0ZWQxClJl Z2lzdHJhbnQgQ29udGFjdDogIElFVEYgRUNSSVQgV29ya2luZyBHcm91cCwgQnJpYW4gUm9zZW4K ICAoYnJAYnJpYW5yb3Nlbi5uZXQpLgpYTUw6CgpCRUdJTgo8P3htbCB2ZXJzaW9uPSIyLjAiPz4K PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCBCYXNpYyAxLjAvL0VOIgoi aHR0cDovL3d3dy53My5vcmcvVFIveGh0bWwtYmFzaWMveGh0bWwtYmFzaWMxMC5kdGQiPgo8aHRt bCB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94aHRtbCI+CjxoZWFkPgo8bWV0YSBodHRw LWVxdWl2PSJjb250ZW50LXR5cGUiCiAgICBjb250ZW50PSJ0ZXh0L2h0bWw7Y2hhcnNldD1pc28t ODg1OS0xIi8+Cjx0aXRsZT5Mb1NUIExvY2F0aW9uIEludmFsaWRlZCBOYW1lc3BhY2U8L3RpdGxl Pgo8L2hlYWQ+Cjxib2R5Pgo8aDE+TmFtZXNwYWNlIGZvciBMb1NUIExvY2F0aW9uIEludmFsaWRh dGVkIG5vdGlmaWNhdGlvbjwvaDE+CjxoMj51cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmxvc3RMb2Nh dGlvbkludmFsaWRhdGVkMTwvaDI+CjxwPlNlZSA8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0 b3Iub3JnL3JmYy9yZmM/Pz8/LnR4dCI+ClJGQz8/Pz88L2E+LjwvcD4KPC9ib2R5Pgo8L2h0bWw+ CkVORApdXT48L2FydHdvcms+PC9maWd1cmU+Cjx0PiAgVGhlIFhNTCBTY2hlbWEgaXMgZm91bmQg aW4gPHhyZWYgdGFyZ2V0PSJsb2NhdGlvbkludmFsaWRhdGVkIi8+LjwvdD4KCjwvc2VjdGlvbj48 L3NlY3Rpb24+CiAgIDwvbWlkZGxlPgoKICA8YmFjaz4KCiAgICA8cmVmZXJlbmNlcyB0aXRsZT0i Tm9ybWF0aXZlIFJlZmVyZW5jZXMiPgogICAgICAmUkZDMjExOTsKICAgICAgJlJGQzUyMjI7CiAg ICA8L3JlZmVyZW5jZXM+CiAgPC9iYWNrPgo8L3JmYz4K --=_MailMate_377DAA09-F515-441D-9F06-024008E3CEEA_=-- From nobody Tue Aug 24 17:50:28 2021 Return-Path: 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 486013A1B66 for ; Tue, 24 Aug 2021 17:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=bell.ca 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 16QEJwkdmyEr for ; Tue, 24 Aug 2021 17:50:20 -0700 (PDT) Received: from ESA1-Wyn.bell.ca (esa1-wyn.bell.ca [67.69.243.161]) (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 4DCF83A1B5E for ; Tue, 24 Aug 2021 17:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1629852620; x=1661388620; h=from:to:date:message-id:references:in-reply-to: mime-version:subject; bh=JgE04OBKMTNWCbANmpQN91fj37J05I4IkXJWG8encTs=; b=cq4hNSGjgz8n3Fr1i8ldx/EURjSyB4B+0uzg4mpv83skfgvSmOQGwE+T qvTnwiwD3uClqU2fhvNnJ7eE3iNNDPYOSi2cJJJBADNEEMhSKxOcBYAZX M8L6Ov/SXrvtuvgQR6VaW51/4PtsuW5rFV/Hot55gZj3sH9rlgeoZZRpT VUBDNXM4dp6BHT5IKL5FbOkZiw/jGZ60uqd5CivMxsfgermN1YDuazmYY NXXffooUcVkEXYJWNul3pqKa0q9H6OtIzbjD2Cyb3PA6zd+cWw6KxapNT 5cd3G+pux97bV1VnTuk78EI0gNyeqJnTFGuNUZpZU79Y9jdkVKy2NzV6y A==; IronPort-SDR: N95DZkJ63AaTSFNi7Zpgqjex5RfuY6JntOw0leetiGBmBOsEp17YEjirs5gyfRRZAn07ESsxOK UX/kO4GT2U2A== Received: from dm5cch-d00.bellca.int.bell.ca (HELO DG1MBX02-WYN.bell.corp.bce.ca) ([198.235.102.30]) by esa01corp-wyn.bell.corp.bce.ca with ESMTP; 24 Aug 2021 20:50:18 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG1MBX02-WYN.bell.corp.bce.ca (142.182.18.12) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Tue, 24 Aug 2021 20:50:18 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Tue, 24 Aug 2021 20:50:17 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Tue, 24 Aug 2021 20:50:17 -0400 From: "Caron, Guy" To: Brian Rosen , ECRIT Thread-Topic: [EXT][Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS Thread-Index: AQHXmSPgZWsF4pdx70yGlJDW5eVgsquDZBEo Date: Wed, 25 Aug 2021 00:50:17 +0000 Message-ID: <0dfc5720ba66426780b002678fe46fb3@bell.ca> References: In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: fr-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_0dfc5720ba66426780b002678fe46fb3bellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2021 00:50:27 -0000 --_000_0dfc5720ba66426780b002678fe46fb3bellca_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I recognize the problem but do not like the proposed solutions. I need to think more about this. Guy -------- Message d'origine -------- De : Brian Rosen Date : 2021-08-24 4 h 09 p.m. (GMT-05:00) =C0 : ECRIT Objet : [EXT][Ecrit] Problem in -planned-changes: unique records in LoST se= rver may not match unique records in LIS I realized we have a problem with -planned-changes. The text notes: Each client of the server may only store one URI against a location, where = =93location=94 is defined by policy at the server, since a given unique loc= ation may have many combinations of location elements that resolve to the s= ame location. If the server receives a =91uri=92 for the same location fro= m the same client, the URI in the request replaces the URI it previously re= tained. But this means that multiple records in the LIS may be one record in the Lo= ST server and when the LIS associates unique URIs with what it thinks is mu= ltiple records, only one is retained and it doesn=92t know that. The easiest fix is to return the replaced URI. The client would then be ab= le to spot that the records are linked and do the book keeping to track wha= t it should do. Another way to fix this is to return a unique ID of the record in the LoST = server when you use the extension. The LIS can then keep an internal recor= d of all the related entries it has that are one record to the server. Brian --_000_0dfc5720ba66426780b002678fe46fb3bellca_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I recognize the problem but do not like the proposed solutions.

I need to think more about this.

Guy


-------- Message d'origine --------
De : Brian Rosen <br@brianrosen.net>
Date : 2021-08-24 4 h 09 p.m. (GMT-05:00)
=C0 : ECRIT <ecrit@ietf.org>
Objet : [EXT][Ecrit] Problem in -planned-changes: unique records in Lo= ST server may not match unique records in LIS

I realized we have a problem with -planned-changes.  The text not= es:
Each client of the server may only store one URI against a location, where = =93location=94 is defined by policy at the server, since a given unique loc= ation may have many combinations of location elements that resolve to the s= ame location.  If the server receives a =91uri=92 for the same location from the same client, the URI in the req= uest replaces the URI it previously retained.

But this means that multiple records in the LIS may be one = record in the LoST server and when the LIS associates unique URIs with what= it thinks is multiple records, only one is retained and it doesn=92t know = that.

The easiest fix is to return the replaced URI.  The cl= ient would then be able to spot that the records are linked and do the book= keeping to track what it should do.
Another way to fix this is to return a unique ID of the rec= ord in the LoST server when you use the extension.  The LIS can then k= eep an internal record of all the related entries it has that are one recor= d to the server.  

Brian

--_000_0dfc5720ba66426780b002678fe46fb3bellca_-- From nobody Wed Aug 25 14:51:54 2021 Return-Path: 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 817E13A149A for ; Wed, 25 Aug 2021 14:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, 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 pk0RXM9RKnPZ for ; Wed, 25 Aug 2021 14:51:45 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 778A43A1494 for ; Wed, 25 Aug 2021 14:51:45 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 25 Aug 2021 14:51:44 -0700 From: "Randall Gellens" To: "Brian Rosen" Cc: "Caron, Guy" , ecrit@ietf.org Date: Wed, 25 Aug 2021 14:51:43 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: <83B4F74D-11D0-4AD5-AA6F-B6BFB2E852DB@brianrosen.net> References: <7f40b92699324c7588a8baab528aab36@bell.ca> <3664c600fa824230906807733dbff5ad@bell.ca> <83B4F74D-11D0-4AD5-AA6F-B6BFB2E852DB@brianrosen.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_68492281-6F2B-4775-99AE-72DCF9488F98_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[1203, 22150], "plain":[714, 5123], "uuid":"ACC27D50-D379-449D-9818-00904685E004"}] Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: XML vs RelaxNG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2021 21:51:52 -0000 --=_MailMate_68492281-6F2B-4775-99AE-72DCF9488F98_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit If we go with your option: > So maybe we should normatively update 5222 to say that the RelaxNG is > “replaced by†the xml schema for the purposes of defining new > extensions, but the existing extension definitions in RelaxNG form are > still valid. We should probably try to also at least create an XML schema for LoST-Sync, since that's going to be increasingly needed for emergency services, at least in North America. How much would that delay the draft, or would we want to try and do it in its own document? I'd like to hear from other group members. Especially from anyone who supports this approach and is willing to review the XML schemas. --Randall On 24 Aug 2021, at 11:12, Brian Rosen wrote: > In general, I’d like to deprecate it, but I’m having second > thoughts on the difficulty in doing so. > > If we were to deprecate it, we would have to deal with existing > extensions. I see RFCs 6197, 6451 and 6739 have RelaxNG schemas that > extend LoST. I note that all 3 of these are Experimental. So one > argument is that if we deprecate the RelaxNG schema in 5222, we have > to do that to these extensions, and provide xml schemas to replace > them. I will note that LoST Sync (6739) is going to be heavily > deployed soon. > > So maybe we should normatively update 5222 to say that the RelaxNG is > “replaced by†the xml schema for the purposes of defining new > extensions, but the existing extension definitions in RelaxNG form are > still valid. If someone wanted to help make xml schema replacements > for at least 6739, that would be useful. If we did all 3, then we > probably could deprecate the RelaxNG everywhere. This draft would > have to update those 3 RFCs as well as 5222. > > If we don’t deprecate the RelaxNG, then there is always the > standards issue of what if there is a discrepancy between the xml > schema and the RelaxNG. I think we would have to say that it’s the > RelaxNG, and we would use the errata process to fix the xml schema. > > The thing to keep in mind is that every implementor I know is using > xml schemas, however they get them, to build their code. The practical > answer is that everyone needs xml schemas and no one needs RelaxNG. > > Brian > > >> On Aug 24, 2021, at 1:48 PM, Caron, Guy wrote: >> >> Thanks for pointing me to this email. My search somehow did not find >> this one. >> >> Reading the comments, it seems to me that the commenter is not >> totally adverse to the idea of making a normative change towards the >> XML schema. >> >> I’m not familiar enough with the process to determine if or how the >> RelaxNG version of the LoST schema can be deprecated. I can live with >> a normative XML version to which any further extensions (or updates) >> attach to and leave the initial RelaxNG schema becoming organically >> outdated and useless. >> >> Thanks, >> >> Guy >> >> De : Brian Rosen >> Envoyé : 23 août 2021 17:12 >> À : Caron, Guy >> Cc : ecrit@ietf.org >> Objet : [EXT]Re: lost-planned-changes-04: XML vs RelaxNG >> >> https://mailarchive.ietf.org/arch/msg/ecrit/oTPSzxsLp3YNy8J6HOwYjxdx1bI/ >> >> >> If we don’t deprecate the RelaxNG schema, shouldn’t extensions >> have to provide Relax NG? That’s my setf serving reason to >> deprecate it. I guess we could not actually deprecate it, but >> normatively update 5222 to say that extensions should reference the >> xml schema. >> >> Brian >> >> >> >> >> On Aug 23, 2021, at 4:59 PM, Caron, Guy > > wrote: >> >> If you refer to general comments made in the early days of LoST, some >> 15 years ago, I guess time tells that RelaxNG did not ramp up as >> expected. >> >> I can’t find comments on the ECRIT list specific to planned-changes >> asking for XML schemas to be informative while updating RFC5222. >> >> I agree with your sentiment that XML schemas should be a normative >> alternative (i.e., does not deprecates) to RelaxNG. >> >> Besides, by not providing RelaxNG equivalents for the extensions, >> isn’t that what you are doing anyway? >> >> Thanks, >> >> Guy >> >> De : Brian Rosen > >> Envoyé : 23 août 2021 16:37 >> À : Caron, Guy > >> Cc : ecrit@ietf.org >> Objet : [EXT]Re: lost-planned-changes-04: XML vs RelaxNG >> >> We have had comments suggesting it be non normative, which is why it >> says what it does now. >> >> My personal view is that it should replace the Relax NG schema, and >> any subsequent changes and extensions should only reference this one. >> No one that I know uses the Relax NG schema one way or another they >> get an xml schema and use that. >> >> But I will go with whatever the consensus is >> >> Brian >> >> On Mon, Aug 23, 2021 at 4:32 PM Caron, Guy > > wrote: >> In section 7, the replacement XML schema is qualified as an >> “informative alternative†however, the text in the Intro states >> “Alternative schemas have been circulated, which is undesirable, as >> they may not be in conformance to the RelaxNG schema in [RFC5222]. >> This document provides an XML schema that replaces the RelaxNG >> schema. It can be used by any implementation interchangeably with the >> RelaxNG schema.†>> >> The latter seems to indicate that the XML schema in section 7 is a >> normative alternative rather than an informative one. >> >> I think this is what we want but the text must be adjusted >> accordingly. >> >> Thanks, >> >> Guy >> External Email: Please use caution when opening links and attachments >> / Courriel externe: Soyez prudent avec les liens et documents joints >> >> External Email: Please use caution when opening links and attachments >> / Courriel externe: Soyez prudent avec les liens et documents joints > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --=_MailMate_68492281-6F2B-4775-99AE-72DCF9488F98_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

______________________= _________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

--=_MailMate_68492281-6F2B-4775-99AE-72DCF9488F98_=-- From nobody Wed Aug 25 14:56:56 2021 Return-Path: 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 A8B3B3A150D for ; Wed, 25 Aug 2021 14:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, 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 t5fTyZoQVEdQ for ; Wed, 25 Aug 2021 14:56:49 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id ABBEA3A1514 for ; Wed, 25 Aug 2021 14:56:49 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 25 Aug 2021 14:56:49 -0700 From: "Randall Gellens" To: "Brian Rosen" Cc: ECRIT Date: Wed, 25 Aug 2021 14:56:48 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <1120BD41-A143-4AC1-B1A7-6CFF40658FF7@randy.pensive.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2021 21:56:55 -0000 Either approach would work: the server returning the prior URI if it replaces it, or the server always returning a "unique location ID" whenever it stores a URI. In the latter case, we'd want to add this ID to the object. The latter seems a bit cleaner, as then the server always returns an ID, and a client always stores this ID whenever it sends a URI, and uses the ID to re-validate locations when it gets a object. --Randall On 24 Aug 2021, at 13:08, Brian Rosen wrote: > I realized we have a problem with -planned-changes. The text notes: > Each client of the server may only store one URI against a location, > where “location†is defined by policy at the server, since a given > unique location may have many combinations of location elements that > resolve to the same location. If the server receives a ‘uri’ for > the same location from the same client, the URI in the request > replaces the URI it previously retained. > > But this means that multiple records in the LIS may be one record in > the LoST server and when the LIS associates unique URIs with what it > thinks is multiple records, only one is retained and it doesn’t know > that. > > The easiest fix is to return the replaced URI. The client would then > be able to spot that the records are linked and do the book keeping to > track what it should do. > Another way to fix this is to return a unique ID of the record in the > LoST server when you use the extension. The LIS can then keep an > internal record of all the related entries it has that are one record > to the server. > > Brian > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Wed Aug 25 14:58:38 2021 Return-Path: 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 B28EB3A1547 for ; Wed, 25 Aug 2021 14:58:35 -0700 (PDT) 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.20150623.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 hzi2QoEcOwZD for ; Wed, 25 Aug 2021 14:58:29 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 ADADF3A1542 for ; Wed, 25 Aug 2021 14:58:29 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id y18so1000483ioc.1 for ; Wed, 25 Aug 2021 14:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fDK0Gk46zhxDfzwKFE53GR65WoanKQvOPnPWprsDsxE=; b=s/UIvKfHsq6Unwzj+zie6l3bWaQhvUOTPpVHVUwSLh+AuiRjyOxV4LMumhKyXKmNyZ o5RTMx2yN00rRUSKTKH+cC+QwXdhmqeh/IDX9Tc8S3W3DQ5MJPYuDTauCcQt9tQDKw2V rFyJ+zjFI2W0bu3Zw1Q3yOX8B9J77tcYxn7krH2HiGH67dpnmR61TzCctszPXDOqUGix 0NUDAV/MHVMd5hFcqLk0O4yQoiuOI6+fXb4Ajt2uFNFgdheavuJSwsiGx1y1bt43FjiF gSqXW3uOYNJo0OV+1OLeZ+yphFx6bxWHKfkOK8hKrjYfHoSnQCEBV//X/2aXlY16ZvL2 ywmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fDK0Gk46zhxDfzwKFE53GR65WoanKQvOPnPWprsDsxE=; b=AHjy0pE/8APyNN40BObwXAWdrc48JflC8YqirA523c8i9L/ZKthCM9AXttNVRGOCMh jgMc3pwLPHvIDskSEBRKH2wfJ0m4HGWZHu+As6I9eYgYHnOXVQFVWuStLzuKpAsXhdc2 2yFjg4dzFeUl0o0NIbQY1lgfWb4ISE+JIZWr6TGhxL9yI68mFkfZdxPjwSq6sXIbeF2S 6Sfdg07fyBwLB2I/fZZQ1GsdrWf6XNLn/M/0/vOkOnCHuvbQeHTpraOX380TuxHcKofj RgAIaO4XOKSi8NnnW8XuPwOfUV705vpQUi+46VX51rmNBr3HrGvNBh8y8Zf9qqR8Oy78 9f2A== X-Gm-Message-State: AOAM530jI00c6ofoQO7wna9fxi7c/6xeKOjMI5//t4EVhHRzxX4ae0iC qNeDz81xj+7MwXZmlV7F3QtpoVfHsjl6e2dX X-Google-Smtp-Source: ABdhPJx14EtJZAaVX4ienJDFYqa7W0cYq4ff30mSE1Il5Eh/rRDj5uogdBCm+zcsSh3GjhcDUEQBew== X-Received: by 2002:a6b:7a03:: with SMTP id h3mr498896iom.39.1629928707742; Wed, 25 Aug 2021 14:58:27 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id f5sm685010ils.3.2021.08.25.14.58.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Aug 2021 14:58:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Brian Rosen In-Reply-To: <1120BD41-A143-4AC1-B1A7-6CFF40658FF7@randy.pensive.org> Date: Wed, 25 Aug 2021 17:58:26 -0400 Cc: ECRIT Content-Transfer-Encoding: quoted-printable Message-Id: <26184A64-2B40-4230-A09B-9A2D00D5F150@brianrosen.net> References: <1120BD41-A143-4AC1-B1A7-6CFF40658FF7@randy.pensive.org> To: Randall Gellens X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2021 21:58:36 -0000 Yeah, of the two options, I like the second. I would like to wait to = here from Guy, who didn=E2=80=99t like either. Either of the two I came up with can be added quickly to the doc. Brian > On Aug 25, 2021, at 5:56 PM, Randall Gellens = wrote: >=20 > Either approach would work: the server returning the prior URI if it = replaces it, or the server always returning a "unique location ID" = whenever it stores a URI. In the latter case, we'd want to add this ID = to the object. The latter seems a bit cleaner, as = then the server always returns an ID, and a client always stores this ID = whenever it sends a URI, and uses the ID to re-validate locations when = it gets a object. >=20 > --Randall >=20 > On 24 Aug 2021, at 13:08, Brian Rosen wrote: >=20 >> I realized we have a problem with -planned-changes. The text notes: >> Each client of the server may only store one URI against a location, = where =E2=80=9Clocation=E2=80=9D is defined by policy at the server, = since a given unique location may have many combinations of location = elements that resolve to the same location. If the server receives a = =E2=80=98uri=E2=80=99 for the same location from the same client, the = URI in the request replaces the URI it previously retained. >>=20 >> But this means that multiple records in the LIS may be one record in = the LoST server and when the LIS associates unique URIs with what it = thinks is multiple records, only one is retained and it doesn=E2=80=99t = know that. >>=20 >> The easiest fix is to return the replaced URI. The client would then = be able to spot that the records are linked and do the book keeping to = track what it should do. >> Another way to fix this is to return a unique ID of the record in the = LoST server when you use the extension. The LIS can then keep an = internal record of all the related entries it has that are one record to = the server. >>=20 >> Brian >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit From nobody Wed Aug 25 14:59:40 2021 Return-Path: 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 ADCF13A1568 for ; Wed, 25 Aug 2021 14:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, 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.20150623.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 90xx-_CseOIG for ; Wed, 25 Aug 2021 14:59:32 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 6B52C3A155D for ; Wed, 25 Aug 2021 14:59:32 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id x5so1080364ill.3 for ; Wed, 25 Aug 2021 14:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Lz5THzGrVffvRX0ppByTpwwS/ncbRJeRZIkdaBkKzD8=; b=Lkg6s8fwAH+E4+n8eNehv+i34KOGw3meB6KP4mH7R0a/U1m+NLsBuZNMaAfzdOw4Iz xPkvYjnSzNNHlbCOGBPd8Y13OjXDgMp/YBKet0Lwgb6n7LAbRKGKSwBLAAM4wyXuZZtl tfyS7+QgCRFOdz1NPRuJNEQJIXfdOKDeElFa2q5yYVcEuLV/s42PyVmje8tZF5iJhOuE Zc/fGQyfQ48zaltoyrzLS7xo+oUPMVgRyUT4d7zx31L6OR91UaC/pbu7eDW7YZ3jWq3R fpptXY5InpPQO2WecsxwG+OIo14vmvbcym6qhsDo71G9fvUlcm05DnqBi9Erd79ILwKp qibg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Lz5THzGrVffvRX0ppByTpwwS/ncbRJeRZIkdaBkKzD8=; b=ln/KGdo1js34H0R8QWs2N5cR8U9H2YxtIERfZM5BLRM8F5WIcAVHZOqTxsG8Jpkc0S OrWWM/yK7N152Pj5KsiD2Mp/5/DZP9uBe4AfWwtbHdvYAOMktY+6ubqiXusFIM0+gXXm +FDBGmeCoT6aPJPqUWeLAal5US3fRkjQyr34SYTKrPBUhUvw1glUwtUIv9F8AMvjBOCc jk7Jeq3LYN5aHdhOxynQw2FaNgCPfSbvoj3YclSBVaT1lPrFj67/MelEvJHayJiF47dP XwJtZBZNS/BXUwp8hIMYkcLaZdiQEfNi07K7iCfR19uLBdi7DMJ8BOdgOPLkLoGYvkua Tlng== X-Gm-Message-State: AOAM532nlrA7Ys/c3EYM0bWBxLA+9xdIcdLswY1Hp7TnhPHr2x8WbRXL U/F/Oa8SVBdE108QdQXZPBYk6w== X-Google-Smtp-Source: ABdhPJzeUsqVcz48qCraNEpGE4xo7DnHlFjoUGj6yv7wHSumgFnQPkiXimHelk0kP1/1gUlJlLs0Kg== X-Received: by 2002:a92:7304:: with SMTP id o4mr336957ilc.75.1629928770513; Wed, 25 Aug 2021 14:59:30 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id g12sm543988iok.32.2021.08.25.14.59.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Aug 2021 14:59:29 -0700 (PDT) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4BCBB8BD-4B45-4846-8F02-323B5104CB4E" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Wed, 25 Aug 2021 17:59:28 -0400 In-Reply-To: Cc: "Caron, Guy" , ecrit@ietf.org To: Randall Gellens References: <7f40b92699324c7588a8baab528aab36@bell.ca> <3664c600fa824230906807733dbff5ad@bell.ca> <83B4F74D-11D0-4AD5-AA6F-B6BFB2E852DB@brianrosen.net> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Ecrit] lost-planned-changes-04: XML vs RelaxNG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2021 21:59:39 -0000 --Apple-Mail=_4BCBB8BD-4B45-4846-8F02-323B5104CB4E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree. I=E2=80=99m willing to work on LoST-Sync schemas but need help = because my xml-fu is pretty weak. Brian > On Aug 25, 2021, at 5:51 PM, Randall Gellens = wrote: >=20 > If we go with your option: >=20 > So maybe we should normatively update 5222 to say that the RelaxNG is = =E2=80=9Creplaced by=E2=80=9D the xml schema for the purposes of = defining new extensions, but the existing extension definitions in = RelaxNG form are still valid. >=20 > We should probably try to also at least create an XML schema for = LoST-Sync, since that's going to be increasingly needed for emergency = services, at least in North America. How much would that delay the = draft, or would we want to try and do it in its own document? >=20 > I'd like to hear from other group members. Especially from anyone who = supports this approach and is willing to review the XML schemas. >=20 >=20 > --Randall >=20 > On 24 Aug 2021, at 11:12, Brian Rosen wrote: >=20 > In general, I=E2=80=99d like to deprecate it, but I=E2=80=99m having = second thoughts on the difficulty in doing so. >=20 > If we were to deprecate it, we would have to deal with existing = extensions. I see RFCs 6197, 6451 and 6739 have RelaxNG schemas that = extend LoST. I note that all 3 of these are Experimental. So one = argument is that if we deprecate the RelaxNG schema in 5222, we have to = do that to these extensions, and provide xml schemas to replace them. I = will note that LoST Sync (6739) is going to be heavily deployed soon. =20= >=20 > So maybe we should normatively update 5222 to say that the RelaxNG is = =E2=80=9Creplaced by=E2=80=9D the xml schema for the purposes of = defining new extensions, but the existing extension definitions in = RelaxNG form are still valid. If someone wanted to help make xml schema = replacements for at least 6739, that would be useful. If we did all 3, = then we probably could deprecate the RelaxNG everywhere. This draft = would have to update those 3 RFCs as well as 5222. >=20 > If we don=E2=80=99t deprecate the RelaxNG, then there is always the = standards issue of what if there is a discrepancy between the xml schema = and the RelaxNG. I think we would have to say that it=E2=80=99s the = RelaxNG, and we would use the errata process to fix the xml schema. >=20 > The thing to keep in mind is that every implementor I know is using = xml schemas, however they get them, to build their code. The practical = answer is that everyone needs xml schemas and no one needs RelaxNG. >=20 > Brian >=20 >=20 >> On Aug 24, 2021, at 1:48 PM, Caron, Guy > wrote: >>=20 >> Thanks for pointing me to this email. My search somehow did not find = this one. >> =20 >> Reading the comments, it seems to me that the commenter is not = totally adverse to the idea of making a normative change towards the XML = schema. >> =20 >> I=E2=80=99m not familiar enough with the process to determine if or = how the RelaxNG version of the LoST schema can be deprecated. I can live = with a normative XML version to which any further extensions (or = updates) attach to and leave the initial RelaxNG schema becoming = organically outdated and useless. >> =20 >> Thanks, >> =20 >> Guy >> =20 >> De : Brian Rosen >=20 >> Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:12 >> =C3=80 : Caron, Guy > >> Cc : ecrit@ietf.org >> Objet : [EXT]Re: lost-planned-changes-04: XML vs RelaxNG >> =20 >> = https://mailarchive.ietf.org/arch/msg/ecrit/oTPSzxsLp3YNy8J6HOwYjxdx1bI/ = = >> =20 >> If we don=E2=80=99t deprecate the RelaxNG schema, shouldn=E2=80=99t = extensions have to provide Relax NG? That=E2=80=99s my setf serving = reason to deprecate it. I guess we could not actually deprecate it, = but normatively update 5222 to say that extensions should reference the = xml schema. >> =20 >> Brian >> =20 >> =20 >>=20 >>=20 >> On Aug 23, 2021, at 4:59 PM, Caron, Guy > wrote: >> =20 >> If you refer to general comments made in the early days of LoST, some = 15 years ago, I guess time tells that RelaxNG did not ramp up as = expected. >> =20 >> I can=E2=80=99t find comments on the ECRIT list specific to = planned-changes asking for XML schemas to be informative while updating = RFC5222. >> =20 >> I agree with your sentiment that XML schemas should be a normative = alternative (i.e., does not deprecates) to RelaxNG. >> =20 >> Besides, by not providing RelaxNG equivalents for the extensions, = isn=E2=80=99t that what you are doing anyway? >> =20 >> Thanks, >> =20 >> Guy >> =20 >> De : Brian Rosen >=20 >> Envoy=C3=A9 : 23 ao=C3=BBt 2021 16:37 >> =C3=80 : Caron, Guy > >> Cc : ecrit@ietf.org >> Objet : [EXT]Re: lost-planned-changes-04: XML vs RelaxNG >> =20 >> We have had comments suggesting it be non normative, which is why it = says what it does now.=20 >> =20 >> My personal view is that it should replace the Relax NG schema, and = any subsequent changes and extensions should only reference this one. No = one that I know uses the Relax NG schema one way or another they get an = xml schema and use that.=20 >> =20 >> But I will go with whatever the consensus is =20 >> =20 >> Brian >> =20 >> On Mon, Aug 23, 2021 at 4:32 PM Caron, Guy > wrote: >> In section 7, the replacement XML schema is qualified as an = =E2=80=9Cinformative alternative=E2=80=9D however, the text in the Intro = states =E2=80=9CAlternative schemas have been circulated, which is = undesirable, as they may not be in conformance to the RelaxNG schema in = [RFC5222]. This document provides an XML schema that replaces the = RelaxNG schema. It can be used by any implementation interchangeably = with the RelaxNG schema.=E2=80=9D >> =20 >> The latter seems to indicate that the XML schema in section 7 is a = normative alternative rather than an informative one. >> =20 >> I think this is what we want but the text must be adjusted = accordingly. >> =20 >> Thanks, >> =20 >> Guy >> External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints >> =20 >> External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit = --Apple-Mail=_4BCBB8BD-4B45-4846-8F02-323B5104CB4E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = agree.  I=E2=80=99m willing to work on LoST-Sync schemas but need = help because my xml-fu is pretty weak.

Brian


On Aug 25, 2021, at 5:51 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

If we = go with your option:

So maybe we = should normatively update 5222 to say that the RelaxNG is =E2=80=9Creplace= d by=E2=80=9D the xml schema for the purposes of defining new = extensions, but the existing extension definitions in RelaxNG form are = still valid.

We should probably try to also = at least create an XML schema for LoST-Sync, since that's going to be = increasingly needed for emergency services, at least in North America. = How much would that delay the draft, or would we want to try and do it = in its own document?

I'd like to hear from = other group members. Especially from anyone who supports this approach = and is willing to review the XML schemas.


--Randall

On 24 Aug 2021, at 11:12, Brian Rosen wrote:

In general, I=E2=80=99d like to deprecate = it, but I=E2=80=99m having second thoughts on the difficulty in doing = so.

If = we were to deprecate it, we would have to deal with existing extensions. =  I see RFCs 6197, 6451 and 6739 have RelaxNG schemas that extend = LoST.  I note that all 3 of these are Experimental.   So one = argument is that if we deprecate the RelaxNG schema in 5222, we have to = do that to these extensions, and provide xml schemas to replace them. =  I will note that LoST Sync (6739) is going to be heavily deployed = soon.  

So = maybe we should normatively update 5222 to say that the RelaxNG is = =E2=80=9Creplaced by=E2=80=9D the xml schema for the purposes of = defining new extensions, but the existing extension definitions in = RelaxNG form are still valid.  If someone wanted to help make xml = schema replacements for at least 6739, that would be useful.  If we = did all 3, then we probably could deprecate the RelaxNG everywhere. =  This draft would have to update those 3 RFCs as well as = 5222.

If we = don=E2=80=99t deprecate the RelaxNG, then there is always the standards = issue of what if there is a discrepancy between the xml schema and the = RelaxNG.  I think we would have to say that it=E2=80=99s the = RelaxNG, and we would use the errata process to fix the xml schema.

The = thing to keep in mind is that every implementor I know is using xml = schemas, however they get them, to build their code. The practical = answer is that everyone needs xml schemas and no one needs = RelaxNG.

Brian


On Aug = 24, 2021, at 1:48 PM, Caron, Guy <g.caron@bell.ca> wrote:

Thanks for pointing me = to this email. My search somehow did not find this one.
 
Reading the comments, it seems to me that the commenter is = not totally adverse to the idea of making a normative change towards the = XML schema.
 
I=E2=80=99m not familiar enough with the process to determine = if or how the RelaxNG version of the LoST schema can be deprecated. I = can live with a normative XML version to which any further extensions = (or updates) attach to and leave the initial RelaxNG schema becoming = organically outdated and useless.
 
Thanks,
 
Guy
 
De : Brian = Rosen <br@brianrosen.net> 
Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:12
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : ecrit@ietf.org
Objet : [EXT]Re: = lost-planned-changes-04: XML vs RelaxNG
 
https://mailarchive.ietf.org/arch/msg/ecrit/oTPSzxsLp3YNy8J6HOw= Yjxdx1bI/
 
If we don=E2=80=99t deprecate the = RelaxNG schema, shouldn=E2=80=99t extensions have to provide Relax NG? =   That=E2=80=99s my setf serving reason to deprecate it.   I = guess we could not actually deprecate it, but normatively update 5222 to = say that extensions should reference the xml schema.
 
Brian
 
 


On Aug 23, 2021, at 4:59 PM, Caron, Guy = <g.caron@bell.ca> = wrote:
 
If you refer to general = comments made in the early days of LoST, some 15 years ago, I guess time = tells that RelaxNG did not ramp up as expected.
 
I can=E2=80=99t find = comments on the ECRIT list specific to planned-changes asking for XML = schemas to be informative while updating RFC5222.
 
I agree with your = sentiment that XML schemas should be a normative alternative (i.e., does = not deprecates) to RelaxNG.
 
Besides, by not providing RelaxNG equivalents for the = extensions, isn=E2=80=99t that what you are doing anyway?
 
Thanks,
 
Guy
 
De : Brian Rosen <br@brianrosen.net> 
Envoy=C3=A9 : 23 ao=C3=BBt 2021 16:37
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : ecrit@ietf.org
Objet : [EXT]Re: = lost-planned-changes-04: XML vs RelaxNG
 
We have had comments suggesting it be non normative, which is = why it says what it does now. 
 
My personal view is that = it should replace the Relax NG schema, and any subsequent changes and = extensions should only reference this one. No one that I know uses the = Relax NG schema one way or another they get an xml schema and use = that. 
 
But I will go with = whatever the consensus is  
 
Brian
 
On Mon, Aug = 23, 2021 at 4:32 PM Caron, Guy <g.caron@bell.ca> = wrote:
In section 7, the replacement XML schema is = qualified as an =E2=80=9Cinformative alternative=E2=80=9D however, the = text in the Intro states =E2=80=9CAlternative schemas have been = circulated, which is undesirable, as they may not be in conformance to = the RelaxNG schema in [RFC5222]. This document provides an XML schema = that replaces the RelaxNG schema. It can be used by any implementation = interchangeably with the RelaxNG schema.=E2=80=9D
 
The latter seems to = indicate that the XML schema in section 7 is a normative alternative = rather than an informative one.
 
I think this is what = we want but the text must be adjusted accordingly.
 
Thanks,
 
Guy
External Email: Please use caution = when opening links and attachments / Courriel externe: Soyez prudent avec = les liens et documents joints
 
External Email: Please use caution when = opening links and attachments / Courriel externe: Soyez prudent avec les = liens et documents = joints

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit


= --Apple-Mail=_4BCBB8BD-4B45-4846-8F02-323B5104CB4E-- From nobody Wed Aug 25 19:33:29 2021 Return-Path: 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 E3E8C3A0934 for ; Wed, 25 Aug 2021 19:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=bell.ca 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 pL5uKJeEDNi7 for ; Wed, 25 Aug 2021 19:33:22 -0700 (PDT) Received: from ESA1-Wyn.bell.ca (esa1-wyn.bell.ca [67.69.243.161]) (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 E12313A0932 for ; Wed, 25 Aug 2021 19:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1629945202; x=1661481202; h=from:to:cc:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=f9LVkdQak23c1f1ZhKgxcFyL1QaXAnWvTKRCcS1Gta8=; b=GBsKO1EDutb9paXgUbnMwyppWb8XkwqvpiV9OFtkafPcO02bvS6kl90h ft7H6TSLhb+i8TiYUMclpAyRdrDnnBVWAFiAZcb5VTLVGSI46diiyxYhn iJNTdWZsfdmSWSzqC8EM+WFyiroThDmUs8+Tsd9TSYKdGkpGDnc3PqR1E w+gnX/oUHs92kRZ5WezJi8734G+CyFqFaQjJXkny9D1kKDIYX3YEnPza0 jd6K7G7SNE8fYa9D/sqVLxdVikfmb6vZVrpRvbZoGEJVTwtFGGirvLyQK HFnbPRmHhRqvo3o0tZw9zpcnRTTeqO5rdWUFd/fB7WINUHyfE5TKOhKlM A==; IronPort-SDR: OGUaa7oHU839b5OjRLeQ0QSNZOj1K5SFL44LwgRSXrq/63KQhBZagqwNwOM0dLPNnLIozgvwLZ f7j8qluchfGQ== Received: from dm5cch-d00.bellca.int.bell.ca (HELO DG3MBX04-WYN.bell.corp.bce.ca) ([198.235.102.30]) by esa01corp-wyn.bell.corp.bce.ca with ESMTP; 25 Aug 2021 22:33:20 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG3MBX04-WYN.bell.corp.bce.ca (142.182.18.26) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Wed, 25 Aug 2021 22:33:19 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Wed, 25 Aug 2021 22:33:19 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Wed, 25 Aug 2021 22:33:19 -0400 From: "Caron, Guy" To: Brian Rosen , Randall Gellens CC: ECRIT Thread-Topic: [EXT]Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS Thread-Index: AQHXmfwhRqgqGYN29EukUdmptVZv5auFB74AgAAC6zA= Date: Thu, 26 Aug 2021 02:33:19 +0000 Message-ID: <14a2a0fad5f1499ca7939e820cc8a852@bell.ca> References: <1120BD41-A143-4AC1-B1A7-6CFF40658FF7@randy.pensive.org> <26184A64-2B40-4230-A09B-9A2D00D5F150@brianrosen.net> In-Reply-To: <26184A64-2B40-4230-A09B-9A2D00D5F150@brianrosen.net> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.67] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 02:33:28 -0000 SSBkaWQgbm90IGhhdmUgbXVjaCBjeWNsZSB0aW1lIHRvIHRoaW5rIGFib3V0IHRoaXMgYnV0IEkg Y2FuIHNoYXJlIG15IGluaXRpYWwgY29uY2VybnMgd2l0aCB0aGUgcHJvcG9zZWQgc29sdXRpb25z Lg0KDQpUaGUgY29uY2VybnMgSSBoYXZlIGFyZSBzZWN1cml0eS1yZWxhdGVkLiAgQSBMb1NUIHNl cnZlciB1c2VkIGluIHRoZSBjb250ZXh0IG9mIGVtZXJnZW5jeSBjYWxsaW5nICh0aGUgc2NvcGUg b2YgRUNSSVQpIGhvbGRzIGNyaXRpY2FsIGluZm9ybWF0aW9uIGFib3V0IGhvdyBlbWVyZ2VuY3kg Y2FsbHMgYXJlIHJvdXRlZCBhbmQgdGhlaXIgZGVzdGluYXRpb25zLiBCb3RoIHNvbHV0aW9ucyB3 b3VsZCBhbGxvdyBhIG1hbGV2b2xlbnQgY2xpZW50IHRvIHJlYnVpbGQgdGhlIHNlcnZlcidzIGlu dGVybmFsIGRhdGEgc3RydWN0dXJlIGFuZCB1c2UgdGhhdCBhcyBhbiBhdHRhY2sgb2Ygc29tZSBm b3JtIChpbXBlcnNvbmFsaXNhdGlvbiwgTUlUTSwgU1dBVHRpbmcsIGV0Yy4pLg0KDQpJIGhhdmUg cmUtcmVhZCB0aGUgU2VjdXJpdHkgc2VjdGlvbiBvZiBSRkMgNTIyMiBhbmQgcGVyaGFwcyB0aGVz ZSBjb25jZXJucyBhcmUgYWxyZWFkeSBhZGRyZXNzZWQgYnV0IHdvdWxkIGxpa2UgdG8gaGVhciB0 aGUgb3BpbmlvbiBvZiBvdGhlcnMuDQoNClRoYW5rcywNCg0KR3V5DQoNCg0KDQotLS0tLU1lc3Nh Z2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IEVjcml0IDxlY3JpdC1ib3VuY2VzQGlldGYub3JnPiBE ZSBsYSBwYXJ0IGRlIEJyaWFuIFJvc2VuDQpFbnZvecOpwqA6IDI1IGFvw7t0IDIwMjEgMTc6NTgN CsOAwqA6IFJhbmRhbGwgR2VsbGVucyA8cmcraWV0ZkByYW5keS5wZW5zaXZlLm9yZz4NCkNjwqA6 IEVDUklUIDxlY3JpdEBpZXRmLm9yZz4NCk9iamV0wqA6IFtFWFRdUmU6IFtFY3JpdF0gUHJvYmxl bSBpbiAtcGxhbm5lZC1jaGFuZ2VzOiB1bmlxdWUgcmVjb3JkcyBpbiBMb1NUIHNlcnZlciBtYXkg bm90IG1hdGNoIHVuaXF1ZSByZWNvcmRzIGluIExJUw0KDQpZZWFoLCBvZiB0aGUgdHdvIG9wdGlv bnMsIEkgbGlrZSB0aGUgc2Vjb25kLiAgSSB3b3VsZCBsaWtlIHRvIHdhaXQgdG8gaGVyZSBmcm9t IEd1eSwgd2hvIGRpZG7igJl0IGxpa2UgZWl0aGVyLg0KDQpFaXRoZXIgb2YgdGhlIHR3byBJIGNh bWUgdXAgd2l0aCBjYW4gYmUgYWRkZWQgcXVpY2tseSB0byB0aGUgZG9jLg0KDQpCcmlhbg0KDQoN Cj4gT24gQXVnIDI1LCAyMDIxLCBhdCA1OjU2IFBNLCBSYW5kYWxsIEdlbGxlbnMgPHJnK2lldGZA cmFuZHkucGVuc2l2ZS5vcmc+IHdyb3RlOg0KPiANCj4gRWl0aGVyIGFwcHJvYWNoIHdvdWxkIHdv cms6IHRoZSBzZXJ2ZXIgcmV0dXJuaW5nIHRoZSBwcmlvciBVUkkgaWYgaXQgcmVwbGFjZXMgaXQs IG9yIHRoZSBzZXJ2ZXIgYWx3YXlzIHJldHVybmluZyBhICJ1bmlxdWUgbG9jYXRpb24gSUQiIHdo ZW5ldmVyIGl0IHN0b3JlcyBhIFVSSS4gIEluIHRoZSBsYXR0ZXIgY2FzZSwgd2UnZCB3YW50IHRv IGFkZCB0aGlzIElEIHRvIHRoZSA8bG9jYXRpb25JbnZhbGlkYXRlZD4gb2JqZWN0LiAgVGhlIGxh dHRlciBzZWVtcyBhIGJpdCBjbGVhbmVyLCBhcyB0aGVuIHRoZSBzZXJ2ZXIgYWx3YXlzIHJldHVy bnMgYW4gSUQsIGFuZCBhIGNsaWVudCBhbHdheXMgc3RvcmVzIHRoaXMgSUQgd2hlbmV2ZXIgaXQg c2VuZHMgYSBVUkksIGFuZCB1c2VzIHRoZSBJRCB0byByZS12YWxpZGF0ZSBsb2NhdGlvbnMgd2hl biBpdCBnZXRzIGEgPGxvY2F0aW9uSW52YWxpZGF0ZWQ+IG9iamVjdC4NCj4gDQo+IC0tUmFuZGFs bA0KPiANCj4gT24gMjQgQXVnIDIwMjEsIGF0IDEzOjA4LCBCcmlhbiBSb3NlbiB3cm90ZToNCj4g DQo+PiBJIHJlYWxpemVkIHdlIGhhdmUgYSBwcm9ibGVtIHdpdGggLXBsYW5uZWQtY2hhbmdlcy4g IFRoZSB0ZXh0IG5vdGVzOg0KPj4gRWFjaCBjbGllbnQgb2YgdGhlIHNlcnZlciBtYXkgb25seSBz dG9yZSBvbmUgVVJJIGFnYWluc3QgYSBsb2NhdGlvbiwgd2hlcmUg4oCcbG9jYXRpb27igJ0gaXMg ZGVmaW5lZCBieSBwb2xpY3kgYXQgdGhlIHNlcnZlciwgc2luY2UgYSBnaXZlbiB1bmlxdWUgbG9j YXRpb24gbWF5IGhhdmUgbWFueSBjb21iaW5hdGlvbnMgb2YgbG9jYXRpb24gZWxlbWVudHMgdGhh dCByZXNvbHZlIHRvIHRoZSBzYW1lIGxvY2F0aW9uLiAgSWYgdGhlIHNlcnZlciByZWNlaXZlcyBh IOKAmHVyaeKAmSBmb3IgdGhlIHNhbWUgbG9jYXRpb24gZnJvbSB0aGUgc2FtZSBjbGllbnQsIHRo ZSBVUkkgaW4gdGhlIHJlcXVlc3QgcmVwbGFjZXMgdGhlIFVSSSBpdCBwcmV2aW91c2x5IHJldGFp bmVkLg0KPj4gDQo+PiBCdXQgdGhpcyBtZWFucyB0aGF0IG11bHRpcGxlIHJlY29yZHMgaW4gdGhl IExJUyBtYXkgYmUgb25lIHJlY29yZCBpbiB0aGUgTG9TVCBzZXJ2ZXIgYW5kIHdoZW4gdGhlIExJ UyBhc3NvY2lhdGVzIHVuaXF1ZSBVUklzIHdpdGggd2hhdCBpdCB0aGlua3MgaXMgbXVsdGlwbGUg cmVjb3Jkcywgb25seSBvbmUgaXMgcmV0YWluZWQgYW5kIGl0IGRvZXNu4oCZdCBrbm93IHRoYXQu DQo+PiANCj4+IFRoZSBlYXNpZXN0IGZpeCBpcyB0byByZXR1cm4gdGhlIHJlcGxhY2VkIFVSSS4g IFRoZSBjbGllbnQgd291bGQgdGhlbiBiZSBhYmxlIHRvIHNwb3QgdGhhdCB0aGUgcmVjb3JkcyBh cmUgbGlua2VkIGFuZCBkbyB0aGUgYm9vayBrZWVwaW5nIHRvIHRyYWNrIHdoYXQgaXQgc2hvdWxk IGRvLg0KPj4gQW5vdGhlciB3YXkgdG8gZml4IHRoaXMgaXMgdG8gcmV0dXJuIGEgdW5pcXVlIElE IG9mIHRoZSByZWNvcmQgaW4gdGhlIExvU1Qgc2VydmVyIHdoZW4geW91IHVzZSB0aGUgZXh0ZW5z aW9uLiAgVGhlIExJUyBjYW4gdGhlbiBrZWVwIGFuIGludGVybmFsIHJlY29yZCBvZiBhbGwgdGhl IHJlbGF0ZWQgZW50cmllcyBpdCBoYXMgdGhhdCBhcmUgb25lIHJlY29yZCB0byB0aGUgc2VydmVy Lg0KPj4gDQo+PiBCcmlhbg0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+PiBFY3JpdEBpZXRmLm9y Zw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRWNyaXQgbWFpbGlu ZyBsaXN0DQpFY3JpdEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9lY3JpdA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpFeHRlcm5hbCBFbWFpbDogUGxlYXNl IHVzZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQgYXR0YWNobWVudHMgLyBDb3Vycmll bCBleHRlcm5lOiBTb3lleiBwcnVkZW50IGF2ZWMgbGVzIGxpZW5zIGV0IGRvY3VtZW50cyBqb2lu dHMNCg== From nobody Wed Aug 25 21:39:54 2021 Return-Path: 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 806773A14F2 for ; Wed, 25 Aug 2021 21:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, 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 3Y5ZHrcgOIBh for ; Wed, 25 Aug 2021 21:39:45 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id A66423A14F7 for ; Wed, 25 Aug 2021 21:39:45 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Wed, 25 Aug 2021 21:39:45 -0700 From: "Randall Gellens" To: "Caron, Guy" Cc: "Brian Rosen" , ECRIT Date: Wed, 25 Aug 2021 21:39:44 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: <14a2a0fad5f1499ca7939e820cc8a852@bell.ca> References: <1120BD41-A143-4AC1-B1A7-6CFF40658FF7@randy.pensive.org> <26184A64-2B40-4230-A09B-9A2D00D5F150@brianrosen.net> <14a2a0fad5f1499ca7939e820cc8a852@bell.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 04:39:52 -0000 Hi Guy, I'm not following how "Both solutions would allow a malevolent client to rebuild the server's internal data structure". In either solution, the LoST server returns something to the LoST client that the LoST client uses to mark one or more of its location records. If/when the LoST server sends the client a object, the object contains this same marker, which the client uses to know which of its records should be revalidated. --Randall On 25 Aug 2021, at 19:33, Caron, Guy wrote: > I did not have much cycle time to think about this but I can share my > initial concerns with the proposed solutions. > > The concerns I have are security-related. A LoST server used in the > context of emergency calling (the scope of ECRIT) holds critical > information about how emergency calls are routed and their > destinations. Both solutions would allow a malevolent client to > rebuild the server's internal data structure and use that as an attack > of some form (impersonalisation, MITM, SWATting, etc.). > > I have re-read the Security section of RFC 5222 and perhaps these > concerns are already addressed but would like to hear the opinion of > others. > > Thanks, > > Guy > > > > -----Message d'origine----- > De : Ecrit De la part de Brian Rosen > Envoyé : 25 août 2021 17:58 > À : Randall Gellens > Cc : ECRIT > Objet : [EXT]Re: [Ecrit] Problem in -planned-changes: unique records > in LoST server may not match unique records in LIS > > Yeah, of the two options, I like the second. I would like to wait to > here from Guy, who didn’t like either. > > Either of the two I came up with can be added quickly to the doc. > > Brian > > >> On Aug 25, 2021, at 5:56 PM, Randall Gellens >> wrote: >> >> Either approach would work: the server returning the prior URI if it >> replaces it, or the server always returning a "unique location ID" >> whenever it stores a URI. In the latter case, we'd want to add this >> ID to the object. The latter seems a bit >> cleaner, as then the server always returns an ID, and a client always >> stores this ID whenever it sends a URI, and uses the ID to >> re-validate locations when it gets a object. >> >> --Randall >> >> On 24 Aug 2021, at 13:08, Brian Rosen wrote: >> >>> I realized we have a problem with -planned-changes. The text notes: >>> Each client of the server may only store one URI against a location, >>> where “location†is defined by policy at the server, since a >>> given unique location may have many combinations of location >>> elements that resolve to the same location. If the server receives >>> a ‘uri’ for the same location from the same client, the URI in >>> the request replaces the URI it previously retained. >>> >>> But this means that multiple records in the LIS may be one record in >>> the LoST server and when the LIS associates unique URIs with what it >>> thinks is multiple records, only one is retained and it doesn’t >>> know that. >>> >>> The easiest fix is to return the replaced URI. The client would >>> then be able to spot that the records are linked and do the book >>> keeping to track what it should do. >>> Another way to fix this is to return a unique ID of the record in >>> the LoST server when you use the extension. The LIS can then keep >>> an internal record of all the related entries it has that are one >>> record to the server. >>> >>> Brian >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > ------------------------------------------------------------------------------ > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints From nobody Thu Aug 26 06:09:58 2021 Return-Path: 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 56CD43A1182 for ; Thu, 26 Aug 2021 06:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=bell.ca 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 C0B5fWuzJtIE for ; Thu, 26 Aug 2021 06:09:50 -0700 (PDT) Received: from ESA2-Wyn.bell.ca (esa2-wyn.bell.ca [67.69.243.180]) (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 F118A3A0CB3 for ; Thu, 26 Aug 2021 06:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1629983390; x=1661519390; h=from:to:cc:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=GPI4R+gZ5yC/lR7PWu/IovKTEvOoyfIV0wVUeu8kP0M=; b=b8edgUSVbFWpXMln0gh6/iwmsEsGtfk2ufW6n+ACtHK4bXEd/3oomMnF ccgKoYXHtKyz+4wxDMt6ZI3wV7GjyXL1ZiGernWf3+1SzypDGfNEnEfDG LajKTZOkBGGhY4LitJw2uQVf93jlcGccvVQ/Wyah1PanEOw/nn4Up8A0z zJRuTXnnLbW8zjQ9VMJxiUXeYGNZEx3llSQW7V/01lYg44lxwYZPlw1s4 SKE2xpPVLvFygwFpWyatf7TEuL/pDPomIJHG777G+61ZPOKpe27/0enEZ Fl+KRe6/F35pdZlQ9GKiG/NppKIy+Q2fh4YmU8sN0a5c1ucdYVDcEs8Eo g==; IronPort-SDR: 22HEJ80KtMVciWcXJW3m33S+optVd8xZd1hQD0O/nO+ESxbgr2YiVhlZNDgbKulL6svd3kkeEY JAb+KQnjIcXQ== Received: from dm5cch-d01.bellca.int.bell.ca (HELO DG6MBX01-WYN.bell.corp.bce.ca) ([198.235.102.31]) by esa02corp-wyn.bell.corp.bce.ca with ESMTP; 26 Aug 2021 09:09:48 -0400 Received: from DG12MBX03-WYN.bell.corp.bce.ca (142.182.18.48) by DG6MBX01-WYN.bell.corp.bce.ca (142.182.18.36) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Thu, 26 Aug 2021 09:09:48 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX03-WYN.bell.corp.bce.ca (142.182.18.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Thu, 26 Aug 2021 09:09:47 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Thu, 26 Aug 2021 09:09:47 -0400 From: "Caron, Guy" To: Randall Gellens CC: Brian Rosen , ECRIT Thread-Topic: [EXT]Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS Thread-Index: AQHXmfwhRqgqGYN29EukUdmptVZv5auFB74AgAAC6zCAAG01AIAAQ6ZA Date: Thu, 26 Aug 2021 13:09:47 +0000 Message-ID: <34febd3e0984476380325a181f7b611a@bell.ca> References: <1120BD41-A143-4AC1-B1A7-6CFF40658FF7@randy.pensive.org> <26184A64-2B40-4230-A09B-9A2D00D5F150@brianrosen.net> <14a2a0fad5f1499ca7939e820cc8a852@bell.ca> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.68] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 13:09:56 -0000 Qm90aCBzb2x1dGlvbnMgcmV2ZWFsIHRoZSBncmFudWxhcml0eSBvZiB0aGUgdW5kZXJseWluZyBk YXRhIGluIHRoZSBMb1NUIHNlcnZlci4NCg0KSGVyZSBpcyBhbiBleGFtcGxlOg0KDQoxLiBDbGll bnQgc2VuZHMgYSBVUkkgZm9yIGVhY2ggZGlzY3JldGUgbG9jYXRpb24gKHRoaW5rIGNpdmljIG51 bWJlcnMpIG9mIGEgc3RyZWV0Lg0KMi4gU2VydmVyIGlzIG9ubHkgcHJvdmlzaW9uZWQgd2l0aCBy b2FkIGNlbnRlcmxpbmUgZGF0YSBmb3IgdGhhdCBzdHJlZXQgYW5kIHRodXMgcmV0dXJuIG9uZSBV UkkgKG9yIElEKSBiYWNrIHRvIHRoZSBjbGllbnQgZm9yIGVhY2ggZGlzY3JldGUgbG9jYXRpb24g aXQgaGFzLg0KMy4gQ2xpZW50IHN0b3JlcyB0aGlzIHVuaXF1ZSBVUkkgKG9yIElEKSBhZ2FpbnN0 IGFsbCBkaXNjcmV0ZSBsb2NhdGlvbnMuDQo0LiBBZnRlciBhbGwgdGhlIENsaWVudCdzIGxvY2F0 aW9ucyBoYXZlIGdvdHRlbiB0aGUgVVJJcyAob3IgKElEcykgZnJvbSB0aGUgU2VydmVyLCB0aGUg Q2xpZW50IGhhcyBhIGRldGFpbGVkIHZpZXcgb2YgdGhlIFNlcnZlcidzIHVuZGVybHlpbmcgZGF0 YS4NCg0KVGhlbiwgcHV0IHRoaXMgaW4gdGhlIGhhbmRzIG9mIGFuIGF0dGFja2VyLg0KDQpUaGFu a3MsDQoNCg0KR3V5DQoNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBSYW5k YWxsIEdlbGxlbnMgPHJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmc+IA0KRW52b3nDqcKgOiAyNiBh b8O7dCAyMDIxIDAwOjQwDQrDgMKgOiBDYXJvbiwgR3V5IDxnLmNhcm9uQGJlbGwuY2E+DQpDY8Kg OiBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ+OyBFQ1JJVCA8ZWNyaXRAaWV0Zi5vcmc+ DQpPYmpldMKgOiBbRVhUXVJlOiBbRWNyaXRdIFByb2JsZW0gaW4gLXBsYW5uZWQtY2hhbmdlczog dW5pcXVlIHJlY29yZHMgaW4gTG9TVCBzZXJ2ZXIgbWF5IG5vdCBtYXRjaCB1bmlxdWUgcmVjb3Jk cyBpbiBMSVMNCg0KSGkgR3V5LA0KDQpJJ20gbm90IGZvbGxvd2luZyBob3cgIkJvdGggc29sdXRp b25zIHdvdWxkIGFsbG93IGEgbWFsZXZvbGVudCBjbGllbnQgdG8gcmVidWlsZCB0aGUgc2VydmVy J3MgaW50ZXJuYWwgZGF0YSBzdHJ1Y3R1cmUiLiAgSW4gZWl0aGVyIHNvbHV0aW9uLCB0aGUgTG9T VCBzZXJ2ZXIgcmV0dXJucyBzb21ldGhpbmcgdG8gdGhlIExvU1QgY2xpZW50IHRoYXQgdGhlIExv U1QgY2xpZW50IHVzZXMgdG8gbWFyayBvbmUgb3IgbW9yZSBvZiBpdHMgbG9jYXRpb24gcmVjb3Jk cy4gSWYvd2hlbiB0aGUgTG9TVCBzZXJ2ZXIgc2VuZHMgdGhlIGNsaWVudCBhIDxsb2NhdGlvbklu dmFsaWRhdGVkPiBvYmplY3QsIHRoZSBvYmplY3QgY29udGFpbnMgdGhpcyBzYW1lIG1hcmtlciwg d2hpY2ggdGhlIGNsaWVudCB1c2VzIHRvIGtub3cgd2hpY2ggb2YgaXRzIHJlY29yZHMgc2hvdWxk IGJlIHJldmFsaWRhdGVkLg0KDQotLVJhbmRhbGwNCg0KT24gMjUgQXVnIDIwMjEsIGF0IDE5OjMz LCBDYXJvbiwgR3V5IHdyb3RlOg0KDQo+IEkgZGlkIG5vdCBoYXZlIG11Y2ggY3ljbGUgdGltZSB0 byB0aGluayBhYm91dCB0aGlzIGJ1dCBJIGNhbiBzaGFyZSBteSANCj4gaW5pdGlhbCBjb25jZXJu cyB3aXRoIHRoZSBwcm9wb3NlZCBzb2x1dGlvbnMuDQo+DQo+IFRoZSBjb25jZXJucyBJIGhhdmUg YXJlIHNlY3VyaXR5LXJlbGF0ZWQuICBBIExvU1Qgc2VydmVyIHVzZWQgaW4gdGhlIA0KPiBjb250 ZXh0IG9mIGVtZXJnZW5jeSBjYWxsaW5nICh0aGUgc2NvcGUgb2YgRUNSSVQpIGhvbGRzIGNyaXRp Y2FsIA0KPiBpbmZvcm1hdGlvbiBhYm91dCBob3cgZW1lcmdlbmN5IGNhbGxzIGFyZSByb3V0ZWQg YW5kIHRoZWlyIA0KPiBkZXN0aW5hdGlvbnMuIEJvdGggc29sdXRpb25zIHdvdWxkIGFsbG93IGEg bWFsZXZvbGVudCBjbGllbnQgdG8gDQo+IHJlYnVpbGQgdGhlIHNlcnZlcidzIGludGVybmFsIGRh dGEgc3RydWN0dXJlIGFuZCB1c2UgdGhhdCBhcyBhbiBhdHRhY2sgDQo+IG9mIHNvbWUgZm9ybSAo aW1wZXJzb25hbGlzYXRpb24sIE1JVE0sIFNXQVR0aW5nLCBldGMuKS4NCj4NCj4gSSBoYXZlIHJl LXJlYWQgdGhlIFNlY3VyaXR5IHNlY3Rpb24gb2YgUkZDIDUyMjIgYW5kIHBlcmhhcHMgdGhlc2Ug DQo+IGNvbmNlcm5zIGFyZSBhbHJlYWR5IGFkZHJlc3NlZCBidXQgd291bGQgbGlrZSB0byBoZWFy IHRoZSBvcGluaW9uIG9mIA0KPiBvdGhlcnMuDQo+DQo+IFRoYW5rcywNCj4NCj4gR3V5DQo+DQo+ DQo+DQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBFY3JpdCA8ZWNyaXQt Ym91bmNlc0BpZXRmLm9yZz4gRGUgbGEgcGFydCBkZSBCcmlhbiBSb3NlbiBFbnZvecOpwqA6IA0K PiAyNSBhb8O7dCAyMDIxIDE3OjU4IMOAwqA6IFJhbmRhbGwgR2VsbGVucyA8cmcraWV0ZkByYW5k eS5wZW5zaXZlLm9yZz4gQ2PCoA0KPiA6IEVDUklUIDxlY3JpdEBpZXRmLm9yZz4gT2JqZXTCoDog W0VYVF1SZTogW0Vjcml0XSBQcm9ibGVtIGluIA0KPiAtcGxhbm5lZC1jaGFuZ2VzOiB1bmlxdWUg cmVjb3JkcyBpbiBMb1NUIHNlcnZlciBtYXkgbm90IG1hdGNoIHVuaXF1ZSANCj4gcmVjb3JkcyBp biBMSVMNCj4NCj4gWWVhaCwgb2YgdGhlIHR3byBvcHRpb25zLCBJIGxpa2UgdGhlIHNlY29uZC4g IEkgd291bGQgbGlrZSB0byB3YWl0IHRvIA0KPiBoZXJlIGZyb20gR3V5LCB3aG8gZGlkbuKAmXQg bGlrZSBlaXRoZXIuDQo+DQo+IEVpdGhlciBvZiB0aGUgdHdvIEkgY2FtZSB1cCB3aXRoIGNhbiBi ZSBhZGRlZCBxdWlja2x5IHRvIHRoZSBkb2MuDQo+DQo+IEJyaWFuDQo+DQo+DQo+PiBPbiBBdWcg MjUsIDIwMjEsIGF0IDU6NTYgUE0sIFJhbmRhbGwgR2VsbGVucyANCj4+IDxyZytpZXRmQHJhbmR5 LnBlbnNpdmUub3JnPiB3cm90ZToNCj4+DQo+PiBFaXRoZXIgYXBwcm9hY2ggd291bGQgd29yazog dGhlIHNlcnZlciByZXR1cm5pbmcgdGhlIHByaW9yIFVSSSBpZiBpdCANCj4+IHJlcGxhY2VzIGl0 LCBvciB0aGUgc2VydmVyIGFsd2F5cyByZXR1cm5pbmcgYSAidW5pcXVlIGxvY2F0aW9uIElEIg0K Pj4gd2hlbmV2ZXIgaXQgc3RvcmVzIGEgVVJJLiAgSW4gdGhlIGxhdHRlciBjYXNlLCB3ZSdkIHdh bnQgdG8gYWRkIHRoaXMgDQo+PiBJRCB0byB0aGUgPGxvY2F0aW9uSW52YWxpZGF0ZWQ+IG9iamVj dC4gIFRoZSBsYXR0ZXIgc2VlbXMgYSBiaXQgDQo+PiBjbGVhbmVyLCBhcyB0aGVuIHRoZSBzZXJ2 ZXIgYWx3YXlzIHJldHVybnMgYW4gSUQsIGFuZCBhIGNsaWVudCBhbHdheXMgDQo+PiBzdG9yZXMg dGhpcyBJRCB3aGVuZXZlciBpdCBzZW5kcyBhIFVSSSwgYW5kIHVzZXMgdGhlIElEIHRvIA0KPj4g cmUtdmFsaWRhdGUgbG9jYXRpb25zIHdoZW4gaXQgZ2V0cyBhIDxsb2NhdGlvbkludmFsaWRhdGVk PiBvYmplY3QuDQo+Pg0KPj4gLS1SYW5kYWxsDQo+Pg0KPj4gT24gMjQgQXVnIDIwMjEsIGF0IDEz OjA4LCBCcmlhbiBSb3NlbiB3cm90ZToNCj4+DQo+Pj4gSSByZWFsaXplZCB3ZSBoYXZlIGEgcHJv YmxlbSB3aXRoIC1wbGFubmVkLWNoYW5nZXMuICBUaGUgdGV4dCBub3RlczoNCj4+PiBFYWNoIGNs aWVudCBvZiB0aGUgc2VydmVyIG1heSBvbmx5IHN0b3JlIG9uZSBVUkkgYWdhaW5zdCBhIGxvY2F0 aW9uLCANCj4+PiB3aGVyZSDigJxsb2NhdGlvbuKAnSBpcyBkZWZpbmVkIGJ5IHBvbGljeSBhdCB0 aGUgc2VydmVyLCBzaW5jZSBhIGdpdmVuIA0KPj4+IHVuaXF1ZSBsb2NhdGlvbiBtYXkgaGF2ZSBt YW55IGNvbWJpbmF0aW9ucyBvZiBsb2NhdGlvbiBlbGVtZW50cyB0aGF0IA0KPj4+IHJlc29sdmUg dG8gdGhlIHNhbWUgbG9jYXRpb24uICBJZiB0aGUgc2VydmVyIHJlY2VpdmVzIGEg4oCYdXJp4oCZ IGZvciANCj4+PiB0aGUgc2FtZSBsb2NhdGlvbiBmcm9tIHRoZSBzYW1lIGNsaWVudCwgdGhlIFVS SSBpbiB0aGUgcmVxdWVzdCANCj4+PiByZXBsYWNlcyB0aGUgVVJJIGl0IHByZXZpb3VzbHkgcmV0 YWluZWQuDQo+Pj4NCj4+PiBCdXQgdGhpcyBtZWFucyB0aGF0IG11bHRpcGxlIHJlY29yZHMgaW4g dGhlIExJUyBtYXkgYmUgb25lIHJlY29yZCBpbiANCj4+PiB0aGUgTG9TVCBzZXJ2ZXIgYW5kIHdo ZW4gdGhlIExJUyBhc3NvY2lhdGVzIHVuaXF1ZSBVUklzIHdpdGggd2hhdCBpdCANCj4+PiB0aGlu a3MgaXMgbXVsdGlwbGUgcmVjb3Jkcywgb25seSBvbmUgaXMgcmV0YWluZWQgYW5kIGl0IGRvZXNu 4oCZdCBrbm93IA0KPj4+IHRoYXQuDQo+Pj4NCj4+PiBUaGUgZWFzaWVzdCBmaXggaXMgdG8gcmV0 dXJuIHRoZSByZXBsYWNlZCBVUkkuICBUaGUgY2xpZW50IHdvdWxkIA0KPj4+IHRoZW4gYmUgYWJs ZSB0byBzcG90IHRoYXQgdGhlIHJlY29yZHMgYXJlIGxpbmtlZCBhbmQgZG8gdGhlIGJvb2sgDQo+ Pj4ga2VlcGluZyB0byB0cmFjayB3aGF0IGl0IHNob3VsZCBkby4NCj4+PiBBbm90aGVyIHdheSB0 byBmaXggdGhpcyBpcyB0byByZXR1cm4gYSB1bmlxdWUgSUQgb2YgdGhlIHJlY29yZCBpbiANCj4+ PiB0aGUgTG9TVCBzZXJ2ZXIgd2hlbiB5b3UgdXNlIHRoZSBleHRlbnNpb24uICBUaGUgTElTIGNh biB0aGVuIGtlZXAgDQo+Pj4gYW4gaW50ZXJuYWwgcmVjb3JkIG9mIGFsbCB0aGUgcmVsYXRlZCBl bnRyaWVzIGl0IGhhcyB0aGF0IGFyZSBvbmUgDQo+Pj4gcmVjb3JkIHRvIHRoZSBzZXJ2ZXIuDQo+ Pj4NCj4+PiBCcmlhbg0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+PiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4+PiBFY3JpdEBpZXRmLm9y Zw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4NCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRWNyaXQg bWFpbGluZyBsaXN0DQo+IEVjcml0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZWNyaXQNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0tLS0tLSBFeHRlcm5h bCBFbWFpbDogUGxlYXNlIHVzZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQgDQo+IGF0 dGFjaG1lbnRzIC8gQ291cnJpZWwgZXh0ZXJuZTogU295ZXogcHJ1ZGVudCBhdmVjIGxlcyBsaWVu cyBldCANCj4gZG9jdW1lbnRzIGpvaW50cw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpFeHRlcm5h bCBFbWFpbDogUGxlYXNlIHVzZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQgYXR0YWNo bWVudHMgLyBDb3VycmllbCBleHRlcm5lOiBTb3lleiBwcnVkZW50IGF2ZWMgbGVzIGxpZW5zIGV0 IGRvY3VtZW50cyBqb2ludHMNCg== From nobody Thu Aug 26 06:31:47 2021 Return-Path: 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 581303A141C for ; Thu, 26 Aug 2021 06:31:44 -0700 (PDT) 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.20150623.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 H0t2G0w0aD-d for ; Thu, 26 Aug 2021 06:31:38 -0700 (PDT) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 096B53A1418 for ; Thu, 26 Aug 2021 06:31:38 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id y3so3276629ilm.6 for ; Thu, 26 Aug 2021 06:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1BwzYaIXWFjo0xZLWSn+mH3aWg2inHZa7QJ1YvXnxUY=; b=i8VOu6fGxyl/liPFOZTsAc8/sj5r8s7HYWDsaum++A9Qo9DDu8D3Q0nY+XRFcl3wQU 7GMEIuXaouaTQCntI8v5X16qOfuVbOX/Hym+oGrP11iUs43eDlrQeJefEo+Z+u6NUPdB awvxmMzN5YBvM24QiPJG/DJPvp8fFrKGuSdGZ6WTYbsh3meIY/Y1RIuqhq6UALjw3TRL Dv0TGqDx1Oi3+/qkIdPiTnoa4gH1VQti2khzJ5DJfXaqdBaznTeUWZ+7VVH8h28g13cH kr03aICabfjwV8PLFcskETSFYfGm6HHO/rm+COjNNB04Sl1Ldk7PrCOoNat2SLlNOiAE HJdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1BwzYaIXWFjo0xZLWSn+mH3aWg2inHZa7QJ1YvXnxUY=; b=OMCPc66J5+DjPCzkylnjm3AN0/467u9WJ6dlKoPTSEnGnIn71YlqL4iH6QJLY4Kby7 g/YtK7n1q2nDjNynkCSCJZz2TxNcA3n8TpJ31XwSLZS/ej20DHL5/PUDpWCNEqXg8qvV +7HpJNlNZuDcYhHkTyFWc94HkggERwIsHzCjhRLWLkI8WZcbmGlvfDrc66QlBqAmzuee 1iETds/NZwRnGDcStV//1ouoPm2WkgosdFxPAKN41QTSTpXVxMZwBTOBKDZG0rZPZYnY P2loC9uSHIZEpMTE/4myNb1N7miptRj4yErwSHeU66xaW3FkWeLijTYbEFe0bX5StBVo dYUA== X-Gm-Message-State: AOAM531GBZPLeOM0CEBCOjhmz+hph8qOTpRkKXOyTseGwW2yfQjHJ/9G 9n+BiuCH1bZW7gp9Rv8AhzPQhQ== X-Google-Smtp-Source: ABdhPJwVXn8ZUFMvtYsHnK7f69JhqvHoOKCR+2BXYrhi6JXQX7u35CQwnSX3BiVkpL3ZgGwBqwPZIg== X-Received: by 2002:a92:3f0b:: with SMTP id m11mr2783510ila.265.1629984696735; Thu, 26 Aug 2021 06:31:36 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id a11sm1683079ilf.79.2021.08.26.06.31.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Aug 2021 06:31:36 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Brian Rosen In-Reply-To: <34febd3e0984476380325a181f7b611a@bell.ca> Date: Thu, 26 Aug 2021 09:31:35 -0400 Cc: Randall Gellens , ECRIT Content-Transfer-Encoding: quoted-printable Message-Id: <219EED44-D2BB-477A-9452-6BF688FB89AD@brianrosen.net> References: <1120BD41-A143-4AC1-B1A7-6CFF40658FF7@randy.pensive.org> <26184A64-2B40-4230-A09B-9A2D00D5F150@brianrosen.net> <14a2a0fad5f1499ca7939e820cc8a852@bell.ca> <34febd3e0984476380325a181f7b611a@bell.ca> To: "Caron, Guy" X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 13:31:44 -0000 I don=E2=80=99t see how this knowledge aids an attack. Yes, it knows = what is a road centerline and what is an address point (or equivalent), = but I don=E2=80=99t see how an attacker could use that information. =20 Also, you get exactly the same information already: address number will = be in =E2=80=9Cunchecked=E2=80=9D for a road centerline (assuming it=E2=80= =99s in a range, if it=E2=80=99s not, it=E2=80=99s in invalid). This is because 4-100 includes 55 and there may or may not be an actual = 55 address number. Now, that really is specific to North America: the = NENA standard says that=E2=80=99s how you populate the unchecked list: = 5222 isn=E2=80=99t specific. Brian > On Aug 26, 2021, at 9:09 AM, Caron, Guy wrote: >=20 > Both solutions reveal the granularity of the underlying data in the = LoST server. >=20 > Here is an example: >=20 > 1. Client sends a URI for each discrete location (think civic numbers) = of a street. > 2. Server is only provisioned with road centerline data for that = street and thus return one URI (or ID) back to the client for each = discrete location it has. > 3. Client stores this unique URI (or ID) against all discrete = locations. > 4. After all the Client's locations have gotten the URIs (or (IDs) = from the Server, the Client has a detailed view of the Server's = underlying data. >=20 > Then, put this in the hands of an attacker. >=20 > Thanks, >=20 >=20 > Guy >=20 >=20 > -----Message d'origine----- > De : Randall Gellens =20 > Envoy=C3=A9 : 26 ao=C3=BBt 2021 00:40 > =C3=80 : Caron, Guy > Cc : Brian Rosen ; ECRIT > Objet : [EXT]Re: [Ecrit] Problem in -planned-changes: unique records = in LoST server may not match unique records in LIS >=20 > Hi Guy, >=20 > I'm not following how "Both solutions would allow a malevolent client = to rebuild the server's internal data structure". In either solution, = the LoST server returns something to the LoST client that the LoST = client uses to mark one or more of its location records. If/when the = LoST server sends the client a object, the object = contains this same marker, which the client uses to know which of its = records should be revalidated. >=20 > --Randall >=20 > On 25 Aug 2021, at 19:33, Caron, Guy wrote: >=20 >> I did not have much cycle time to think about this but I can share my=20= >> initial concerns with the proposed solutions. >>=20 >> The concerns I have are security-related. A LoST server used in the=20= >> context of emergency calling (the scope of ECRIT) holds critical=20 >> information about how emergency calls are routed and their=20 >> destinations. Both solutions would allow a malevolent client to=20 >> rebuild the server's internal data structure and use that as an = attack=20 >> of some form (impersonalisation, MITM, SWATting, etc.). >>=20 >> I have re-read the Security section of RFC 5222 and perhaps these=20 >> concerns are already addressed but would like to hear the opinion of=20= >> others. >>=20 >> Thanks, >>=20 >> Guy >>=20 >>=20 >>=20 >> -----Message d'origine----- >> De : Ecrit De la part de Brian Rosen Envoy=C3=A9= :=20 >> 25 ao=C3=BBt 2021 17:58 =C3=80 : Randall Gellens = Cc=20 >> : ECRIT Objet : [EXT]Re: [Ecrit] Problem in=20 >> -planned-changes: unique records in LoST server may not match unique=20= >> records in LIS >>=20 >> Yeah, of the two options, I like the second. I would like to wait to=20= >> here from Guy, who didn=E2=80=99t like either. >>=20 >> Either of the two I came up with can be added quickly to the doc. >>=20 >> Brian >>=20 >>=20 >>> On Aug 25, 2021, at 5:56 PM, Randall Gellens=20 >>> wrote: >>>=20 >>> Either approach would work: the server returning the prior URI if it=20= >>> replaces it, or the server always returning a "unique location ID" >>> whenever it stores a URI. In the latter case, we'd want to add this=20= >>> ID to the object. The latter seems a bit=20 >>> cleaner, as then the server always returns an ID, and a client = always=20 >>> stores this ID whenever it sends a URI, and uses the ID to=20 >>> re-validate locations when it gets a object. >>>=20 >>> --Randall >>>=20 >>> On 24 Aug 2021, at 13:08, Brian Rosen wrote: >>>=20 >>>> I realized we have a problem with -planned-changes. The text = notes: >>>> Each client of the server may only store one URI against a = location,=20 >>>> where =E2=80=9Clocation=E2=80=9D is defined by policy at the = server, since a given=20 >>>> unique location may have many combinations of location elements = that=20 >>>> resolve to the same location. If the server receives a =E2=80=98uri=E2= =80=99 for=20 >>>> the same location from the same client, the URI in the request=20 >>>> replaces the URI it previously retained. >>>>=20 >>>> But this means that multiple records in the LIS may be one record = in=20 >>>> the LoST server and when the LIS associates unique URIs with what = it=20 >>>> thinks is multiple records, only one is retained and it doesn=E2=80=99= t know=20 >>>> that. >>>>=20 >>>> The easiest fix is to return the replaced URI. The client would=20 >>>> then be able to spot that the records are linked and do the book=20 >>>> keeping to track what it should do. >>>> Another way to fix this is to return a unique ID of the record in=20= >>>> the LoST server when you use the extension. The LIS can then keep=20= >>>> an internal record of all the related entries it has that are one=20= >>>> record to the server. >>>>=20 >>>> Brian >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> = ---------------------------------------------------------------------- >> -------- External Email: Please use caution when opening links and=20 >> attachments / Courriel externe: Soyez prudent avec les liens et=20 >> documents joints > = --------------------------------------------------------------------------= ---- > External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints From nobody Thu Aug 26 06:36:02 2021 Return-Path: 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 262B03A14A1 for ; Thu, 26 Aug 2021 06:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=bell.ca 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 s6rj8eIklp1o for ; Thu, 26 Aug 2021 06:35:55 -0700 (PDT) Received: from ESA1-Wyn.bell.ca (esa1-wyn.bell.ca [67.69.243.161]) (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 C7D003A1497 for ; Thu, 26 Aug 2021 06:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1629984954; x=1661520954; h=from:to:cc:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=iWdNFfyFY5WZxiK4hhZLXyPsn9RMPjKYqoQ+CAzzzT4=; b=fwaQsqDBj5vUEi1sma1mtWClsxMaqvgq1PFfcNeuSvoNNZYYMDrmq5m1 ZnFxJouEa/PMrAyEMvdnm0TQ5w0rK4lUTqkHOqqSbxEFvMJAmA/ec2mRe NQb5c51TW2ugIfCN5i+GLyrHMoBxf2pqZhaRZ0Gv9T1o6LKP+5Z16LrYQ 7DUgWaek70a4ITiSXce8L9M6o9gNdgcyALNspZW+cL3ie4MgcXIisQnpi 5v4FgUmE4VePPeTqeoyA3LDx0OUIUjvphxZsqTAffDI4D9K6RO+xbkx0C pEpo4jOnaO3LN+BYSpO+OuJhFD7BmgrUgo1qsTUPrON1onIsIyWnCoziN Q==; IronPort-SDR: S4QQgM6othq4rlmY2HfTqklTSWtY3SLS+iZT4a0UGwSfJmA6veedudPd1BPNI/5TtO9xMRY3by lL75FXPEg/Qg== Received: from dm5cch-d00.bellca.int.bell.ca (HELO DG4MBX01-WYN.bell.corp.bce.ca) ([198.235.102.30]) by esa01corp-wyn.bell.corp.bce.ca with ESMTP; 26 Aug 2021 09:35:53 -0400 Received: from DG12MBX04-WYN.bell.corp.bce.ca (142.182.18.49) by DG4MBX01-WYN.bell.corp.bce.ca (142.182.18.27) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Thu, 26 Aug 2021 09:35:53 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX04-WYN.bell.corp.bce.ca (142.182.18.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Thu, 26 Aug 2021 09:35:52 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Thu, 26 Aug 2021 09:35:52 -0400 From: "Caron, Guy" To: Brian Rosen CC: Randall Gellens , ECRIT Thread-Topic: [EXT]Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS Thread-Index: AQHXmfwhRqgqGYN29EukUdmptVZv5auFB74AgAAC6zCAAG01AIAAQ6ZAgABQ84D//71fAA== Date: Thu, 26 Aug 2021 13:35:52 +0000 Message-ID: <7bd393f69edc400cad28ed4c98b78c66@bell.ca> References: <1120BD41-A143-4AC1-B1A7-6CFF40658FF7@randy.pensive.org> <26184A64-2B40-4230-A09B-9A2D00D5F150@brianrosen.net> <14a2a0fad5f1499ca7939e820cc8a852@bell.ca> <34febd3e0984476380325a181f7b611a@bell.ca> <219EED44-D2BB-477A-9452-6BF688FB89AD@brianrosen.net> In-Reply-To: <219EED44-D2BB-477A-9452-6BF688FB89AD@brianrosen.net> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.68] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 13:36:01 -0000 QW4gYXR0YWNrZXIgY2FuIG1pbWljIHRoZSBMb1NUIFNlcnZlcidzIGJlaGF2aW91ciB2ZXJ5IGNs b3NlbHkgd2hpbGUgbWFuaXB1bGF0aW5nIHRoZSBkYXRhIHNvIHRoYXQgcm91dGluZyBpcyBhZmZl Y3RlZC4NCg0KSSBkb24ndCBrbm93IHRvIHdoYXQgZXh0ZW50IHRoaXMgaXMgcmVhbGlzdGljLiBJ ZiBmb2xrcyBkbyBub3Qgc2VlIGFybSB0aGVuIGxldCdzIG1vdmUgb24uDQoNClRoYW5rcywNCg0K R3V5DQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogQnJpYW4gUm9zZW4gPGJy QGJyaWFucm9zZW4ubmV0PiANCkVudm95w6nCoDogMjYgYW/Du3QgMjAyMSAwOTozMg0Kw4DCoDog Q2Fyb24sIEd1eSA8Zy5jYXJvbkBiZWxsLmNhPg0KQ2PCoDogUmFuZGFsbCBHZWxsZW5zIDxyZytp ZXRmQHJhbmR5LnBlbnNpdmUub3JnPjsgRUNSSVQgPGVjcml0QGlldGYub3JnPg0KT2JqZXTCoDog W0VYVF1SZTogW0Vjcml0XSBQcm9ibGVtIGluIC1wbGFubmVkLWNoYW5nZXM6IHVuaXF1ZSByZWNv cmRzIGluIExvU1Qgc2VydmVyIG1heSBub3QgbWF0Y2ggdW5pcXVlIHJlY29yZHMgaW4gTElTDQoN CkkgZG9u4oCZdCBzZWUgaG93IHRoaXMga25vd2xlZGdlIGFpZHMgYW4gYXR0YWNrLiAgWWVzLCBp dCBrbm93cyB3aGF0IGlzIGEgcm9hZCBjZW50ZXJsaW5lIGFuZCB3aGF0IGlzIGFuIGFkZHJlc3Mg cG9pbnQgKG9yIGVxdWl2YWxlbnQpLCBidXQgSSBkb27igJl0IHNlZSBob3cgYW4gYXR0YWNrZXIg Y291bGQgdXNlIHRoYXQgaW5mb3JtYXRpb24uICANCg0KQWxzbywgeW91IGdldCBleGFjdGx5IHRo ZSBzYW1lIGluZm9ybWF0aW9uIGFscmVhZHk6IGFkZHJlc3MgbnVtYmVyIHdpbGwgYmUgaW4g4oCc dW5jaGVja2Vk4oCdIGZvciBhIHJvYWQgY2VudGVybGluZSAoYXNzdW1pbmcgaXTigJlzIGluIGEg cmFuZ2UsIGlmIGl04oCZcyBub3QsIGl04oCZcyBpbiBpbnZhbGlkKS4NClRoaXMgaXMgYmVjYXVz ZSA0LTEwMCBpbmNsdWRlcyA1NSBhbmQgdGhlcmUgbWF5IG9yIG1heSBub3QgYmUgYW4gYWN0dWFs IDU1IGFkZHJlc3MgbnVtYmVyLiAgTm93LCB0aGF0IHJlYWxseSBpcyBzcGVjaWZpYyB0byBOb3J0 aCBBbWVyaWNhOiB0aGUgTkVOQSBzdGFuZGFyZCBzYXlzIHRoYXTigJlzIGhvdyB5b3UgcG9wdWxh dGUgdGhlIHVuY2hlY2tlZCBsaXN0OiA1MjIyIGlzbuKAmXQgc3BlY2lmaWMuDQoNCkJyaWFuDQoN Cj4gT24gQXVnIDI2LCAyMDIxLCBhdCA5OjA5IEFNLCBDYXJvbiwgR3V5IDxnLmNhcm9uQGJlbGwu Y2E+IHdyb3RlOg0KPiANCj4gQm90aCBzb2x1dGlvbnMgcmV2ZWFsIHRoZSBncmFudWxhcml0eSBv ZiB0aGUgdW5kZXJseWluZyBkYXRhIGluIHRoZSBMb1NUIHNlcnZlci4NCj4gDQo+IEhlcmUgaXMg YW4gZXhhbXBsZToNCj4gDQo+IDEuIENsaWVudCBzZW5kcyBhIFVSSSBmb3IgZWFjaCBkaXNjcmV0 ZSBsb2NhdGlvbiAodGhpbmsgY2l2aWMgbnVtYmVycykgb2YgYSBzdHJlZXQuDQo+IDIuIFNlcnZl ciBpcyBvbmx5IHByb3Zpc2lvbmVkIHdpdGggcm9hZCBjZW50ZXJsaW5lIGRhdGEgZm9yIHRoYXQg c3RyZWV0IGFuZCB0aHVzIHJldHVybiBvbmUgVVJJIChvciBJRCkgYmFjayB0byB0aGUgY2xpZW50 IGZvciBlYWNoIGRpc2NyZXRlIGxvY2F0aW9uIGl0IGhhcy4NCj4gMy4gQ2xpZW50IHN0b3JlcyB0 aGlzIHVuaXF1ZSBVUkkgKG9yIElEKSBhZ2FpbnN0IGFsbCBkaXNjcmV0ZSBsb2NhdGlvbnMuDQo+ IDQuIEFmdGVyIGFsbCB0aGUgQ2xpZW50J3MgbG9jYXRpb25zIGhhdmUgZ290dGVuIHRoZSBVUklz IChvciAoSURzKSBmcm9tIHRoZSBTZXJ2ZXIsIHRoZSBDbGllbnQgaGFzIGEgZGV0YWlsZWQgdmll dyBvZiB0aGUgU2VydmVyJ3MgdW5kZXJseWluZyBkYXRhLg0KPiANCj4gVGhlbiwgcHV0IHRoaXMg aW4gdGhlIGhhbmRzIG9mIGFuIGF0dGFja2VyLg0KPiANCj4gVGhhbmtzLA0KPiANCj4gDQo+IEd1 eQ0KPiANCj4gDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZSA6IFJhbmRhbGwg R2VsbGVucyA8cmcraWV0ZkByYW5keS5wZW5zaXZlLm9yZz4gRW52b3nDqSA6IDI2IGFvw7t0IDIw MjEgDQo+IDAwOjQwIMOAIDogQ2Fyb24sIEd1eSA8Zy5jYXJvbkBiZWxsLmNhPiBDYyA6IEJyaWFu IFJvc2VuIA0KPiA8YnJAYnJpYW5yb3Nlbi5uZXQ+OyBFQ1JJVCA8ZWNyaXRAaWV0Zi5vcmc+IE9i amV0IDogW0VYVF1SZTogW0Vjcml0XSANCj4gUHJvYmxlbSBpbiAtcGxhbm5lZC1jaGFuZ2VzOiB1 bmlxdWUgcmVjb3JkcyBpbiBMb1NUIHNlcnZlciBtYXkgbm90IA0KPiBtYXRjaCB1bmlxdWUgcmVj b3JkcyBpbiBMSVMNCj4gDQo+IEhpIEd1eSwNCj4gDQo+IEknbSBub3QgZm9sbG93aW5nIGhvdyAi Qm90aCBzb2x1dGlvbnMgd291bGQgYWxsb3cgYSBtYWxldm9sZW50IGNsaWVudCB0byByZWJ1aWxk IHRoZSBzZXJ2ZXIncyBpbnRlcm5hbCBkYXRhIHN0cnVjdHVyZSIuICBJbiBlaXRoZXIgc29sdXRp b24sIHRoZSBMb1NUIHNlcnZlciByZXR1cm5zIHNvbWV0aGluZyB0byB0aGUgTG9TVCBjbGllbnQg dGhhdCB0aGUgTG9TVCBjbGllbnQgdXNlcyB0byBtYXJrIG9uZSBvciBtb3JlIG9mIGl0cyBsb2Nh dGlvbiByZWNvcmRzLiBJZi93aGVuIHRoZSBMb1NUIHNlcnZlciBzZW5kcyB0aGUgY2xpZW50IGEg PGxvY2F0aW9uSW52YWxpZGF0ZWQ+IG9iamVjdCwgdGhlIG9iamVjdCBjb250YWlucyB0aGlzIHNh bWUgbWFya2VyLCB3aGljaCB0aGUgY2xpZW50IHVzZXMgdG8ga25vdyB3aGljaCBvZiBpdHMgcmVj b3JkcyBzaG91bGQgYmUgcmV2YWxpZGF0ZWQuDQo+IA0KPiAtLVJhbmRhbGwNCj4gDQo+IE9uIDI1 IEF1ZyAyMDIxLCBhdCAxOTozMywgQ2Fyb24sIEd1eSB3cm90ZToNCj4gDQo+PiBJIGRpZCBub3Qg aGF2ZSBtdWNoIGN5Y2xlIHRpbWUgdG8gdGhpbmsgYWJvdXQgdGhpcyBidXQgSSBjYW4gc2hhcmUg bXkgDQo+PiBpbml0aWFsIGNvbmNlcm5zIHdpdGggdGhlIHByb3Bvc2VkIHNvbHV0aW9ucy4NCj4+ IA0KPj4gVGhlIGNvbmNlcm5zIEkgaGF2ZSBhcmUgc2VjdXJpdHktcmVsYXRlZC4gIEEgTG9TVCBz ZXJ2ZXIgdXNlZCBpbiB0aGUgDQo+PiBjb250ZXh0IG9mIGVtZXJnZW5jeSBjYWxsaW5nICh0aGUg c2NvcGUgb2YgRUNSSVQpIGhvbGRzIGNyaXRpY2FsIA0KPj4gaW5mb3JtYXRpb24gYWJvdXQgaG93 IGVtZXJnZW5jeSBjYWxscyBhcmUgcm91dGVkIGFuZCB0aGVpciANCj4+IGRlc3RpbmF0aW9ucy4g Qm90aCBzb2x1dGlvbnMgd291bGQgYWxsb3cgYSBtYWxldm9sZW50IGNsaWVudCB0byANCj4+IHJl YnVpbGQgdGhlIHNlcnZlcidzIGludGVybmFsIGRhdGEgc3RydWN0dXJlIGFuZCB1c2UgdGhhdCBh cyBhbiANCj4+IGF0dGFjayBvZiBzb21lIGZvcm0gKGltcGVyc29uYWxpc2F0aW9uLCBNSVRNLCBT V0FUdGluZywgZXRjLikuDQo+PiANCj4+IEkgaGF2ZSByZS1yZWFkIHRoZSBTZWN1cml0eSBzZWN0 aW9uIG9mIFJGQyA1MjIyIGFuZCBwZXJoYXBzIHRoZXNlIA0KPj4gY29uY2VybnMgYXJlIGFscmVh ZHkgYWRkcmVzc2VkIGJ1dCB3b3VsZCBsaWtlIHRvIGhlYXIgdGhlIG9waW5pb24gb2YgDQo+PiBv dGhlcnMuDQo+PiANCj4+IFRoYW5rcywNCj4+IA0KPj4gR3V5DQo+PiANCj4+IA0KPj4gDQo+PiAt LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+IERlIDogRWNyaXQgPGVjcml0LWJvdW5jZXNA aWV0Zi5vcmc+IERlIGxhIHBhcnQgZGUgQnJpYW4gUm9zZW4gRW52b3nDqSA6IA0KPj4gMjUgYW/D u3QgMjAyMSAxNzo1OCDDgCA6IFJhbmRhbGwgR2VsbGVucyA8cmcraWV0ZkByYW5keS5wZW5zaXZl Lm9yZz4gQ2MNCj4+IDogRUNSSVQgPGVjcml0QGlldGYub3JnPiBPYmpldCA6IFtFWFRdUmU6IFtF Y3JpdF0gUHJvYmxlbSBpbg0KPj4gLXBsYW5uZWQtY2hhbmdlczogdW5pcXVlIHJlY29yZHMgaW4g TG9TVCBzZXJ2ZXIgbWF5IG5vdCBtYXRjaCB1bmlxdWUgDQo+PiByZWNvcmRzIGluIExJUw0KPj4g DQo+PiBZZWFoLCBvZiB0aGUgdHdvIG9wdGlvbnMsIEkgbGlrZSB0aGUgc2Vjb25kLiAgSSB3b3Vs ZCBsaWtlIHRvIHdhaXQgdG8gDQo+PiBoZXJlIGZyb20gR3V5LCB3aG8gZGlkbuKAmXQgbGlrZSBl aXRoZXIuDQo+PiANCj4+IEVpdGhlciBvZiB0aGUgdHdvIEkgY2FtZSB1cCB3aXRoIGNhbiBiZSBh ZGRlZCBxdWlja2x5IHRvIHRoZSBkb2MuDQo+PiANCj4+IEJyaWFuDQo+PiANCj4+IA0KPj4+IE9u IEF1ZyAyNSwgMjAyMSwgYXQgNTo1NiBQTSwgUmFuZGFsbCBHZWxsZW5zIA0KPj4+IDxyZytpZXRm QHJhbmR5LnBlbnNpdmUub3JnPiB3cm90ZToNCj4+PiANCj4+PiBFaXRoZXIgYXBwcm9hY2ggd291 bGQgd29yazogdGhlIHNlcnZlciByZXR1cm5pbmcgdGhlIHByaW9yIFVSSSBpZiBpdCANCj4+PiBy ZXBsYWNlcyBpdCwgb3IgdGhlIHNlcnZlciBhbHdheXMgcmV0dXJuaW5nIGEgInVuaXF1ZSBsb2Nh dGlvbiBJRCINCj4+PiB3aGVuZXZlciBpdCBzdG9yZXMgYSBVUkkuICBJbiB0aGUgbGF0dGVyIGNh c2UsIHdlJ2Qgd2FudCB0byBhZGQgdGhpcyANCj4+PiBJRCB0byB0aGUgPGxvY2F0aW9uSW52YWxp ZGF0ZWQ+IG9iamVjdC4gIFRoZSBsYXR0ZXIgc2VlbXMgYSBiaXQgDQo+Pj4gY2xlYW5lciwgYXMg dGhlbiB0aGUgc2VydmVyIGFsd2F5cyByZXR1cm5zIGFuIElELCBhbmQgYSBjbGllbnQgDQo+Pj4g YWx3YXlzIHN0b3JlcyB0aGlzIElEIHdoZW5ldmVyIGl0IHNlbmRzIGEgVVJJLCBhbmQgdXNlcyB0 aGUgSUQgdG8gDQo+Pj4gcmUtdmFsaWRhdGUgbG9jYXRpb25zIHdoZW4gaXQgZ2V0cyBhIDxsb2Nh dGlvbkludmFsaWRhdGVkPiBvYmplY3QuDQo+Pj4gDQo+Pj4gLS1SYW5kYWxsDQo+Pj4gDQo+Pj4g T24gMjQgQXVnIDIwMjEsIGF0IDEzOjA4LCBCcmlhbiBSb3NlbiB3cm90ZToNCj4+PiANCj4+Pj4g SSByZWFsaXplZCB3ZSBoYXZlIGEgcHJvYmxlbSB3aXRoIC1wbGFubmVkLWNoYW5nZXMuICBUaGUg dGV4dCBub3RlczoNCj4+Pj4gRWFjaCBjbGllbnQgb2YgdGhlIHNlcnZlciBtYXkgb25seSBzdG9y ZSBvbmUgVVJJIGFnYWluc3QgYSANCj4+Pj4gbG9jYXRpb24sIHdoZXJlIOKAnGxvY2F0aW9u4oCd IGlzIGRlZmluZWQgYnkgcG9saWN5IGF0IHRoZSBzZXJ2ZXIsIA0KPj4+PiBzaW5jZSBhIGdpdmVu IHVuaXF1ZSBsb2NhdGlvbiBtYXkgaGF2ZSBtYW55IGNvbWJpbmF0aW9ucyBvZiANCj4+Pj4gbG9j YXRpb24gZWxlbWVudHMgdGhhdCByZXNvbHZlIHRvIHRoZSBzYW1lIGxvY2F0aW9uLiAgSWYgdGhl IHNlcnZlciANCj4+Pj4gcmVjZWl2ZXMgYSDigJh1cmnigJkgZm9yIHRoZSBzYW1lIGxvY2F0aW9u IGZyb20gdGhlIHNhbWUgY2xpZW50LCB0aGUgDQo+Pj4+IFVSSSBpbiB0aGUgcmVxdWVzdCByZXBs YWNlcyB0aGUgVVJJIGl0IHByZXZpb3VzbHkgcmV0YWluZWQuDQo+Pj4+IA0KPj4+PiBCdXQgdGhp cyBtZWFucyB0aGF0IG11bHRpcGxlIHJlY29yZHMgaW4gdGhlIExJUyBtYXkgYmUgb25lIHJlY29y ZCANCj4+Pj4gaW4gdGhlIExvU1Qgc2VydmVyIGFuZCB3aGVuIHRoZSBMSVMgYXNzb2NpYXRlcyB1 bmlxdWUgVVJJcyB3aXRoIA0KPj4+PiB3aGF0IGl0IHRoaW5rcyBpcyBtdWx0aXBsZSByZWNvcmRz LCBvbmx5IG9uZSBpcyByZXRhaW5lZCBhbmQgaXQgDQo+Pj4+IGRvZXNu4oCZdCBrbm93IHRoYXQu DQo+Pj4+IA0KPj4+PiBUaGUgZWFzaWVzdCBmaXggaXMgdG8gcmV0dXJuIHRoZSByZXBsYWNlZCBV UkkuICBUaGUgY2xpZW50IHdvdWxkIA0KPj4+PiB0aGVuIGJlIGFibGUgdG8gc3BvdCB0aGF0IHRo ZSByZWNvcmRzIGFyZSBsaW5rZWQgYW5kIGRvIHRoZSBib29rIA0KPj4+PiBrZWVwaW5nIHRvIHRy YWNrIHdoYXQgaXQgc2hvdWxkIGRvLg0KPj4+PiBBbm90aGVyIHdheSB0byBmaXggdGhpcyBpcyB0 byByZXR1cm4gYSB1bmlxdWUgSUQgb2YgdGhlIHJlY29yZCBpbiANCj4+Pj4gdGhlIExvU1Qgc2Vy dmVyIHdoZW4geW91IHVzZSB0aGUgZXh0ZW5zaW9uLiAgVGhlIExJUyBjYW4gdGhlbiBrZWVwIA0K Pj4+PiBhbiBpbnRlcm5hbCByZWNvcmQgb2YgYWxsIHRoZSByZWxhdGVkIGVudHJpZXMgaXQgaGFz IHRoYXQgYXJlIG9uZSANCj4+Pj4gcmVjb3JkIHRvIHRoZSBzZXJ2ZXIuDQo+Pj4+IA0KPj4+PiBC cmlhbg0KPj4+PiANCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+Pj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+Pj4+IEVjcml0QGlldGYub3JnDQo+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4+IA0KPj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IEVjcml0 IG1haWxpbmcgbGlzdA0KPj4gRWNyaXRAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gLQ0KPj4gLS0tLS0t LS0gRXh0ZXJuYWwgRW1haWw6IFBsZWFzZSB1c2UgY2F1dGlvbiB3aGVuIG9wZW5pbmcgbGlua3Mg YW5kIA0KPj4gYXR0YWNobWVudHMgLyBDb3VycmllbCBleHRlcm5lOiBTb3lleiBwcnVkZW50IGF2 ZWMgbGVzIGxpZW5zIGV0IA0KPj4gZG9jdW1lbnRzIGpvaW50cw0KPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ IC0tLS0tLS0tIEV4dGVybmFsIEVtYWlsOiBQbGVhc2UgdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5n IGxpbmtzIGFuZCANCj4gYXR0YWNobWVudHMgLyBDb3VycmllbCBleHRlcm5lOiBTb3lleiBwcnVk ZW50IGF2ZWMgbGVzIGxpZW5zIGV0IA0KPiBkb2N1bWVudHMgam9pbnRzDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KRXh0ZXJuYWwgRW1haWw6IFBsZWFzZSB1c2UgY2F1dGlvbiB3aGVuIG9wZW5p bmcgbGlua3MgYW5kIGF0dGFjaG1lbnRzIC8gQ291cnJpZWwgZXh0ZXJuZTogU295ZXogcHJ1ZGVu dCBhdmVjIGxlcyBsaWVucyBldCBkb2N1bWVudHMgam9pbnRzDQo= From nobody Thu Aug 26 06:46:14 2021 Return-Path: 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 BFC7B3A15AA for ; Thu, 26 Aug 2021 06:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bell.ca 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 0dXagTkPP_Au for ; Thu, 26 Aug 2021 06:46:07 -0700 (PDT) Received: from ESA3-Dor.bell.ca (esa3-dor.bell.ca [204.101.223.60]) (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 58E5D3A15AC for ; Thu, 26 Aug 2021 06:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1629985567; x=1661521567; h=from:to:cc:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=fD5bBITlAFs+rlomZtUFlZkeFE+POvCG5h/IV5qwpJo=; b=QB5il4pxGHt8imWzFdFrVOgbUEGlOjxYIqfWKhlB/SDtA8Ek/+aI2xxm VJEeS6HZblg6ogha/kYLqWD44zU1NKV8F6eBk+AHldoTiG8CeAQUXkWtm rDrxCGoTGEsW1La5dpr6tbN9xAMuVOmelwTzBChQkDZTpWNA/B5E1V08g TcHtiar/9knYnbVLRmLHDCINogrUQ8Q55KVAnerXdvIHA220554XVhBom k8EdpJugGax7dS98yo/2MDs2pIJJ1q3Qm5H0U0XWiEf55LowvAJuVj7+A Zs69YjQDl53FlKrrpTAjw3s1GpW3ToZ+XBzs7vAHod+UBiCVa9sfxMNxn A==; IronPort-SDR: cRmE/TwKjc11Uqs+ZoWW85k/gBPcAoP24trMfh+MFlqJnJJy5XVUOKz+vbypCyORrOfK/+rI81 K7T0xmzTudHA== Received: from dc5cmz-d00.bellca.int.bell.ca (HELO DG6MBX01-WYN.bell.corp.bce.ca) ([198.235.121.231]) by esa03corp-dor.bell.corp.bce.ca with ESMTP; 26 Aug 2021 09:46:05 -0400 Received: from DG12MBX02-WYN.bell.corp.bce.ca (142.182.18.47) by DG6MBX01-WYN.bell.corp.bce.ca (142.182.18.36) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Thu, 26 Aug 2021 09:46:04 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX02-WYN.bell.corp.bce.ca (142.182.18.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Thu, 26 Aug 2021 09:46:04 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Thu, 26 Aug 2021 09:46:04 -0400 From: "Caron, Guy" To: "Caron, Guy" , Brian Rosen CC: ECRIT Thread-Topic: [EXT]Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS Thread-Index: AQHXmfwhRqgqGYN29EukUdmptVZv5auFB74AgAAC6zCAAG01AIAAQ6ZAgABQ84D//71fAIAAA11Q Date: Thu, 26 Aug 2021 13:46:04 +0000 Message-ID: <7b4c1ab16f3f43498066780cce47410a@bell.ca> References: <1120BD41-A143-4AC1-B1A7-6CFF40658FF7@randy.pensive.org> <26184A64-2B40-4230-A09B-9A2D00D5F150@brianrosen.net> <14a2a0fad5f1499ca7939e820cc8a852@bell.ca> <34febd3e0984476380325a181f7b611a@bell.ca> <219EED44-D2BB-477A-9452-6BF688FB89AD@brianrosen.net> <7bd393f69edc400cad28ed4c98b78c66@bell.ca> In-Reply-To: <7bd393f69edc400cad28ed4c98b78c66@bell.ca> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.68] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 13:46:13 -0000 ImFybSIgc2hvdWxkIGJlICJoYXJtIiwgb2J2aW91c2x5Lg0KDQpHdXkNCg0KLS0tLS1NZXNzYWdl IGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBFY3JpdCA8ZWNyaXQtYm91bmNlc0BpZXRmLm9yZz4gRGUg bGEgcGFydCBkZSBDYXJvbiwgR3V5DQpFbnZvecOpwqA6IDI2IGFvw7t0IDIwMjEgMDk6MzYNCsOA wqA6IEJyaWFuIFJvc2VuIDxickBicmlhbnJvc2VuLm5ldD4NCkNjwqA6IEVDUklUIDxlY3JpdEBp ZXRmLm9yZz4NCk9iamV0wqA6IFtFWFRdUmU6IFtFY3JpdF0gUHJvYmxlbSBpbiAtcGxhbm5lZC1j aGFuZ2VzOiB1bmlxdWUgcmVjb3JkcyBpbiBMb1NUIHNlcnZlciBtYXkgbm90IG1hdGNoIHVuaXF1 ZSByZWNvcmRzIGluIExJUw0KDQpBbiBhdHRhY2tlciBjYW4gbWltaWMgdGhlIExvU1QgU2VydmVy J3MgYmVoYXZpb3VyIHZlcnkgY2xvc2VseSB3aGlsZSBtYW5pcHVsYXRpbmcgdGhlIGRhdGEgc28g dGhhdCByb3V0aW5nIGlzIGFmZmVjdGVkLg0KDQpJIGRvbid0IGtub3cgdG8gd2hhdCBleHRlbnQg dGhpcyBpcyByZWFsaXN0aWMuIElmIGZvbGtzIGRvIG5vdCBzZWUgYXJtIHRoZW4gbGV0J3MgbW92 ZSBvbi4NCg0KVGhhbmtzLA0KDQpHdXkNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpE ZcKgOiBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ+DQpFbnZvecOpwqA6IDI2IGFvw7t0 IDIwMjEgMDk6MzINCsOAwqA6IENhcm9uLCBHdXkgPGcuY2Fyb25AYmVsbC5jYT4NCkNjwqA6IFJh bmRhbGwgR2VsbGVucyA8cmcraWV0ZkByYW5keS5wZW5zaXZlLm9yZz47IEVDUklUIDxlY3JpdEBp ZXRmLm9yZz4gT2JqZXTCoDogW0VYVF1SZTogW0Vjcml0XSBQcm9ibGVtIGluIC1wbGFubmVkLWNo YW5nZXM6IHVuaXF1ZSByZWNvcmRzIGluIExvU1Qgc2VydmVyIG1heSBub3QgbWF0Y2ggdW5pcXVl IHJlY29yZHMgaW4gTElTDQoNCkkgZG9u4oCZdCBzZWUgaG93IHRoaXMga25vd2xlZGdlIGFpZHMg YW4gYXR0YWNrLiAgWWVzLCBpdCBrbm93cyB3aGF0IGlzIGEgcm9hZCBjZW50ZXJsaW5lIGFuZCB3 aGF0IGlzIGFuIGFkZHJlc3MgcG9pbnQgKG9yIGVxdWl2YWxlbnQpLCBidXQgSSBkb27igJl0IHNl ZSBob3cgYW4gYXR0YWNrZXIgY291bGQgdXNlIHRoYXQgaW5mb3JtYXRpb24uICANCg0KQWxzbywg eW91IGdldCBleGFjdGx5IHRoZSBzYW1lIGluZm9ybWF0aW9uIGFscmVhZHk6IGFkZHJlc3MgbnVt YmVyIHdpbGwgYmUgaW4g4oCcdW5jaGVja2Vk4oCdIGZvciBhIHJvYWQgY2VudGVybGluZSAoYXNz dW1pbmcgaXTigJlzIGluIGEgcmFuZ2UsIGlmIGl04oCZcyBub3QsIGl04oCZcyBpbiBpbnZhbGlk KS4NClRoaXMgaXMgYmVjYXVzZSA0LTEwMCBpbmNsdWRlcyA1NSBhbmQgdGhlcmUgbWF5IG9yIG1h eSBub3QgYmUgYW4gYWN0dWFsIDU1IGFkZHJlc3MgbnVtYmVyLiAgTm93LCB0aGF0IHJlYWxseSBp cyBzcGVjaWZpYyB0byBOb3J0aCBBbWVyaWNhOiB0aGUgTkVOQSBzdGFuZGFyZCBzYXlzIHRoYXTi gJlzIGhvdyB5b3UgcG9wdWxhdGUgdGhlIHVuY2hlY2tlZCBsaXN0OiA1MjIyIGlzbuKAmXQgc3Bl Y2lmaWMuDQoNCkJyaWFuDQoNCj4gT24gQXVnIDI2LCAyMDIxLCBhdCA5OjA5IEFNLCBDYXJvbiwg R3V5IDxnLmNhcm9uQGJlbGwuY2E+IHdyb3RlOg0KPiANCj4gQm90aCBzb2x1dGlvbnMgcmV2ZWFs IHRoZSBncmFudWxhcml0eSBvZiB0aGUgdW5kZXJseWluZyBkYXRhIGluIHRoZSBMb1NUIHNlcnZl ci4NCj4gDQo+IEhlcmUgaXMgYW4gZXhhbXBsZToNCj4gDQo+IDEuIENsaWVudCBzZW5kcyBhIFVS SSBmb3IgZWFjaCBkaXNjcmV0ZSBsb2NhdGlvbiAodGhpbmsgY2l2aWMgbnVtYmVycykgb2YgYSBz dHJlZXQuDQo+IDIuIFNlcnZlciBpcyBvbmx5IHByb3Zpc2lvbmVkIHdpdGggcm9hZCBjZW50ZXJs aW5lIGRhdGEgZm9yIHRoYXQgc3RyZWV0IGFuZCB0aHVzIHJldHVybiBvbmUgVVJJIChvciBJRCkg YmFjayB0byB0aGUgY2xpZW50IGZvciBlYWNoIGRpc2NyZXRlIGxvY2F0aW9uIGl0IGhhcy4NCj4g My4gQ2xpZW50IHN0b3JlcyB0aGlzIHVuaXF1ZSBVUkkgKG9yIElEKSBhZ2FpbnN0IGFsbCBkaXNj cmV0ZSBsb2NhdGlvbnMuDQo+IDQuIEFmdGVyIGFsbCB0aGUgQ2xpZW50J3MgbG9jYXRpb25zIGhh dmUgZ290dGVuIHRoZSBVUklzIChvciAoSURzKSBmcm9tIHRoZSBTZXJ2ZXIsIHRoZSBDbGllbnQg aGFzIGEgZGV0YWlsZWQgdmlldyBvZiB0aGUgU2VydmVyJ3MgdW5kZXJseWluZyBkYXRhLg0KPiAN Cj4gVGhlbiwgcHV0IHRoaXMgaW4gdGhlIGhhbmRzIG9mIGFuIGF0dGFja2VyLg0KPiANCj4gVGhh bmtzLA0KPiANCj4gDQo+IEd1eQ0KPiANCj4gDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0t LQ0KPiBEZSA6IFJhbmRhbGwgR2VsbGVucyA8cmcraWV0ZkByYW5keS5wZW5zaXZlLm9yZz4gRW52 b3nDqSA6IDI2IGFvw7t0IDIwMjENCj4gMDA6NDAgw4AgOiBDYXJvbiwgR3V5IDxnLmNhcm9uQGJl bGwuY2E+IENjIDogQnJpYW4gUm9zZW4gDQo+IDxickBicmlhbnJvc2VuLm5ldD47IEVDUklUIDxl Y3JpdEBpZXRmLm9yZz4gT2JqZXQgOiBbRVhUXVJlOiBbRWNyaXRdIA0KPiBQcm9ibGVtIGluIC1w bGFubmVkLWNoYW5nZXM6IHVuaXF1ZSByZWNvcmRzIGluIExvU1Qgc2VydmVyIG1heSBub3QgDQo+ IG1hdGNoIHVuaXF1ZSByZWNvcmRzIGluIExJUw0KPiANCj4gSGkgR3V5LA0KPiANCj4gSSdtIG5v dCBmb2xsb3dpbmcgaG93ICJCb3RoIHNvbHV0aW9ucyB3b3VsZCBhbGxvdyBhIG1hbGV2b2xlbnQg Y2xpZW50IHRvIHJlYnVpbGQgdGhlIHNlcnZlcidzIGludGVybmFsIGRhdGEgc3RydWN0dXJlIi4g IEluIGVpdGhlciBzb2x1dGlvbiwgdGhlIExvU1Qgc2VydmVyIHJldHVybnMgc29tZXRoaW5nIHRv IHRoZSBMb1NUIGNsaWVudCB0aGF0IHRoZSBMb1NUIGNsaWVudCB1c2VzIHRvIG1hcmsgb25lIG9y IG1vcmUgb2YgaXRzIGxvY2F0aW9uIHJlY29yZHMuIElmL3doZW4gdGhlIExvU1Qgc2VydmVyIHNl bmRzIHRoZSBjbGllbnQgYSA8bG9jYXRpb25JbnZhbGlkYXRlZD4gb2JqZWN0LCB0aGUgb2JqZWN0 IGNvbnRhaW5zIHRoaXMgc2FtZSBtYXJrZXIsIHdoaWNoIHRoZSBjbGllbnQgdXNlcyB0byBrbm93 IHdoaWNoIG9mIGl0cyByZWNvcmRzIHNob3VsZCBiZSByZXZhbGlkYXRlZC4NCj4gDQo+IC0tUmFu ZGFsbA0KPiANCj4gT24gMjUgQXVnIDIwMjEsIGF0IDE5OjMzLCBDYXJvbiwgR3V5IHdyb3RlOg0K PiANCj4+IEkgZGlkIG5vdCBoYXZlIG11Y2ggY3ljbGUgdGltZSB0byB0aGluayBhYm91dCB0aGlz IGJ1dCBJIGNhbiBzaGFyZSBteSANCj4+IGluaXRpYWwgY29uY2VybnMgd2l0aCB0aGUgcHJvcG9z ZWQgc29sdXRpb25zLg0KPj4gDQo+PiBUaGUgY29uY2VybnMgSSBoYXZlIGFyZSBzZWN1cml0eS1y ZWxhdGVkLiAgQSBMb1NUIHNlcnZlciB1c2VkIGluIHRoZSANCj4+IGNvbnRleHQgb2YgZW1lcmdl bmN5IGNhbGxpbmcgKHRoZSBzY29wZSBvZiBFQ1JJVCkgaG9sZHMgY3JpdGljYWwgDQo+PiBpbmZv cm1hdGlvbiBhYm91dCBob3cgZW1lcmdlbmN5IGNhbGxzIGFyZSByb3V0ZWQgYW5kIHRoZWlyIA0K Pj4gZGVzdGluYXRpb25zLiBCb3RoIHNvbHV0aW9ucyB3b3VsZCBhbGxvdyBhIG1hbGV2b2xlbnQg Y2xpZW50IHRvIA0KPj4gcmVidWlsZCB0aGUgc2VydmVyJ3MgaW50ZXJuYWwgZGF0YSBzdHJ1Y3R1 cmUgYW5kIHVzZSB0aGF0IGFzIGFuIA0KPj4gYXR0YWNrIG9mIHNvbWUgZm9ybSAoaW1wZXJzb25h bGlzYXRpb24sIE1JVE0sIFNXQVR0aW5nLCBldGMuKS4NCj4+IA0KPj4gSSBoYXZlIHJlLXJlYWQg dGhlIFNlY3VyaXR5IHNlY3Rpb24gb2YgUkZDIDUyMjIgYW5kIHBlcmhhcHMgdGhlc2UgDQo+PiBj b25jZXJucyBhcmUgYWxyZWFkeSBhZGRyZXNzZWQgYnV0IHdvdWxkIGxpa2UgdG8gaGVhciB0aGUg b3BpbmlvbiBvZiANCj4+IG90aGVycy4NCj4+IA0KPj4gVGhhbmtzLA0KPj4gDQo+PiBHdXkNCj4+ IA0KPj4gDQo+PiANCj4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4gRGUgOiBFY3Jp dCA8ZWNyaXQtYm91bmNlc0BpZXRmLm9yZz4gRGUgbGEgcGFydCBkZSBCcmlhbiBSb3NlbiBFbnZv ecOpIDogDQo+PiAyNSBhb8O7dCAyMDIxIDE3OjU4IMOAIDogUmFuZGFsbCBHZWxsZW5zIDxyZytp ZXRmQHJhbmR5LnBlbnNpdmUub3JnPiBDYw0KPj4gOiBFQ1JJVCA8ZWNyaXRAaWV0Zi5vcmc+IE9i amV0IDogW0VYVF1SZTogW0Vjcml0XSBQcm9ibGVtIGluDQo+PiAtcGxhbm5lZC1jaGFuZ2VzOiB1 bmlxdWUgcmVjb3JkcyBpbiBMb1NUIHNlcnZlciBtYXkgbm90IG1hdGNoIHVuaXF1ZSANCj4+IHJl Y29yZHMgaW4gTElTDQo+PiANCj4+IFllYWgsIG9mIHRoZSB0d28gb3B0aW9ucywgSSBsaWtlIHRo ZSBzZWNvbmQuICBJIHdvdWxkIGxpa2UgdG8gd2FpdCB0byANCj4+IGhlcmUgZnJvbSBHdXksIHdo byBkaWRu4oCZdCBsaWtlIGVpdGhlci4NCj4+IA0KPj4gRWl0aGVyIG9mIHRoZSB0d28gSSBjYW1l IHVwIHdpdGggY2FuIGJlIGFkZGVkIHF1aWNrbHkgdG8gdGhlIGRvYy4NCj4+IA0KPj4gQnJpYW4N Cj4+IA0KPj4gDQo+Pj4gT24gQXVnIDI1LCAyMDIxLCBhdCA1OjU2IFBNLCBSYW5kYWxsIEdlbGxl bnMgDQo+Pj4gPHJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmc+IHdyb3RlOg0KPj4+IA0KPj4+IEVp dGhlciBhcHByb2FjaCB3b3VsZCB3b3JrOiB0aGUgc2VydmVyIHJldHVybmluZyB0aGUgcHJpb3Ig VVJJIGlmIGl0IA0KPj4+IHJlcGxhY2VzIGl0LCBvciB0aGUgc2VydmVyIGFsd2F5cyByZXR1cm5p bmcgYSAidW5pcXVlIGxvY2F0aW9uIElEIg0KPj4+IHdoZW5ldmVyIGl0IHN0b3JlcyBhIFVSSS4g IEluIHRoZSBsYXR0ZXIgY2FzZSwgd2UnZCB3YW50IHRvIGFkZCB0aGlzIA0KPj4+IElEIHRvIHRo ZSA8bG9jYXRpb25JbnZhbGlkYXRlZD4gb2JqZWN0LiAgVGhlIGxhdHRlciBzZWVtcyBhIGJpdCAN Cj4+PiBjbGVhbmVyLCBhcyB0aGVuIHRoZSBzZXJ2ZXIgYWx3YXlzIHJldHVybnMgYW4gSUQsIGFu ZCBhIGNsaWVudCANCj4+PiBhbHdheXMgc3RvcmVzIHRoaXMgSUQgd2hlbmV2ZXIgaXQgc2VuZHMg YSBVUkksIGFuZCB1c2VzIHRoZSBJRCB0byANCj4+PiByZS12YWxpZGF0ZSBsb2NhdGlvbnMgd2hl biBpdCBnZXRzIGEgPGxvY2F0aW9uSW52YWxpZGF0ZWQ+IG9iamVjdC4NCj4+PiANCj4+PiAtLVJh bmRhbGwNCj4+PiANCj4+PiBPbiAyNCBBdWcgMjAyMSwgYXQgMTM6MDgsIEJyaWFuIFJvc2VuIHdy b3RlOg0KPj4+IA0KPj4+PiBJIHJlYWxpemVkIHdlIGhhdmUgYSBwcm9ibGVtIHdpdGggLXBsYW5u ZWQtY2hhbmdlcy4gIFRoZSB0ZXh0IG5vdGVzOg0KPj4+PiBFYWNoIGNsaWVudCBvZiB0aGUgc2Vy dmVyIG1heSBvbmx5IHN0b3JlIG9uZSBVUkkgYWdhaW5zdCBhIA0KPj4+PiBsb2NhdGlvbiwgd2hl cmUg4oCcbG9jYXRpb27igJ0gaXMgZGVmaW5lZCBieSBwb2xpY3kgYXQgdGhlIHNlcnZlciwgDQo+ Pj4+IHNpbmNlIGEgZ2l2ZW4gdW5pcXVlIGxvY2F0aW9uIG1heSBoYXZlIG1hbnkgY29tYmluYXRp b25zIG9mIA0KPj4+PiBsb2NhdGlvbiBlbGVtZW50cyB0aGF0IHJlc29sdmUgdG8gdGhlIHNhbWUg bG9jYXRpb24uICBJZiB0aGUgc2VydmVyIA0KPj4+PiByZWNlaXZlcyBhIOKAmHVyaeKAmSBmb3Ig dGhlIHNhbWUgbG9jYXRpb24gZnJvbSB0aGUgc2FtZSBjbGllbnQsIHRoZSANCj4+Pj4gVVJJIGlu IHRoZSByZXF1ZXN0IHJlcGxhY2VzIHRoZSBVUkkgaXQgcHJldmlvdXNseSByZXRhaW5lZC4NCj4+ Pj4gDQo+Pj4+IEJ1dCB0aGlzIG1lYW5zIHRoYXQgbXVsdGlwbGUgcmVjb3JkcyBpbiB0aGUgTElT IG1heSBiZSBvbmUgcmVjb3JkIA0KPj4+PiBpbiB0aGUgTG9TVCBzZXJ2ZXIgYW5kIHdoZW4gdGhl IExJUyBhc3NvY2lhdGVzIHVuaXF1ZSBVUklzIHdpdGggDQo+Pj4+IHdoYXQgaXQgdGhpbmtzIGlz IG11bHRpcGxlIHJlY29yZHMsIG9ubHkgb25lIGlzIHJldGFpbmVkIGFuZCBpdCANCj4+Pj4gZG9l c27igJl0IGtub3cgdGhhdC4NCj4+Pj4gDQo+Pj4+IFRoZSBlYXNpZXN0IGZpeCBpcyB0byByZXR1 cm4gdGhlIHJlcGxhY2VkIFVSSS4gIFRoZSBjbGllbnQgd291bGQgDQo+Pj4+IHRoZW4gYmUgYWJs ZSB0byBzcG90IHRoYXQgdGhlIHJlY29yZHMgYXJlIGxpbmtlZCBhbmQgZG8gdGhlIGJvb2sgDQo+ Pj4+IGtlZXBpbmcgdG8gdHJhY2sgd2hhdCBpdCBzaG91bGQgZG8uDQo+Pj4+IEFub3RoZXIgd2F5 IHRvIGZpeCB0aGlzIGlzIHRvIHJldHVybiBhIHVuaXF1ZSBJRCBvZiB0aGUgcmVjb3JkIGluIA0K Pj4+PiB0aGUgTG9TVCBzZXJ2ZXIgd2hlbiB5b3UgdXNlIHRoZSBleHRlbnNpb24uICBUaGUgTElT IGNhbiB0aGVuIGtlZXAgDQo+Pj4+IGFuIGludGVybmFsIHJlY29yZCBvZiBhbGwgdGhlIHJlbGF0 ZWQgZW50cmllcyBpdCBoYXMgdGhhdCBhcmUgb25lIA0KPj4+PiByZWNvcmQgdG8gdGhlIHNlcnZl ci4NCj4+Pj4gDQo+Pj4+IEJyaWFuDQo+Pj4+IA0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4+Pj4g RWNyaXRAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9lY3JpdA0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+PiBFY3JpdEBpZXRmLm9yZw0KPj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KPj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+PiAtDQo+PiAtLS0tLS0tLSBFeHRlcm5hbCBFbWFpbDogUGxlYXNlIHVzZSBjYXV0aW9uIHdo ZW4gb3BlbmluZyBsaW5rcyBhbmQgDQo+PiBhdHRhY2htZW50cyAvIENvdXJyaWVsIGV4dGVybmU6 IFNveWV6IHBydWRlbnQgYXZlYyBsZXMgbGllbnMgZXQgDQo+PiBkb2N1bWVudHMgam9pbnRzDQo+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gLS0tLS0tLS0gRXh0ZXJuYWwgRW1haWw6IFBsZWFzZSB1c2UgY2F1 dGlvbiB3aGVuIG9wZW5pbmcgbGlua3MgYW5kIA0KPiBhdHRhY2htZW50cyAvIENvdXJyaWVsIGV4 dGVybmU6IFNveWV6IHBydWRlbnQgYXZlYyBsZXMgbGllbnMgZXQgDQo+IGRvY3VtZW50cyBqb2lu dHMNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpFeHRlcm5hbCBFbWFpbDogUGxlYXNlIHVzZSBj YXV0aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQgYXR0YWNobWVudHMgLyBDb3VycmllbCBleHRl cm5lOiBTb3lleiBwcnVkZW50IGF2ZWMgbGVzIGxpZW5zIGV0IGRvY3VtZW50cyBqb2ludHMgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkVjcml0IG1haWxp bmcgbGlzdA0KRWNyaXRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZWNyaXQNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRXh0ZXJuYWwgRW1haWw6IFBsZWFz ZSB1c2UgY2F1dGlvbiB3aGVuIG9wZW5pbmcgbGlua3MgYW5kIGF0dGFjaG1lbnRzIC8gQ291cnJp ZWwgZXh0ZXJuZTogU295ZXogcHJ1ZGVudCBhdmVjIGxlcyBsaWVucyBldCBkb2N1bWVudHMgam9p bnRzDQo= From nobody Thu Aug 26 10:05:42 2021 Return-Path: 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 8CD823A1464 for ; Thu, 26 Aug 2021 10:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, 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 ozh6FUqkP0Sf for ; Thu, 26 Aug 2021 10:05:35 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id DA8513A1463 for ; Thu, 26 Aug 2021 10:05:34 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 26 Aug 2021 10:05:34 -0700 From: "Randall Gellens" To: "Brian Rosen" Cc: "Caron, Guy" , ECRIT Date: Thu, 26 Aug 2021 10:05:33 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <6B187A69-3FBF-4B13-B3FA-62505221F55C@randy.pensive.org> In-Reply-To: <219EED44-D2BB-477A-9452-6BF688FB89AD@brianrosen.net> References: <1120BD41-A143-4AC1-B1A7-6CFF40658FF7@randy.pensive.org> <26184A64-2B40-4230-A09B-9A2D00D5F150@brianrosen.net> <14a2a0fad5f1499ca7939e820cc8a852@bell.ca> <34febd3e0984476380325a181f7b611a@bell.ca> <219EED44-D2BB-477A-9452-6BF688FB89AD@brianrosen.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 17:05:41 -0000 On 26 Aug 2021, at 6:31, Brian Rosen wrote: > I don=E2=80=99t see how this knowledge aids an attack. Yes, it knows w= hat = > is a road centerline and what is an address point (or equivalent), but = > I don=E2=80=99t see how an attacker could use that information. [rg] Yes, exactly. There's a lot of information an attacker can have, = but most of it doesn't help an attack. > Also, you get exactly the same information already: address number = > will be in =E2=80=9Cunchecked=E2=80=9D for a road centerline (assuming = it=E2=80=99s in a = > range, if it=E2=80=99s not, it=E2=80=99s in invalid). > This is because 4-100 includes 55 and there may or may not be an = > actual 55 address number. Now, that really is specific to North = > America: the NENA standard says that=E2=80=99s how you populate the = > unchecked list: 5222 isn=E2=80=99t specific. > > Brian > >> On Aug 26, 2021, at 9:09 AM, Caron, Guy wrote: >> >> Both solutions reveal the granularity of the underlying data in the = >> LoST server. >> >> Here is an example: >> >> 1. Client sends a URI for each discrete location (think civic = >> numbers) of a street. >> 2. Server is only provisioned with road centerline data for that = >> street and thus return one URI (or ID) back to the client for each = >> discrete location it has. >> 3. Client stores this unique URI (or ID) against all discrete = >> locations. >> 4. After all the Client's locations have gotten the URIs (or (IDs) = >> from the Server, the Client has a detailed view of the Server's = >> underlying data. >> >> Then, put this in the hands of an attacker. >> >> Thanks, >> >> >> Guy >> >> >> -----Message d'origine----- >> De : Randall Gellens >> Envoy=C3=A9 : 26 ao=C3=BBt 2021 00:40 >> =C3=80 : Caron, Guy >> Cc : Brian Rosen ; ECRIT >> Objet : [EXT]Re: [Ecrit] Problem in -planned-changes: unique records = >> in LoST server may not match unique records in LIS >> >> Hi Guy, >> >> I'm not following how "Both solutions would allow a malevolent client = >> to rebuild the server's internal data structure". In either = >> solution, the LoST server returns something to the LoST client that = >> the LoST client uses to mark one or more of its location records. = >> If/when the LoST server sends the client a = >> object, the object contains this same marker, which the client uses = >> to know which of its records should be revalidated. >> >> --Randall >> >> On 25 Aug 2021, at 19:33, Caron, Guy wrote: >> >>> I did not have much cycle time to think about this but I can share = >>> my >>> initial concerns with the proposed solutions. >>> >>> The concerns I have are security-related. A LoST server used in the >>> context of emergency calling (the scope of ECRIT) holds critical >>> information about how emergency calls are routed and their >>> destinations. Both solutions would allow a malevolent client to >>> rebuild the server's internal data structure and use that as an = >>> attack >>> of some form (impersonalisation, MITM, SWATting, etc.). >>> >>> I have re-read the Security section of RFC 5222 and perhaps these >>> concerns are already addressed but would like to hear the opinion of >>> others. >>> >>> Thanks, >>> >>> Guy >>> >>> >>> >>> -----Message d'origine----- >>> De : Ecrit De la part de Brian Rosen = >>> Envoy=C3=A9 : >>> 25 ao=C3=BBt 2021 17:58 =C3=80 : Randall Gellens = >>> Cc >>> : ECRIT Objet : [EXT]Re: [Ecrit] Problem in >>> -planned-changes: unique records in LoST server may not match unique >>> records in LIS >>> >>> Yeah, of the two options, I like the second. I would like to wait = >>> to >>> here from Guy, who didn=E2=80=99t like either. >>> >>> Either of the two I came up with can be added quickly to the doc. >>> >>> Brian >>> >>> >>>> On Aug 25, 2021, at 5:56 PM, Randall Gellens >>>> wrote: >>>> >>>> Either approach would work: the server returning the prior URI if = >>>> it >>>> replaces it, or the server always returning a "unique location ID" >>>> whenever it stores a URI. In the latter case, we'd want to add = >>>> this >>>> ID to the object. The latter seems a bit >>>> cleaner, as then the server always returns an ID, and a client = >>>> always >>>> stores this ID whenever it sends a URI, and uses the ID to >>>> re-validate locations when it gets a object. >>>> >>>> --Randall >>>> >>>> On 24 Aug 2021, at 13:08, Brian Rosen wrote: >>>> >>>>> I realized we have a problem with -planned-changes. The text = >>>>> notes: >>>>> Each client of the server may only store one URI against a = >>>>> location, >>>>> where =E2=80=9Clocation=E2=80=9D is defined by policy at the server= , since a = >>>>> given >>>>> unique location may have many combinations of location elements = >>>>> that >>>>> resolve to the same location. If the server receives a =E2=80=98ur= i=E2=80=99 = >>>>> for >>>>> the same location from the same client, the URI in the request >>>>> replaces the URI it previously retained. >>>>> >>>>> But this means that multiple records in the LIS may be one record = >>>>> in >>>>> the LoST server and when the LIS associates unique URIs with what = >>>>> it >>>>> thinks is multiple records, only one is retained and it doesn=E2=80= =99t = >>>>> know >>>>> that. >>>>> >>>>> The easiest fix is to return the replaced URI. The client would >>>>> then be able to spot that the records are linked and do the book >>>>> keeping to track what it should do. >>>>> Another way to fix this is to return a unique ID of the record in >>>>> the LoST server when you use the extension. The LIS can then keep >>>>> an internal record of all the related entries it has that are one >>>>> record to the server. >>>>> >>>>> Brian >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> ---------------------------------------------------------------------= - >>> -------- External Email: Please use caution when opening links and >>> attachments / Courriel externe: Soyez prudent avec les liens et >>> documents joints >> ----------------------------------------------------------------------= -------- >> External Email: Please use caution when opening links and attachments = >> / Courriel externe: Soyez prudent avec les liens et documents joints From nobody Thu Aug 26 10:08:16 2021 Return-Path: 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 0506F3A14AA for ; Thu, 26 Aug 2021 10:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, 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 WhPTK0OYrOHe for ; Thu, 26 Aug 2021 10:08:08 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id F1A783A14A5 for ; Thu, 26 Aug 2021 10:08:07 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Thu, 26 Aug 2021 10:08:07 -0700 From: "Randall Gellens" To: "Caron, Guy" Cc: "Brian Rosen" , ECRIT Date: Thu, 26 Aug 2021 10:08:06 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <565C8384-115A-4500-9986-4E746E1A09D6@randy.pensive.org> In-Reply-To: <7bd393f69edc400cad28ed4c98b78c66@bell.ca> References: <1120BD41-A143-4AC1-B1A7-6CFF40658FF7@randy.pensive.org> <26184A64-2B40-4230-A09B-9A2D00D5F150@brianrosen.net> <14a2a0fad5f1499ca7939e820cc8a852@bell.ca> <34febd3e0984476380325a181f7b611a@bell.ca> <219EED44-D2BB-477A-9452-6BF688FB89AD@brianrosen.net> <7bd393f69edc400cad28ed4c98b78c66@bell.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 17:08:15 -0000 On 26 Aug 2021, at 6:35, Caron, Guy wrote: > An attacker can mimic the LoST Server's behaviour very closely while > manipulating the data so that routing is affected. [rg] I'm not following. You mean an attacker pretending to be a LoST server? Using DNS cache poisoning or routing protocol attacks to redirect LoST queries to itself? I don't see how the extension helps that kind of an attack. > I don't know to what extent this is realistic. If folks do not see arm > then let's move on. [rg] I'm having trouble imagining how the extension helps an attacker. > > Thanks, > > Guy > > -----Message d'origine----- > De : Brian Rosen > Envoyé : 26 août 2021 09:32 > À : Caron, Guy > Cc : Randall Gellens ; ECRIT > > Objet : [EXT]Re: [Ecrit] Problem in -planned-changes: unique records > in LoST server may not match unique records in LIS > > I don’t see how this knowledge aids an attack. Yes, it knows what > is a road centerline and what is an address point (or equivalent), but > I don’t see how an attacker could use that information. > > Also, you get exactly the same information already: address number > will be in “unchecked†for a road centerline (assuming it’s in a > range, if it’s not, it’s in invalid). > This is because 4-100 includes 55 and there may or may not be an > actual 55 address number. Now, that really is specific to North > America: the NENA standard says that’s how you populate the > unchecked list: 5222 isn’t specific. > > Brian > >> On Aug 26, 2021, at 9:09 AM, Caron, Guy wrote: >> >> Both solutions reveal the granularity of the underlying data in the >> LoST server. >> >> Here is an example: >> >> 1. Client sends a URI for each discrete location (think civic >> numbers) of a street. >> 2. Server is only provisioned with road centerline data for that >> street and thus return one URI (or ID) back to the client for each >> discrete location it has. >> 3. Client stores this unique URI (or ID) against all discrete >> locations. >> 4. After all the Client's locations have gotten the URIs (or (IDs) >> from the Server, the Client has a detailed view of the Server's >> underlying data. >> >> Then, put this in the hands of an attacker. >> >> Thanks, >> >> >> Guy >> >> >> -----Message d'origine----- >> De : Randall Gellens Envoyé : 26 août >> 2021 >> 00:40 À : Caron, Guy Cc : Brian Rosen >> ; ECRIT Objet : [EXT]Re: [Ecrit] >> Problem in -planned-changes: unique records in LoST server may not >> match unique records in LIS >> >> Hi Guy, >> >> I'm not following how "Both solutions would allow a malevolent client >> to rebuild the server's internal data structure". In either >> solution, the LoST server returns something to the LoST client that >> the LoST client uses to mark one or more of its location records. >> If/when the LoST server sends the client a >> object, the object contains this same marker, which the client uses >> to know which of its records should be revalidated. >> >> --Randall >> >> On 25 Aug 2021, at 19:33, Caron, Guy wrote: >> >>> I did not have much cycle time to think about this but I can share >>> my >>> initial concerns with the proposed solutions. >>> >>> The concerns I have are security-related. A LoST server used in the >>> context of emergency calling (the scope of ECRIT) holds critical >>> information about how emergency calls are routed and their >>> destinations. Both solutions would allow a malevolent client to >>> rebuild the server's internal data structure and use that as an >>> attack of some form (impersonalisation, MITM, SWATting, etc.). >>> >>> I have re-read the Security section of RFC 5222 and perhaps these >>> concerns are already addressed but would like to hear the opinion of >>> others. >>> >>> Thanks, >>> >>> Guy >>> >>> >>> >>> -----Message d'origine----- >>> De : Ecrit De la part de Brian Rosen >>> Envoyé : >>> 25 août 2021 17:58 À : Randall Gellens >>> Cc >>> : ECRIT Objet : [EXT]Re: [Ecrit] Problem in >>> -planned-changes: unique records in LoST server may not match unique >>> records in LIS >>> >>> Yeah, of the two options, I like the second. I would like to wait >>> to >>> here from Guy, who didn’t like either. >>> >>> Either of the two I came up with can be added quickly to the doc. >>> >>> Brian >>> >>> >>>> On Aug 25, 2021, at 5:56 PM, Randall Gellens >>>> wrote: >>>> >>>> Either approach would work: the server returning the prior URI if >>>> it >>>> replaces it, or the server always returning a "unique location ID" >>>> whenever it stores a URI. In the latter case, we'd want to add >>>> this >>>> ID to the object. The latter seems a bit >>>> cleaner, as then the server always returns an ID, and a client >>>> always stores this ID whenever it sends a URI, and uses the ID to >>>> re-validate locations when it gets a object. >>>> >>>> --Randall >>>> >>>> On 24 Aug 2021, at 13:08, Brian Rosen wrote: >>>> >>>>> I realized we have a problem with -planned-changes. The text >>>>> notes: >>>>> Each client of the server may only store one URI against a >>>>> location, where “location†is defined by policy at the server, >>>>> since a given unique location may have many combinations of >>>>> location elements that resolve to the same location. If the >>>>> server >>>>> receives a ‘uri’ for the same location from the same client, >>>>> the >>>>> URI in the request replaces the URI it previously retained. >>>>> >>>>> But this means that multiple records in the LIS may be one record >>>>> in the LoST server and when the LIS associates unique URIs with >>>>> what it thinks is multiple records, only one is retained and it >>>>> doesn’t know that. >>>>> >>>>> The easiest fix is to return the replaced URI. The client would >>>>> then be able to spot that the records are linked and do the book >>>>> keeping to track what it should do. >>>>> Another way to fix this is to return a unique ID of the record in >>>>> the LoST server when you use the extension. The LIS can then keep >>>>> an internal record of all the related entries it has that are one >>>>> record to the server. >>>>> >>>>> Brian >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> --------------------------------------------------------------------- >>> - >>> -------- External Email: Please use caution when opening links and >>> attachments / Courriel externe: Soyez prudent avec les liens et >>> documents joints >> ---------------------------------------------------------------------- >> -------- External Email: Please use caution when opening links and >> attachments / Courriel externe: Soyez prudent avec les liens et >> documents joints > > ------------------------------------------------------------------------------ > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints From nobody Thu Aug 26 10:35:51 2021 Return-Path: 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 D09333A1739 for ; Thu, 26 Aug 2021 10:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=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=bell.ca 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 4qLnxNbUuzp3 for ; Thu, 26 Aug 2021 10:35:42 -0700 (PDT) Received: from ESA4-Dor.bell.ca (esa4-dor.bell.ca [204.101.223.61]) (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 402403A1737 for ; Thu, 26 Aug 2021 10:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1629999342; x=1661535342; h=from:to:cc:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=yhhGVTauZKG8Achi4zOEvhIFQ1otdWKKrtw7w2VZP9s=; b=FpfG/alVm7zn2uPvCXbkobjdsHfnsaeJnzePIYPp5JDa9fJraM4Yh5wr H3FQ66ZkI/aRWn/Nf15xr61ovqbfnduzOaT2O+lSXAoEtPzMCKh/eCZa1 t71/2qbok4nma9MooKMolIxxFhkskXjDiWLcFLtje+QZceufKuJvsmd+J KPPG7W3IeU8UGpT5wKK0lbOwOySoDnJkiSs06Afv564cIAlt0FohIdpbv 03ikVzwEi92kn8MFCn/9dToJGyt40qsPGWOGuiHrTEmn+qMz8kCIFL4ly +HwyG28qS7srpnuhtmb9lP799COJ3Okut2d7+j2GQ1O58U0PjWJ9JN6ad w==; IronPort-SDR: bGxldVLsXL3JrsPuF/70dvPjqQ7uZKLsWg2i9KnB962wLVqM8QDVmuBjxVaTAawvoYR0dwoRb4 o5rM/URNB60A== Received: from dc5cmz-d01.bellca.int.bell.ca (HELO DG1MBX03-WYN.bell.corp.bce.ca) ([198.235.121.232]) by esa04corp-dor.bell.corp.bce.ca with ESMTP; 26 Aug 2021 13:35:40 -0400 Received: from DG12MBX04-WYN.bell.corp.bce.ca (142.182.18.49) by DG1MBX03-WYN.bell.corp.bce.ca (142.182.18.13) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Thu, 26 Aug 2021 13:35:40 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX04-WYN.bell.corp.bce.ca (142.182.18.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Thu, 26 Aug 2021 13:35:39 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Thu, 26 Aug 2021 13:35:39 -0400 From: "Caron, Guy" To: Randall Gellens CC: Brian Rosen , ECRIT Thread-Topic: [EXT]Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS Thread-Index: AQHXmfwhRqgqGYN29EukUdmptVZv5auFB74AgAAC6zCAAG01AIAAQ6ZAgABQ84D//71fAIAAfx8A///A97A= Date: Thu, 26 Aug 2021 17:35:39 +0000 Message-ID: References: <1120BD41-A143-4AC1-B1A7-6CFF40658FF7@randy.pensive.org> <26184A64-2B40-4230-A09B-9A2D00D5F150@brianrosen.net> <14a2a0fad5f1499ca7939e820cc8a852@bell.ca> <34febd3e0984476380325a181f7b611a@bell.ca> <219EED44-D2BB-477A-9452-6BF688FB89AD@brianrosen.net> <7bd393f69edc400cad28ed4c98b78c66@bell.ca> <565C8384-115A-4500-9986-4E746E1A09D6@randy.pensive.org> In-Reply-To: <565C8384-115A-4500-9986-4E746E1A09D6@randy.pensive.org> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.68] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 17:35:50 -0000 QXMgSSBzYWlkLCBpZiBubyBvbmUgc2VlcyBoYXJtIHdpdGggdGhlIHByb3Bvc2VkIHNvbHV0aW9u cywgbGV0J3MgbW92ZSBvbi4NCg0KVGhhbmtzLA0KDQpHdXkNCg0KLS0tLS1NZXNzYWdlIGQnb3Jp Z2luZS0tLS0tDQpEZcKgOiBSYW5kYWxsIEdlbGxlbnMgPHJnK2lldGZAcmFuZHkucGVuc2l2ZS5v cmc+IA0KRW52b3nDqcKgOiAyNiBhb8O7dCAyMDIxIDEzOjA4DQrDgMKgOiBDYXJvbiwgR3V5IDxn LmNhcm9uQGJlbGwuY2E+DQpDY8KgOiBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ+OyBF Q1JJVCA8ZWNyaXRAaWV0Zi5vcmc+DQpPYmpldMKgOiBbRVhUXVJlOiBbRWNyaXRdIFByb2JsZW0g aW4gLXBsYW5uZWQtY2hhbmdlczogdW5pcXVlIHJlY29yZHMgaW4gTG9TVCBzZXJ2ZXIgbWF5IG5v dCBtYXRjaCB1bmlxdWUgcmVjb3JkcyBpbiBMSVMNCg0KT24gMjYgQXVnIDIwMjEsIGF0IDY6MzUs IENhcm9uLCBHdXkgd3JvdGU6DQoNCj4gQW4gYXR0YWNrZXIgY2FuIG1pbWljIHRoZSBMb1NUIFNl cnZlcidzIGJlaGF2aW91ciB2ZXJ5IGNsb3NlbHkgd2hpbGUgDQo+IG1hbmlwdWxhdGluZyB0aGUg ZGF0YSBzbyB0aGF0IHJvdXRpbmcgaXMgYWZmZWN0ZWQuDQoNCltyZ10gSSdtIG5vdCBmb2xsb3dp bmcuICBZb3UgbWVhbiBhbiBhdHRhY2tlciBwcmV0ZW5kaW5nIHRvIGJlIGEgTG9TVCBzZXJ2ZXI/ ICBVc2luZyBETlMgY2FjaGUgcG9pc29uaW5nIG9yIHJvdXRpbmcgcHJvdG9jb2wgYXR0YWNrcyB0 byByZWRpcmVjdCBMb1NUIHF1ZXJpZXMgdG8gaXRzZWxmPyAgSSBkb24ndCBzZWUgaG93IHRoZSBl eHRlbnNpb24gaGVscHMgdGhhdCBraW5kIG9mIGFuIGF0dGFjay4NCg0KDQo+IEkgZG9uJ3Qga25v dyB0byB3aGF0IGV4dGVudCB0aGlzIGlzIHJlYWxpc3RpYy4gSWYgZm9sa3MgZG8gbm90IHNlZSBh cm0gDQo+IHRoZW4gbGV0J3MgbW92ZSBvbi4NCg0KW3JnXSBJJ20gaGF2aW5nIHRyb3VibGUgaW1h Z2luaW5nIGhvdyB0aGUgZXh0ZW5zaW9uIGhlbHBzIGFuIGF0dGFja2VyLg0KDQo+DQo+IFRoYW5r cywNCj4NCj4gR3V5DQo+DQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBC cmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ+DQo+IEVudm95w6nCoDogMjYgYW/Du3QgMjAy MSAwOTozMg0KPiDDgMKgOiBDYXJvbiwgR3V5IDxnLmNhcm9uQGJlbGwuY2E+DQo+IENjwqA6IFJh bmRhbGwgR2VsbGVucyA8cmcraWV0ZkByYW5keS5wZW5zaXZlLm9yZz47IEVDUklUIA0KPiA8ZWNy aXRAaWV0Zi5vcmc+IE9iamV0wqA6IFtFWFRdUmU6IFtFY3JpdF0gUHJvYmxlbSBpbiAtcGxhbm5l ZC1jaGFuZ2VzOiANCj4gdW5pcXVlIHJlY29yZHMgaW4gTG9TVCBzZXJ2ZXIgbWF5IG5vdCBtYXRj aCB1bmlxdWUgcmVjb3JkcyBpbiBMSVMNCj4NCj4gSSBkb27igJl0IHNlZSBob3cgdGhpcyBrbm93 bGVkZ2UgYWlkcyBhbiBhdHRhY2suICBZZXMsIGl0IGtub3dzIHdoYXQgaXMgDQo+IGEgcm9hZCBj ZW50ZXJsaW5lIGFuZCB3aGF0IGlzIGFuIGFkZHJlc3MgcG9pbnQgKG9yIGVxdWl2YWxlbnQpLCBi dXQgSSANCj4gZG9u4oCZdCBzZWUgaG93IGFuIGF0dGFja2VyIGNvdWxkIHVzZSB0aGF0IGluZm9y bWF0aW9uLg0KPg0KPiBBbHNvLCB5b3UgZ2V0IGV4YWN0bHkgdGhlIHNhbWUgaW5mb3JtYXRpb24g YWxyZWFkeTogYWRkcmVzcyBudW1iZXIgDQo+IHdpbGwgYmUgaW4g4oCcdW5jaGVja2Vk4oCdIGZv ciBhIHJvYWQgY2VudGVybGluZSAoYXNzdW1pbmcgaXTigJlzIGluIGEgDQo+IHJhbmdlLCBpZiBp dOKAmXMgbm90LCBpdOKAmXMgaW4gaW52YWxpZCkuDQo+IFRoaXMgaXMgYmVjYXVzZSA0LTEwMCBp bmNsdWRlcyA1NSBhbmQgdGhlcmUgbWF5IG9yIG1heSBub3QgYmUgYW4gDQo+IGFjdHVhbCA1NSBh ZGRyZXNzIG51bWJlci4gIE5vdywgdGhhdCByZWFsbHkgaXMgc3BlY2lmaWMgdG8gTm9ydGgNCj4g QW1lcmljYTogdGhlIE5FTkEgc3RhbmRhcmQgc2F5cyB0aGF04oCZcyBob3cgeW91IHBvcHVsYXRl IHRoZSB1bmNoZWNrZWQgDQo+IGxpc3Q6IDUyMjIgaXNu4oCZdCBzcGVjaWZpYy4NCj4NCj4gQnJp YW4NCj4NCj4+IE9uIEF1ZyAyNiwgMjAyMSwgYXQgOTowOSBBTSwgQ2Fyb24sIEd1eSA8Zy5jYXJv bkBiZWxsLmNhPiB3cm90ZToNCj4+DQo+PiBCb3RoIHNvbHV0aW9ucyByZXZlYWwgdGhlIGdyYW51 bGFyaXR5IG9mIHRoZSB1bmRlcmx5aW5nIGRhdGEgaW4gdGhlIA0KPj4gTG9TVCBzZXJ2ZXIuDQo+ Pg0KPj4gSGVyZSBpcyBhbiBleGFtcGxlOg0KPj4NCj4+IDEuIENsaWVudCBzZW5kcyBhIFVSSSBm b3IgZWFjaCBkaXNjcmV0ZSBsb2NhdGlvbiAodGhpbmsgY2l2aWMNCj4+IG51bWJlcnMpIG9mIGEg c3RyZWV0Lg0KPj4gMi4gU2VydmVyIGlzIG9ubHkgcHJvdmlzaW9uZWQgd2l0aCByb2FkIGNlbnRl cmxpbmUgZGF0YSBmb3IgdGhhdCANCj4+IHN0cmVldCBhbmQgdGh1cyByZXR1cm4gb25lIFVSSSAo b3IgSUQpIGJhY2sgdG8gdGhlIGNsaWVudCBmb3IgZWFjaCANCj4+IGRpc2NyZXRlIGxvY2F0aW9u IGl0IGhhcy4NCj4+IDMuIENsaWVudCBzdG9yZXMgdGhpcyB1bmlxdWUgVVJJIChvciBJRCkgYWdh aW5zdCBhbGwgZGlzY3JldGUgDQo+PiBsb2NhdGlvbnMuDQo+PiA0LiBBZnRlciBhbGwgdGhlIENs aWVudCdzIGxvY2F0aW9ucyBoYXZlIGdvdHRlbiB0aGUgVVJJcyAob3IgKElEcykgDQo+PiBmcm9t IHRoZSBTZXJ2ZXIsIHRoZSBDbGllbnQgaGFzIGEgZGV0YWlsZWQgdmlldyBvZiB0aGUgU2VydmVy J3MgDQo+PiB1bmRlcmx5aW5nIGRhdGEuDQo+Pg0KPj4gVGhlbiwgcHV0IHRoaXMgaW4gdGhlIGhh bmRzIG9mIGFuIGF0dGFja2VyLg0KPj4NCj4+IFRoYW5rcywNCj4+DQo+Pg0KPj4gR3V5DQo+Pg0K Pj4NCj4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4gRGUgOiBSYW5kYWxsIEdlbGxl bnMgPHJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmc+IEVudm95w6kgOiAyNiBhb8O7dA0KPj4gMjAy MQ0KPj4gMDA6NDAgw4AgOiBDYXJvbiwgR3V5IDxnLmNhcm9uQGJlbGwuY2E+IENjIDogQnJpYW4g Um9zZW4gDQo+PiA8YnJAYnJpYW5yb3Nlbi5uZXQ+OyBFQ1JJVCA8ZWNyaXRAaWV0Zi5vcmc+IE9i amV0IDogW0VYVF1SZTogW0Vjcml0XSANCj4+IFByb2JsZW0gaW4gLXBsYW5uZWQtY2hhbmdlczog dW5pcXVlIHJlY29yZHMgaW4gTG9TVCBzZXJ2ZXIgbWF5IG5vdCANCj4+IG1hdGNoIHVuaXF1ZSBy ZWNvcmRzIGluIExJUw0KPj4NCj4+IEhpIEd1eSwNCj4+DQo+PiBJJ20gbm90IGZvbGxvd2luZyBo b3cgIkJvdGggc29sdXRpb25zIHdvdWxkIGFsbG93IGEgbWFsZXZvbGVudCBjbGllbnQgDQo+PiB0 byByZWJ1aWxkIHRoZSBzZXJ2ZXIncyBpbnRlcm5hbCBkYXRhIHN0cnVjdHVyZSIuICBJbiBlaXRo ZXIgDQo+PiBzb2x1dGlvbiwgdGhlIExvU1Qgc2VydmVyIHJldHVybnMgc29tZXRoaW5nIHRvIHRo ZSBMb1NUIGNsaWVudCB0aGF0IA0KPj4gdGhlIExvU1QgY2xpZW50IHVzZXMgdG8gbWFyayBvbmUg b3IgbW9yZSBvZiBpdHMgbG9jYXRpb24gcmVjb3Jkcy4NCj4+IElmL3doZW4gdGhlIExvU1Qgc2Vy dmVyIHNlbmRzIHRoZSBjbGllbnQgYSA8bG9jYXRpb25JbnZhbGlkYXRlZD4gDQo+PiBvYmplY3Qs IHRoZSBvYmplY3QgY29udGFpbnMgdGhpcyBzYW1lIG1hcmtlciwgd2hpY2ggdGhlIGNsaWVudCB1 c2VzIA0KPj4gdG8ga25vdyB3aGljaCBvZiBpdHMgcmVjb3JkcyBzaG91bGQgYmUgcmV2YWxpZGF0 ZWQuDQo+Pg0KPj4gLS1SYW5kYWxsDQo+Pg0KPj4gT24gMjUgQXVnIDIwMjEsIGF0IDE5OjMzLCBD YXJvbiwgR3V5IHdyb3RlOg0KPj4NCj4+PiBJIGRpZCBub3QgaGF2ZSBtdWNoIGN5Y2xlIHRpbWUg dG8gdGhpbmsgYWJvdXQgdGhpcyBidXQgSSBjYW4gc2hhcmUgDQo+Pj4gbXkgaW5pdGlhbCBjb25j ZXJucyB3aXRoIHRoZSBwcm9wb3NlZCBzb2x1dGlvbnMuDQo+Pj4NCj4+PiBUaGUgY29uY2VybnMg SSBoYXZlIGFyZSBzZWN1cml0eS1yZWxhdGVkLiAgQSBMb1NUIHNlcnZlciB1c2VkIGluIHRoZSAN Cj4+PiBjb250ZXh0IG9mIGVtZXJnZW5jeSBjYWxsaW5nICh0aGUgc2NvcGUgb2YgRUNSSVQpIGhv bGRzIGNyaXRpY2FsIA0KPj4+IGluZm9ybWF0aW9uIGFib3V0IGhvdyBlbWVyZ2VuY3kgY2FsbHMg YXJlIHJvdXRlZCBhbmQgdGhlaXIgDQo+Pj4gZGVzdGluYXRpb25zLiBCb3RoIHNvbHV0aW9ucyB3 b3VsZCBhbGxvdyBhIG1hbGV2b2xlbnQgY2xpZW50IHRvIA0KPj4+IHJlYnVpbGQgdGhlIHNlcnZl cidzIGludGVybmFsIGRhdGEgc3RydWN0dXJlIGFuZCB1c2UgdGhhdCBhcyBhbiANCj4+PiBhdHRh Y2sgb2Ygc29tZSBmb3JtIChpbXBlcnNvbmFsaXNhdGlvbiwgTUlUTSwgU1dBVHRpbmcsIGV0Yy4p Lg0KPj4+DQo+Pj4gSSBoYXZlIHJlLXJlYWQgdGhlIFNlY3VyaXR5IHNlY3Rpb24gb2YgUkZDIDUy MjIgYW5kIHBlcmhhcHMgdGhlc2UgDQo+Pj4gY29uY2VybnMgYXJlIGFscmVhZHkgYWRkcmVzc2Vk IGJ1dCB3b3VsZCBsaWtlIHRvIGhlYXIgdGhlIG9waW5pb24gb2YgDQo+Pj4gb3RoZXJzLg0KPj4+ DQo+Pj4gVGhhbmtzLA0KPj4+DQo+Pj4gR3V5DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gLS0tLS1NZXNz YWdlIGQnb3JpZ2luZS0tLS0tDQo+Pj4gRGUgOiBFY3JpdCA8ZWNyaXQtYm91bmNlc0BpZXRmLm9y Zz4gRGUgbGEgcGFydCBkZSBCcmlhbiBSb3NlbiBFbnZvecOpIA0KPj4+IDoNCj4+PiAyNSBhb8O7 dCAyMDIxIDE3OjU4IMOAIDogUmFuZGFsbCBHZWxsZW5zIDxyZytpZXRmQHJhbmR5LnBlbnNpdmUu b3JnPiANCj4+PiBDYw0KPj4+IDogRUNSSVQgPGVjcml0QGlldGYub3JnPiBPYmpldCA6IFtFWFRd UmU6IFtFY3JpdF0gUHJvYmxlbSBpbg0KPj4+IC1wbGFubmVkLWNoYW5nZXM6IHVuaXF1ZSByZWNv cmRzIGluIExvU1Qgc2VydmVyIG1heSBub3QgbWF0Y2ggdW5pcXVlIA0KPj4+IHJlY29yZHMgaW4g TElTDQo+Pj4NCj4+PiBZZWFoLCBvZiB0aGUgdHdvIG9wdGlvbnMsIEkgbGlrZSB0aGUgc2Vjb25k LiAgSSB3b3VsZCBsaWtlIHRvIHdhaXQgDQo+Pj4gdG8gaGVyZSBmcm9tIEd1eSwgd2hvIGRpZG7i gJl0IGxpa2UgZWl0aGVyLg0KPj4+DQo+Pj4gRWl0aGVyIG9mIHRoZSB0d28gSSBjYW1lIHVwIHdp dGggY2FuIGJlIGFkZGVkIHF1aWNrbHkgdG8gdGhlIGRvYy4NCj4+Pg0KPj4+IEJyaWFuDQo+Pj4N Cj4+Pg0KPj4+PiBPbiBBdWcgMjUsIDIwMjEsIGF0IDU6NTYgUE0sIFJhbmRhbGwgR2VsbGVucyAN Cj4+Pj4gPHJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmc+IHdyb3RlOg0KPj4+Pg0KPj4+PiBFaXRo ZXIgYXBwcm9hY2ggd291bGQgd29yazogdGhlIHNlcnZlciByZXR1cm5pbmcgdGhlIHByaW9yIFVS SSBpZiANCj4+Pj4gaXQgcmVwbGFjZXMgaXQsIG9yIHRoZSBzZXJ2ZXIgYWx3YXlzIHJldHVybmlu ZyBhICJ1bmlxdWUgbG9jYXRpb24gDQo+Pj4+IElEIg0KPj4+PiB3aGVuZXZlciBpdCBzdG9yZXMg YSBVUkkuICBJbiB0aGUgbGF0dGVyIGNhc2UsIHdlJ2Qgd2FudCB0byBhZGQgDQo+Pj4+IHRoaXMg SUQgdG8gdGhlIDxsb2NhdGlvbkludmFsaWRhdGVkPiBvYmplY3QuICBUaGUgbGF0dGVyIHNlZW1z IGEgDQo+Pj4+IGJpdCBjbGVhbmVyLCBhcyB0aGVuIHRoZSBzZXJ2ZXIgYWx3YXlzIHJldHVybnMg YW4gSUQsIGFuZCBhIGNsaWVudCANCj4+Pj4gYWx3YXlzIHN0b3JlcyB0aGlzIElEIHdoZW5ldmVy IGl0IHNlbmRzIGEgVVJJLCBhbmQgdXNlcyB0aGUgSUQgdG8gDQo+Pj4+IHJlLXZhbGlkYXRlIGxv Y2F0aW9ucyB3aGVuIGl0IGdldHMgYSA8bG9jYXRpb25JbnZhbGlkYXRlZD4gb2JqZWN0Lg0KPj4+ Pg0KPj4+PiAtLVJhbmRhbGwNCj4+Pj4NCj4+Pj4gT24gMjQgQXVnIDIwMjEsIGF0IDEzOjA4LCBC cmlhbiBSb3NlbiB3cm90ZToNCj4+Pj4NCj4+Pj4+IEkgcmVhbGl6ZWQgd2UgaGF2ZSBhIHByb2Js ZW0gd2l0aCAtcGxhbm5lZC1jaGFuZ2VzLiAgVGhlIHRleHQNCj4+Pj4+IG5vdGVzOg0KPj4+Pj4g RWFjaCBjbGllbnQgb2YgdGhlIHNlcnZlciBtYXkgb25seSBzdG9yZSBvbmUgVVJJIGFnYWluc3Qg YSANCj4+Pj4+IGxvY2F0aW9uLCB3aGVyZSDigJxsb2NhdGlvbuKAnSBpcyBkZWZpbmVkIGJ5IHBv bGljeSBhdCB0aGUgc2VydmVyLCANCj4+Pj4+IHNpbmNlIGEgZ2l2ZW4gdW5pcXVlIGxvY2F0aW9u IG1heSBoYXZlIG1hbnkgY29tYmluYXRpb25zIG9mIA0KPj4+Pj4gbG9jYXRpb24gZWxlbWVudHMg dGhhdCByZXNvbHZlIHRvIHRoZSBzYW1lIGxvY2F0aW9uLiAgSWYgdGhlIA0KPj4+Pj4gc2VydmVy IHJlY2VpdmVzIGEg4oCYdXJp4oCZIGZvciB0aGUgc2FtZSBsb2NhdGlvbiBmcm9tIHRoZSBzYW1l IA0KPj4+Pj4gY2xpZW50LCB0aGUgVVJJIGluIHRoZSByZXF1ZXN0IHJlcGxhY2VzIHRoZSBVUkkg aXQgcHJldmlvdXNseSANCj4+Pj4+IHJldGFpbmVkLg0KPj4+Pj4NCj4+Pj4+IEJ1dCB0aGlzIG1l YW5zIHRoYXQgbXVsdGlwbGUgcmVjb3JkcyBpbiB0aGUgTElTIG1heSBiZSBvbmUgcmVjb3JkIA0K Pj4+Pj4gaW4gdGhlIExvU1Qgc2VydmVyIGFuZCB3aGVuIHRoZSBMSVMgYXNzb2NpYXRlcyB1bmlx dWUgVVJJcyB3aXRoIA0KPj4+Pj4gd2hhdCBpdCB0aGlua3MgaXMgbXVsdGlwbGUgcmVjb3Jkcywg b25seSBvbmUgaXMgcmV0YWluZWQgYW5kIGl0IA0KPj4+Pj4gZG9lc27igJl0IGtub3cgdGhhdC4N Cj4+Pj4+DQo+Pj4+PiBUaGUgZWFzaWVzdCBmaXggaXMgdG8gcmV0dXJuIHRoZSByZXBsYWNlZCBV UkkuICBUaGUgY2xpZW50IHdvdWxkIA0KPj4+Pj4gdGhlbiBiZSBhYmxlIHRvIHNwb3QgdGhhdCB0 aGUgcmVjb3JkcyBhcmUgbGlua2VkIGFuZCBkbyB0aGUgYm9vayANCj4+Pj4+IGtlZXBpbmcgdG8g dHJhY2sgd2hhdCBpdCBzaG91bGQgZG8uDQo+Pj4+PiBBbm90aGVyIHdheSB0byBmaXggdGhpcyBp cyB0byByZXR1cm4gYSB1bmlxdWUgSUQgb2YgdGhlIHJlY29yZCBpbiANCj4+Pj4+IHRoZSBMb1NU IHNlcnZlciB3aGVuIHlvdSB1c2UgdGhlIGV4dGVuc2lvbi4gIFRoZSBMSVMgY2FuIHRoZW4ga2Vl cCANCj4+Pj4+IGFuIGludGVybmFsIHJlY29yZCBvZiBhbGwgdGhlIHJlbGF0ZWQgZW50cmllcyBp dCBoYXMgdGhhdCBhcmUgb25lIA0KPj4+Pj4gcmVjb3JkIHRvIHRoZSBzZXJ2ZXIuDQo+Pj4+Pg0K Pj4+Pj4gQnJpYW4NCj4+Pj4+DQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+Pj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+Pj4+PiBFY3JpdEBp ZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3Jp dA0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+PiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4+PiBFY3JpdEBpZXRmLm9yZw0KPj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4+PiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Pj4+IC0NCj4+PiAtDQo+Pj4gLS0tLS0tLS0gRXh0ZXJuYWwgRW1haWw6IFBsZWFzZSB1c2UgY2F1 dGlvbiB3aGVuIG9wZW5pbmcgbGlua3MgYW5kIA0KPj4+IGF0dGFjaG1lbnRzIC8gQ291cnJpZWwg ZXh0ZXJuZTogU295ZXogcHJ1ZGVudCBhdmVjIGxlcyBsaWVucyBldCANCj4+PiBkb2N1bWVudHMg am9pbnRzDQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IC0NCj4+IC0tLS0tLS0tIEV4dGVybmFsIEVtYWls OiBQbGVhc2UgdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxpbmtzIGFuZCANCj4+IGF0dGFjaG1l bnRzIC8gQ291cnJpZWwgZXh0ZXJuZTogU295ZXogcHJ1ZGVudCBhdmVjIGxlcyBsaWVucyBldCAN Cj4+IGRvY3VtZW50cyBqb2ludHMNCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0tLS0tLSBFeHRl cm5hbCBFbWFpbDogUGxlYXNlIHVzZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQgDQo+ IGF0dGFjaG1lbnRzIC8gQ291cnJpZWwgZXh0ZXJuZTogU295ZXogcHJ1ZGVudCBhdmVjIGxlcyBs aWVucyBldCANCj4gZG9jdW1lbnRzIGpvaW50cw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpFeHRl cm5hbCBFbWFpbDogUGxlYXNlIHVzZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQgYXR0 YWNobWVudHMgLyBDb3VycmllbCBleHRlcm5lOiBTb3lleiBwcnVkZW50IGF2ZWMgbGVzIGxpZW5z IGV0IGRvY3VtZW50cyBqb2ludHMNCg== From nobody Fri Aug 27 09:58:36 2021 Return-Path: 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 76D233A186F for ; Fri, 27 Aug 2021 09:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-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=bell.ca 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 YVDHfRxAsTFY for ; Fri, 27 Aug 2021 09:58:28 -0700 (PDT) Received: from ESA1-Dor.bell.ca (esa1-dor.bell.ca [204.101.223.58]) (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 657A53A186E for ; Fri, 27 Aug 2021 09:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1630083508; x=1661619508; h=from:to:cc:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=S08PfeT/ELVI3nWEgVrhS2xNsPyejMvU6+wz9Qok+IQ=; b=UurUU7KsYYd+9tFVVOICLf63cZax9AKAxEUwHLymutZsADQfetZMfI/b +m/VLzT/WHPajKgiSX6A3UN+BPg0ut914ykkgy4Gqn9+Vjfs08zxW5uyv iCG68o5A1/CeXGE06hom7WMdv8+kAmXQgOx8oPI3vCBkhhFymerEjJI15 VhXcQwoS/asxqZukqX9VRNEH5UbVgcw1XdttQYW1221YVtWswSwbziU5N 74efPbpxWQRIpt/1kTii8Q8n9N9wsRB0/B2pcg3PUbqyCi4eMm5oeRBGy 5sgeIZL7Lz3Q8MxHYXc5zutH6pnyNH3TmQiq4KKX4IcJHp58lx6Aa8fTs g==; IronPort-SDR: jhR8hXxaBAYT8JKWt//21kthr4u3bhDJxRiIXdjisE+BX2U0ttVGj2EJTA/lF7tRReSQoCDgBB lmGOo1fpPRUQ== Received: from dc5cmy-d00.bellca.int.bell.ca (HELO DG3MBX03-WYN.bell.corp.bce.ca) ([198.235.121.229]) by esa01corp-dor.bell.corp.bce.ca with ESMTP; 27 Aug 2021 12:58:26 -0400 Received: from DG12MBX03-WYN.bell.corp.bce.ca (142.182.18.48) by DG3MBX03-WYN.bell.corp.bce.ca (142.182.18.25) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Fri, 27 Aug 2021 12:58:26 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX03-WYN.bell.corp.bce.ca (142.182.18.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Fri, 27 Aug 2021 12:58:26 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Fri, 27 Aug 2021 12:58:26 -0400 From: "Caron, Guy" To: Brian Rosen CC: Randall Gellens , ECRIT Thread-Topic: [EXT]Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS Thread-Index: AQHXmfwhRqgqGYN29EukUdmptVZv5auFB74AgAAC6zCAAG01AIAAQ6ZAgABQ84CAAYiU8A== Date: Fri, 27 Aug 2021 16:58:26 +0000 Message-ID: <741db5d6ee69431fa8d81c54095fe317@bell.ca> References: <1120BD41-A143-4AC1-B1A7-6CFF40658FF7@randy.pensive.org> <26184A64-2B40-4230-A09B-9A2D00D5F150@brianrosen.net> <14a2a0fad5f1499ca7939e820cc8a852@bell.ca> <34febd3e0984476380325a181f7b611a@bell.ca> <219EED44-D2BB-477A-9452-6BF688FB89AD@brianrosen.net> In-Reply-To: <219EED44-D2BB-477A-9452-6BF688FB89AD@brianrosen.net> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.65] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2021 16:58:35 -0000 WW91IG1ha2UgYSBnb29kIHBvaW50IGFib3V0IGdldHRpbmcgZXhhY3RseSB0aGUgc2FtZSBpbmZv cm1hdGlvbiBhbHJlYWR5OiBhZGRyZXNzIG51bWJlciB3aWxsIGJlIGluIOKAnHVuY2hlY2tlZOKA nSBmb3IgYSByb2FkIGNlbnRlcmxpbmUgKGFzc3VtaW5nIGl04oCZcyBpbiBhIHJhbmdlLCBpZiBp dOKAmXMgbm90LCBpdOKAmXMgaW4gaW52YWxpZCkuDQoNCkkgdGhlcmVmb3JlIHJlc2NpbmQgbXkg Y29uY2VybiBhYm91dCB0aGUgcHJvcG9zZWQgc29sdXRpb25zLg0KDQpUaGFua3MsDQoNCkd1eQ0K DQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IEJyaWFuIFJvc2VuIDxickBicmlh bnJvc2VuLm5ldD4gDQpFbnZvecOpwqA6IDI2IGFvw7t0IDIwMjEgMDk6MzINCsOAwqA6IENhcm9u LCBHdXkgPGcuY2Fyb25AYmVsbC5jYT4NCkNjwqA6IFJhbmRhbGwgR2VsbGVucyA8cmcraWV0ZkBy YW5keS5wZW5zaXZlLm9yZz47IEVDUklUIDxlY3JpdEBpZXRmLm9yZz4NCk9iamV0wqA6IFtFWFRd UmU6IFtFY3JpdF0gUHJvYmxlbSBpbiAtcGxhbm5lZC1jaGFuZ2VzOiB1bmlxdWUgcmVjb3JkcyBp biBMb1NUIHNlcnZlciBtYXkgbm90IG1hdGNoIHVuaXF1ZSByZWNvcmRzIGluIExJUw0KDQpJIGRv buKAmXQgc2VlIGhvdyB0aGlzIGtub3dsZWRnZSBhaWRzIGFuIGF0dGFjay4gIFllcywgaXQga25v d3Mgd2hhdCBpcyBhIHJvYWQgY2VudGVybGluZSBhbmQgd2hhdCBpcyBhbiBhZGRyZXNzIHBvaW50 IChvciBlcXVpdmFsZW50KSwgYnV0IEkgZG9u4oCZdCBzZWUgaG93IGFuIGF0dGFja2VyIGNvdWxk IHVzZSB0aGF0IGluZm9ybWF0aW9uLiAgDQoNCkFsc28sIHlvdSBnZXQgZXhhY3RseSB0aGUgc2Ft ZSBpbmZvcm1hdGlvbiBhbHJlYWR5OiBhZGRyZXNzIG51bWJlciB3aWxsIGJlIGluIOKAnHVuY2hl Y2tlZOKAnSBmb3IgYSByb2FkIGNlbnRlcmxpbmUgKGFzc3VtaW5nIGl04oCZcyBpbiBhIHJhbmdl LCBpZiBpdOKAmXMgbm90LCBpdOKAmXMgaW4gaW52YWxpZCkuDQpUaGlzIGlzIGJlY2F1c2UgNC0x MDAgaW5jbHVkZXMgNTUgYW5kIHRoZXJlIG1heSBvciBtYXkgbm90IGJlIGFuIGFjdHVhbCA1NSBh ZGRyZXNzIG51bWJlci4gIE5vdywgdGhhdCByZWFsbHkgaXMgc3BlY2lmaWMgdG8gTm9ydGggQW1l cmljYTogdGhlIE5FTkEgc3RhbmRhcmQgc2F5cyB0aGF04oCZcyBob3cgeW91IHBvcHVsYXRlIHRo ZSB1bmNoZWNrZWQgbGlzdDogNTIyMiBpc27igJl0IHNwZWNpZmljLg0KDQpCcmlhbg0KDQo+IE9u IEF1ZyAyNiwgMjAyMSwgYXQgOTowOSBBTSwgQ2Fyb24sIEd1eSA8Zy5jYXJvbkBiZWxsLmNhPiB3 cm90ZToNCj4gDQo+IEJvdGggc29sdXRpb25zIHJldmVhbCB0aGUgZ3JhbnVsYXJpdHkgb2YgdGhl IHVuZGVybHlpbmcgZGF0YSBpbiB0aGUgTG9TVCBzZXJ2ZXIuDQo+IA0KPiBIZXJlIGlzIGFuIGV4 YW1wbGU6DQo+IA0KPiAxLiBDbGllbnQgc2VuZHMgYSBVUkkgZm9yIGVhY2ggZGlzY3JldGUgbG9j YXRpb24gKHRoaW5rIGNpdmljIG51bWJlcnMpIG9mIGEgc3RyZWV0Lg0KPiAyLiBTZXJ2ZXIgaXMg b25seSBwcm92aXNpb25lZCB3aXRoIHJvYWQgY2VudGVybGluZSBkYXRhIGZvciB0aGF0IHN0cmVl dCBhbmQgdGh1cyByZXR1cm4gb25lIFVSSSAob3IgSUQpIGJhY2sgdG8gdGhlIGNsaWVudCBmb3Ig ZWFjaCBkaXNjcmV0ZSBsb2NhdGlvbiBpdCBoYXMuDQo+IDMuIENsaWVudCBzdG9yZXMgdGhpcyB1 bmlxdWUgVVJJIChvciBJRCkgYWdhaW5zdCBhbGwgZGlzY3JldGUgbG9jYXRpb25zLg0KPiA0LiBB ZnRlciBhbGwgdGhlIENsaWVudCdzIGxvY2F0aW9ucyBoYXZlIGdvdHRlbiB0aGUgVVJJcyAob3Ig KElEcykgZnJvbSB0aGUgU2VydmVyLCB0aGUgQ2xpZW50IGhhcyBhIGRldGFpbGVkIHZpZXcgb2Yg dGhlIFNlcnZlcidzIHVuZGVybHlpbmcgZGF0YS4NCj4gDQo+IFRoZW4sIHB1dCB0aGlzIGluIHRo ZSBoYW5kcyBvZiBhbiBhdHRhY2tlci4NCj4gDQo+IFRoYW5rcywNCj4gDQo+IA0KPiBHdXkNCj4g DQo+IA0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGUgOiBSYW5kYWxsIEdlbGxl bnMgPHJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmc+IEVudm95w6kgOiAyNiBhb8O7dCAyMDIxIA0K PiAwMDo0MCDDgCA6IENhcm9uLCBHdXkgPGcuY2Fyb25AYmVsbC5jYT4gQ2MgOiBCcmlhbiBSb3Nl biANCj4gPGJyQGJyaWFucm9zZW4ubmV0PjsgRUNSSVQgPGVjcml0QGlldGYub3JnPiBPYmpldCA6 IFtFWFRdUmU6IFtFY3JpdF0gDQo+IFByb2JsZW0gaW4gLXBsYW5uZWQtY2hhbmdlczogdW5pcXVl IHJlY29yZHMgaW4gTG9TVCBzZXJ2ZXIgbWF5IG5vdCANCj4gbWF0Y2ggdW5pcXVlIHJlY29yZHMg aW4gTElTDQo+IA0KPiBIaSBHdXksDQo+IA0KPiBJJ20gbm90IGZvbGxvd2luZyBob3cgIkJvdGgg c29sdXRpb25zIHdvdWxkIGFsbG93IGEgbWFsZXZvbGVudCBjbGllbnQgdG8gcmVidWlsZCB0aGUg c2VydmVyJ3MgaW50ZXJuYWwgZGF0YSBzdHJ1Y3R1cmUiLiAgSW4gZWl0aGVyIHNvbHV0aW9uLCB0 aGUgTG9TVCBzZXJ2ZXIgcmV0dXJucyBzb21ldGhpbmcgdG8gdGhlIExvU1QgY2xpZW50IHRoYXQg dGhlIExvU1QgY2xpZW50IHVzZXMgdG8gbWFyayBvbmUgb3IgbW9yZSBvZiBpdHMgbG9jYXRpb24g cmVjb3Jkcy4gSWYvd2hlbiB0aGUgTG9TVCBzZXJ2ZXIgc2VuZHMgdGhlIGNsaWVudCBhIDxsb2Nh dGlvbkludmFsaWRhdGVkPiBvYmplY3QsIHRoZSBvYmplY3QgY29udGFpbnMgdGhpcyBzYW1lIG1h cmtlciwgd2hpY2ggdGhlIGNsaWVudCB1c2VzIHRvIGtub3cgd2hpY2ggb2YgaXRzIHJlY29yZHMg c2hvdWxkIGJlIHJldmFsaWRhdGVkLg0KPiANCj4gLS1SYW5kYWxsDQo+IA0KPiBPbiAyNSBBdWcg MjAyMSwgYXQgMTk6MzMsIENhcm9uLCBHdXkgd3JvdGU6DQo+IA0KPj4gSSBkaWQgbm90IGhhdmUg bXVjaCBjeWNsZSB0aW1lIHRvIHRoaW5rIGFib3V0IHRoaXMgYnV0IEkgY2FuIHNoYXJlIG15IA0K Pj4gaW5pdGlhbCBjb25jZXJucyB3aXRoIHRoZSBwcm9wb3NlZCBzb2x1dGlvbnMuDQo+PiANCj4+ IFRoZSBjb25jZXJucyBJIGhhdmUgYXJlIHNlY3VyaXR5LXJlbGF0ZWQuICBBIExvU1Qgc2VydmVy IHVzZWQgaW4gdGhlIA0KPj4gY29udGV4dCBvZiBlbWVyZ2VuY3kgY2FsbGluZyAodGhlIHNjb3Bl IG9mIEVDUklUKSBob2xkcyBjcml0aWNhbCANCj4+IGluZm9ybWF0aW9uIGFib3V0IGhvdyBlbWVy Z2VuY3kgY2FsbHMgYXJlIHJvdXRlZCBhbmQgdGhlaXIgDQo+PiBkZXN0aW5hdGlvbnMuIEJvdGgg c29sdXRpb25zIHdvdWxkIGFsbG93IGEgbWFsZXZvbGVudCBjbGllbnQgdG8gDQo+PiByZWJ1aWxk IHRoZSBzZXJ2ZXIncyBpbnRlcm5hbCBkYXRhIHN0cnVjdHVyZSBhbmQgdXNlIHRoYXQgYXMgYW4g DQo+PiBhdHRhY2sgb2Ygc29tZSBmb3JtIChpbXBlcnNvbmFsaXNhdGlvbiwgTUlUTSwgU1dBVHRp bmcsIGV0Yy4pLg0KPj4gDQo+PiBJIGhhdmUgcmUtcmVhZCB0aGUgU2VjdXJpdHkgc2VjdGlvbiBv ZiBSRkMgNTIyMiBhbmQgcGVyaGFwcyB0aGVzZSANCj4+IGNvbmNlcm5zIGFyZSBhbHJlYWR5IGFk ZHJlc3NlZCBidXQgd291bGQgbGlrZSB0byBoZWFyIHRoZSBvcGluaW9uIG9mIA0KPj4gb3RoZXJz Lg0KPj4gDQo+PiBUaGFua3MsDQo+PiANCj4+IEd1eQ0KPj4gDQo+PiANCj4+IA0KPj4gLS0tLS1N ZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+PiBEZSA6IEVjcml0IDxlY3JpdC1ib3VuY2VzQGlldGYu b3JnPiBEZSBsYSBwYXJ0IGRlIEJyaWFuIFJvc2VuIEVudm95w6kgOiANCj4+IDI1IGFvw7t0IDIw MjEgMTc6NTggw4AgOiBSYW5kYWxsIEdlbGxlbnMgPHJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmc+ IENjDQo+PiA6IEVDUklUIDxlY3JpdEBpZXRmLm9yZz4gT2JqZXQgOiBbRVhUXVJlOiBbRWNyaXRd IFByb2JsZW0gaW4NCj4+IC1wbGFubmVkLWNoYW5nZXM6IHVuaXF1ZSByZWNvcmRzIGluIExvU1Qg c2VydmVyIG1heSBub3QgbWF0Y2ggdW5pcXVlIA0KPj4gcmVjb3JkcyBpbiBMSVMNCj4+IA0KPj4g WWVhaCwgb2YgdGhlIHR3byBvcHRpb25zLCBJIGxpa2UgdGhlIHNlY29uZC4gIEkgd291bGQgbGlr ZSB0byB3YWl0IHRvIA0KPj4gaGVyZSBmcm9tIEd1eSwgd2hvIGRpZG7igJl0IGxpa2UgZWl0aGVy Lg0KPj4gDQo+PiBFaXRoZXIgb2YgdGhlIHR3byBJIGNhbWUgdXAgd2l0aCBjYW4gYmUgYWRkZWQg cXVpY2tseSB0byB0aGUgZG9jLg0KPj4gDQo+PiBCcmlhbg0KPj4gDQo+PiANCj4+PiBPbiBBdWcg MjUsIDIwMjEsIGF0IDU6NTYgUE0sIFJhbmRhbGwgR2VsbGVucyANCj4+PiA8cmcraWV0ZkByYW5k eS5wZW5zaXZlLm9yZz4gd3JvdGU6DQo+Pj4gDQo+Pj4gRWl0aGVyIGFwcHJvYWNoIHdvdWxkIHdv cms6IHRoZSBzZXJ2ZXIgcmV0dXJuaW5nIHRoZSBwcmlvciBVUkkgaWYgaXQgDQo+Pj4gcmVwbGFj ZXMgaXQsIG9yIHRoZSBzZXJ2ZXIgYWx3YXlzIHJldHVybmluZyBhICJ1bmlxdWUgbG9jYXRpb24g SUQiDQo+Pj4gd2hlbmV2ZXIgaXQgc3RvcmVzIGEgVVJJLiAgSW4gdGhlIGxhdHRlciBjYXNlLCB3 ZSdkIHdhbnQgdG8gYWRkIHRoaXMgDQo+Pj4gSUQgdG8gdGhlIDxsb2NhdGlvbkludmFsaWRhdGVk PiBvYmplY3QuICBUaGUgbGF0dGVyIHNlZW1zIGEgYml0IA0KPj4+IGNsZWFuZXIsIGFzIHRoZW4g dGhlIHNlcnZlciBhbHdheXMgcmV0dXJucyBhbiBJRCwgYW5kIGEgY2xpZW50IA0KPj4+IGFsd2F5 cyBzdG9yZXMgdGhpcyBJRCB3aGVuZXZlciBpdCBzZW5kcyBhIFVSSSwgYW5kIHVzZXMgdGhlIElE IHRvIA0KPj4+IHJlLXZhbGlkYXRlIGxvY2F0aW9ucyB3aGVuIGl0IGdldHMgYSA8bG9jYXRpb25J bnZhbGlkYXRlZD4gb2JqZWN0Lg0KPj4+IA0KPj4+IC0tUmFuZGFsbA0KPj4+IA0KPj4+IE9uIDI0 IEF1ZyAyMDIxLCBhdCAxMzowOCwgQnJpYW4gUm9zZW4gd3JvdGU6DQo+Pj4gDQo+Pj4+IEkgcmVh bGl6ZWQgd2UgaGF2ZSBhIHByb2JsZW0gd2l0aCAtcGxhbm5lZC1jaGFuZ2VzLiAgVGhlIHRleHQg bm90ZXM6DQo+Pj4+IEVhY2ggY2xpZW50IG9mIHRoZSBzZXJ2ZXIgbWF5IG9ubHkgc3RvcmUgb25l IFVSSSBhZ2FpbnN0IGEgDQo+Pj4+IGxvY2F0aW9uLCB3aGVyZSDigJxsb2NhdGlvbuKAnSBpcyBk ZWZpbmVkIGJ5IHBvbGljeSBhdCB0aGUgc2VydmVyLCANCj4+Pj4gc2luY2UgYSBnaXZlbiB1bmlx dWUgbG9jYXRpb24gbWF5IGhhdmUgbWFueSBjb21iaW5hdGlvbnMgb2YgDQo+Pj4+IGxvY2F0aW9u IGVsZW1lbnRzIHRoYXQgcmVzb2x2ZSB0byB0aGUgc2FtZSBsb2NhdGlvbi4gIElmIHRoZSBzZXJ2 ZXIgDQo+Pj4+IHJlY2VpdmVzIGEg4oCYdXJp4oCZIGZvciB0aGUgc2FtZSBsb2NhdGlvbiBmcm9t IHRoZSBzYW1lIGNsaWVudCwgdGhlIA0KPj4+PiBVUkkgaW4gdGhlIHJlcXVlc3QgcmVwbGFjZXMg dGhlIFVSSSBpdCBwcmV2aW91c2x5IHJldGFpbmVkLg0KPj4+PiANCj4+Pj4gQnV0IHRoaXMgbWVh bnMgdGhhdCBtdWx0aXBsZSByZWNvcmRzIGluIHRoZSBMSVMgbWF5IGJlIG9uZSByZWNvcmQgDQo+ Pj4+IGluIHRoZSBMb1NUIHNlcnZlciBhbmQgd2hlbiB0aGUgTElTIGFzc29jaWF0ZXMgdW5pcXVl IFVSSXMgd2l0aCANCj4+Pj4gd2hhdCBpdCB0aGlua3MgaXMgbXVsdGlwbGUgcmVjb3Jkcywgb25s eSBvbmUgaXMgcmV0YWluZWQgYW5kIGl0IA0KPj4+PiBkb2VzbuKAmXQga25vdyB0aGF0Lg0KPj4+ PiANCj4+Pj4gVGhlIGVhc2llc3QgZml4IGlzIHRvIHJldHVybiB0aGUgcmVwbGFjZWQgVVJJLiAg VGhlIGNsaWVudCB3b3VsZCANCj4+Pj4gdGhlbiBiZSBhYmxlIHRvIHNwb3QgdGhhdCB0aGUgcmVj b3JkcyBhcmUgbGlua2VkIGFuZCBkbyB0aGUgYm9vayANCj4+Pj4ga2VlcGluZyB0byB0cmFjayB3 aGF0IGl0IHNob3VsZCBkby4NCj4+Pj4gQW5vdGhlciB3YXkgdG8gZml4IHRoaXMgaXMgdG8gcmV0 dXJuIGEgdW5pcXVlIElEIG9mIHRoZSByZWNvcmQgaW4gDQo+Pj4+IHRoZSBMb1NUIHNlcnZlciB3 aGVuIHlvdSB1c2UgdGhlIGV4dGVuc2lvbi4gIFRoZSBMSVMgY2FuIHRoZW4ga2VlcCANCj4+Pj4g YW4gaW50ZXJuYWwgcmVjb3JkIG9mIGFsbCB0aGUgcmVsYXRlZCBlbnRyaWVzIGl0IGhhcyB0aGF0 IGFyZSBvbmUgDQo+Pj4+IHJlY29yZCB0byB0aGUgc2VydmVyLg0KPj4+PiANCj4+Pj4gQnJpYW4N Cj4+Pj4gDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4+IEVjcml0IG1haWxpbmcgbGlzdA0KPj4+PiBFY3JpdEBpZXRmLm9yZw0KPj4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+PiANCj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBFY3JpdCBtYWls aW5nIGxpc3QNCj4+IEVjcml0QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2Vjcml0DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IC0NCj4+IC0tLS0tLS0tIEV4 dGVybmFsIEVtYWlsOiBQbGVhc2UgdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxpbmtzIGFuZCAN Cj4+IGF0dGFjaG1lbnRzIC8gQ291cnJpZWwgZXh0ZXJuZTogU295ZXogcHJ1ZGVudCBhdmVjIGxl cyBsaWVucyBldCANCj4+IGRvY3VtZW50cyBqb2ludHMNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0t LS0tLSBFeHRlcm5hbCBFbWFpbDogUGxlYXNlIHVzZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBsaW5r cyBhbmQgDQo+IGF0dGFjaG1lbnRzIC8gQ291cnJpZWwgZXh0ZXJuZTogU295ZXogcHJ1ZGVudCBh dmVjIGxlcyBsaWVucyBldCANCj4gZG9jdW1lbnRzIGpvaW50cw0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCkV4dGVybmFsIEVtYWlsOiBQbGVhc2UgdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxp bmtzIGFuZCBhdHRhY2htZW50cyAvIENvdXJyaWVsIGV4dGVybmU6IFNveWV6IHBydWRlbnQgYXZl YyBsZXMgbGllbnMgZXQgZG9jdW1lbnRzIGpvaW50cw0K From nobody Fri Aug 27 10:06:20 2021 Return-Path: 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 0A49E3A193D for ; Fri, 27 Aug 2021 10:06:18 -0700 (PDT) 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.20150623.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 cG4T0mvrS7lQ for ; Fri, 27 Aug 2021 10:06:12 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 EB4473A193C for ; Fri, 27 Aug 2021 10:06:11 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id z1so9373475ioh.7 for ; Fri, 27 Aug 2021 10:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/83FOosivzTRF8C81SxTyDgNH1jEIdO3WY6v3etMfzs=; b=ke/VIv1R9CTG3OicAr3uzbDjeJSgPIs75ApnL/I2iOrtilynJQVYBza6jOCjeESRrT J1AswO2/evFihKxrlShqVq2N4I933kfpWFiV0jFjWBlHqpeofg2uvVLKO/D7z/IgVTXY Z8bHY7EtwOmkaXhcaQlzMVjHR0vF+RuODyTAFuWENbdw7pONGRbgIESiHcMMSMDqDwTn RgnI6pzm1HFfbXaT+OUHxFCIzJhrkCYnKZHk8vQiBUv/D4QV3mpiqcSOJC/9y4QYppT6 UXDlP08HjtUD0bV1ALaFA4BZ/Gfkv6hXcnw54csVfbkDuybUKDOIlwdUx3DETitBqZ79 BXbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/83FOosivzTRF8C81SxTyDgNH1jEIdO3WY6v3etMfzs=; b=KoQbbJgmWkXObWRZtRz/Ou832nxJNm6zyeA4A8o0XWCd7dnJbG75mBbi/LoQycZmo7 UIHQybT6h6EFkdD6SQJfaApVHYwVikvq1U3ZzO3FbdRENCQNVQL+sRZzrSAAap7ipHun +OzzwGhARCK4gwxJiex5ZIgt57axaOvSn+kcvALHRZem5RIfntRCFre64Ckeml/KwWAL MRdXVgGO2NCh9kuvLg+6hDkAJw6TbZTne2HMyApQ/gzQUSOneJaJLk69Z/czh9k/wRNC H4XKIqMSEv1Y7fBtnYageJmWb3MmiqUAYnVSJwAQG8qsJvR7GQhJVZBraoqydE77P7RO AxoA== X-Gm-Message-State: AOAM530XwGsg4bEQokcsdj/BePM6oo+CpzVk3ga9oMt6/lOiyGN4DTC3 YRA+ZJoI7ThvLgwBBhJtmCQLn+T1qegUOCH7 X-Google-Smtp-Source: ABdhPJy1/vc+TjtexX0cHGLtscB1Y2YwieU1kRWsO20pFCkSvRX+GVsf8DnhyCQYR96TpQZuBccQ/Q== X-Received: by 2002:a5d:8588:: with SMTP id f8mr8108906ioj.46.1630083970238; Fri, 27 Aug 2021 10:06:10 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id x15sm3712008ilp.23.2021.08.27.10.06.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Aug 2021 10:06:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Brian Rosen In-Reply-To: <741db5d6ee69431fa8d81c54095fe317@bell.ca> Date: Fri, 27 Aug 2021 13:06:07 -0400 Cc: Randall Gellens , ECRIT Content-Transfer-Encoding: quoted-printable Message-Id: <62C54BFE-15F0-4F17-B290-248324F62373@brianrosen.net> References: <1120BD41-A143-4AC1-B1A7-6CFF40658FF7@randy.pensive.org> <26184A64-2B40-4230-A09B-9A2D00D5F150@brianrosen.net> <14a2a0fad5f1499ca7939e820cc8a852@bell.ca> <34febd3e0984476380325a181f7b611a@bell.ca> <219EED44-D2BB-477A-9452-6BF688FB89AD@brianrosen.net> <741db5d6ee69431fa8d81c54095fe317@bell.ca> To: "Caron, Guy" X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2021 17:06:18 -0000 Okay, good. Do you have a preference between the options I came up = with? I think we=E2=80=99re leaning towards the second: the server = returns a unique ID for every record it has. Brian > On Aug 27, 2021, at 12:58 PM, Caron, Guy wrote: >=20 > You make a good point about getting exactly the same information = already: address number will be in =E2=80=9Cunchecked=E2=80=9D for a = road centerline (assuming it=E2=80=99s in a range, if it=E2=80=99s not, = it=E2=80=99s in invalid). >=20 > I therefore rescind my concern about the proposed solutions. >=20 > Thanks, >=20 > Guy >=20 > -----Message d'origine----- > De : Brian Rosen =20 > Envoy=C3=A9 : 26 ao=C3=BBt 2021 09:32 > =C3=80 : Caron, Guy > Cc : Randall Gellens ; ECRIT = > Objet : [EXT]Re: [Ecrit] Problem in -planned-changes: unique records = in LoST server may not match unique records in LIS >=20 > I don=E2=80=99t see how this knowledge aids an attack. Yes, it knows = what is a road centerline and what is an address point (or equivalent), = but I don=E2=80=99t see how an attacker could use that information. =20 >=20 > Also, you get exactly the same information already: address number = will be in =E2=80=9Cunchecked=E2=80=9D for a road centerline (assuming = it=E2=80=99s in a range, if it=E2=80=99s not, it=E2=80=99s in invalid). > This is because 4-100 includes 55 and there may or may not be an = actual 55 address number. Now, that really is specific to North = America: the NENA standard says that=E2=80=99s how you populate the = unchecked list: 5222 isn=E2=80=99t specific. >=20 > Brian >=20 >> On Aug 26, 2021, at 9:09 AM, Caron, Guy wrote: >>=20 >> Both solutions reveal the granularity of the underlying data in the = LoST server. >>=20 >> Here is an example: >>=20 >> 1. Client sends a URI for each discrete location (think civic = numbers) of a street. >> 2. Server is only provisioned with road centerline data for that = street and thus return one URI (or ID) back to the client for each = discrete location it has. >> 3. Client stores this unique URI (or ID) against all discrete = locations. >> 4. After all the Client's locations have gotten the URIs (or (IDs) = from the Server, the Client has a detailed view of the Server's = underlying data. >>=20 >> Then, put this in the hands of an attacker. >>=20 >> Thanks, >>=20 >>=20 >> Guy >>=20 >>=20 >> -----Message d'origine----- >> De : Randall Gellens Envoy=C3=A9 : 26 = ao=C3=BBt 2021=20 >> 00:40 =C3=80 : Caron, Guy Cc : Brian Rosen=20 >> ; ECRIT Objet : [EXT]Re: [Ecrit]=20= >> Problem in -planned-changes: unique records in LoST server may not=20 >> match unique records in LIS >>=20 >> Hi Guy, >>=20 >> I'm not following how "Both solutions would allow a malevolent client = to rebuild the server's internal data structure". In either solution, = the LoST server returns something to the LoST client that the LoST = client uses to mark one or more of its location records. If/when the = LoST server sends the client a object, the object = contains this same marker, which the client uses to know which of its = records should be revalidated. >>=20 >> --Randall >>=20 >> On 25 Aug 2021, at 19:33, Caron, Guy wrote: >>=20 >>> I did not have much cycle time to think about this but I can share = my=20 >>> initial concerns with the proposed solutions. >>>=20 >>> The concerns I have are security-related. A LoST server used in the=20= >>> context of emergency calling (the scope of ECRIT) holds critical=20 >>> information about how emergency calls are routed and their=20 >>> destinations. Both solutions would allow a malevolent client to=20 >>> rebuild the server's internal data structure and use that as an=20 >>> attack of some form (impersonalisation, MITM, SWATting, etc.). >>>=20 >>> I have re-read the Security section of RFC 5222 and perhaps these=20 >>> concerns are already addressed but would like to hear the opinion of=20= >>> others. >>>=20 >>> Thanks, >>>=20 >>> Guy >>>=20 >>>=20 >>>=20 >>> -----Message d'origine----- >>> De : Ecrit De la part de Brian Rosen = Envoy=C3=A9 :=20 >>> 25 ao=C3=BBt 2021 17:58 =C3=80 : Randall Gellens = Cc >>> : ECRIT Objet : [EXT]Re: [Ecrit] Problem in >>> -planned-changes: unique records in LoST server may not match unique=20= >>> records in LIS >>>=20 >>> Yeah, of the two options, I like the second. I would like to wait = to=20 >>> here from Guy, who didn=E2=80=99t like either. >>>=20 >>> Either of the two I came up with can be added quickly to the doc. >>>=20 >>> Brian >>>=20 >>>=20 >>>> On Aug 25, 2021, at 5:56 PM, Randall Gellens=20 >>>> wrote: >>>>=20 >>>> Either approach would work: the server returning the prior URI if = it=20 >>>> replaces it, or the server always returning a "unique location ID" >>>> whenever it stores a URI. In the latter case, we'd want to add = this=20 >>>> ID to the object. The latter seems a bit=20 >>>> cleaner, as then the server always returns an ID, and a client=20 >>>> always stores this ID whenever it sends a URI, and uses the ID to=20= >>>> re-validate locations when it gets a object. >>>>=20 >>>> --Randall >>>>=20 >>>> On 24 Aug 2021, at 13:08, Brian Rosen wrote: >>>>=20 >>>>> I realized we have a problem with -planned-changes. The text = notes: >>>>> Each client of the server may only store one URI against a=20 >>>>> location, where =E2=80=9Clocation=E2=80=9D is defined by policy at = the server,=20 >>>>> since a given unique location may have many combinations of=20 >>>>> location elements that resolve to the same location. If the = server=20 >>>>> receives a =E2=80=98uri=E2=80=99 for the same location from the = same client, the=20 >>>>> URI in the request replaces the URI it previously retained. >>>>>=20 >>>>> But this means that multiple records in the LIS may be one record=20= >>>>> in the LoST server and when the LIS associates unique URIs with=20 >>>>> what it thinks is multiple records, only one is retained and it=20 >>>>> doesn=E2=80=99t know that. >>>>>=20 >>>>> The easiest fix is to return the replaced URI. The client would=20= >>>>> then be able to spot that the records are linked and do the book=20= >>>>> keeping to track what it should do. >>>>> Another way to fix this is to return a unique ID of the record in=20= >>>>> the LoST server when you use the extension. The LIS can then keep=20= >>>>> an internal record of all the related entries it has that are one=20= >>>>> record to the server. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> = --------------------------------------------------------------------- >>> - >>> -------- External Email: Please use caution when opening links and=20= >>> attachments / Courriel externe: Soyez prudent avec les liens et=20 >>> documents joints >> = ---------------------------------------------------------------------- >> -------- External Email: Please use caution when opening links and=20 >> attachments / Courriel externe: Soyez prudent avec les liens et=20 >> documents joints >=20 > = --------------------------------------------------------------------------= ---- > External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints From nobody Fri Aug 27 10:08:13 2021 Return-Path: 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 DB22F3A19BE for ; Fri, 27 Aug 2021 10:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=bell.ca 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 YwcTWWMebuzT for ; Fri, 27 Aug 2021 10:08:03 -0700 (PDT) Received: from ESA3-Dor.bell.ca (esa3-dor.bell.ca [204.101.223.60]) (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 195D33A1995 for ; Fri, 27 Aug 2021 10:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1630084083; x=1661620083; h=from:to:cc:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=wr6ElZEiVVQqo8cLhTRxtQMWnkAOxwvemRWoXLbCZKY=; b=I08XGNsTcE2LQUwCFZCfgHd1CwIeeYFFsHua14sUfgMM1fGNO1BPBmB4 tZtgbtiWplByVIe0L8QAkF7A8jWxC1Gl6346LhtoxBZonhjSSol89wE2m w+jgEdNzQFvY1VjArfr5wHut/FoZXQAeKbgbDjMY8mXpWFRRw6vBxczkz 0xPUX5FAtA6xDxhSfZYgwwGAZ4iQ0B5F6yLTd8xUr4DWFOjlvOffIShJx 9ivmzeYotLYifIQItzBpB+WOuKR0YMkFkli4CZSrsmq8d2/+UHT0qe7B8 oyHx0gTp5HwrGGU+dVg2sBYkOY09U1CGvh2dgr2KVZABLMa/URsHGTpJH w==; IronPort-SDR: wk3JOdpqcE/9IJZNNDuWa4LJHupcpyGEBplltHoA/gMPa0knJUThMk310AH4eqtePM1Pdu6+z8 ++5lPJnup+rg== Received: from dc5cmz-d00.bellca.int.bell.ca (HELO DG6MBX01-WYN.bell.corp.bce.ca) ([198.235.121.231]) by esa03corp-dor.bell.corp.bce.ca with ESMTP; 27 Aug 2021 13:08:01 -0400 Received: from DG12MBX02-WYN.bell.corp.bce.ca (142.182.18.47) by DG6MBX01-WYN.bell.corp.bce.ca (142.182.18.36) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Fri, 27 Aug 2021 13:08:01 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX02-WYN.bell.corp.bce.ca (142.182.18.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Fri, 27 Aug 2021 13:08:00 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Fri, 27 Aug 2021 13:08:00 -0400 From: "Caron, Guy" To: Brian Rosen , Randall Gellens CC: ECRIT Thread-Topic: [EXT]Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS Thread-Index: AQHXmfwhRqgqGYN29EukUdmptVZv5auFB74AgAKN/vA= Date: Fri, 27 Aug 2021 17:08:00 +0000 Message-ID: <0a255415fb484766990e467518d50ed3@bell.ca> References: <1120BD41-A143-4AC1-B1A7-6CFF40658FF7@randy.pensive.org> <26184A64-2B40-4230-A09B-9A2D00D5F150@brianrosen.net> In-Reply-To: <26184A64-2B40-4230-A09B-9A2D00D5F150@brianrosen.net> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.65] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2021 17:08:10 -0000 SSB0b28gcHJlZmVyIHRoZSBzb2x1dGlvbiB3aXRoIGFuIElELg0KDQpPbmUgc2lkZSBiZW5lZml0 IHRvIHRoaXMgc29sdXRpb24gaXMgdGhhdCB0aGUgQ2xpZW50IG5vIGxvbmdlciBuZWVkcyBhIGRp ZmZlcmVudCBVUkkgZm9yIGVhY2ggbG9jYXRpb24gaXQgdmFsaWRhdGVzLiBJdCBvbmx5IG5lZWQg YSBnZW5lcmljIG9uZSAoYnV0IHNwZWNpZmljIHRvIGl0c2VsZikgc2luY2UgdGhlIHJldmFsaWRh dGlvbiByZXF1ZXN0IHRvIHRoZSBTZXJ2ZXIgd2lsbCBpbmNsdWRlIHRoZSBJRCByZWNlaXZlZCBp biB0aGUgPGxvY2F0aW9uSW52YWxpZGF0ZWQ+IGZpZWxkIG9mIHRoZSBub3RpZmljYXRpb24uDQoN Ckxlc3MgYnVyZGVuIG9uIHRoZSBDbGllbnRzLiBXZSBtYXkgd2FudCB0byBzYXkgdGhhdC4NCg0K SSBzdGlsbCB0aGluayB3ZSBuZWVkIHRvIGNoYW5nZSA8bG9jYXRpb25JbnZhbGlkZWQ+IHRvIHNv bWV0aGluZyBsaWtlIDxsb2NhdGlvbkltcGFjdGVkPi4NCg0KVGhhbmtzLA0KDQpHdXkNCg0KLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBFY3JpdCA8ZWNyaXQtYm91bmNlc0BpZXRm Lm9yZz4gRGUgbGEgcGFydCBkZSBCcmlhbiBSb3Nlbg0KRW52b3nDqcKgOiAyNSBhb8O7dCAyMDIx IDE3OjU4DQrDgMKgOiBSYW5kYWxsIEdlbGxlbnMgPHJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmc+ DQpDY8KgOiBFQ1JJVCA8ZWNyaXRAaWV0Zi5vcmc+DQpPYmpldMKgOiBbRVhUXVJlOiBbRWNyaXRd IFByb2JsZW0gaW4gLXBsYW5uZWQtY2hhbmdlczogdW5pcXVlIHJlY29yZHMgaW4gTG9TVCBzZXJ2 ZXIgbWF5IG5vdCBtYXRjaCB1bmlxdWUgcmVjb3JkcyBpbiBMSVMNCg0KWWVhaCwgb2YgdGhlIHR3 byBvcHRpb25zLCBJIGxpa2UgdGhlIHNlY29uZC4gIEkgd291bGQgbGlrZSB0byB3YWl0IHRvIGhl cmUgZnJvbSBHdXksIHdobyBkaWRu4oCZdCBsaWtlIGVpdGhlci4NCg0KRWl0aGVyIG9mIHRoZSB0 d28gSSBjYW1lIHVwIHdpdGggY2FuIGJlIGFkZGVkIHF1aWNrbHkgdG8gdGhlIGRvYy4NCg0KQnJp YW4NCg0KDQo+IE9uIEF1ZyAyNSwgMjAyMSwgYXQgNTo1NiBQTSwgUmFuZGFsbCBHZWxsZW5zIDxy ZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnPiB3cm90ZToNCj4gDQo+IEVpdGhlciBhcHByb2FjaCB3 b3VsZCB3b3JrOiB0aGUgc2VydmVyIHJldHVybmluZyB0aGUgcHJpb3IgVVJJIGlmIGl0IHJlcGxh Y2VzIGl0LCBvciB0aGUgc2VydmVyIGFsd2F5cyByZXR1cm5pbmcgYSAidW5pcXVlIGxvY2F0aW9u IElEIiB3aGVuZXZlciBpdCBzdG9yZXMgYSBVUkkuICBJbiB0aGUgbGF0dGVyIGNhc2UsIHdlJ2Qg d2FudCB0byBhZGQgdGhpcyBJRCB0byB0aGUgPGxvY2F0aW9uSW52YWxpZGF0ZWQ+IG9iamVjdC4g IFRoZSBsYXR0ZXIgc2VlbXMgYSBiaXQgY2xlYW5lciwgYXMgdGhlbiB0aGUgc2VydmVyIGFsd2F5 cyByZXR1cm5zIGFuIElELCBhbmQgYSBjbGllbnQgYWx3YXlzIHN0b3JlcyB0aGlzIElEIHdoZW5l dmVyIGl0IHNlbmRzIGEgVVJJLCBhbmQgdXNlcyB0aGUgSUQgdG8gcmUtdmFsaWRhdGUgbG9jYXRp b25zIHdoZW4gaXQgZ2V0cyBhIDxsb2NhdGlvbkludmFsaWRhdGVkPiBvYmplY3QuDQo+IA0KPiAt LVJhbmRhbGwNCj4gDQo+IE9uIDI0IEF1ZyAyMDIxLCBhdCAxMzowOCwgQnJpYW4gUm9zZW4gd3Jv dGU6DQo+IA0KPj4gSSByZWFsaXplZCB3ZSBoYXZlIGEgcHJvYmxlbSB3aXRoIC1wbGFubmVkLWNo YW5nZXMuICBUaGUgdGV4dCBub3RlczoNCj4+IEVhY2ggY2xpZW50IG9mIHRoZSBzZXJ2ZXIgbWF5 IG9ubHkgc3RvcmUgb25lIFVSSSBhZ2FpbnN0IGEgbG9jYXRpb24sIHdoZXJlIOKAnGxvY2F0aW9u 4oCdIGlzIGRlZmluZWQgYnkgcG9saWN5IGF0IHRoZSBzZXJ2ZXIsIHNpbmNlIGEgZ2l2ZW4gdW5p cXVlIGxvY2F0aW9uIG1heSBoYXZlIG1hbnkgY29tYmluYXRpb25zIG9mIGxvY2F0aW9uIGVsZW1l bnRzIHRoYXQgcmVzb2x2ZSB0byB0aGUgc2FtZSBsb2NhdGlvbi4gIElmIHRoZSBzZXJ2ZXIgcmVj ZWl2ZXMgYSDigJh1cmnigJkgZm9yIHRoZSBzYW1lIGxvY2F0aW9uIGZyb20gdGhlIHNhbWUgY2xp ZW50LCB0aGUgVVJJIGluIHRoZSByZXF1ZXN0IHJlcGxhY2VzIHRoZSBVUkkgaXQgcHJldmlvdXNs eSByZXRhaW5lZC4NCj4+IA0KPj4gQnV0IHRoaXMgbWVhbnMgdGhhdCBtdWx0aXBsZSByZWNvcmRz IGluIHRoZSBMSVMgbWF5IGJlIG9uZSByZWNvcmQgaW4gdGhlIExvU1Qgc2VydmVyIGFuZCB3aGVu IHRoZSBMSVMgYXNzb2NpYXRlcyB1bmlxdWUgVVJJcyB3aXRoIHdoYXQgaXQgdGhpbmtzIGlzIG11 bHRpcGxlIHJlY29yZHMsIG9ubHkgb25lIGlzIHJldGFpbmVkIGFuZCBpdCBkb2VzbuKAmXQga25v dyB0aGF0Lg0KPj4gDQo+PiBUaGUgZWFzaWVzdCBmaXggaXMgdG8gcmV0dXJuIHRoZSByZXBsYWNl ZCBVUkkuICBUaGUgY2xpZW50IHdvdWxkIHRoZW4gYmUgYWJsZSB0byBzcG90IHRoYXQgdGhlIHJl Y29yZHMgYXJlIGxpbmtlZCBhbmQgZG8gdGhlIGJvb2sga2VlcGluZyB0byB0cmFjayB3aGF0IGl0 IHNob3VsZCBkby4NCj4+IEFub3RoZXIgd2F5IHRvIGZpeCB0aGlzIGlzIHRvIHJldHVybiBhIHVu aXF1ZSBJRCBvZiB0aGUgcmVjb3JkIGluIHRoZSBMb1NUIHNlcnZlciB3aGVuIHlvdSB1c2UgdGhl IGV4dGVuc2lvbi4gIFRoZSBMSVMgY2FuIHRoZW4ga2VlcCBhbiBpbnRlcm5hbCByZWNvcmQgb2Yg YWxsIHRoZSByZWxhdGVkIGVudHJpZXMgaXQgaGFzIHRoYXQgYXJlIG9uZSByZWNvcmQgdG8gdGhl IHNlcnZlci4NCj4+IA0KPj4gQnJpYW4NCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+IEVjcml0IG1haWxpbmcgbGlzdA0KPj4gRWNyaXRA aWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkVjcml0 IG1haWxpbmcgbGlzdA0KRWNyaXRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZWNyaXQNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRXh0ZXJuYWwgRW1haWw6 IFBsZWFzZSB1c2UgY2F1dGlvbiB3aGVuIG9wZW5pbmcgbGlua3MgYW5kIGF0dGFjaG1lbnRzIC8g Q291cnJpZWwgZXh0ZXJuZTogU295ZXogcHJ1ZGVudCBhdmVjIGxlcyBsaWVucyBldCBkb2N1bWVu dHMgam9pbnRzDQo= From nobody Fri Aug 27 10:10:26 2021 Return-Path: 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 40BBF3A19CD for ; Fri, 27 Aug 2021 10:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-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=bell.ca 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 1MahFRYzltGh for ; Fri, 27 Aug 2021 10:10:03 -0700 (PDT) Received: from ESA1-Dor.bell.ca (esa1-dor.bell.ca [204.101.223.58]) (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 0EDD73A19AD for ; Fri, 27 Aug 2021 10:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1630084203; x=1661620203; h=from:to:cc:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=bvPlrPP1p6H3dDXuwfZYjfau9LAqW5d8Q0NZ+Nr5Svw=; b=S8wsKBvRgdNupDYkB7iqR2Pj53+STa48XlUlPSpDCCkK+0uOhTvT2+jr 0DWfUPsRiyFkuxBnVNfcTDmRLHNontPIujYrEmA4czdxYhlTZjo1NDEcQ gXT1Aaf40trZr0FA1liURzXeHikOhcWykPha0SccA4ZL4M7v8VLqfHVIy NgnrS1YBqI5T67fyhMmB4+3X2aDsrj1JwoyFAJUX6E87nKQ1bisDx07aL 3tHp/C0vKyGNE695QUxKc1o8voIFO6WHHa8p5rloxEpNXeTh1cqJIpirs kq/xdUR3C9+EQABVDhq+MHTxKeFLdZJZkyAfDlNummFcmONK1pNVeiIPx A==; IronPort-SDR: Vjp/oCRDurLIKWfJnXr8PN5ktyZX7EETEFeA1OFt+ddbZFNGqj3GyFR0TWLtl8kHVEr6R7RqzW PprAD4lugHsw== Received: from dc5cmy-d00.bellca.int.bell.ca (HELO DG1MBX01-WYN.bell.corp.bce.ca) ([198.235.121.229]) by esa01corp-dor.bell.corp.bce.ca with ESMTP; 27 Aug 2021 13:10:01 -0400 Received: from DG12MBX04-WYN.bell.corp.bce.ca (142.182.18.49) by DG1MBX01-WYN.bell.corp.bce.ca (142.182.18.11) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Fri, 27 Aug 2021 13:10:01 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX04-WYN.bell.corp.bce.ca (142.182.18.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Fri, 27 Aug 2021 13:10:01 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Fri, 27 Aug 2021 13:10:01 -0400 From: "Caron, Guy" To: "Caron, Guy" , Brian Rosen , Randall Gellens CC: ECRIT Thread-Topic: [EXT]Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS Thread-Index: AQHXmfwhRqgqGYN29EukUdmptVZv5auFB74AgAKN/vCAAALPQA== Date: Fri, 27 Aug 2021 17:10:01 +0000 Message-ID: <0c8729663d2d458994d40a2e6334c3d8@bell.ca> References: <1120BD41-A143-4AC1-B1A7-6CFF40658FF7@randy.pensive.org> <26184A64-2B40-4230-A09B-9A2D00D5F150@brianrosen.net> <0a255415fb484766990e467518d50ed3@bell.ca> In-Reply-To: <0a255415fb484766990e467518d50ed3@bell.ca> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.65] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2021 17:10:25 -0000 TGVzcyBidXJkZW4gb24gdGhlIFNlcnZlcnMgdG9vIHNpbmNlIHRoZXkgd291bGQgbm8gbG9uZ2Vy IG5lZWQgdG8gcmVwbGFjZSB0aGUgVVJJLg0KDQpHdXkNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2lu ZS0tLS0tDQpEZcKgOiBFY3JpdCA8ZWNyaXQtYm91bmNlc0BpZXRmLm9yZz4gRGUgbGEgcGFydCBk ZSBDYXJvbiwgR3V5DQpFbnZvecOpwqA6IDI3IGFvw7t0IDIwMjEgMTM6MDgNCsOAwqA6IEJyaWFu IFJvc2VuIDxickBicmlhbnJvc2VuLm5ldD47IFJhbmRhbGwgR2VsbGVucyA8cmcraWV0ZkByYW5k eS5wZW5zaXZlLm9yZz4NCkNjwqA6IEVDUklUIDxlY3JpdEBpZXRmLm9yZz4NCk9iamV0wqA6IFtF WFRdUmU6IFtFY3JpdF0gUHJvYmxlbSBpbiAtcGxhbm5lZC1jaGFuZ2VzOiB1bmlxdWUgcmVjb3Jk cyBpbiBMb1NUIHNlcnZlciBtYXkgbm90IG1hdGNoIHVuaXF1ZSByZWNvcmRzIGluIExJUw0KDQpJ IHRvbyBwcmVmZXIgdGhlIHNvbHV0aW9uIHdpdGggYW4gSUQuDQoNCk9uZSBzaWRlIGJlbmVmaXQg dG8gdGhpcyBzb2x1dGlvbiBpcyB0aGF0IHRoZSBDbGllbnQgbm8gbG9uZ2VyIG5lZWRzIGEgZGlm ZmVyZW50IFVSSSBmb3IgZWFjaCBsb2NhdGlvbiBpdCB2YWxpZGF0ZXMuIEl0IG9ubHkgbmVlZCBh IGdlbmVyaWMgb25lIChidXQgc3BlY2lmaWMgdG8gaXRzZWxmKSBzaW5jZSB0aGUgcmV2YWxpZGF0 aW9uIHJlcXVlc3QgdG8gdGhlIFNlcnZlciB3aWxsIGluY2x1ZGUgdGhlIElEIHJlY2VpdmVkIGlu IHRoZSA8bG9jYXRpb25JbnZhbGlkYXRlZD4gZmllbGQgb2YgdGhlIG5vdGlmaWNhdGlvbi4NCg0K TGVzcyBidXJkZW4gb24gdGhlIENsaWVudHMuIFdlIG1heSB3YW50IHRvIHNheSB0aGF0Lg0KDQpJ IHN0aWxsIHRoaW5rIHdlIG5lZWQgdG8gY2hhbmdlIDxsb2NhdGlvbkludmFsaWRlZD4gdG8gc29t ZXRoaW5nIGxpa2UgPGxvY2F0aW9uSW1wYWN0ZWQ+Lg0KDQpUaGFua3MsDQoNCkd1eQ0KDQotLS0t LU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IEVjcml0IDxlY3JpdC1ib3VuY2VzQGlldGYu b3JnPiBEZSBsYSBwYXJ0IGRlIEJyaWFuIFJvc2VuIEVudm95w6nCoDogMjUgYW/Du3QgMjAyMSAx Nzo1OCDDgMKgOiBSYW5kYWxsIEdlbGxlbnMgPHJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmc+IENj wqA6IEVDUklUIDxlY3JpdEBpZXRmLm9yZz4gT2JqZXTCoDogW0VYVF1SZTogW0Vjcml0XSBQcm9i bGVtIGluIC1wbGFubmVkLWNoYW5nZXM6IHVuaXF1ZSByZWNvcmRzIGluIExvU1Qgc2VydmVyIG1h eSBub3QgbWF0Y2ggdW5pcXVlIHJlY29yZHMgaW4gTElTDQoNClllYWgsIG9mIHRoZSB0d28gb3B0 aW9ucywgSSBsaWtlIHRoZSBzZWNvbmQuICBJIHdvdWxkIGxpa2UgdG8gd2FpdCB0byBoZXJlIGZy b20gR3V5LCB3aG8gZGlkbuKAmXQgbGlrZSBlaXRoZXIuDQoNCkVpdGhlciBvZiB0aGUgdHdvIEkg Y2FtZSB1cCB3aXRoIGNhbiBiZSBhZGRlZCBxdWlja2x5IHRvIHRoZSBkb2MuDQoNCkJyaWFuDQoN Cg0KPiBPbiBBdWcgMjUsIDIwMjEsIGF0IDU6NTYgUE0sIFJhbmRhbGwgR2VsbGVucyA8cmcraWV0 ZkByYW5keS5wZW5zaXZlLm9yZz4gd3JvdGU6DQo+IA0KPiBFaXRoZXIgYXBwcm9hY2ggd291bGQg d29yazogdGhlIHNlcnZlciByZXR1cm5pbmcgdGhlIHByaW9yIFVSSSBpZiBpdCByZXBsYWNlcyBp dCwgb3IgdGhlIHNlcnZlciBhbHdheXMgcmV0dXJuaW5nIGEgInVuaXF1ZSBsb2NhdGlvbiBJRCIg d2hlbmV2ZXIgaXQgc3RvcmVzIGEgVVJJLiAgSW4gdGhlIGxhdHRlciBjYXNlLCB3ZSdkIHdhbnQg dG8gYWRkIHRoaXMgSUQgdG8gdGhlIDxsb2NhdGlvbkludmFsaWRhdGVkPiBvYmplY3QuICBUaGUg bGF0dGVyIHNlZW1zIGEgYml0IGNsZWFuZXIsIGFzIHRoZW4gdGhlIHNlcnZlciBhbHdheXMgcmV0 dXJucyBhbiBJRCwgYW5kIGEgY2xpZW50IGFsd2F5cyBzdG9yZXMgdGhpcyBJRCB3aGVuZXZlciBp dCBzZW5kcyBhIFVSSSwgYW5kIHVzZXMgdGhlIElEIHRvIHJlLXZhbGlkYXRlIGxvY2F0aW9ucyB3 aGVuIGl0IGdldHMgYSA8bG9jYXRpb25JbnZhbGlkYXRlZD4gb2JqZWN0Lg0KPiANCj4gLS1SYW5k YWxsDQo+IA0KPiBPbiAyNCBBdWcgMjAyMSwgYXQgMTM6MDgsIEJyaWFuIFJvc2VuIHdyb3RlOg0K PiANCj4+IEkgcmVhbGl6ZWQgd2UgaGF2ZSBhIHByb2JsZW0gd2l0aCAtcGxhbm5lZC1jaGFuZ2Vz LiAgVGhlIHRleHQgbm90ZXM6DQo+PiBFYWNoIGNsaWVudCBvZiB0aGUgc2VydmVyIG1heSBvbmx5 IHN0b3JlIG9uZSBVUkkgYWdhaW5zdCBhIGxvY2F0aW9uLCB3aGVyZSDigJxsb2NhdGlvbuKAnSBp cyBkZWZpbmVkIGJ5IHBvbGljeSBhdCB0aGUgc2VydmVyLCBzaW5jZSBhIGdpdmVuIHVuaXF1ZSBs b2NhdGlvbiBtYXkgaGF2ZSBtYW55IGNvbWJpbmF0aW9ucyBvZiBsb2NhdGlvbiBlbGVtZW50cyB0 aGF0IHJlc29sdmUgdG8gdGhlIHNhbWUgbG9jYXRpb24uICBJZiB0aGUgc2VydmVyIHJlY2VpdmVz IGEg4oCYdXJp4oCZIGZvciB0aGUgc2FtZSBsb2NhdGlvbiBmcm9tIHRoZSBzYW1lIGNsaWVudCwg dGhlIFVSSSBpbiB0aGUgcmVxdWVzdCByZXBsYWNlcyB0aGUgVVJJIGl0IHByZXZpb3VzbHkgcmV0 YWluZWQuDQo+PiANCj4+IEJ1dCB0aGlzIG1lYW5zIHRoYXQgbXVsdGlwbGUgcmVjb3JkcyBpbiB0 aGUgTElTIG1heSBiZSBvbmUgcmVjb3JkIGluIHRoZSBMb1NUIHNlcnZlciBhbmQgd2hlbiB0aGUg TElTIGFzc29jaWF0ZXMgdW5pcXVlIFVSSXMgd2l0aCB3aGF0IGl0IHRoaW5rcyBpcyBtdWx0aXBs ZSByZWNvcmRzLCBvbmx5IG9uZSBpcyByZXRhaW5lZCBhbmQgaXQgZG9lc27igJl0IGtub3cgdGhh dC4NCj4+IA0KPj4gVGhlIGVhc2llc3QgZml4IGlzIHRvIHJldHVybiB0aGUgcmVwbGFjZWQgVVJJ LiAgVGhlIGNsaWVudCB3b3VsZCB0aGVuIGJlIGFibGUgdG8gc3BvdCB0aGF0IHRoZSByZWNvcmRz IGFyZSBsaW5rZWQgYW5kIGRvIHRoZSBib29rIGtlZXBpbmcgdG8gdHJhY2sgd2hhdCBpdCBzaG91 bGQgZG8uDQo+PiBBbm90aGVyIHdheSB0byBmaXggdGhpcyBpcyB0byByZXR1cm4gYSB1bmlxdWUg SUQgb2YgdGhlIHJlY29yZCBpbiB0aGUgTG9TVCBzZXJ2ZXIgd2hlbiB5b3UgdXNlIHRoZSBleHRl bnNpb24uICBUaGUgTElTIGNhbiB0aGVuIGtlZXAgYW4gaW50ZXJuYWwgcmVjb3JkIG9mIGFsbCB0 aGUgcmVsYXRlZCBlbnRyaWVzIGl0IGhhcyB0aGF0IGFyZSBvbmUgcmVjb3JkIHRvIHRoZSBzZXJ2 ZXIuDQo+PiANCj4+IEJyaWFuDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4+IEVjcml0QGlldGYu b3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpFY3JpdCBtYWls aW5nIGxpc3QNCkVjcml0QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2Vjcml0DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkV4dGVybmFsIEVtYWlsOiBQbGVh c2UgdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxpbmtzIGFuZCBhdHRhY2htZW50cyAvIENvdXJy aWVsIGV4dGVybmU6IFNveWV6IHBydWRlbnQgYXZlYyBsZXMgbGllbnMgZXQgZG9jdW1lbnRzIGpv aW50cyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRWNy aXQgbWFpbGluZyBsaXN0DQpFY3JpdEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9lY3JpdA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpFeHRlcm5hbCBFbWFp bDogUGxlYXNlIHVzZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQgYXR0YWNobWVudHMg LyBDb3VycmllbCBleHRlcm5lOiBTb3lleiBwcnVkZW50IGF2ZWMgbGVzIGxpZW5zIGV0IGRvY3Vt ZW50cyBqb2ludHMNCg== From nobody Fri Aug 27 10:18:01 2021 Return-Path: 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 E71983A1A65 for ; Fri, 27 Aug 2021 10:17:47 -0700 (PDT) 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.20150623.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 KZkZKg_58HU9 for ; Fri, 27 Aug 2021 10:17:41 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 54A873A1A6B for ; Fri, 27 Aug 2021 10:17:41 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id s16so7693013ilo.9 for ; Fri, 27 Aug 2021 10:17:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gT5ZMWqhMLp8F0bezIZAaeq0ziq01php0gNe+dgjrw8=; b=nA7xnwQn2+yqUztBOuDGfAqirVa+1PW3FeGWQgaHBU9TS8Ji0hl8Ng1Q8dMmq0Fhfm jTjtPuBiIu5s00oK7fHRQUByM1jr2xqVJmxQgAj49RYuNbqBqEiB2bPWHCggIqbs7xoV 3k/9spmdIc+81eifl5U+YP8mHfgbaNsaG04qReeQm30etkDho0eAKnzf2Lj+/rIP2kor 0E+1YpbA9IobX+9lwUeOqPLvPBxHOOgo1ygGHQPaEWKMl2gxWHAy7LBXKgxqbKl+ZaiD pjzwV9/sEKTdyO1ZTxfhtBGpCv8CE9P/cYzRvmkyf3hc23+bB3ulnc7O6zCUh+NWTlOg YIMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gT5ZMWqhMLp8F0bezIZAaeq0ziq01php0gNe+dgjrw8=; b=R72a2yhh0RYRdMxNfucLlMnaOsrY34GKWD5moFSZ63lWbdEAJIdWH/6tCx6RghCBZr CArOa1JnzJVUmb/CCs8qXWuANmh/hY5JBLjuk3hWhluoCeWdEyJ652a+FJT2Y3pH0X1E /nj0KxBMJT6Bv5hpaYG1Ua093YZ4m4v15eFkv4XF8uhIFhBlLSV932tN8aIe8/lTxJSq vx8/71kqidcX021a3daFCwlx6Jt5oKqzN8pex4UlGrcWuoMFxC7M7wGvEk+0c8u6Dich SJbVzC1/REBKzRQujbQxwRxm3tMT/A5AqPzICBfVEVNb1IybgFvKbt6hKiPUf//JdbCK P0pw== X-Gm-Message-State: AOAM532N8VE0zE4L33ifrVMQVkJXY8TYenrMZmo87FFaONnJSBOpdanW irWK4NLNsPnCwCxmeehXv1SQGw== X-Google-Smtp-Source: ABdhPJxrr8XVDJANfUWlS4utxTq6AOcquqI3l8lxTEYqzeWGWCkf10MDWiYnP6oF1pzIF2Ym4zlbTg== X-Received: by 2002:a92:7f03:: with SMTP id a3mr7408744ild.254.1630084660195; Fri, 27 Aug 2021 10:17:40 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id x21sm874794ioh.55.2021.08.27.10.17.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Aug 2021 10:17:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Brian Rosen In-Reply-To: <0c8729663d2d458994d40a2e6334c3d8@bell.ca> Date: Fri, 27 Aug 2021 13:17:38 -0400 Cc: "Caron, Guy" , Randall Gellens , ECRIT Content-Transfer-Encoding: quoted-printable Message-Id: <63CCAD69-474C-4D7C-9DFB-618446ABF143@brianrosen.net> References: <1120BD41-A143-4AC1-B1A7-6CFF40658FF7@randy.pensive.org> <26184A64-2B40-4230-A09B-9A2D00D5F150@brianrosen.net> <0a255415fb484766990e467518d50ed3@bell.ca> <0c8729663d2d458994d40a2e6334c3d8@bell.ca> To: "Caron, Guy" X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2021 17:17:59 -0000 Good idea. I=E2=80=99ll do it that way: the response contains an ID = which is also present in the Notification. The client still has to = recognize that more than one of its records may have the same ID, but it = is simpler for both, I agree. Brian > On Aug 27, 2021, at 1:10 PM, Caron, Guy wrote: >=20 > Less burden on the Servers too since they would no longer need to = replace the URI. >=20 > Guy >=20 > -----Message d'origine----- > De : Ecrit De la part de Caron, Guy > Envoy=C3=A9 : 27 ao=C3=BBt 2021 13:08 > =C3=80 : Brian Rosen ; Randall Gellens = > Cc : ECRIT > Objet : [EXT]Re: [Ecrit] Problem in -planned-changes: unique records = in LoST server may not match unique records in LIS >=20 > I too prefer the solution with an ID. >=20 > One side benefit to this solution is that the Client no longer needs a = different URI for each location it validates. It only need a generic one = (but specific to itself) since the revalidation request to the Server = will include the ID received in the field of the = notification. >=20 > Less burden on the Clients. We may want to say that. >=20 > I still think we need to change to something like = . >=20 > Thanks, >=20 > Guy >=20 > -----Message d'origine----- > De : Ecrit De la part de Brian Rosen Envoy=C3=A9= : 25 ao=C3=BBt 2021 17:58 =C3=80 : Randall Gellens = Cc : ECRIT Objet : [EXT]Re: = [Ecrit] Problem in -planned-changes: unique records in LoST server may = not match unique records in LIS >=20 > Yeah, of the two options, I like the second. I would like to wait to = here from Guy, who didn=E2=80=99t like either. >=20 > Either of the two I came up with can be added quickly to the doc. >=20 > Brian >=20 >=20 >> On Aug 25, 2021, at 5:56 PM, Randall Gellens = wrote: >>=20 >> Either approach would work: the server returning the prior URI if it = replaces it, or the server always returning a "unique location ID" = whenever it stores a URI. In the latter case, we'd want to add this ID = to the object. The latter seems a bit cleaner, as = then the server always returns an ID, and a client always stores this ID = whenever it sends a URI, and uses the ID to re-validate locations when = it gets a object. >>=20 >> --Randall >>=20 >> On 24 Aug 2021, at 13:08, Brian Rosen wrote: >>=20 >>> I realized we have a problem with -planned-changes. The text notes: >>> Each client of the server may only store one URI against a location, = where =E2=80=9Clocation=E2=80=9D is defined by policy at the server, = since a given unique location may have many combinations of location = elements that resolve to the same location. If the server receives a = =E2=80=98uri=E2=80=99 for the same location from the same client, the = URI in the request replaces the URI it previously retained. >>>=20 >>> But this means that multiple records in the LIS may be one record in = the LoST server and when the LIS associates unique URIs with what it = thinks is multiple records, only one is retained and it doesn=E2=80=99t = know that. >>>=20 >>> The easiest fix is to return the replaced URI. The client would = then be able to spot that the records are linked and do the book keeping = to track what it should do. >>> Another way to fix this is to return a unique ID of the record in = the LoST server when you use the extension. The LIS can then keep an = internal record of all the related entries it has that are one record to = the server. >>>=20 >>> Brian >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = --------------------------------------------------------------------------= ---- > External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints = _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = --------------------------------------------------------------------------= ---- > External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints From nobody Fri Aug 27 10:24:02 2021 Return-Path: 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 5F8093A1C61 for ; Fri, 27 Aug 2021 10:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=bell.ca 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 SCwsO8EyNs-k for ; Fri, 27 Aug 2021 10:23:53 -0700 (PDT) Received: from ESA2-Wyn.bell.ca (esa2-wyn.bell.ca [67.69.243.180]) (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 AE33A3A1C5E for ; Fri, 27 Aug 2021 10:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1630085033; x=1661621033; h=from:to:cc:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=PE3CuPpTH8MeE27GufqdOui0XuY/yWnsh4nAo5kUiuQ=; b=d3YekMS5Z9CrxZ1i+x1GMWgfGsF473Y4XueDxHCeZxnuleQoEuHcpfeB 5oz5/ZWLzan2AihLC/4JGKvpd6m0k2tcPsMIORVjijLRcV20mBjhnZZWU R4LospoUHojPAtZMh/RGSFfJwjM0joSMEI5/Jmj5o7zuIYIA1gOOvtCAC F6kg60J8CAldtL0ZnA8uYa7jffr2SlhGNt1j7afwjKGVYd6myd7ilz5nx RQFjBJJikZKe4IUU7KhKZjy4RGvW8O/8h9ZgQILBoPER6llMAj6IrjqB3 YIYuX0lS++kZzpjhf/pPa4rOUsCM0xwEv6QLRux2eszNKx+ldqT+PjZe3 A==; IronPort-SDR: IHhZZtmjMaT/S8Bg+LQ7AHiqQMJhCke6PtannblNwmy7HpJAKaHyMSKl7x2O85kLzaQMb+EKRP HALePihY6UiA== Received: from dm5czo-d01.bellca.int.bell.ca (HELO DG6MBX02-WYN.bell.corp.bce.ca) ([198.235.102.33]) by esa02corp-wyn.bell.corp.bce.ca with ESMTP; 27 Aug 2021 13:23:52 -0400 Received: from DG12MBX03-WYN.bell.corp.bce.ca (142.182.18.48) by DG6MBX02-WYN.bell.corp.bce.ca (142.182.18.37) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Fri, 27 Aug 2021 13:23:51 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX03-WYN.bell.corp.bce.ca (142.182.18.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Fri, 27 Aug 2021 13:23:51 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Fri, 27 Aug 2021 13:23:51 -0400 From: "Caron, Guy" To: Brian Rosen CC: "Caron, Guy" , Randall Gellens , ECRIT Thread-Topic: [EXT]Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS Thread-Index: AQHXmfwhRqgqGYN29EukUdmptVZv5auFB74AgAKN/vCAAALPQIAARWkA//+9L8A= Date: Fri, 27 Aug 2021 17:23:51 +0000 Message-ID: References: <1120BD41-A143-4AC1-B1A7-6CFF40658FF7@randy.pensive.org> <26184A64-2B40-4230-A09B-9A2D00D5F150@brianrosen.net> <0a255415fb484766990e467518d50ed3@bell.ca> <0c8729663d2d458994d40a2e6334c3d8@bell.ca> <63CCAD69-474C-4D7C-9DFB-618446ABF143@brianrosen.net> In-Reply-To: <63CCAD69-474C-4D7C-9DFB-618446ABF143@brianrosen.net> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.65] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2021 17:24:01 -0000 WWVzLiBUaGUgQ2xpZW50IHJlcXVlc3Rpbmcgbm90aWZpY2F0aW9uIG9mIHBsYW5uZWQgY2hhbmdl cyBvbmx5IG5lZWRzIHRvIHN0b3JlIHRoZSBJRCBhZ2FpbnN0IGxvY2F0aW9ucyBpdCB2YWxpZGF0 ZXMuDQoNClRoYW5rcywNCg0KR3V5DQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXC oDogQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0PiANCkVudm95w6nCoDogMjcgYW/Du3Qg MjAyMSAxMzoxOA0Kw4DCoDogQ2Fyb24sIEd1eSA8Zy5jYXJvbkBiZWxsLmNhPg0KQ2PCoDogQ2Fy b24sIEd1eSA8Zy5jYXJvbj00MGJlbGwuY2FAZG1hcmMuaWV0Zi5vcmc+OyBSYW5kYWxsIEdlbGxl bnMgPHJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmc+OyBFQ1JJVCA8ZWNyaXRAaWV0Zi5vcmc+DQpP YmpldMKgOiBbRVhUXVJlOiBbRWNyaXRdIFByb2JsZW0gaW4gLXBsYW5uZWQtY2hhbmdlczogdW5p cXVlIHJlY29yZHMgaW4gTG9TVCBzZXJ2ZXIgbWF5IG5vdCBtYXRjaCB1bmlxdWUgcmVjb3JkcyBp biBMSVMNCg0KR29vZCBpZGVhLiAgSeKAmWxsIGRvIGl0IHRoYXQgd2F5OiB0aGUgcmVzcG9uc2Ug Y29udGFpbnMgYW4gSUQgd2hpY2ggaXMgYWxzbyBwcmVzZW50IGluIHRoZSBOb3RpZmljYXRpb24u ICBUaGUgY2xpZW50IHN0aWxsIGhhcyB0byByZWNvZ25pemUgdGhhdCBtb3JlIHRoYW4gb25lIG9m IGl0cyByZWNvcmRzIG1heSBoYXZlIHRoZSBzYW1lIElELCBidXQgaXQgaXMgc2ltcGxlciBmb3Ig Ym90aCwgSSBhZ3JlZS4NCg0KQnJpYW4NCg0KPiBPbiBBdWcgMjcsIDIwMjEsIGF0IDE6MTAgUE0s IENhcm9uLCBHdXkgPGcuY2Fyb25AYmVsbC5jYT4gd3JvdGU6DQo+IA0KPiBMZXNzIGJ1cmRlbiBv biB0aGUgU2VydmVycyB0b28gc2luY2UgdGhleSB3b3VsZCBubyBsb25nZXIgbmVlZCB0byByZXBs YWNlIHRoZSBVUkkuDQo+IA0KPiBHdXkNCj4gDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0t LQ0KPiBEZSA6IEVjcml0IDxlY3JpdC1ib3VuY2VzQGlldGYub3JnPiBEZSBsYSBwYXJ0IGRlIENh cm9uLCBHdXkgRW52b3nDqSA6IA0KPiAyNyBhb8O7dCAyMDIxIDEzOjA4IMOAIDogQnJpYW4gUm9z ZW4gPGJyQGJyaWFucm9zZW4ubmV0PjsgUmFuZGFsbCANCj4gR2VsbGVucyA8cmcraWV0ZkByYW5k eS5wZW5zaXZlLm9yZz4gQ2MgOiBFQ1JJVCA8ZWNyaXRAaWV0Zi5vcmc+IE9iamV0IA0KPiA6IFtF WFRdUmU6IFtFY3JpdF0gUHJvYmxlbSBpbiAtcGxhbm5lZC1jaGFuZ2VzOiB1bmlxdWUgcmVjb3Jk cyBpbiBMb1NUIA0KPiBzZXJ2ZXIgbWF5IG5vdCBtYXRjaCB1bmlxdWUgcmVjb3JkcyBpbiBMSVMN Cj4gDQo+IEkgdG9vIHByZWZlciB0aGUgc29sdXRpb24gd2l0aCBhbiBJRC4NCj4gDQo+IE9uZSBz aWRlIGJlbmVmaXQgdG8gdGhpcyBzb2x1dGlvbiBpcyB0aGF0IHRoZSBDbGllbnQgbm8gbG9uZ2Vy IG5lZWRzIGEgZGlmZmVyZW50IFVSSSBmb3IgZWFjaCBsb2NhdGlvbiBpdCB2YWxpZGF0ZXMuIEl0 IG9ubHkgbmVlZCBhIGdlbmVyaWMgb25lIChidXQgc3BlY2lmaWMgdG8gaXRzZWxmKSBzaW5jZSB0 aGUgcmV2YWxpZGF0aW9uIHJlcXVlc3QgdG8gdGhlIFNlcnZlciB3aWxsIGluY2x1ZGUgdGhlIElE IHJlY2VpdmVkIGluIHRoZSA8bG9jYXRpb25JbnZhbGlkYXRlZD4gZmllbGQgb2YgdGhlIG5vdGlm aWNhdGlvbi4NCj4gDQo+IExlc3MgYnVyZGVuIG9uIHRoZSBDbGllbnRzLiBXZSBtYXkgd2FudCB0 byBzYXkgdGhhdC4NCj4gDQo+IEkgc3RpbGwgdGhpbmsgd2UgbmVlZCB0byBjaGFuZ2UgPGxvY2F0 aW9uSW52YWxpZGVkPiB0byBzb21ldGhpbmcgbGlrZSA8bG9jYXRpb25JbXBhY3RlZD4uDQo+IA0K PiBUaGFua3MsDQo+IA0KPiBHdXkNCj4gDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0K PiBEZSA6IEVjcml0IDxlY3JpdC1ib3VuY2VzQGlldGYub3JnPiBEZSBsYSBwYXJ0IGRlIEJyaWFu IFJvc2VuIEVudm95w6kgOiANCj4gMjUgYW/Du3QgMjAyMSAxNzo1OCDDgCA6IFJhbmRhbGwgR2Vs bGVucyA8cmcraWV0ZkByYW5keS5wZW5zaXZlLm9yZz4gQ2MgDQo+IDogRUNSSVQgPGVjcml0QGll dGYub3JnPiBPYmpldCA6IFtFWFRdUmU6IFtFY3JpdF0gUHJvYmxlbSBpbiANCj4gLXBsYW5uZWQt Y2hhbmdlczogdW5pcXVlIHJlY29yZHMgaW4gTG9TVCBzZXJ2ZXIgbWF5IG5vdCBtYXRjaCB1bmlx dWUgDQo+IHJlY29yZHMgaW4gTElTDQo+IA0KPiBZZWFoLCBvZiB0aGUgdHdvIG9wdGlvbnMsIEkg bGlrZSB0aGUgc2Vjb25kLiAgSSB3b3VsZCBsaWtlIHRvIHdhaXQgdG8gaGVyZSBmcm9tIEd1eSwg d2hvIGRpZG7igJl0IGxpa2UgZWl0aGVyLg0KPiANCj4gRWl0aGVyIG9mIHRoZSB0d28gSSBjYW1l IHVwIHdpdGggY2FuIGJlIGFkZGVkIHF1aWNrbHkgdG8gdGhlIGRvYy4NCj4gDQo+IEJyaWFuDQo+ IA0KPiANCj4+IE9uIEF1ZyAyNSwgMjAyMSwgYXQgNTo1NiBQTSwgUmFuZGFsbCBHZWxsZW5zIDxy ZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnPiB3cm90ZToNCj4+IA0KPj4gRWl0aGVyIGFwcHJvYWNo IHdvdWxkIHdvcms6IHRoZSBzZXJ2ZXIgcmV0dXJuaW5nIHRoZSBwcmlvciBVUkkgaWYgaXQgcmVw bGFjZXMgaXQsIG9yIHRoZSBzZXJ2ZXIgYWx3YXlzIHJldHVybmluZyBhICJ1bmlxdWUgbG9jYXRp b24gSUQiIHdoZW5ldmVyIGl0IHN0b3JlcyBhIFVSSS4gIEluIHRoZSBsYXR0ZXIgY2FzZSwgd2Un ZCB3YW50IHRvIGFkZCB0aGlzIElEIHRvIHRoZSA8bG9jYXRpb25JbnZhbGlkYXRlZD4gb2JqZWN0 LiAgVGhlIGxhdHRlciBzZWVtcyBhIGJpdCBjbGVhbmVyLCBhcyB0aGVuIHRoZSBzZXJ2ZXIgYWx3 YXlzIHJldHVybnMgYW4gSUQsIGFuZCBhIGNsaWVudCBhbHdheXMgc3RvcmVzIHRoaXMgSUQgd2hl bmV2ZXIgaXQgc2VuZHMgYSBVUkksIGFuZCB1c2VzIHRoZSBJRCB0byByZS12YWxpZGF0ZSBsb2Nh dGlvbnMgd2hlbiBpdCBnZXRzIGEgPGxvY2F0aW9uSW52YWxpZGF0ZWQ+IG9iamVjdC4NCj4+IA0K Pj4gLS1SYW5kYWxsDQo+PiANCj4+IE9uIDI0IEF1ZyAyMDIxLCBhdCAxMzowOCwgQnJpYW4gUm9z ZW4gd3JvdGU6DQo+PiANCj4+PiBJIHJlYWxpemVkIHdlIGhhdmUgYSBwcm9ibGVtIHdpdGggLXBs YW5uZWQtY2hhbmdlcy4gIFRoZSB0ZXh0IG5vdGVzOg0KPj4+IEVhY2ggY2xpZW50IG9mIHRoZSBz ZXJ2ZXIgbWF5IG9ubHkgc3RvcmUgb25lIFVSSSBhZ2FpbnN0IGEgbG9jYXRpb24sIHdoZXJlIOKA nGxvY2F0aW9u4oCdIGlzIGRlZmluZWQgYnkgcG9saWN5IGF0IHRoZSBzZXJ2ZXIsIHNpbmNlIGEg Z2l2ZW4gdW5pcXVlIGxvY2F0aW9uIG1heSBoYXZlIG1hbnkgY29tYmluYXRpb25zIG9mIGxvY2F0 aW9uIGVsZW1lbnRzIHRoYXQgcmVzb2x2ZSB0byB0aGUgc2FtZSBsb2NhdGlvbi4gIElmIHRoZSBz ZXJ2ZXIgcmVjZWl2ZXMgYSDigJh1cmnigJkgZm9yIHRoZSBzYW1lIGxvY2F0aW9uIGZyb20gdGhl IHNhbWUgY2xpZW50LCB0aGUgVVJJIGluIHRoZSByZXF1ZXN0IHJlcGxhY2VzIHRoZSBVUkkgaXQg cHJldmlvdXNseSByZXRhaW5lZC4NCj4+PiANCj4+PiBCdXQgdGhpcyBtZWFucyB0aGF0IG11bHRp cGxlIHJlY29yZHMgaW4gdGhlIExJUyBtYXkgYmUgb25lIHJlY29yZCBpbiB0aGUgTG9TVCBzZXJ2 ZXIgYW5kIHdoZW4gdGhlIExJUyBhc3NvY2lhdGVzIHVuaXF1ZSBVUklzIHdpdGggd2hhdCBpdCB0 aGlua3MgaXMgbXVsdGlwbGUgcmVjb3Jkcywgb25seSBvbmUgaXMgcmV0YWluZWQgYW5kIGl0IGRv ZXNu4oCZdCBrbm93IHRoYXQuDQo+Pj4gDQo+Pj4gVGhlIGVhc2llc3QgZml4IGlzIHRvIHJldHVy biB0aGUgcmVwbGFjZWQgVVJJLiAgVGhlIGNsaWVudCB3b3VsZCB0aGVuIGJlIGFibGUgdG8gc3Bv dCB0aGF0IHRoZSByZWNvcmRzIGFyZSBsaW5rZWQgYW5kIGRvIHRoZSBib29rIGtlZXBpbmcgdG8g dHJhY2sgd2hhdCBpdCBzaG91bGQgZG8uDQo+Pj4gQW5vdGhlciB3YXkgdG8gZml4IHRoaXMgaXMg dG8gcmV0dXJuIGEgdW5pcXVlIElEIG9mIHRoZSByZWNvcmQgaW4gdGhlIExvU1Qgc2VydmVyIHdo ZW4geW91IHVzZSB0aGUgZXh0ZW5zaW9uLiAgVGhlIExJUyBjYW4gdGhlbiBrZWVwIGFuIGludGVy bmFsIHJlY29yZCBvZiBhbGwgdGhlIHJlbGF0ZWQgZW50cmllcyBpdCBoYXMgdGhhdCBhcmUgb25l IHJlY29yZCB0byB0aGUgc2VydmVyLg0KPj4+IA0KPj4+IEJyaWFuDQo+Pj4gDQo+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBFY3JpdCBtYWls aW5nIGxpc3QNCj4+PiBFY3JpdEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZWNyaXQNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IEVjcml0IG1haWxpbmcgbGlzdA0KPiBFY3JpdEBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gLS0tLS0tLS0gRXh0ZXJuYWwgRW1haWw6IFBsZWFzZSB1c2UgY2F1dGlvbiB3 aGVuIG9wZW5pbmcgbGlua3MgYW5kIA0KPiBhdHRhY2htZW50cyAvIENvdXJyaWVsIGV4dGVybmU6 IFNveWV6IHBydWRlbnQgYXZlYyBsZXMgbGllbnMgZXQgDQo+IGRvY3VtZW50cyBqb2ludHMgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRWNyaXQgbWFp bGluZyBsaXN0DQo+IEVjcml0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZWNyaXQNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0tLS0tLSBFeHRlcm5hbCBF bWFpbDogUGxlYXNlIHVzZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQgDQo+IGF0dGFj aG1lbnRzIC8gQ291cnJpZWwgZXh0ZXJuZTogU295ZXogcHJ1ZGVudCBhdmVjIGxlcyBsaWVucyBl dCANCj4gZG9jdW1lbnRzIGpvaW50cw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkV4dGVybmFs IEVtYWlsOiBQbGVhc2UgdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxpbmtzIGFuZCBhdHRhY2ht ZW50cyAvIENvdXJyaWVsIGV4dGVybmU6IFNveWV6IHBydWRlbnQgYXZlYyBsZXMgbGllbnMgZXQg ZG9jdW1lbnRzIGpvaW50cw0K From nobody Fri Aug 27 13:09:31 2021 Return-Path: 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 2E0AC3A1466 for ; Fri, 27 Aug 2021 13:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=bell.ca 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 RbgudjhfDhtI for ; Fri, 27 Aug 2021 13:09:22 -0700 (PDT) Received: from ESA2-Wyn.bell.ca (esa2-wyn.bell.ca [67.69.243.180]) (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 2EC9D3A142A for ; Fri, 27 Aug 2021 13:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1630094962; x=1661630962; h=from:to:subject:date:message-id:mime-version; bh=fphn+zIQ+xtlX4dgSWc9C4HAlGi0MyJMv+J0etG5PkA=; b=WgqTKBwtn9wpnODOFJBl+8DHyb9b/9z99Nv+xEsSfpba1LqhgAcfwHtE R6x8P5Ff68xSgXFZuvcX2Bkn+LCuFXwp4jsAZZQdq8RVCKVExYthRDsFF k6aTs+VlCJxWw3p7om4sDnrO1Or6Y8UiO3Z5JiVc9/8yNCqWwMjY276gA tzI1fA16D5j+mxb+E+yJyxGInjupXmxz0zXhvYhgNYVBp2lMhRzTheQHF j6FNhfiPa/YVXH8p1APsLs7hbTDAhu1n3mjRiRn7/Xhp99IQ2T2vbShtz QbQ71jFCIEfjH05Sz5cHGQlEtTd5IwU/EH4sYNk2/VWCFN2lIlpxYWFnk Q==; IronPort-SDR: ZLAY+s6Sho9nx84hm3Ffl6mnKnkIbjTM2ooLHUl5TME8KhZHhOWARKLsqTPOASbeKHw1Vwamm/ PyYiC0lwNBtA== Received: from dm5cch-d01.bellca.int.bell.ca (HELO DG3MBX02-WYN.bell.corp.bce.ca) ([198.235.102.31]) by esa02corp-wyn.bell.corp.bce.ca with ESMTP; 27 Aug 2021 16:09:19 -0400 Received: from DG12MBX04-WYN.bell.corp.bce.ca (142.182.18.49) by DG3MBX02-WYN.bell.corp.bce.ca (142.182.18.24) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Fri, 27 Aug 2021 16:09:19 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX04-WYN.bell.corp.bce.ca (142.182.18.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Fri, 27 Aug 2021 16:09:18 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Fri, 27 Aug 2021 16:09:18 -0400 From: "Caron, Guy" To: ECRIT Thread-Topic: similar-location-09: GCaron Review Thread-Index: Adebe1KGR57xvilqQAOgCtIx5j1+GgABAJmw Date: Fri, 27 Aug 2021 20:09:18 +0000 Message-ID: <6fdb8f42317d4dfc99783a4d834b6c85@bell.ca> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.65] Content-Type: multipart/mixed; boundary="_004_6fdb8f42317d4dfc99783a4d834b6c85bellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Ecrit] TR: similar-location-09: GCaron Review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2021 20:09:29 -0000 --_004_6fdb8f42317d4dfc99783a4d834b6c85bellca_ Content-Type: multipart/alternative; boundary="_000_6fdb8f42317d4dfc99783a4d834b6c85bellca_" --_000_6fdb8f42317d4dfc99783a4d834b6c85bellca_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Resending to the ECRIT list. Guy De : Caron, Guy Envoy=E9 : 27 ao=FBt 2021 16:01 =C0 : 'draft-ietf-ecrit-similar-location@ietf.org' Objet : similar-location-09: GCaron Review Hi, I reviewed this document and think it is mostly in good shape. I have a few= comments to offer: 1. The document does not use a convention to express XML types such a= s for elements, 'boobooboo' for attributes, "heyheyhey" for val= ues, etc. in the text. Should it? 2. The document defines terms in section 2, which are spelled with ca= pital first letters however, when used in the text after section 2, a numbe= r of instances do no use the same style and should. 3. Section 2, in the Invalid Location definition, the term locationIn= valid is used however, there is no defined element in here or anywhere else= . Was that suppose to refer to lost-planned-changes ? 4. Section 2, the Similar Location definition says "A suggested civic= location that is comparatively close to the civic location which was input= ". Comparing what? Geographic proximity, semantically close, else? 5. For completeness, it would be nice to include the 'similarLocation= sLimited' attribute in the example in section 5.2. 6. There are two errors in the XML schema in section 6: a. xmlns=3D"urn:ietf:params:xml:ns:lost-rli1=E2 should be xmlns=3D"ur= n:ietf:params:xml:ns:lost-rli1" b. should be 7. The reference to planned-changes in section 9.1 should be updated I'm trying to attach a MSWord version with track-change here that includes = resolutions to 2 and 5, with additional proposed editorial and non-subtativ= e changes. If it does not pass the mail server, I will send directly to the= authors. Thanks, Guy --_000_6fdb8f42317d4dfc99783a4d834b6c85bellca_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Resendi= ng to the ECRIT list.

&n= bsp;

Guy

 

De : Caron, Guy
Envoy=E9 : 27 ao=FBt 2021 16:01
=C0 : 'draft-ietf-ecrit-similar-location@ietf.org' <draft-ie= tf-ecrit-similar-location@ietf.org>
Objet : similar-location-09: GCaron Review

 

Hi,

 

I reviewed this document and= think it is mostly in good shape. I have a few comments to offer:

 

1= .   &= nbsp;   The document does not u= se a convention to express XML types such as <blablabla> for elements= , ‘boobooboo’ for attributes, “heyheyhey” for value= s, etc. in the text. Should it?

2= .   &= nbsp;   The document defines te= rms in section 2, which are spelled with capital first letters however, whe= n used in the text after section 2, a number of instances do no use the sam= e style and should.

3= .   &= nbsp;   Section 2, in the Inval= id Location definition, the term locationInvalid is used however, there is = no defined element in here or anywhere else. Was that suppose to refer to l= ost-planned-changes <locationInvalidated>?

4= .   &= nbsp;   Section 2, the Similar = Location definition says “A suggested civic location that is comparat= ively close to the civic location which was input”. Comparing what? G= eographic proximity, semantically close, else?

5= .   &= nbsp;   For completeness, it wo= uld be nice to include the ‘similarLocationsLimited’ attribute = in the example <findServiceResponse> in section 5.2.

6= .   &= nbsp;   There are two errors in= the XML schema in section 6:

a= .   &= nbsp;   xmlns=3D"urn:ietf:= params:xml:ns:lost-rli1=E2 should be xmlns=3D"urn:ietf:params:xml:ns:l= ost-rli1"

b= .   &= nbsp;   <xs:minInclusive val= ue=3D"1"> should be <xs:minInclusive value=3D"1"/= >

7= .   &= nbsp;   The reference to planne= d-changes in section 9.1 should be updated

 

I’m trying to attach a= MSWord version with track-change here that includes resolutions to 2 and 5= , with additional proposed editorial and non-subtative changes. If it does = not pass the mail server, I will send directly to the authors.

 

Thanks,

 

Guy

--_000_6fdb8f42317d4dfc99783a4d834b6c85bellca_-- --_004_6fdb8f42317d4dfc99783a4d834b6c85bellca_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="draft-ietf-ecrit-similar-location-09 GCaron.docx" Content-Description: draft-ietf-ecrit-similar-location-09 GCaron.docx Content-Disposition: attachment; filename="draft-ietf-ecrit-similar-location-09 GCaron.docx"; size=49144; creation-date="Fri, 27 Aug 2021 19:14:05 GMT"; modification-date="Fri, 27 Aug 2021 19:58:32 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQCEnxmUuwEAAD8KAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADE lk1u2zAQhfcFegeB28Kik0VRFJazSNtlG6DuAWhyZAsROQQ5TuLbd2T9oCgc06lNdCNA4rz3PnIo gou7F9sWTxBig64SN+VcFOA0msZtKvFr9W32SRSRlDOqRQeV2EMUd8v37xarvYdYsNrFSmyJ/Gcp o96CVbFED45HagxWEb+GjfRKP6oNyNv5/KPU6AgczajzEMvFF6jVrqXi6wt/7kkCtFEU931hl1UJ 5X3baEU8Lp+c+StlNiSUrDzUxG3j4wcuEPJoQjfyesCg+8FLExoDxYMK9F1ZrpLPGIw0qHeWleVp myOcWNeNhknfufmAGmLkNbdtOY1Y1biR/1UOt7NrCKy8PshknYSItG8hXp+g903HAxELcgAMzkmE Z1j/zEbxh3kSpEYkh5SjG5N1EgKcycQwOicRtqAMhJvrE/TGZ/UhS35vnMzXaDt9hhaMzmcjHM5c AyYfyphwZldu/1tXao5cqXULOQgG6ySEB/Q5CHrfZDzxHQH65+W/x8HmVCRXPgT0kXdj+Ic5j5eK Tj3j2XoI1Jw+fqZEtr54fjDs7Ldm610ktBfH9zZHwuXh+rf8DQAA//8DAFBLAwQUAAYACAAAACEA mVV+Bf4AAADhAgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKySTUsDMRCG74L/Icy9O9sqItLdXkTo TWT9AUMy+4GbD5Kptv/eKIou1LWHHjN558kzQ9abvR3VK8c0eFfBsihBsdPeDK6r4Ll5WNyCSkLO 0OgdV3DgBJv68mL9xCNJbkr9EJLKFJcq6EXCHWLSPVtKhQ/s8k3royXJx9hhIP1CHeOqLG8w/mZA PWGqrakgbs0VqOYQ+BS2b9tB873XO8tOjjyBvBd2hs0ixNwfZcjTqIZix1KB8foxlxNSCEVGAx43 Wp1u9Pe0aFnIkBBqH3ne5yMxJ7Q854qmiR+bNx8Nmq/ynM31OW30Lom3/6znM/OthJOPWb8DAAD/ /wMAUEsDBBQABgAIAAAAIQCoTqC87wMAAI8pAAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwu cmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANRaTW/bOBC9L9D/YAjoUZIl +SMu6iSHboEC20ubBfZKSyNLDUUK5KR2/v2S8keUNhZClyYRIAFCKho/k8M3b5708Wbb0NFPELLm bBkk0TgYAct5UbP1Mvj37nN4FYwkElYQyhksg0eQwc31u78+fgNKUN0kq7qVIxWFyWVQIbYf4ljm FTRERrwFpq6UXDQE1VCs45bk92QNcToez2LRjxFcP4s5+lIsA/GlSLJgdPfYwmuC87Ksc/jE84cG GL7wGXGlIglas3sVlIg14C6sVHFRPEgEiGrAsotGVSwmIaxZyQ///pUXCsnfWwTBCA3iE5ivXGHm nMonxG1RxqLM0yRZmAFOZ14BT9M0NQOc6S/oCXAhSImhngohFzWGlEsMW0oYgyLMK8LWIMOxzluT LUi8bsFkPtc5YLIFkwsDbkhNkX+QQBAphIskuYUtaVoKUc4bM7ATnV+eVneVt4leKxO48zeWDNOx I8CbzSZSCEMoauSii6f5uWORpGMFE9RT/6hnVxNdLQxQ+80Nc662evQkPlIlQY5gd+NIxTlZjO3W NiAFiN5ideNkCEDq6myc2DDjY5F6LK5nZdjEVe3U5/gIl4i8qn9CXBevlgQRbtGQoi5dZYf3wpyd ZlaPO6p74QlsN9xNDh45q/nAHpoVCNUQPeE4Tg2BsMo7wArGsc98h5nBdfAoKpXsmRvmTmo12ZVI 1Jd6S3aYGVqyzKNSPK8VcqEH9ty3ybowyWKxiLcVqlU042mXKtEtT09cSUlbaTN15asMKfb53LAx ml7aWdk3nT+gLKOGCKzZrWINhLxCoOZ9p9WsKDnHX4rAcWqwCry13EydeX6WRE/q1/A7o2i4MPye F427b7uSEa6IrPP+38k4KrAw5FvPPYq513DpMr1nLsHXIDR1yYpQ+kfkNTulHps6F1zyEnXMPVqF Mkl+QdkCb2lPvu/Gg1TlSiEUBAkKkt+rxTpubicPlHB8EEJHNFutznP3l5Hmpn/m13E+o8131QsP SBbzZZ56biiMNdbM6hksOcM7surTwHFqiAms7vUGVt8BlZhb97RTb3IIiMdjrVtow2zrnjQ4gWvv cWnHA2/phKRvzYLPPFvQ5oBdtCzP9am6L4n/+/rP9+6TDCuT34bFvCh1DY7nUnrGU8ZLdy17Db0S tytRE6ZELrCIgaEX5LEZPMN0nfr1iJPuCYcJNdiEK39TBYeZwS7FWcGy+E6S1Zqlfaf+Y9DdePgx 6ClKf203eXDv9TdlBRwNgydf/3BlCEZ2aaq2+dpK5oJKXmZpNdS/N++zz7ufMzxxV2+VDVnM5sa4 VcH/8kFJDxka9xHI6/8BAAD//wMAUEsDBBQABgAIAAAAIQBypY1FWm4AAGbmAwARAAAAd29yZC9k b2N1bWVudC54bWzsfely48iZ4P+N2HdAaP9UR+jADVCe1gTFw66J6u7aUrV7vBOOCYiERLhAgAOA Usm//Bp+PT/J5pcHLgJgJhMEWd1tR3RJApDnd5//9u9f16Hy4idpEEffX2jX6oXiR4t4GUTP31/8 /Hl+5V4oaeZFSy+MI//7izc/vfj3u//9v/7t9XYZL7ZrP8oUNESU3r5uFt9frLJsc3tzky5W/tpL r9fBIonT+Cm7XsTrm/jpKVj4N69xsrzRVU3FP22SeOGnKZpv4kUvXnpBh1t85RttmXiv6GMY0LxZ rLwk878WY2jCg1g3oxu3PtB6d2vxxo/Qw6c4WXsZ+jV5vll7yZft5gqNu/Gy4DEIg+wNDanabJj4 +4ttEt3SIa7ypcAnt2Qp9B/2RcIzL/lkSq8Dz3iT+CFaQxylq2CTn+n60NHQwxUb5KVrEy/rkL33 utFMOYCYklspBuRZPr3KdUhW3j2ipnLcCAyRf8GzhOqcbCVrL4iKiQ86mtLhapbYAPrOAHbqiw1h 0SFu0rd1gRqvm2e5W/5jEm83xWiB3Gjvoy/5WECvBMai0FKG4FRuMQ8rb4NQeb24ff8cxYn3GKIV obtX0PUp+AYUwJKLO0RNH+PlG/y7QQ/M242XeO+X318Y1mzqzu3pBf4rokgZ/NWh/0N/vUWUe/np +wtVHY8Myxjlf5r6T942zOCJpaq6auBZNh8T/M9D9haiyW9fvPD7i0mcbNKlD6P7FzfwPPMeU/ov eyn0nzIYfBOnsADdhDdvilfTjbdAW0ZvPPoIGdBGHY0MFkRL9Ff4HjEYXaXf0ZXg/2R3s8mn95/x cPhh6ZH3SFZ0d3/d9DwhwxSz48VesdXRx5hH4ZfQujaJn/rJi39xpzTOePcpTv2o8gjWu3s5jjU2 NW1kDHw5uyetjXhPmp7HKxtdU63aSd29jzI/ifzsChHLp4zjGAzdNIzJbHJuMGrYTv5m8xt2vvt2 KNZ1eD8MgJjols1++bQFXPa2Wdx89LDF4HmFfrNNoxHk4Zyjpb8E8Srbprf80O3g6z4Uuh+wNJcs U/4JDakJPyfe4ks3bn8SwG1Ll1nMD16Srrww7JivhBxSZGT2dROgd24VbcS/u6s6PgpNOfcfk62X vAnMx4DzoPl0Vdfbb7blsv9D4LKvbMnLzoKo8uymkYRZrmup2gSw+7SUHN8GoyZVAvJ6+7cFGwo/ OYy8T+J15i9WyufJA8fBqNpYmxv6/PQsrnIyhM46qoZFjNohZHeaq4y3z9s0UxCAahzbNCbz8dyc 3Uttkz4R2CaD+b+zV/QKbWP7arkafaSP1ZEc2xVf8+7VYBRt2gy7HI7NmDPdNUaWdno4E+b2um65 JXavGZYFv6686BkbUTTLZEhYhdKx8iF++KzAaiIwvyhZrCR+hvRRBUwIIVqogli1kgbrIPQSJYwX WKVXgugpVpYgnV0FfvZ05S+SILuir12x167UKttpPnjH1e/vZ66cgnFUKGJiLA8UacZYn+lyaCwO RTwKzvgxzZAcxCNPO2h1qn1vnvxKNLwVWcy+v1c10+lFO6BPPh5HYTBVk93drjogRBJMB79GKYJj N3Opz6sgVXIjahBlSbzcLvxU8ZTIRyzcewOKsEnil2DpU8qA1IUKGQCjE/mZEBMkEW3iKEWDZCsP DZoqfpCt/ESJn9CwjKwslThRlJywwDAwFXoRPQgQ2fJCNOJmmymL4CVY5FNeKo9eCl9HyuvKx+Oi YwzwcEFEfiRfeMslWgqaPfRhd2hPSWkLr2hNaMUw3xM6twckxAUL/xNdewVF2H8apUNiYShJN0LS 4Rot0Hv2rxufMmm1ecTq1S19tAt8b/xLz+0nBy0dwQf/VIbUVDl76piwL42JwmADTCj0ssqggwEe oUcWL+JQ+a/akKu3jZ8gRP2iJLcBojjJ+6WDqUV54ehDBLp08Sr633xel5c/zSeWXtNybkrDl5b/ V4J0fgSGPsDA+hpzBl9baxClaBGwSmw4QERlFSeIhHkJ4Nwft2/w16WXAQVCAu2V6l7pzmfNuDWd W1X9f8W22o4bnViAkJBRh/pm0Px7hyhTj0YcV1I/A1KC3iSUgFGN2maXfkg3i2WtwzZLOcHUx/dW 4gVo9M8IZFs2UT4A+mbpGNBf9h3DJZbI4ggIpbJGXFJJt8/PfgqngvafAp1tlNcYoYYDar19bGoS OBCX6/a9qDoj34Uzet56e5gdH+f27gBtGu6o69M280bNWtQNH4JzsldzrtsJV8U9g2jHfXTWrVq6 Z7oWLC+5M0t3Z/jv2V3VolXccTErVkskoOuuCZ/rwHR3rXxeofNUsldEzBGRxChRIRjAKbE08OQn CcIbRBW9XE65yFUfhj4XgGoXdaS6IJgIAwXRItyCIdUDFgzfB8T3CTNPxrAIuO5CFinxEP9rkGYA L5hQdzEeJL5vF4h21+SFm0ah15iqs4k5lTOb9CLC96BVOeOxYWsaKLnnplU9YNM53DOWyH7w1zHH 7djuVJ1Op6e3nFD/hJQZSJ9PJ6Z+QtOlhGakWS7bqaAVE1931VMFyk66fVwHGTBjhN9P2zBE5IAw 32hBZMcaOyvPt2N6psjTsQ4B6Xb/ppoHAyqFdUCQwTGo10ZvEHRdfJPlaVsE3e5Dvp98VBy3jlC7 kq/EHAMcILCJ/UdGMLmfI9uxu7UeWddQPHxGn8/HCMtPbyrqw3pn2BPLdkdD85l9ZiHdJR7H9jcs jVjK4L6GMBxV6R6Rpl7j5AtMyIwSmFIA7WAvKzOwR/t+Am999tJGj2ybEH041mZ38zhZCNh05CZ7 9372ef5dFXXYw9wB+WOMxEusqsdY5nyGCKRUWXsiflNNylHrhWlVUjnimSyRiJsEj9us6xZySjSS 8vXvgCH/JqXc+p7ARJYrM1MN+faAGtKFlBCdP8JG/gVqqpRdc7FFalVU9TR0zidnIMwPhAe6JA2E lOAhSc8T2B8Ws4WnbBASEJmvT8VhQYQIwvT25gYp2R74gL74yTX47Vi4KtrRDb2zm8oabprNjFWQ u2nkpebMHNvW+PQKKHXb7woGAi4kzdHvp/dzsI6dk2CgGSqjJK1s38amHjG23xwwxiExNskFGL5K UsELNuoRM+3a+xqst2tis/zKj09XDnUMDiXY363jKFul2OKDuLTy6CvbDdislpdK4m9CNAv6Ce0p fkxjYqJ+fKPMvdg64vde9KZkwbrZ57N/HTlZf4+1zSDyNkg12ySBBwJFrGzTQt6ilyBwqiaGpgFP VYRpXg29OGwe9KNO0bEftsIDf+iC0S2HAGPonhcBFiD9NYUxJEtGYH28APFHqUWcdR/r0EaGOwSw z2CFvb6oDHDTSHlVd6w5c8kI56OyESH9cuzMnAmYwU9lxwRCv0vam81Zr0EYKj6OIQWHuzZSWHQn RLXpVRLWvGNbdwxTw6rnryCSxBmPZs5Ig0Wemx16Em/eMPdWkG4Z1GhW8270yci9NyanR60+jNAO WofqDO4i2Gu6cQwmSvUqoeEYv1044KC+BaC8W3yHo1MVsFgon5NtCuLJEttskMyfgrE3WCLBJXgK sG9LhKngeQdkKrBoJmgJrJORheEkHuz9bFba93+ei39jRJnxLYpcCiEdg0pQeIAlD6dQdWumjeZD cwopomPPNXvkTORihgdes6VO3PuRIyeD9EH1qUl7ZzNaxTjWvRlj7szduTY+N6o/YpmHAumLPFwe 5wVeitC3w/E7u/OFKKnMTF7YSBALekczmX6ziUzw9//66D2LuDGk7JzaXyt/B0iEBzWz2P1YG4+n s4HRT0C6z9NzKsSE7nITLDK8ci9aIKaMCYo1cub3LrivX7BIpoDh9b+/gl31v1NN1W0oRvEGYhrC 4wBifG49MPlsM/8Pf79COOx/vdUtzbYQhrt/WKfx1Wviba7AAwIRAFeA37dqwwPMzekTNvQVWlXw 9zjKvPCKlFN48dHhP/sXylMSryH8eJNdjq5Va4NISxZDaqJV+kuaJfEX/9UnMuO1baM/oo1r6i3M jYOjvr/I4s04Wt7HWRavLxRyFF/R9mAaODtyDuTw0IF1Q4Ru6ubUnfdt9d1zr+iJv8g+Jg3DY2iG +Cv64QKdZhBt421KIGbz/ACDvsKQIxUHv67Qz7ZLIvHhhR88GBgdE7xjlhNrNd3Fvz7iwwNHLf6V 0nCDDud7Sz9Bh0Bycp/iOCv9+rzN8K90tkUcQrAcxVJ4h2yT7G8vOzTHljNWh3bG78ojIhkz96Z9 P56fQa5Ja6SaiBpqOLO5JqlT9y+Q2Ppor6PA6s1R0MJpatkmOFbqbwiuwZ5ZY0JNni8NH0iZHHB4 vvoJIDqUiTJtulCw//WPf6bKB//ZC5WPRUjVJ0zb0WWgk8Dvsto3qfKO42T0Q06G+QQzWJbvF/7A wQ+raUs0olpsS2Gw8KPUv4Jo9/27yO6+gxg9/+kJYBCSH8GEAH6U+EnZbB/RaHkMb1YG3WvlY+h7 KcQPvwT+K3yXFsaHVFl4iQ+Rf2+XYJFHT9+UpZ8ukuDRV97ibUIVd2xrQYeSJYirYjCA6ED4y4Yg RRNMtQnfckkvaHcCk8mFgrBDbHycy7qTeCki6mpSoRuTeL2Joz2xIrmdQyo8pfldRMghM9NfYrGu Cm3KGuxyNMJceQjWm5DY4+4fpsoHAvEKsAIANgZnOPr0wcdwpZjXGKQBvDkwj9QCKu+cA/OI8bBO 1/bj4PHILnieaeIiyfaLt0jW95LEi7K3naOCs6kerQg+SCEEvcIqPtw0Che2q07vZ1M590MfohL1 xErJfY5uzR1dP8eY/s+QPYdTN2KokFMjC83bsfTxvWXOQKY/3nY+osmekea28pc+xHTRPUXbNXk7 CF8gN4qgUf7sPeyY3A/dbv7BPrkR6iEwAbPlhd3IVFIaBJ8y0XyWcfGBazvtDpHcNGjRaF5yW3kh A9OhboVuulFRFCvUunbVddJOTdjt3wMYvKdp0g2JheVBuYO3O2fLGeJO+meTOUabmaprH9e9/JuB QTroOYLgZz9ZBxGa+bnLPNkzBBocEOiYun7vGMeNk/utQCAR6vuAwGa+XIWWLnj76QWJMKDqIJ74 iZZQ6AC8moBE3fsdE4h7HbtW+6E567tjhfT2Blvh+yId+xD85cFWkwdb9el4bh255NFvBlsrtUZP ia3iGEpj284YQ4de4QAY6nBgqGWpum7MfsfQXxeGzr56UGKgy9wkBVo7Bu/G/AzdMR0XgOg8QIve jhxoaaZOVceON/YU5XVVl4J56xsWUVAFwI1aHPLJd6BEFqbAiImrVjDiquTFriDX4s+QdcFPb/NY sTPmCSTAYcAlgml+X3kwDuy8lvyeB7stYzafjYzjVk09Y+zuxkx8tNyY2b/+/kBLyTSj6ntS90gE EeipCK1CPtTzAIRuhlbDmpqqLllItheveQ9SBhVVm4CrBjtcFGW/byQnDJrKcda65pgzY3w+fP+b Finp4k8vUv7nDx/4CcbQ2tQDbl0iDuR8/FDjsUxqE3Nmmdb0d7D/VYH9g7/YJkEmEKU7NOxPEH0P 0DGTXlhHwwGLAwdUU3X0qWQy3u840CREnpmLcvzjmB8jSEDPmUmP8mhzmJeLC5F03danE/e4aSff iu3kaK5Wh0R1nRaVhOSqs8SkvcLXt7CJT/4z1JA62CB/RGJgWveG5Y5+s6aW3xAxgBK9V58+vP/G kelHb+3j4X8nCsciCurEur93fxe1eyEJ5xMI84mVBDqeImdzQJeBgMuxzePWIfntsJwWx/ABLEcW vn4kQQcvApR5aHvGmaCAY9xb4ym63N9R4NeFAnnkze9IsBcJtPvJRBubxzVqD+U3q9jTiN+suVhZ i6xYvp8xqbLzr3/8kx+G2kRcKSDqXCRrRnIIDHUMXMAQT4iZqmqjyWhqSsHQMevBCKVfu7bq6LPj OpJlxW5WuoCbK1gjKui2v1APRxpGVBZT11oTZ5rvUnd0azI7gwLC/ZQOVB17as2GLpWyD7Sg/lsr aWaFAfBa+uo4WepIV6N7RZ8oPJJUn6g6fFU7RC34uvVpVjFmN+KUwVyoXV+63WziJCOt+l4g7CfP Oa82vqy0cPOg8u9mm11CkWGS5Qo35uEGeOjT0kCIwyDgUVLSpghdGGS1txWgK1gH3BOtCA41hZ+2 YQSN9mgaMV21SIi5XFF/9C7/VIYE287uWI+uripbJbonlXh/gS/q4lK5oL3uaE+xi220WPmLL/6y WiK33PwO0wwBHBkJNL/Dez+oOyGU9QiDdYALYz/6Cw8Bj/K6CkJcrfhN8b3FKm8o6wFUY4CkII/P IMjeSHXw6A23OcwxgHV5VEibNURZMbADQL6uYjRDpcfbJX6w9heICQbpmlTLTrdPT8EiIKMEUQl3 aPM3+Cbv/0axqaWfLG7fkXfYxPtPoNlT5qF5SC3wpzJyhlBbF8pL0H6NuOTDu1WAxvoOF4qI4aDQ 8VTnw+vO/Ajy2NGx8KPBlcaEgoNgc8uXk66N5qP5eHLGZf4FctJ1W3NcZ3y6emYSHNclQetsg/k9 /kLbJAOkNnVUBgDDeKc8omfrIE1hKSVug0GZ9eJcbnGZefYa8EJEeSrvo3dwhx/KoarFLCjqA/4W qFl0nS9avFaRT9lFPyARiPillG2WFimAIlXdQhRFFh5S3niQxJ7fT2bWfd91QgXgprM+GqlQlts0 0FukMtySTH5RkoiodYoUMeP6glqrBOus2XZnnTWLlGGj0bW1QmuaaVUqrekGOZdaqbXN84/b9WdS Gg6JR0mWq6ALuSJsk4k5mmhDK9RShM+ajs2ROh+6kO0uFW+tLMIMSBybUadIYR6rZ2AVq6pae7u4 GRYrm932hoNgfa+61mOfN1yyzY9WUKES02/aH72kYDz5HvSkZS1tsTAUQKPv/9kG0FsXaSjpW5r5 ayoxJX4Icp3iLZB+AeJQS5PuLrJNiMqhZFtMiqoAnuhUiN0tfMwqq2yCvZDrWz93ZxXV2ZbMmkT6 gMnNtKeuWK5FHaOiVglmg2iRQL02omSHwRc/DFZxDKX5qAS/iJGmu8DV729iEOKpDAIyDQghXl1m QppNvEYD1lZUWDCgrJGAdmapzf2156bhGKSXKjrOYI1wpzLlTWHZaPtM6Ma+RPHrDiL2MjIusgXS GhaakKbjQ99s2sSIHbgAYErp+EIEQGom2BuGrT34/1MEeiFS/kBfhiOCgyENIkXQVaqv4CGEWGa+ R7TNLmG9H/pwh4hA8oykVIEcAZJPd+iECy8M91N8sLDBZbPqkmAQjcEwCRJFBPXz+NdrSK33CY0V BhkiS1zUWs7m1fxuQ23CgpZi+UyAlmo1a3DLlJiaVme92TUUY+Sl5ik/SeIkJSY6dMfxa1pwBGL/ wVacR19ZI2FWQTwnCKl9Fu6TFiIs2Etu4imU5yrQ3DQrGM5MtdyJnJOrD2GdKoO7wrqAX8Qw7+/t qX52HRy6/CK5Y4gJ2gdK3S0mm2Z4BXqRZsl2gaXtek1aViAUAWBRG+yyyzPN4clgBUSb+xLcXSL5 CLCACPmesgzSxTYFSGdmWUThkdSUm2yC6CUOX0jFzRxxClVChGCiU8nHxV6QV+9NiFW6UoZ7nxTw EOjEkbf7OEyMOBllppdKLs1DN8tKgYExBFsH+4Gxag5nCcYwyUTKIiKaXvQGJ0oCfj10/IQSK49J 4D81gF+APlmApT7Gail5PYAKzaL9iUk7l0NvL8UZGDykXbMsZ2Kopyft7T5vAauSrc90c2acd6r5 rycaoyv2oq1iZAsYzqbzkWrKMeWzCb1QtfFcd5yhRYxiN0xEgLKY/TRYwMzwi4/YXpwsU+Xih58f PoMbGf5VfvwJ//xp9n9/fv9pNoWfH/40/vAh/4G98fCnn37+QJ/DT8WXk59++GH245R8/MP4L8wv /dPHz+9/+nH84YIUza6xpebjNxx3rNl4V6c8fgu3RRFts6gbjYU7WnglE8ag+DhRBMB1m6A3oLZ7 veh4jVk0BaAQS0sZyfkCUBRdq3XKuhmu/DpPZA2hC+Ib49tXdvfXawVQhAioAAYgFtN+5P5TALoY heBchL7lgGXTcSfudH5u2ormuPsDbLFJkpIivpajLi7kW9ZWlBIXM6wm1NiVSXfiXllhoOqBc39f UQjgWosySgsPTLOgJSyJU/kJHN8xDe7omK5u17JoxlHHMgRQguNMRPJzqdo92Nqw7Zvv2+P2QM91 RogOUp79GCFJ58rqJ0c6NQx4dGzF15XvAWXgeS1C1Nbn7mgmVzu7F6GrtRGWgOyvuZOROxo8lEbe CWs5BIrb33B0k8nX7U7YAwgsyHr7CWx290dhwJezZ3fS64IcY4zEmliwUBYxEkwDEu6Wx6RuOw3M tTUbkq5Hr0u978lkcsfkORyPGCNhj7nBPSZm8G+YqJWHrqQ4e4Ejltu7l23XVcK2AxNzEU9bXlP1 oOVwmOT6unVP+eWPD65J5AuIf1oq0L8t2y79SyWMEfrCj2Uc2HhBorzTp9/hYLqGl7F+xX9UV6TK 4MEbCMkCBCaUAs53xvS7PZDyY5z5XQJhfT1Sns4DRIdje1Zz2JRzdoI+Q/Ub7GGHKEmISUYc8hIH eKIXohjH9C8VP0x94oinVKva5q4yw02zacW+N8ayHQT6kFmqBrVDXVHT0cS0j9u85ACRxdyxJ+6K G1wBw4eIGxxC7mSPflBHJZroOZgQ3pO+2e6Ww0pobfAiUUPDajOv/9q6VY22TI25YWkTajnZt2yW vYEvpjWVo3Cya9iZKbVKEiAksEYEOnUaU3a/7/+++UpwqFbtOkobxTgw9EarRcSKjZbABGPjqcAE p1d1Z/xw7JLp595mEwbgi47znDQB+mDSIODBCEQciUhCQ5tfOkXofkTaQzENh7m0YxrWgc+FpJQw DRrknSlBlrqOJsJX2rZQVi3attnntrGBk4cPCeU1Nq7yAKCpVkstgEbqOmh0V/uFCAUJ930hmOTx XIhQ+F1fFzKTu5C7SpImeH2wwoNUHKQM/W0bkZgT0Hpqt1Mef4fwD82XcLJsDK4LGrqCsybiZAmh 7TQwRsEh20qCxH5gtIjjLv00eMZWB8R7N/4ieEJUYRN69BNsnEr8Zxonw+xGb9gy0fhE4IiIt3TA I3o869UFWeqHIqLP4Cv0hBq/D706YRvqCa44OufVcbjidfWiPuIhRYdw2QvN4A866Brrr9f1YRob mZjzsToeOlaOXe1hoUj21Bjd28etWneAiclw2rsmCQU4HxIyIGxBkkt3oGW39nizcrsOXptCPwLz KZUk0EPIX3/2vcdaUlb32qU8D3sklhJOSU0DwbOlzefxFSUzMf+Or6oIIroWEXO0M5tPZtrojGuZ CdAK07btmTs/N3O0YejMF9JKK+w8M+IbMEcPLdVTUnLGK5wR7am3+KwqCaWjK0I0hFWJGOwMgMoL rG9owY5QYr6PjxuUVU1DAovvZhO+4R9IeaeXYLn1QmUyhhIhytLLIDYCwiY2WZxADlGiMN89LmxW i5LlEWG1i/qKDxVhTcfZKbx6mAh7ybVyvbeVW46z0/P90JWDsYFn9YSx9LF62zV32poeT3VwLNWw NfPo9Xja+WBnPZ7zq5UjVxFHm97bc9s9vaYmEL+ozrUp+v/p65r1URHHHs/1uSFZ3ucIaqfDAnJb 3xiRzLv2N0zdoSfUGq7ZW82cw8I1hdv5mlK6G2e05riu22FL+SuuLIoziYm5mX/VuoTAQzrrdMwl Lc0U/gxdKBzDvNX1vaVZ9i/yDoMAGr0tDqC0PqFADLS+UrmDw9fX0qt5d3VC0RM9nR7PFReL7foG qlL5KS70o6TbxxR+jTIkruYNuLFXBcqOIjGmyb1duO900YCN3Ro/u+470bAdXdTH3lZoqFjCnqic g4JudFGXO88y25y2pSsSdXmLXFG3R7vrrPY5hnVRH7jIsnn9vrqod5rnyjrduoXXdu0lX0TUb7li DiI+MFMqK4EWKL1ufFoJhSbsuKn4N/9a5UpOrL3BrNqPXeFX/RgyWt5FPGAdZJCci83avvKE5L1P lEngK8AVrEnluHKd56JkbW22RbwGGP4EnoEHqCrK0IlGvdIts5ttFg7Lg8ywAFoZooJeO4w0qUjl SFFEu1lCvToY0gsSLJwXp8jmKtVyLSarXdQewH2Pw8u9MI0VJHmnwSOu+t2ZiFO3o5GE/0MBCd2S wFxSqDxgSH+ptHIJXlMFHXMQ5WU0aTFDqNfJCohBPmxtzILJGKJysN3GZCaq404d/ITylY797WGY d5CcQFN4iR2qjnmILlHUE7hqqXqhIrm5Uq4utPd5vI2W18p7kc1JpQINUqMzd+JdKq+kiFPuYaQE sNBD44hYj/PkbY/UQySJKnVoIJCQViT2Ur0pWvWcTAHVYaoU7KbZ9GO5lq3NwAhyWtNPH/XV7JE6 mtqToatvSCW1NNZXwws7kUvxz4Jl5b/RDJf+jUJXJFN60KPoNCQ1MoYellfoTYao/cZp1ptKXHV3 2+32pRaxhHvkQ7Z/IxyeS+0wfHd8gsSGPfYhLwzbtXdCgnrW3vduRNRwZMhbr+rqPce9D5bvVboO eQuZxHXwpj0Y/RvIOK7jJGkPxjGMctwXwmv+wlULB7+QvtIeqOSLuULtIspD1bkhq40yGLcWK8Q+ 9OryLmznvEjQariaEBkjVzOn9uk92rS8DjvAg9zzhuqaztQ91/JCcBt95upDfxaFJ5BavJGClGmE 19kcKf7XjYd72NU6aYjaByVNaaRItsCEUoZtnLvFg9cHWldKTFXeW9PuMuKWKTFkn6kzsjgrEg91 Eq9gcVY4+Gwoj2jXWTWLa6WFyqsz/H7A0iUd07veLQR2nVZJwPKWy4CQMNITy/+KODGQDqaLLztA 8BhKiSi6msdwyh8BXU/nxC+dVf/qQJ/oWjqtYzICXuXJPAYj4IwdoB1Gcbll0u8U+xAE7YJycgZx TlzXF9xknremmjt3Tl9Aq4/2uYbhuDN1dC+1meOFmcJt9NjL5TAJ/SFYB6EnovYOUbtzzJpSSwvo VXgRXa5YTtBBM7UFaFis1QBZCe43Ap1GXuo999rCM/IBynC+a2vvJzyDTNZ0SrI6Rde7ixA6+FF5 pwYnpHc58RXhxs9QbZD8ceUtKw5a5pCtzVwwMVxQ8NTiEWnXcPbikXVMQZlXPCLljgUW0Ra0fGzx yBKVeXcXKi8eEf7S82lxike5I+vxLQ+maKIAzTRXsg8St1hkzM2pPcGh8KcVi6h/eFcsEgjB0Fxj rMkWSe1fLGKZM3AbrYncB5Qx55OEOCzbnyio8oPnFStdP5j1vc3ffk5rfF8EEMoHiNBq7lXmL1RE aGgHCaN4Ams8qyJCpQ+Pm8ktriQPfU5ogA2CNv+68v1NI9VVHUt1x/bpe5j1olk70zH633Gj+H7v pLd7Sbud9H5iDTARFWQcKg+YE0AenSJPx1ziyNO18BIb4EAfazzVbMeYnhx9emkBqM8c3Z5iMeWs RDBLozG+bW/Y7mi/Q/mA1sPtfQXL1TxK7U3Ag8vSCmg/Va4SETY+rzKM8jV6s3S92nb4pqXRGzbv Qpe33CHjhY2JU7QjX64A0RgZ9uqf8z7ECosgVwTrVstlofHPZEtpYZDi9AA0bOF/auSn7M1SIR8R u5wt2caFQlnHhP1IRG3WlpSUL194kL70uvKrYFKBqFLSWH6iJHcsIC5CKidvkvgpQKOJd4DUqe2w tPs+8Yd7SLGwh4Q0i8bhD/nml34SQPPvpyRei1qVpbqv7Otft6OhyExGd8uBUSWCuhIqw6rJdcZ6 jQXmkusQFTxhqzVXnLdcgtE29XGaUHqLsDFJIdGIYS5xAhb4i5MZaJwUNlLXc4qgi2SwRMsOnoiN DIo94tilbRQg9AZGA1ZGkp+W+os4Wu6Z7wXbu5vS2SqTUSO5QszkYfDFD9+K2XNtuwpcN40Sj4PE ndncPr381kcSk3E/snRnAnE7ZyW+qawgU6sCozHxte0NRyX2ILhRuYjBqoAHVrgGAa8ZqX4B2CXq P4NLYIPpF9JHFUMv5JgyfsYg8VIJslR5jpHEFeBuH5n3heToUTNRDVlLdnjReAoROzy3h0c0VoLH Dn8ED49oNIXIWfF6eEiNsbP18JQWKuo7lHGuFJeE24adxrFETqsxAGaf5IoxniZjEXYGsizCc8rp St9iVEc78R4hGxcnBqKxFitaHKE6eO12yH9apBkpdUEs419KsqPHVGW+7Gl3k7Cf8WlGALdrIM+4 BR+MFyQ4SQONi+tgQl5ZXjmhnsbcSh9wOXER0OPpIyJKS4mnSGoRQ9BSW9T/K3JW3LRUvhOPKC1l ZJNWiSB1WDEmY4DkxyG5Si+rONxX/Wa+TUjHEyHUlqsAhEV2/snkigCJVA6RrONeJsplwoM/hGq9 YLxAb4CoVgr4wiUakhT+WlFXgoWPuAtEIvGflVzj2ExEV5W6lZX3sk9pH1MzKK1VDFDqQ28hgSVK 2TEEvXOHHUeJVJ6DiG4PL6JjDtJxzrIWi9IJn4Ng75y3YF+cFg6SPnXoliMv5h8cukXqkcXbcMkq JJF2X9AjCfefTzMP9/HkJRC9sLFqw/WbRvuNber61FSBoPRpjBIwlPym6m3rjj5VTePbqrdtqa5h j2Epp7VX9lFvG12ANdY1udiT/u2VtmrvsUbajtOeKnEEd3O6DTLsZwPtFxHb4MVP3kDuXHtBCAaM Vz/E/3rKehsFi2BTdu5Wvk6wL3MJS8W9JwQIoSZlF0DUOXn2o4VQJ0KZCRdeGF7XH5Vham5rljbH kCM28i8rcNSJ2VQk01OERFqpYyOG7Y7ZenJFEUULcWgMmphDQ6U7YNIVcxz1g/qUcRf2HmbAwyqG koMXU8EQUmAZgGhihUbfgCBMTMC2peitVNJIBDukNLjTYIfyEEQLESjWpPRs6iDhVOoly4GCXp75 kbLxE9DdoSYVEEmckfyCO8Mi+gmKarS8Aj0e936FvcLfcmCCY7pUgpqGDw5JDFy0uC0GTwxnCQGj qqngHcvoQSALoQXgrFRoDdJCSy5BZtmmWc+frqHBd/AtpBvl3+Sib5rFsBwcYPHh/QO4TBdhAAYN GrmBhwVrNoZ+/F6IhPOk2D8/aFhSBG6XVt80S8ijietYWDb49t215ticW5Z6btF2muMK5oEe2+/6 vsACgPbm0DvAjcRHkMzscam3RjjlQ/fJIF2TRDtM4ZU84ELZbBO0Z/8WkCvd4o5cKck87fQHlSqt Vt3BRLpKwc9DSqjw9UhwRF0Tx7AhOcdITuu/R4Ijn5rGb4gpXZF8MtqhRqius9rn5iV0ZHA3ryNv jzzUCNV1WtXGCaT0ARZKLqHhfZoF2RaXJvF2Yg5LWxOyRpq3VmtB8ClSfe9JZzu2m4ATV4ktRWoR +FpLS8ju3h+Aq/tSlF3BMq9Cp4WteDynJdiNh+u02loUkdNinYJyjnBdOyLyWtETgAqEwFmINJiz EgSZmQebIaykaZw2aV2qaBmwLIHJ5JROVlahY8J+FIPmd70Qib2RB2UMlA5gFmXTuzWL26naCy8w i7LplsLJFYr+525gFquPqR3mviudsyiLFzlnbqIhyvB5zpmPaHBFrtqqM9VMLLSdae63SOLeyLVd TTu3kjiGTQIm2t+wNYeWbm97w1XdPdZk18gx5owULqLXNGTBKNCtGAAVBKUOJBaVPI9CLEXlUHli 2cZgOqUkIZnySARvJOrh7o/gKVdXSnDtX2MxHIQdAlsNOWcs5QzXl4/iwuqFM3HLIj2M2ZRFABaC Wv+fDDoEYX19b3IcMZLtrKt2s+Q/zXYyqcJPdLtV/sCedkTgKP+zBY8RsbnTM0Yb+dOPPynvVjEc SbRdP/rJd5fKp6nyLom9pRJ5a/87ZWwo7xZB9oaeVJXkCugISvnqqAV0Sh6Zu528rB0tcyQo1zdM y9CmmJhhCrb9t6JN5929SzM0+w12UEQLdIhgY/WUJ/+V2IFoj3cGu8Q0VQSesfsZ6+jo422EDh9M SB8nyruPxPg7iZf+d/wwp0vFU5HV1mSSOsw1j/gZbGXV+lfUgsY6jFYhEsEjAOCl8vD54VL5+BP6 CcEfnN5Ya6eeo3Owno2+DevZ6DTWs9G3aT0bncZ6Njq19awaS+UhkpVun56CBXYe+VG8fV5hU3qd vyJGSjIiwjeC8cSXSxMBlXTjL4KnoEgqL/cZzlbbVOlscVm3OEg5XMHeFyz9RKjgjZSNA0sl3VT0 7i9+dqmQfGDIdcwCH8szcfgiVt9JrrpkNNSRdCXzH9PcUzj4a65eyo9wdk+QKSs/3DxtQ4BrCHwu S4e12UrIKyrLH4MbaSSc7kzZUXFYmnrMaFXe2F4N+2BFVtHWrv3Ywb2aKirr7K70UNZQPi9RYYfn vDjDe9PtYgVqXkk6RqLi5LIqHEP8Q96MD729gQq2EPCh5DntgvUODCmayuTfPfRfMB5HroowT10a 2jK5tISe69J0bLanSKDFNgFfPxJJljFip6BhEWKuvHpvVIyBNO4GzV+p6P7NhXEaLGT1IAVsaViW umMjzTCL0UFCb2IsYgXQQRuUI2qFyKGUVcyqGD7aS/Kwt2gIRJP1bo0IjPeM1oirAQEwMUkuT3gi Y0H5QoYrHMlYveqcpWOvYsxNo/nYcTVjPJ+dvohdH7Zw3bZUd2LKNaASt4V3mpwtQvHFTM66mgeF cdiccfMjbLFS0hUBzB3wq6AjjtdBysRtF7sUUneNW6s1j7V0oIxD8jrrNVVI+62uguBDt2v+DpdS oVrWrWIjoqxoVrZSxojM/fiL8uB7WRZW+UoLIt3rhmu7Q0fktyJSHbgq0FS+ZyFFnfOe62xIupmo pgop9ruAsHdFR2odyvCwhmjlnYlqPS0WYHdm6e6M7/jbvQslyNBEFaFWG7HI0hgwdPteeO+UUr92 zL5UfhkrIxd9Wruh8gw75hOawiMMDY08m2MbPz9wUCBtMpvatt57DtxvKbHNGjvmvaoN3cJSSuox RyPLGU1PX8q+j8Q21bbnmjM+t1L2hq4yTWqQtDVw/5QltrzkTt0JhPQwpFlRwzJ4Y1mlt8YKOzWr M3Gf0Uo7b1i/e6zlEOW14R5FMhrk6geKZIfpUskT27TeLYI9KhVShDjCmkpZKXuBTs4L/USkvIeU 6bf7fEpsRCrjCI6GNDZbBymuw4RgI3v1aQ3CHCAbFQxWh7AOgji5gDg8ALAStAoIPSCKfMVewH+Y V4ZUrCZDmCoYNBMnezYb66pkkfSj5tAIKctzwzXPLnCMp2nIIVFcLZS23ftOfEkQ4IFzVnJrFzZJ 4eAX9AuuyVkDrLIIfcwYbm4lWjtGEPcxQt41TchGf6SYd00TstH3G/QeQAOlhV+uYyxSpGrA8j96 7w0s2cOc9zZUDSU2ZIFixnLLFKiZLme2TaiRuWO+njh787uY05eM3rmESWvC0EQKb2/dVU07ZgE8 bnuRdowKeP0HFWmaaJyMTKW+8i2JBsr0V6aw67SoF7cjk0TTRO1lIivn9uPqosYxnnvr9uM2nxhz 7uKw3nLKbOg9+mEtVa+i2tV8dO1OOexgAy0TO+NIUSjmb6vMyJIwqErJylRUZ+2gcDWKKtcieemn QeLXwoZumuV6R5tP7AkIH9++E8wcaSPdwXHF5yTXO4bN9LReLSgt2RkkLRBgljjGFgGOcX+MX/xL ZROHwQJp7buV+QnMLn1/TRTfFNY3NnLvcBmZ/BckndD6Fm0R70rFWgO9a0vhgBVzDT9aSBY0Jjq5 wHRycWqEolexkD0t5XAOtZ49bUFyGUsycCLPRWUwlAchsBIjNOuCUl2WeQF/JWWyPVZOYSeOIa9S Uo+nYDJk7gWuh+yUDTHY4kIrLZQXWgD7pfK3LUSY5vWhMfYIXJTUEVLE5SLfljqfaGdAvmnjyV3y LdJIzHVHhns/dAzD3tImI5XurpXA27nfagDDza5OtOM0w7k8NCKYcgEa3ANGHfRjDcFIJQOIbGbY hE4zVaCGNXQXLzASl7bGihDCjS08pXyF1DWBjyEdQwBTSE284RyKzYPl6SNjjdAgRAtq45clYNH4 0/2RjByX2qaClRQEXT4kdVdB2Ls0Pg1V6n72qJK6fIDrARfCoWvq8jGvEhfCoYweeiH7kmA0XdQW 0suV7E+T0XRR80ivV8KRSMOxTab5QpINuC6rkjVJoqldTXnoHRo8cNvo5sFyt23eAux1FSxWSuh7 EAYLdUc7bCM4+EPEct2aDV2yXXNfK7dDQhcyPjUus25g54CXTo8Fx/dERBeAKLOvMKHyDQtZv/q+ YW4XiiFaZamXG+70sXB8LxyqPXgfdyKUXh/2dXfG8b2/8EAwrptEsrdNAAlebyUvAEcyl2bIy4dH E8PKkNp/AhPHPR4l1nRPwphxjAQo7gvhzigz+s+Q4riQqv2tpwvZm5NmyMuHRxPDylciLy32KMZy XknhGcECFLGa4fQlQkRZ3d487ZraYgNcVbsw6GKTQVrJYGWWuJUHdjiwArN8uVp+kYKbIJE/1qCg vIsdCyctnTQYW8E1TiS5CsnA42rZTkGgNH5Lalz3qkWbUHeN9VelM9lN4PJY3avBLu9JrLIhtkUO uDwImuL7VCKqgYfC76lPxJ+jKHDapAPO+Zz2ydfHMjvPeY3Ez33Wx8hBZZEKVh/x9FT2nM80FWoF ODxidzouz2B9IhLO4MvDGq1U2nclzbwc9tLip4VATrzuCNd7ZL4jwdoJ1Nk/4EnlUTzXlQFuGr2V hmHpE3fwRmDFIfUZOaOOpq4zN+Xqwsqk8DIvKTZJ9JRIFONoABy6fokTv6HjCSlOpaQhfIwk3nW8 JNWlXvwEh7ZTdMB+zbwIVZASfYYWUoDA3JRU/KEoo9BAl1sOyLG0kaPquMroaSGHVHySBB19ZI7U EW5oOiTo8CZ5G4J+AU1ttTPslnvkNvsbgmb/hlUQM0K51qVMfn85CZiH2jnafOyqkzMuHF1JvOsG WUPXxzN9NhsYZPfm/2jWnrLQDngXyDaHyBC6+wxZP1mwRptCwoD3hVbmS9PtelMEU+G/FYQSQggR Pb2ggV0XyuPbjmX9sbC4IzEiAJsDqdEE5PUZgksuCli9KNevKY3yr3/8MyUBKawYDdSc7eD9OwKG VCWk+ElgKqm0UIqrVTxlT3Mj1J/iVx8yWwVWJZW38cqVsSEXTeiFKVTR22wg9zJWvkSIn5fS0Uho EwNC0jFcyV5jBo7Qz68AHQajADIQwpTXqbygEuoFjmOKoMgRrv0F3eAqX+LhERqgVwR05NHRyh3W Jqpmmwvf5yreC2OfsT2YCfTFKRftk/lXS0y9h662s+hnSciXmiQ3idE2eqwTHkCaiJFErgnqUwxF t1Ie0dLQLdU1cRX9Ptm0AJP5bdXMsObubIaj7oaUiqTkdXM0NW1r/uuomeGYlnNv4Zs9pd5qkaAP wUpnZt79tUFtEQp2MW4tq8/aVJi28eg1BAMPWybXipDwUyd7gr7QKq9S/o/WXRFJgKqTQnXD2aea B4MKTk6Ho90UCkY5HSQJBaOcBSTpO5A0+0YgCQNNtezXTSN9tY2phTR/wPJz0pRtM+9S16se3JZR h/Vg7BvDJkJcBLVUmZUqtaXc0MKCuCsr11KW+MHErOTSiEqRIoVlDCnFcNfXcN34YlmrEFibVM2b CN3iUHOBDNkdU9mXngJ27lwfzrVWDJvlbgkM5JT//OFD7tt5Srxn4rRhVhQCuC84Kw8+Yxl66cKP vCSI00uFKEZwUlgtYql2aIAdeOc/7Su5ilawOzjxFz/kKmmk6vq9brtyVsA+BGFq9GOHclhb8Imj 37u4cerxCPVHNNlz4m1WPuLfkMRJFh5t1+TtIHwBsQO/S/Ur9Ow9UFsC5XQ/+Qf76Lw1wpyr6wUG MmwoQtxXXvSMDhnoOx2Bnm5rHEBx7NXce3bsrYhLx2/7HsDwEzMjMEepCE60RNJ3zigvLHRv6H0R PMSBaLarTeYjXBDqTBFNxHcwdu9nzmjoYsd7awzoZnuVxsZ2kD0WHPhcE4QCYAfAUwiDqMhOP4z/ kktJO8UFC/6xG1LQXcN+EydkhJ1gBn5cMyVthTw9m5uHhAPcOQxgva2nUbTjA0LcXZbIPGb7D+5s Axxc0G8k9VGay5jHCEwXTgUw+487P1JzGVO0jNNRmsuYokWdemwuQ6LnFx5u+QTUJ8fSLWTI1wPj K91I4ckFqVCxSeKnIPQv4AOeIEeNrB7/p1O4KVE0oS4rQI5ZGQG6OGXpJ5UCfbS6Bn1cpX03jQxU N011ZtqnryTaS/SL7br23BwDzTgncUDXSaF2uI5WA8kBsVa8EkCZy+NIwQxJ5Dh0sK20i3CmyADM +u49liaYXzmOlbUXvSFZI02DcqZMKuJzlythJHZGUm5HcpUds+U6g5yPH2CF2BOUCEHIJZCdIMMg RP/sKbj3Hi7GmJL+iwiqUpGgYLmCamHwhdOooE1s0zTProYNUoMZLLTSAztXD2TpQYtOWTp9CFYR uL02Jfiw++RYHuD5Oa9PqEr44KsjaHvOKxTLFBp6dYBpv0PfwasTS8cYHPSYcaQvS+DRVioW4Pj7 NVeWJ1ZRfPj1EenuWgHJnZntkMIa4RRwFmr5ysJ7814ojfmjpLgnzq+oraasoctHtGCxaTR1rBnt MLp/m9V4xBtRn3/LmeOE2T8gKVXkhocumCLE44YOQHje+rjo5vVh35ddxwnW5wW1R6LjD7jhRZwk /kJIZRl6iRz9WkufHzVlvXkw6DcEqYdFwyacjEhM/q2mcvyQUDjauiclNR5LEb0LL4IRcWYDyxFD mj4Zek3U/9VOK8PDr1biItvaQt806qPmdDxTZ/PT5+20FogVSjVzVXc+P7e8Hc1xaRHTVnOcS/qC tb/BVUK2vy5rzfD2C7F1VSx5TZWvGoWAxA894vAjRvAa7JYkARKYLWCrb5EEuDxBJU+FJVqWqzUS UtgP1nXqe2qbEjNtz6fFUbrUEvUaipyWdJsM5lmpdG75RGKdSPnxrnz2snm6o236/2fvW3fcRrI0 X4WbCwy6AaeTjAgyyGzYM7x2GVNlG75UzWAxWDCVtJNrpZQtUenK/bWvsX/3VfZN9kk2LiRFUiQV oaBIpj2FRlWnbow4ceLcz3dy3qdMfYz74+WaXtUipbMm1y+lH37kKeqkb/STeQ6QWOn8rDk8YOtZ xsZwKThSZrR6SufMcyrfhx56jZkZrdJLyt8bNC/cR6/cKvxb0dd3HM2RNyFNojYqx8ij8yMpTdnr WaWWuro69ZpUqaWuvAYtn+gjmKz0lyGYcP2EJSv9RQimMtQpH++bN5PfPDG1uyzn12y1VbKg2nzz RA1OqoiJJu+ls6zeEJnpLn+NZbXI8ZH3x67x69y8aZCG/6vVP7VPc0+r25RVOiLb7MI4rh6yrNKR OeR+COiC2G2+efFu/2jlwuz87TNxv96+kwgfY6U+hd5W6saT1DpDin7qnucNE2Hq0l3UTa37AhQk lXm9q6ce4YFlbYCzmOh4+LkjZ7EB8DnGkEjbAHj4oSBnKqHE53QAhU0AfA4HUMUEWC8WOzotPc9A MVe6LHemrxV3mZUM7ScQHZ3TyiNkEjuFZ7nNsqbA4SrGuc2yulyGWuK3WVazi1DrLLeZo1SciV7C t5m1gg1NL9GC6KLDlbce3q5Zuua0gY9KZZ7SAx+VYJra8zLF28c7QHpYSnKMPTK6WCqwDD3g2XNp gWVLjqhvWQVjqcoaThNYRbtpg2DVpUrOsRdaqoD/YUvpUMmDEvE/OgiWexiFZ7FvHyJWbyVRGlem dN7Hm2+NGcpEy3LYtpg4K5vNevOCzgiIyUVfpA8sj8oUM/mVMkb+kGyob87Gp9MaXnIdV63AmdqO lgO0ZY6q5JVS3Ge7B5KQkmPfgyrBJHEnB+THKsGkdLfibeQEE/TDC8w8zscVDi24shgU2/YzXTpE cUrv+ZsgKgziSE6rOs+NYiO7x71RAlGxMhRxYn9DdYOyCrzDt5LVR46syu70LM+hj3iilpXPUEfu lnJ2D6vK6nSJvbQvsxACwmwsq/1FTrlwcpuM2vUFEd48uAzVhHhpD+Rm/G61uEsW33qjds14pBJS DXXx63L7qr22CQHdpwgQ5wY77Ky7+anADqGN7MALxoZxUKoYM0NgulFElzJt+dsQYIeWFfiBiWc3 Hx3q+e5OAqc4Ax6Fz4o6t2xsBfV0NutlHpBg7YTESTlWznPzlItDVvtDvsLgrsmn+U+45df3aA1Z tklvdsQaZ0VAZY8ooQbRIdoFbW28eFGFGr4oEkAXmswYq7Kg7yTZekE8vou6cC3eOw2OCymFTBh1 eh521mwQPxPtPolXbL4wDVIVHaf9/FE5R1ZJXDlK+mv0x9ar5VPxa0WsmqNT0bGirGr5GBP+hQ/g 21diUs98m6woKtfTX/mD6XHmO9CqAHQNMlTNKFkfujM82WISCsM9OrI+dEd4smYq9QI8dgW/c7iy 1e3VetNHNllPWoZs4o6SrCctQrazhB4At1DORDDR0APQZT1LEYKJhR6O3N8jQphDDxzEITQGp1Qq G+5B5Q+g0b0eWdoQ3OUkiZMEd395wkBi+zUjVqtsZGo9fkz2GIRM59OREOIkuFStZmBnUz/Iq3ZX RY+wiVgYf0zT7dAOZfEAFZOLNzLQXVZMrsNjP2guenefZns8sL211MgVUaywf+xS8is0ClcqNPJF iWO1cqC30Tqn0gqaDzNpcntPhDUsDxshgmqAcmft0JGAodQ9FOCIxUFm5aIc7dAxMZdUPZ9wSlN3 DCemO02YS3taIEmJsLknj+NZl6zEqqnj1DS4uqqkZeOS5zAG6WGrrmJQY7CnjBToslHI85g1spHG 4cyaLXM8bpNFStwM6jIRIU31tIR8VqpWpA2ZEs9Sck/j5bIuwot3aoWcq939TS9Q0oF+UlmTFCrD abGCKrvLeovoLAJC1ls8XIWsgMhlQQ+tVdNDVSrLOpcyVBYXKrLOpQiVRYUKG69Jrb9Vlm6S5ZO2 e9BkcGYspYsulXUFSlhiXH0LiBX+QQkKKDkzv7n/Lv4otdFduS/b87hh/MdT76lMDDFu4g5sfyV/ 037PSkD4Ll3cVRqpKczd5f9MNtS5yZKvFHlldZvSr+e+LFcoLTWslctqSFYZdk0UrXVYdInEiqhi MN5qz81FVUuHRb9C6DuH3HLroZdkTboQvY5n4IEhWYUuRS+ZjhQ6Y7OMI5WotEV2WVgeURlNK8jW N8v0a0wZPaOwmGw0qBTiTDnB5SQZIm1zqc1gpJXoZLN9OJ+q5kAvd+8nrTLnjrXG7XFVeX08EyF9 jebAkOwzGPDuVm+iZJ+BkuTqpWqrzKjSS7JPYMC7W6WXZJ+AkuTKGX7v6z3GhEg0iJALjFs6b/cu oTWibKyvzI1Xqgpps5uuWoNQEAMEXBba+AEiaoblo4j5+3OKqJkQ5XhmnUl/ZDdns+wppDCjy7aL xIVAvKyoBGD1TV9XOU5Ye0qhMajiNvlC1rXlCHnVz5FPleUAeeyD40mVr/ZZo41LoWSzy/hHak7L 7jhU9kpiLWq77hU6Q6WeFvGWWu5FT1krxzRyFxQG8ZFXyjd5aZ1w82tBBxNJYtVBJbHJFpRmDfDq luPjWbRYZiAdVpw3TYgrwTRKxzkO04hwSVppqCDuoRYvs2SzInq8g8e2WtE1zZO9JbRQ+fFNcs8c y/JnC3C7Ko5XCwsSQ/LhgVK4cAI0PuuBY/XnwmxZrYTihuZ+cVxG5qZAlePr3HbVrqYhsVt01qU7 rZrOEz9KahoD23ExqzaYJsGrkIECOp8/Wuyw824c5D2papSbW7STkS/jz0WtivrKkLMSmoGNPREZ zgLYKVYf2zl5rm89wuNaBPb2H9rugfoL9LoKXE9gBraPfG9mhieG1llGv3YAJb5uHrbAkVaJ/uYy eJkm2ZfLZLFJs8vleptdPizjFZGal1wSt8ZMyGm9aMjdYgJPpfaHBxYpbPM2+bJb0iamqqYpI45d ainuHOsjfkcdNSuL9p6LP0zNiG0dUvS97iRX0KXlfvyTDNHKIhqVffQ8bih7Zh/DZp2jN1T77+OH N+u85KU6Y7YaVGQvFN+kb2zj+z0jpytxgqmljOlC66d+1e5r2zowI9Y7PK1Fkqs9JYvEDA0rDMF5 5fd/ToTt0rzd36dsGOajmgWYEuqe50eeiJmcC6/ipfeblhfPdLjsIFUP14ZHUJJt2D3FaN9poxWG AOKwTRVDIPs1ibfZMVvAsCHLcpU8AwtDVJxn2ruUGkKuh0P8osK6tKELN5DN6f6dgeFU3mtpEuzi J8PzUUTJNDA/1d9531CnkwpDiCwdYJ+yg6QwFLxEQ21awY2zOap8p0Rq4cXWTQr8RKcC9mKKy8yC qUkxj54o+ofdvqOeTZd/0Zd1kS2GsQ7zHW2ndlghc3SXRXqGJRqFcjWyJTQta5ddJPESm9e+SOYM fr6FCOo+PSDb9nH+0xPOtAHZZpFBTq8zFadwekUCr3FOtVUOwA59fCBbb9HSC9/DB5VkpjAfpMJ8 IFuz0dHHL7PI7PWbc/BBPZKczz9pQ85vIORviaPHfbYy3szFeJzjn6VsBvk2n8b5yMwRGs4mr9+n bLSPtl3f1yC2Weq4qGOoBafv4u3L5u7bWiVwaHiOdcL8j2NavP7x56DFv3eDD3Tyy4+GSGA6DnQA GNtfL+h/EiKBHpiuGWG6lGljDEMgEpgR0XWuEShtRj5GXL09uc9YrJNJDyHJ+E/L7G//5fJSe0X/ ySeHsP/f/09To1Zp2Mxe5D1Ho2UvLi//6Wv2NwFBCnTX9wM8ds/ZIa/V4qD9vAZ0E9rBD9Inh3Qz cAJnbCiPEzMlhs4DKaUmgGyJZXgElH209dwJvWJVqD/C7KvtqwviQlzTnAijxv32mt6B1faa5kaI Ac4+dL1Zpr0fvCQfIB9mdke8Tz6+usg2u+RC4pJaSjUMZBXXXZAgrxg4g+CNtABGnslmFEx7I2WC KsAiTOidEFQZuKk5Dz4esOzJemGfMKNKzsaLW0jLzorUxasLlrcSPVtg+1YU2WqSaxA6sfpfqXHv holYuW4lSyp68xmN3Nxd6Lj693+yG/2Q3n65/pqsHzbpo6Ffl98UpTA2kWU4pv9D6AYjQDgEDOp0 KqOKnfrJt2ex3q2yzRM9u88f6QtXlVdEZKHjO6EHxi55bbkvuQEnQBq+c9egW/zDZZvmfwjsVwco DNw5yNEcN2E4VnAhpcHHJM6yZcKpwl4RkZoWsJED1BylgaSmHBd8COgWDTO7Yzvmf4pIMWB7OPTo 3ibecZtC7dvxx08f6R7dx2S148ecvyJy233bMZA7PTTK8Nz//h07+rfrTXb3nbiXjDL5iyKUMULH dtB0NYUny8Ff3r6jeyTmoc72nP8tsGcTI2j5oZpjNIQmz7sblFxWU/ewDhXNEkVNnoMznsbAV1Ub TvAEDVu3fRzOQIq1ye12tyDfbWH2i2ooGDqONXoUpWWneTRVyew0IQxtl4EsPxdvjh8b9dDTRUIP jboX+Z/X2/WWHWrlbZEzNUwMvUDNFpuL/AGuE2LDHnteutCRKsVtrypRJVGx5GE8QVOg0vkh04EI hWMHhc4kYGDgY8Ng+beptOFQyQKeLD2SKXj1gyQLDEe3/MhXc8dHvjnQNAMrCNWKXwe5OUNoZh+F 5AwmTxYIRgzryQJQJJolkwVlRQLl0uEzB4K8jwIdB9if3pjNA4vDhLg5oRZxJ51U47FIDwPCtNN3 4HdePwlZgn3XimxFLTyFYZy3dwqcF/Bd7OBgBhmKUsTQ5CQrITsqb6iHu5c30OHorwcUSf58SInS fHXx9t2l7/q/EKt4GW+zz7wnjuaXdevSMC5145NOxwuxki4B2kGEHUSxQZ+HdK5TyyCKspVa2/Vu Q+0MXgSXZjFFrn+ZV/ReaPxtulEbO05Cy6vJP44dxzARTot5kQ+BIuGGEBKdBeYyZT0m0AMXjK2j BUI9XBbcptuHZfz0ljZgUSG/jKkuTlbssPL4fO3M6trkwFpVAg93DIN5cZVFiYYHbTMMLVZbOrmg kjuAQaMUyHMjBwXTWYS9MfMDMrQ1SPMHV3nsmP+126SUPNv0gVCPMewlYaR/yWXSy8X6nlEy/1iT ipWW6Q5x5ISRbvpju6ctpl6bracUxs2Z6y3DTKPEKS7gwRsiV9DwAttV7CscQmx35tolbDsrslzs s6mtk4nt3pB0bsOJZowgxEFkD302P9WYM2zY2NcdtaDpEOEOCesDR5FpYTaXdto7OURRsY4cg6xl UlNqkOqx33lxonhCyYLk2nh47EibTLxXxm8GkaGDYFLZqqQ2H+n50aNbxNd5BZNG/q9rsH9D+u8P Af33x08f6X/evwtqh1x/2oEJPTa2DVnhL2/fCbAhgLrlomAGAY+2uoM+I/uqPDKBbZp6GJr2mQES ZG6b8DZzoC+6T7bryt8iUgZ4DvIDNdytQfada4vhbmw5qrYkTe0VAeJgxzcBNqevPxlEBBuejUwr eL4FKLS+/gBgrKUKO8/PFR+VGUZi5lw4mhzOOyiF828w0lFoWdPnIKQLIanelC8ggq6OfdWs99mC G5hPkjqNnfeGBKVFURxde1FEcWHDcXRzpvXR7QQq918rkS7/Fti17vogAnhsWSaotlTZwgWUDP/6 5u3fNf/d57ef/r2kD3tDRHPBIIAhnJ4reGp7aPrwQvLQ/fTp17CkjWgtue64xKkHMyiEOuHGFOXk n34p9i1cUW5Enu4Gc9j3OURpUXX+e/j2c8kT4oXnJo50G7NBxDPUq0eYoigtf/fh0y9/hB8/FdsX ry5Hhh3aDp5Bdfk5eKNZgb5/SeTaIOjZ9hzSKyeIi/c+i/Dbhm6VTMFeEuEJNwqdEMygDqDNJT66 8bctOiJ/VWDzwNQth1YnzXLzZq2qyrTMvED4fyyKn14kqyzZdFKI2Zny1rhuAwTgDPAqhiiItgJs 2GhSvAq10PJVm0Ms6ldZoQVDc87tCjIVnk4EAgc+W+iRstnkd9ksAUQ28j3FGohBznGIG0mcWddi Sb+Z3Uh+TA9xdidqTyId+o7i/ZoknvyYxnlFV1fB15Uob5INYJNlaWdIg95Mu8RJG45nQC+aPk83 hE6EkWkGbjB239fw6dbPFHo0pRexBOwQZVvT8+wAsinDP4BqNH0b2REeO7E1nGpsaQMQPEgL2Qa0 3OlhdGS6vHzDxYE/vT7P/fDDzUj0qoDIxCZi8NnPkvfKJi/xf2psWX/aQa5ptk1eCCHTs/UZOAdD 3CiDmMfgzG7e+3j+6Pj8WpStV9io10yOAGP/MR+y2o5i/4YXLpTvSlylghg9D5e/Sn07kYDYt5wA Yo+hCD9/+5AwDQ5DNJ1bozDUySk3KqcK2jmHTjv7sl4u19/pwgp0++3d+vtWy76v96zd4LAqKrbU BGZ0jeyuicKnAKELj2hm2Ftqy2QMIQeE3jvD+dRDOzrkGUgNeR76SMSx6dlVG/tIesdEC3w/l+t0 NuURwPHvdwmfGiGEN16OumTDNdnkSX4bb5JFvNty5PIqwvgqSSjuOXvAfZrRKXjv3wU5JDkdYJ8t 7sgKd6v0HzsGWk4f+lJA1gMYBrYxOHCnhPj7qarzLcd2QjccOx1xqEElqvMtTzdD15jewRsE8tuP DA+Pbg40dfwpWr3u4P1kkN9INwzLZdf72URGKGKP68Pp5/ENAesKPSNAiA0IegZ2dBPFw7JYM/58 Ib+14aC4fd+Frjtj701C9wAT2pYbqUW2z5hfGxZpW9ctHxkTTuGu1IhWbpzQGJgjSNtGGZE4JKII 0vZAyC7EArQsdwaYh0wTKl4OwwSRExiTdhrivqImRSBtYnV6FhgdlKL1OojuXNCMOw1p24pC4Opz AESULexrrw8XLg4n0sRCoTOD4nnZwr7Dwm/hqm8DEPsxcGbQSDI4+zdqwoULwk2EXcMwnmHryGGx twTEuBOG0EY/Yhn86UjbGEQgQqPXfbQ4V214J0pEaZZAC9c/W4GLLWIRPL/r0VL8LF75jOhmXH1s yAuZ8heZ+SlGBDxdEftT0arrbVI/oQobWNgJTDa/Z2LGlAUhlAZVdyMdAranmXrfMpVYnu97vjsD s0v41ARF7KBwZqZthaHLdj9X+SNTUAkM3zbwDDDqDg99bNR1ssPQ940fAyxMd4jr6NlToim0n99B ZkMUn1wqtdHkCSnIR3G0AwsR/4RNYh+TY9TyFE6ALJ1VnkzL5Z0VnDLZSmibtq3PAe6Ysr0UFLAC 9HiDbRfr+/tklX0gX00+ZvEm04o6jCKJyr/aUtLQ80shW2z9d6oEDYDheoCRLT/DTY1sv8Wbf+yS 2yT/zTjdMOrtL2XxsORLsknoBPfa0xp3kt7IyZDVDeTrCE6oJXPO4uU/e85K/owXmbC1NAKWOghD G7hArS11Lgax4bmWHvhjJ0GHs3vFMdWRb3mOqVipMkh8pSpIrXIErDqm+nGStZsILUjsDZmZE3wQ fHbTskBojQ5DeCBoTqL8tPjsMDRNtuxpBU8eC1OyaohNGXoOy7BOJnh+Anx27EQWdN0ZYCoKAZML irHhIx7YgqZnONPHCMTAxtsA3BF7sAwFzwzgrqPQBQGcQdxFFrZ0UHx2YAXIQYopvkOx/VNVGSOE DM+KxlZ9ShoO2AZynECt6W0IdT1ElTF0zMh2R8dSGM5PkATuBwbysGfMedKjDKgH9gI30CfNwE2D 4I6BiyzTm95ZH6KNFuAgQiaYIXpwDltyHJ89R2b/ELA7WX5B4CShZwVYhzOoGRkcJbsCF54jBlLi yIGIYx3TuXgzLSTq45oaIngOC8jMTkmkcBg6PrbcGVz1QYomoK2HkT02KLzwqdHq/i3v5RTAAa8d X73bky1ctI3SvDZoqKm129MOTWCH7B3p/lrITFilVbCjqKzhSPtsljfCNihTFRsHMYTT+ukrxGYw IOcitnDnLPMIhyZ2b2Ns2fcqnPU0ETZgyLJcY16/Y5ATRCg0ISUEQy3tsPCCCuoYUqXwr8U3fJtl fjwXIWVX8X81JC5EkbKTDniff0Q3xroTzQHL9wQo4yEQ8S2XTk6a6TzE9v2L34XTIfMd6Ju2Yupw niW+g0DmW7RMdBYTgE64NmqI+CD0fIAVIQxne2MUIPN1aJpuNPrIHEHH5ghPKCLi6w6yIZzD4K9z jNhQh8yHRuSYIJrpYLQjvKGEiI9QpNs8bD/xzmX7xxQR8U3XjCLMUhDPceOKiPihA103mkFGrW3z fZOnTgS7x8AwfOzO4LQHD/ox5PhGBEWUDSKAgGtNHwptnSykPF9OIKwkQCTDwb6NFccGT+TBt9L1 uXjwoOeHn48HbzqWZxszaPA6y/SuAVx83UfQC/AMppaeYHud7MEbAVFHoT+DwMYJ5oe6g27otkvW /wxhC5QddMOBvmM9U8NTwf9GyITICekOf0AfVNFBRy6yIn/CWuazaomqgx66pzjoQDdDsr0flD5K HrwZQN01Z4D8cR7WKV18U9rFByF0dc+Zwdy3EywLVRdfh4Fnh3gGwAIjufiGHSE3sme64V4khdM9 eBxEoYHNH6VWBQcAIzglbFtfH/bpk91w5ANTR9OX8A6CfeHbkeONnpMVuE6CakViIJjum1YQoZkO jB1n9Bv2fMMG4UzHpw41+g05Po5c78e4ogYO3QgyoNHneUUHGP0GPBsajjM92u8QCCVmhO0A+mMn KIU14+mD3aBjGdD0hoYv/7lmJximacGA/vCYrH7I0TJdTTBEZmBPjzc8RFeT7oYm8pwpm5D/czje fkvi5ZWOY0BPsbzyvO6TDFoRdAEIzuw+vY/Fp+Plm1Kbjmc67Hz7PlBMDemYjodw/gs5dQWm49Wn xIldqu7vUz78t9/qleX9V6bgB6lnqF+i/i18XNwl97HAtQKRG/pOMAPY0QFulRnZkELjjyzb95sp YEZKtBfxMXl01sChUshef6KTtahtkZdFPKa3yZbN0NqyM9bWX/aDtuiaVls67OuFdhNTg3zNB3rl n9XSlThnE7fgdK7NXv+3nid1XOsqB7+5DF5SJKfLZEHc4UuGbfWwjFer5PZyQeVFwjp9Dp/7HwJc j3THifh0h0EtWXFG+LmM3sAmm2O4cM/G6EUwQLplTi8YB2nlt3UTYGfK+fJKA8P+mQge7THZUNFG PvSScFKyWqxvmc3w+VN0aV/8s6gTa/s+RIpj5gcJkZVYVPSOio2nwaw5tLzpJguZVObTwFJk15RI u9ymhP1ze52rhoYwbUObMdmG82PhmHt/EqPuLsserq+uvn///vI7fLnefL0Cum5cESuKWyEHAGEV FJn+FeaYhwwAUQge8Tg0YmOb1RZFRkvx4Z7kf60tihFx8dk4G/7SeypEixc56Q4IkvctVrs2JWfU tiwm79qsPLlo1Py//4c+tLNts/dEsnjzNckoGlX+3vFhYckyoXiY0XpzX16hf+ziZfolTW6Fp0r5 EQqgPd21HQiqsnDh39w/rDcZM9KI6bbNNGFHGGALOhDPtM9OKZRMpFHK6bISYjBDOMIMgREihGfQ ZcakjJSf4JjsYwUOpIGYbKi4zG2Kdc9pzCe4rc791W6eNGJKs5VR52A/TzvO6AsNGVk9wYaL4Cj4 tdnr0lt5v05XmcApohASF4+Zs9MKgca5dQgBenBtJ8PmJSfEF1ssd3QgMgUMXq/yWajvY2p4r67F BYKObcNxvOm83jJ70pb0M+zTYEsLgUDIsUlvdlnCZAIxRDrGS9aVai/XXpp54m60KOduS35m/cBX LNzNYEQQ+KPjEbScqxA+oeS5blOa2f5ETEFhwz3CUeiqZU7Olt+3LNY+3CqFyW4JBxE25kEcqvNf XZAXs/W3HFxUhBv8yLBCYxZjNQ+37+gKKQ1CimS1u082vPeHfHRHnrNarxLxwgfTsGGkiJN7NuZo p07f5vMSM3H7hlg3vj2hedxrFJ6BO4jOJOKDrkOQQrRm2wv8Wfj9Q3AIHaYsuncEIgurzvYZZO9t dcd9ovOqLjtFLSLkea7HYKZmuF8EWoM05X6lNSMIXSMKGdDTDLfbbgDut1saeKKKELuGGVhjjzNS SkwBZDt2oFjwfN7ktUxo3Nct352wylDKfQaA1VyXQVOLY5Htg6YdoZruoGnFqz4sMz7mXO9zdMzr 7fMoGm5LLd4v62uLz37yXKi7M8AfaXM6lJzJr5v17kHUnrTpsFrFjNXZfK92DSJuTy3u1jQMdJ+u 3i0Wu82WLFbUDUGeSa7+6JmkVsLsJYEpNNcD2HyEVZk+sRuSoE9VUSuMB7LzQESjC+RCy4jGfnXB 4pLXhVx4syKrvc8/UKE3kVz38Z/FX7vVzXq3uk1uLzRhgz9wATJYmmBSGSw2FKyg/ImkLox9cVqL ktFArg/CGXgF1bCwaI7hmCHJr7moEenbHjTZRZqhB6kk+K+kJD+0HcdQbHc/r6kmU2cYOa5pR5N2 FyidHbW1YvJr8XK7LiyoitFVO1Ba87L+dh9vvtWmBUJa63vNJcl///vaixff+CqLT1cmAkK2CPEl FkZf3ahrrKr6Yweh6PmioUQmNIM5NCsPbgm2pBUa2nz7K/k7IwpZ5ihZHm72WQUfWCGcA0xrWxys T6WdEhox3Mjzucf3zCJfXUkDIl6Sr4nw5EqEw8jw0AwS3y0EAAbstQKJwfyGJkm36WNSxD2N5pWs lvAww0miasbuKOFBkJgB7PXs9VWTynWUcVF73Y2sMPJnACUjew6nhWBBaNqYXL55mpNKDvRJMVoD YuCH+vQoSsNr01OCuNAysYnYCIZprewhOj5RhAizo7GVzPHq2gq/skpM8T5PEFho6NLnn6rk3Yh8 BJFi8cYQWQqZuL5p4MhF0/d5FjpK7VbC0AkQOC8Y6Pv4Z2ixa2eiupbo7UZLFrtNmj3VZE/j6w1n qlBTg/bQ9a3RJ05fepsn2eutRe38hX0c+JY3g865IfB8dB2Glqk4SUtehx1j9wJ6q/sTSC80ROeN oAOn+j9h2kdulWU7OUN2fQITNdO4eIfBcqEuj3pfILZai0jbmf+PuyS7SzZ5eenDLtOy9b47kH1o o6Vb7aDdo9p6wE5b3IkycVfrQQAM1wPsnaLZ4JE+UWhgFMvZKq2CMWtlDdnr35vXuubKtZOUJnY1 IiB7CMbuwpkIlooSjFs8AxPszQkE4yMMe+iFpCaSSdJLeCIZM9eHplf/RLJ2euURxxcH95QI1fSe rGT5pFGZubkncoMs/y7OtDTTFrm+2tIrfpP0XmnW6CoxfU0/jIsU3UTQNHyur6SvNO9bUFoFj87s 16BwpXuoxfIFZ6KWOH9KxbIEqSU2Me9lgzb83RIFPnxMVlrew7Cg/UvficpJKjqnyM8QTdP2Sx0W Hzf66Sfl7TvChfRQX0g8ruZJyD6tv0mmDJgotce0f3bDu0SIeNhm6XKp3VMrQVutMy1eZLt4SYQF rSTYbDOaNStOJq4dykstWlMbgRgC36jhsf7SdxtkzQFwDnMAyZoDh6sY0BxoUKu6TllbQGSdXbe2 cko8onGmU+qXWfmVKNhrt+VSgeozwmDU1GeJUe37ere81WjlRrpgfMo7ebR74sRUuHNfxEH5dsX1 HZUtVc6PN1lCuDvN7l6QD6SLu/webJLHJF4WRu/+G3HZLqTVnvCXyhu+S4tKtn/V4pv1TiaFW3ez hhUlzWcVvv1JjyqIfES+/3GXLmXWpFSXSJlkrGf1PmkYof2aGG7UXNumm/hmSRWitl3fU/yVZBVv 0vVW2+4It8b0vw+005UVhq605D7ZfE1WiydN0+jteEFNvL1sp/bdtvKzhIMliMYDBKfuaE09Spnr oPIw+m66SLZHWPTN6jZ9TG+Jvqt7tjQpQ+vGeBBH+/jLu8+/BqWpzIVCuv1GNd4mWSbxli5c4yKI 2NhxylEmdhxg55FmHKUgcy6VEHNu1+SnRqP0+giN/56skg0V1DJWlRqr0TuxfJIjgtoT6cn3PGwg oVBTOaWeIdqR3u2CO4lCKzy5bfp1lX4hanKVUcgncuPvyRuLmOrWumK7i5n/Fy83SXz7RP58TLRk td59vavpuS/M3quoWf6kyqO5/Zwr05Rq5W3G9PiWrjP/SfKt3Solzybam/2UhJqwla6GlJZERVXF SY/Kh1oduR3vGRIXfegRFmqszdCV+DVnHvHnmUqP+1rIAJE7YuhKdL9dJ9vV//tf/7viyeTmXLx6 ImaCjFRQ4wB6ov3H3xl9XfV4UhzGYeo4IS/EHjVOmIcExY/PPs2iru5SEsxHKbpXPWNJ3J4BY5s5 rYsCRonLoiQiYjEFqigctrub+zQjTt+BWxnT9ipurzFTcJNjWlNllSNsEAuvUHz0g8SfJIsuhxiS zzEf8ztRpSx+9UKLv8ZEBZJfoiFYQiimDzfUFNyr1ByK8baIhO2fy7xWauHTBgb+rvhhXAIlOuWW QV16XbXnL5EfOrozdoXW0YzfvhapM492Cr5mRx7ttYD/kFBHgFxeds6EfFm62FHOKUIdNCjP42w1 zqS4ndzJo2zLwnFJSq2o3AvZEjakbT/E1dvS3zpF5fxGdCNbPXWatPiReDDMQczWt/GTRgdL0Ke9 WVFImSTTWrmmw1Ap4D1O4sP1ly8yTiMvuz9ZOPCbfH4x1P7ZL0mc7chfL0rf/uI2vdWe1jvtPolX FzR7WExKzTuZWL5nS6NUhEkW8UN8ky7T7KlwCdJVtlnf7hiF6AF/IVwSM76kVtEq+S5zkEjJdcnu iGchJE8gtEPsKU6xGqIeohMwU6IcAvsABIF73m6on6N4aHh87jfuW1ec/y8LwBqph0hckpP2IF1u ZOlO4OPwx6iYBToxPNwzA3XLXK+84FDteuVzHfo+0JwD3rhe2KhTd4TavH/77VetBS3+yJXKW51G q877kHwlJ8hvi8BlgToygGVRtpn2sgwxIQqFlmeBcOyOraOG+n4wZJ2bufV98pCTzx/eXEuI2cpX y+BcG2Qor4DvAAJuJ7xuexEK9TlPbJSRuSEwUMSKcObERhCCwtNQrJtkniNdcwc6NuSwjw2O3MsW mb5dNaOaKP8sXmStbH7E4XsTfoq00P/w5pP2x3rzjS7p77S7/YWER6AWYvA2aVyXwb0Pg0oP+7De Jn0PGyq+9Jebzb/c0I1t6ANfEl/5ry8FJAQKQ9f1XTXRPISEyPXxoYCQaP8wvDCyfVb9NqaAOLzt QpAijdsOdC4kjt32dq7YG0HX2qe7RKN/57j4PFO2YTKCZcqox07vL1kfC/71cKfAmJOPfLKL/I8c iiSFBJv4enH7/RG6LFGIQt+ZHlmj0yiTmX/sm8Qj887b8/dzeDDDBwhoTPfyw69vtHJOQQ/TN30b 3sYxs3CBpP8DPC/0dDC05XpwY5oL/alaPFGAbQ+NPoZYSccD13Md2xi7LVUiSCsx1ciElu1CY+ye +h/MMe6cjtNOdKwjC9mKOGGzcYpNaBoeODec4f8XAAAA///sXety47YVfhVUPzLJjC4EeHdqp7wp 68Tr9chON5m2P2gJsphQpEJC9jq/+hp9vT5JAZCUSYmSQFG2PG13ko0ogbic63cODpA4WaQTTPAX gjuDiz8/nRH/Ps3/C57OHv3wvBPiKenQh0WcnndkGRms5eClabrwx0H0QFuEQYTPO0jVWHP2MFqG 9At/SeKs9yCasF9oh+cdCA2TtUuChxl7VE2ZPc786IH2RkdS9XygxU3CXuZ/kYsRfghSkvgR4ZPg LV5+T7K2L3PiS1DMvKv8ZwK+zEPeiE5vkeAUJ4+4cwHqeiQXThwRf0zOan/17zO61fd46d0NgeeM Lu/A5zj5jU3p+yReLrq1Q9VPHiltJm8ngR+JDya3GmwUp3jXYE/FMFBqNc7X98lf7tnCEjZgP8Lk m36lJZMa1nQBnqBytvAT/3Jy3pEk2bGHhtPh3zKpZ9/q+R8ujGkwGbGGlimrciaf7CsXT/1lSNgv qiQhSe7w3rO5L27Jc4iLpTnxuk69kPgeT+OELhDywTJ1UfQ1dcFfqLBt6kveLlcXQ5L47KZBkpIr 3pFM9a5OYX7+eFUV3XriyKrhSpLnnow4rcmxufhNsVPXxO7C9r6/vBYgj+5qpurJ70B2XkQHSUiY VnWS8VVIvv2O6h14xHSmcUR77Eud7756IN8KUETxVAiHtnV6inCPJLJkAXlgNPmT+8m5++XGAzNC iXPzk3116YBObzD4LDuDgXvngp8/3H28ArafBmNx29pT+Wg7x29gBgUWA/vSYOBddwS4CU3ZllyZ CdSJuSlvclOHhbtoyM3qyim6eF7ghOrLbyA5C+j6ksuJrPH5lnscx2GcFL1K9M9wuJdxFzNCFmeD wdPTU/9J7sfJw+BuNPjCJKh3z+Sk/BlK/QmZrHNlNblGKxTUVsnU1aHjvgNtlYQNVL0yMA3liinA W/2Ft+SC9hZRCLvJKGiaZsaeWmqW+LKFtp4OPd1V/vss4Qz7E1F3gFwqYfBdGBC2+MxDait3uTMW UVA2wwxNyFA22OMqFtEzo7Qun5xEc0x8wGSqh39fBo/nnTENF3BEeoSKTQfkT+cdNucBk7FvxzM/ STE5D9K4Zxiq2YOdgSCRVVvTIeIrPCVIQ2iNrFuAR73dzuhGAhJituyr+PYOjDBZJhGegKt47BOK RcBlRNk5zz5f+3PM7QB7cbB6U8StOchVTOUdSCVshssGDVQPSpqEIHwHtp2D8CPan/t48iyqGshD pu7YJycCQkcEMNwIQ0aClQ4AOgzYrzRr3rE84Dou1TiH3hCXMvJFLOLIJJ2vT4TFpqchF50+Bjs+ ixEjAWXmWYDJlC94np4xmkfpWRinpEcBCMyoxZsKUEvz1KGracPTWwUGjFbJwbWQtd4hGzwQKfyx pgilBrfDxQUj2S3GgD34IsDR4EvOOTRL8LSCG5PpuIcnAYkTjh/pI/v3O/qnT76QfSBy93zBaOiw njizfdZVn3/kaxBhu2sj1VMYg08LEcTzOFt9YAPzr3mubkvW6c0/LCdoxOCnUC6rgAUUQTKSAO/a FSGLbEHdhAzOHk6W/JdWZMlTH4UH+qN4F/FwsLCHxZrrF6Mo1lA3h6+boryhgz0k/mKGJzgM0mJF 0XKetQ7Cx7Bom4ey9LdLxs3MwufrWb2wb0tFNXPabG9QqEjRVSY8K3uo6FXqbs1f7CN71Wm9tM5w XdlpjfAUJzga41RACKHl6Y7ltPNExxBC7jbqhJD7c0EhNFVHlhSm2O9DCPPAop0QMoe7UwgNuQiB twghjUubCmFVrOqFcB057RbL6wz9PuKKVK6J9Rr6LYKWRiO1x8NH1C9dshX6j3py/Spye+0UTENQ NXgG5i09+VFi1r9d9tw+g/A9PE4C0uPQfRH6EY3SemOmKzj9hwBHJUNBSNbfQUaxnEwT3NjXDf5S sbEPV9ItgNb5DnIX2P0u6PzVD4NJFtfG01WMmwIriZd0PB/cZIQFDidsp8v32EEQgZskfqBdpl0a EBNMQ2TScxN/Sja23cfxfI4jMmLv3xI/IXTeLARAxVYNbzUNJ3QIZszyT3cUzJ937jG1fIUErBoH UUqSO0rTLSbiwy833ujq8vpHwCOKlIYUJI7DlIsNDycWk+lgwqbb2yNJPcpd8PcZX9Rq2LXpbJl7 ipmoZXyvs1ZbrHdZ1ktT3GH29na0ZYI4mhw+NzHrXBf3ZQawISV2cmhd22sCwYsuAEgDwFokQQiQ BM2ugI3QHJXGeifMBRc2YmUVDjURprk94NnPM0U6hGeF7rFwfqV5fjKeUfAwCCZbFHA/M19fRin0 PGC9m4LJUhUiwrkRgFfNpsf5WjWaZdlzEbRslE05525Fwj76ye9LCnPzPv0gWRmlYnHZYAUiqo5W MRDkoi+gOKoNhxRjtEsjHgMuVQFzCS0V8F0ALameJFtDj6ndW1qBffEE1/BsEVvrBLVVXrAJnFA4 KnqJO6As1WUDRcDaaOggik6qgEz4/aLy78JO/EmEky64ZajlR/wMnuJkkvI8/TLFDJDQkapAvjrK ekii5Pu4b5aQJ3GD2b31bsFlNAko9tsV05Veb1FYuH8uW0Ar2/lNMLNS4Ao/4jDtbCDNOkOeW8XS 0AdVntjODYBKZbzBYdUk9csTWktmPVqvhSrKDs5szymsK1CeFDmqjB60IGZgjsGaCxFIqHiGJEH7 dXNTArl/yDvem/svOYkq8HM/XQIo9aGuGPogt9Jd8JHBMwBNUxehBRw6rq06p6tnXXn5moKnLSsX EANBTKwcRx3LKHlt0yuIpjHb9TqagPOtLgHGytBRkKO1Y+yrwrcmyS7XM6HhvvW21THgm9hObl02 COyHbxk6UxFCtejsBXx98JNJgLvgjmKva/xE4qgLLPr5djxbhn8kAQ16uuBDv2oxqkK5kRAukn8H uApy4UfVws7dYxVUPmioD1V12aJqq+D6kDHq296l41k8xVHwQAEvK0U5A9YqQdcjce+WtgtoqHaX +FEaZjm8myQmMbVCYthI5eJcXpBAkEtFBjCZ2W+PWM5l3cuwN6nwLB+WaYOzRaiVtCBJMkS8mYQ0 WzV16eTeLN9Ce1NndsQK7T3OTEx4jujMKFeRg1qeunkvzkyDkuMh4/9bo+23Rtvuz68KARtthRZQ 9agbn0fb5lQ01VIMu92m2KaubIp8hfb0FzwmN4xf693zTh5u2YtPDNqYErPPZzP6WTOUnJaLh498 d4PEC/a9xpsUaAgZ/PE+JiSeM0yl8Ofcrsp5f9if4IQ+Kyp/nsYxYc9IVvkSH5aEP+cDUulKQcZb Zq9Xq8mWsU+HoWTJQ5kXMb2lQdrDhN1z1h1bMjS53U7IMYxonrbbXEwF5u1hgA1NRYfeqxrRV4oI 1sJ+sYgAyXxVYhGBouva7oig3kCthwOg4z5H/jwYgw9xShqcxjZawT0njqbBwzJpWKGtrlmkZoMW wHvHeMfJn25p+7X7wbl5VACNjAD/qH0DPi14TMBS5E5AQwVgTSZsxx6noEIjUC5pp5GDSOhQOvTV KHTYQR/hxKPaPv0sMFmmBZUeBltinPVGdekU2bGgap2+XnhVaXKcnCGjURdcx494fo8TQAMtTWhX 3bJcXbba1VK91oGhV4+0SmXv+yS/ZaQlJsIiKxOMtKAtWxpseUjzvRShItPRbenNT8IcBSQcsutr ZDhZMGsI5fo93T0Y4W4Wz1OWP/zY577qhz74HLD6sQyeU8wwwo9BiicN4ALM1LgksM3wAvON4qPJ BVEOGqxI4O0Y71VxwpD7eY4JbtiXrNajfArU9YkP8karE2+f7n+lcQ34+ubSHfauPn0jll08qMyL ZxepbO03W1s3UpmTaiA8ra4tqqQ26bTFaspsT3Wt06UZCzCwZiSagoEhvk+WfvIMmN9fS7DuJLle McJNSS7mZdXWBWvbspdiwinsMlUPWrZivnUuoEFc3WSnDRru0HDfem/8KC7zkKJKPTt7JugydV05 xGV+jsNpF/yY+UurDz76zwnbGUqos6RxHKUezuK4tIHZy85DHaqDVGLEh2p33dk+7/yq3vIlYA4i QGa4hc88A98vA5ZNj2hvjJOX1rUF8ov2qA0FVAOCKMhDcAEDd1CFKi9jUgXqmFqUKanCJVflmXHH TzVEYGqZj28ggMdz8XSCIi5e9wyW3z3dQdnCxYvdXbbVxWfVQEiCUpcf6xZgvnCNWpn5In5XUDaE /a6m2o7RsrL/GH63yEFsOt4GFcrQgnTWLXcU3sTxipxLZ95SMxRjT1lKNXD8od8FpeiyC2w/oba2 C0b088uRJ3Gz0Wt3Keh6jcoWxkF5aNju6WsOKkfqD9pkYGCohptbynn74HtM9RtTEHO7wONg+szm U8lTA+9LfoVJW/8LRINWVbimr2y+mO9i8ipinzZLYtibVHz9iAdT1NjKQmWorifTSJIx6qQupl0Z 6iaIOzCrqgrXMrXOqopxWmRlgq4KGY7nusPTp8vZDHK+K7xMqmwiyBX2072XyGqqWb32bdsV1NaS zOIk/fc//1XatuIXLWfGXIRuMlJdXTn9VUatryvRoVZE4VUqUTawvbzEnwA3YcXb1N/dWHUOqd7H aa3CQKhJysYGQx0cdh2omPwq8tMyonTQWpXXBViADypa5a6aWbF6sv5E4z08AbfEJ1S44ymw5jgJ xj7w5n4Qnon4q82yvV0WZ+NK7x12bAsrbeQNh+j014xsvwahQVGLSoXK1HgF0EmdqFjyqcaS1tmE UfyAM1sw88OQmoc5wTSKu3NuBVQVIkNXVf10dzkWFBEqfBekCFIkCLwwDGioAKxHHC0xQLSbYRiv JbLqiaI5nmoZ3unvfiw54LZ3f91in5CQwu/PFjANiKAAHRRoeJKM3rpsarvyiyx0m5EVWK8kQcdT +BHa0xq7Y2xna0Md6Zby1k74GFe+1HtPcSe5Way0y0kmzH7257n9/Ms4s58Eh336sbHDhKpjyfqw nYvZlKH/qXpZyXQlSx22K59qroetoAVSdNu2W/qMV93Xa1AvK5ue4pzSATbDSVmz1cWmq/KQqmP4 AU+nDCaRIGoKkoyhYxj26QPL5hdHVWmjmqsLPo6LmJANNRW21Ni32wBhVDkWSIJIlWVdOv21YnVn ousXKuAUW6Ao6OpUOPXTX496pJvzNNvzpHdwB+7xuNsWX21WtO4SpV+p3WXwitrd5uBqJ+7JQEj5 EiP2/4c470wyyndKU87vo2yHlLTdSAm9ElJiNzbzD5N4vGQXolz8BwAA//8DAFBLAwQUAAYACAAA ACEA/wEz5+IDAADYDgAAEAAAAHdvcmQvZm9vdGVyMi54bWzUV11v2zYUfR+w/0Bwr7FFKZI/1CpF ajlF3op0fSqGgpZpi4tEEiRty/n1uxTljySbl9TAlsqAJPJennvu5eG1/f5DU1dozbThUmQ47BOM mCjknItlhr/+ftMbYWQsFXNaScEyvGUGf7j69Zf3m3RhNYLVwqQbVWS4tFalQWCKktXU9GteaGnk wvYLWQdyseAFCzZSz4OIhKR9U1oWzBgINaFiTQ3u4IrmZWhzTTew2AHGQVFSbVlzwAhfDZIE42D0 FKh+nppUTIBxIXVNLQz1Mqipvl+pHuAqavmMV9xuAZIMdjAywyst0g6it6filqSeSvfYrdAvieuX 5LJY1UzYNmKgWQUcpDAlV/ua1j+KBsZyB7I+lcS6rnZ+GxXG5wki97tyAHwJ/W4r68ozP40Ykhfs iIPYr3gJhccxd0xqysUh8A+V5qi4YfI6gOgZwMCw10EkHURgtvXhaGzU8rxd/qTlSh3Q+Hlot+J+ j+Va1SuwOrUcK9icR+ZLSRUc5bpIb5dCajqrgBHsPYLtQ+0OIHdK8BU0UgUTcaqoprdz6MGT/OZj cnOJ21noRNbNDrsLZlNo1vO7DBOSEBIR5+incragq8oeWVr0z7p9fLHbCoKma1pleCK1MnPm0BkO nN0oWgBvcKi4qx5w697vVo47XVnpPbUHNA87sIg4Q9BZgn1IH5cXts2EiqKUus0wn1wP84/XQG+d Glcou1UMcTB9bwhc321EIowKCSU1/AGiR+GAkIv2jpEEstaFBR9ot2WG64vKG7V3rPyjYT6E1fKe oT8lF8YVAfy5ZdqRXqcOAC01nXNoeS0ZeZ9h66IUUghWWEcuwxre2jSPKO/5H3M3EUlCjPyq3x4l 1EVX0nDXoFM6M7JaWfYOvj6WXPQqtrDpkCi7m7BSpcPwsk8SmNvwuS3T4bgfuVHJ+LK0KRjb4UOP izlr0l6YxOPBu9rI3i5MD8rOH6SwtOr574Y1g7SX7LEX/AiwvHjqg9GCVxWD9BaOvytk++5Sd+qZ yQZBWZlT3UX7aUVnm1kzgZBQ0+cKH1xO8zyeTv43hc8Y9Gyn8ZG3QOmc1qH6R2I+FrG9upOGiQvE LKJV35mtV7x3be+Pcg725YH1IUk3mirkjwD8uvGV9cNtNzzSlgeFg7OL8c9naTiJB+GEjA9n6akW yRlajMKoPzgpxzCOW48TchxGb1uOST5KptEk/JnkOG0U18ygcIxu2EyvqN4i2NboDSkzGl1Px1Hu NuDvlRmPz1BmDLq7PKnMJOn/S5+MR29bmGE4DfOBO8A/jzC/fYZioHD0x3+uxH0M+F969RcAAAD/ /wMAUEsDBBQABgAIAAAAIQA2D4g2hAQAAD8RAAAQAAAAd29yZC9mb290ZXIxLnhtbNRXWW/jNhB+ L9D/QKivsXVYh62svHBsZ5G3IJs+FcWCliibjUQSJH3l13coybKddF17XbSpA+jgDL+5vhkqnz5v ygKtiFSUs8Ryu46FCEt5Rtk8sX59vu/0LaQ0ZhkuOCOJtSXK+jz8+adP6zjXEsFupuK1SBNrobWI bVulC1Ji1S1pKrniue6mvLR5ntOU2GsuM9tzXKd6EpKnRCkwNcZshZXVwKWb89Ayidew2QD6drrA UpPNHsO9GCSwB3b/LVD5PjQuCANhzmWJNbzKuV1i+bIUHcAVWNMZLajeAqQT7mB4Yi0lixuITuuK 2RLXrjS33Q55jt16y4Sny5IwXVm0JSnAB87Ugoo2p+WPooFwsQNZnQpiVRY7vbVw/esIMamrsgc8 x/2mlGVRe34a0XXOqIiBaHec48KxzZ0nJaZsb/iHUnOQXDe4DMB7BxAqchlE0EDYalvuW2Mt5tdV +YvkS7FHo9ehPbCXFsuMqguwGrYcMlhd58zXBRbQymUaP8wZl3hWgEdQewTlQ1UFkOkSawiDVMCC Hwss8UOWWL43Hk0GU5gcZhUmkTarUfOD1RiGdfaUWI4TOI7n9NqlCcnxstAHkgr9UVa3r3pbgNF4 hYvEGnMpVEYMOrFsI1cCp+A3KBTUZA98a56flsZ3vNS81pQ1oHrdgXmOEdiNxG5N1nZpqqtIMEsX XJpYguk4mkx6Hri3qiwgCqvfNg78vinPCQJz5myNVcEVNbMsxjPFi6Umt68dyjKyiTtuEAy821Lx zk6pA/j0lTONi049BFcE0jonx1pw2mmavtWxUC45TMnIFfom6vldX2gLaZjbgRccLikt+QtZEzpf QKq7YQiLEKjrxGuJBarDhBOsBq1ft82rSVMdcp0nyE2duFPp6vnRZDS9i6p0KcMrvRVHOdOe41ko 5cBARV8hbZ4bOs5NdbUQh9pqUyXQgdNpkVjlTVELZa1Y1LcNqU1UAaI/OGVNFUqqiTTOr2IDgOYS ZxROiMoZ/pJY2lhJOWMk1ca5xJLw1ITbutz6/7beQLV61y9HAX2XA3DazinrFCTXceQIvVvQXMSR 2+s6ULDbNc30Io4GXVO+20VVrxiE1eshi8L+P8oiWhQEwst3TKmeTeim2WZ8gyCtxDTpTfVX9aje zDZjMAk5fT8QAn96H/Tupv/ZQJgROOLMSOjXEkidGQ2Q/YPeP+x5PXziirAbRDTCRdeIW54b1ep6 FLPdpueyVqrodEEvBf4IuimY7nvpLRd7V3DRc71ueJKOru9XGifo6Psfm47hnT/2Aj/4P9FxuhFU EoXcAbonM7nEcougrN4HYqYfhKMwGIXfZ6Z3BTN94F3vJDODoPs3c9JzPjYxo/6dNw37g2NiBpN7 P/R6/Q9JTPO1WQGYAgJBiVzBGfzbI2QIHXGzueRFNoZ/T1H79FwRYkagqLtvsFbZHN/yGRz9ayvo cfRlWllpFc+zpojJeB1+q3+Y3d4gdO4NkdtvRcYfJef5wVeiic2NLoiRsOxdhHr4+7/ewa2NXMvh nwAAAP//AwBQSwMEFAAGAAgAAAAhABRRFbnrAwAA4g4AABAAAAB3b3JkL2hlYWRlcjEueG1s1Ffb buM2EH0v0H8Q2Nfoakm2tassEl8WAfpQJNvnBS3RFhuJJEj6lq/vUJQvSRDDiYFuKgOSyBmeOTM8 pOiv3zZN7ayIVJSzHIVegBzCCl5StsjR3z+m7gA5SmNW4pozkqMtUejb9e+/fV1nVSkdGM1UthZF jiqtReb7qqhIg5XX0EJyxefaK3jj8/mcFsRfc1n6URAG7ZuQvCBKQagRZiusUAdXbM5DKyVew2AD GPtFhaUmmwNG+G6QxB/6g5dAzevUuCAMjHMuG6yhKRd+g+XjUriAK7CmM1pTvQXIIN3B8BwtJcs6 CHdPxQzJLJXusRshz4lrh4x5sWwI021EX5IaOHCmKir2NW0+igbGageyOpXEqql3fmsRxpcJYmxn 5QB4Dv1uKpvaMj+NGAZnzIiB2I84h8LzmDsmDabsEPhDpTkqbpi8DyB6BZAq8j6IpIPw1bY5LI21 WFw2y98lX4oDGr0M7Y497rHMVvUOrE4txwpWl5F5qLCApdwU2d2CcYlnNTCCuXdg+px2BhyzStA1 bKQCOuJMYInvyhwl4xgKHo9Q2ws7kTa9/e6C3gw26/I+R0GQBEEU9PZdYzLHy1ofWVr0v2T7eNDb GoJmK1znaMSlUCUx6AT5xq4ELoA3ONTUVA+4de/3S8MdLzW3ntICqqcdWBQYg99Z/H1IG5cWus0E s6Liss0wHQ8nYTICeqtMmULprSAOBdPPTQDXTx0FEXIKDiVV9AmiR2EaBFftHTkcyGoTFnxgu61y 1FzV1iitY20fG2JDaMkfifMPp0yZIoA/1UQa0qvMADgLiUsKW15Lhj/mSJsoBWeMFNqQy5GEtzbN I8p7/sfcVRQk8NG0o/54llAXXXBFzQad4Zni9VKTL/D5WFDm1mSus34g9K5Dc5H1Qy+BnjUtdZUN Ei+CRkXootJZ2PMiY3tyKSvJJnPDJE3jL43i7i6GCzWnT5xpXLv2w7AikPOCPPeCE4CmxUsf5Mxp XRPIbW7Imyq27yZvI50Z3zhQU2Ikd9X+WsXpzWwzgpBQ0NfyjkdxNBnfTH+ZvGcENmwj8IG1QOmM 0KH0R0o+VrC+voNcJCPahY/IXBu7tnq3vu39WdL+vj4AEAbZWmLh2AUAZxtbWtvcds0jZVlQWDa7 GG+vpP70pp/2JpPDSnqpxP4FSgz7qTc0+npLjVGYeMPTcoyDzy3HNJyMB6Np9H+S4z3RcHIhpfMn L9qTnjMBYGaO8MrRHLoffnwikSa923CY3IzfFml6gUjjXuTFJzSa9r2eaZ3QaJh+bo32p5Pb28nt rzsRfECjN8vFUmkH5jH8z6W4jwH/UK//BQAA//8DAFBLAwQUAAYACAAAACEAoNuz2gICAAATBwAA EgAAAHdvcmQvZm9vdG5vdGVzLnhtbKyUzW7iMBDH7yv1HSLfwUkKLY0I1RbEiuu2+wCu4xCrscey HQJvv07IB9siFMrm4CQznt/87bFn/rwXubdj2nCQMQrGPvKYpJBwuY3Rn7f1aIY8Y4lMSA6SxejA DHpe3P2Yl1EKYCVYZjzHkCYqFY1RZq2KMDY0Y4KYseBUg4HUjikIDGnKKcMl6ASHfuDXX0oDZca4 hEsid8SgBkf3w2iJJqULroATTDOiLdv3jOBqyBQ/4dlnkPi6NFBMOmcKWhDrfvUWC6I/CjVyXEUs f+c5tweH9B9aDMSo0DJqEKNOShUSHaU0rzZCD8l7DFkBLQSTts6INcudBpAm46rbU/FdmnNmLWR3 aRE7kbfzShVMbjsQq2NVeuAQ+U0pRX5UfpkY+AMqUiG6iCES/s3ZKhGEyz7xt7bmZHOD6XWA8Avg wbDrENMGgc1B9FejVNvbqvxLQ6F6Gr+NtpEfHatqWFewmtNyeoLNbWJeM6LcVRY02mwlaPKeO0Wu 9p4rn1dXwKtuCVqctFOvjOxBuXmGKaKJBY2ciScxGgX1ROUiJ1Hl2zjj489wFsxeQlRbXcuytbV5 qlDX25PfMfL99fJxGiw704qlpMjtiaei62roUuPFHNc2N6p6bGWelUxBWi6LuvG8fpbvn1E/uV8F T+HL+r+qP6vi0kpOfsziLwAAAP//AwBQSwMEFAAGAAgAAAAhABgG0v0CAgAADQcAABEAAAB3b3Jk L2VuZG5vdGVzLnhtbKyU23LaMBCG7zvTd/DoHmRTDokHk6FQOtw26QMossCaWIeRZAxv35UxNk0Y xoT4QrZXu9/+0ko7fdqLPNgxY7mSCYr6IQqYpCrlcpugvy+r3gMKrCMyJbmSLEEHZtHT7Pu3aRkz mUrlmA0AIW1capqgzDkdY2xpxgSxfcGpUVZtXJ8qgdVmwynDpTIpHoRRWH1poyizFvItiNwRi2oc 3XejpYaUEOyBQ0wzYhzbt4zoZsgIP+KH9yDxcWlKMwmTG2UEcfBrtlgQ81boHnA1cfyV59wdABmO TxiVoMLIuEb0Gik+JD5KqV+nCNMl7zFkqWghmHRVRmxYDhqUtBnXzZ6Kz9JgMjtBdtcWsRP5ya/U 0fC+A7E8VqUFdpFfl1LkR+XXiVHYoSIe0UR0kfB/zpMSQbhsE39qa842NxrdBhh8AIwtuw0xqhHY HkR7NUq9va/Kv40qdEvj99HW8q1h+X51A6s+Lecn2N4n5jkjGq6yoPF6K5UhrzkogtoHUL6gqkDg bwmatd00KGN30OBmmSaGOGUQmHiaoF5U+WkIHMZ+bg3GcDQfD35NoGt7K3Qs562T+vGh0NnTP+AY rhaTUbRoTEu2IUXuzmY83fihSY1nU1zZYNTVWKu8JJgq6bgsqq7z/F58eEH7cDL/sfo5nH+p9osq rqyj/bazfwAAAP//AwBQSwMEFAAGAAgAAAAhAJa1reLxBQAAUBsAABUAAAB3b3JkL3RoZW1lL3Ro ZW1lMS54bWzsWUtvE0ccv1fqdxjtHfyIHZIIB8WODS0EosRQcRzvjncHz+6sZsYJvlVwrFSpKq16 KFJvPVRtkUDqhX6atFQtlfgK/c/ser1jj8GQVKUCH7zz+P3fj52xL166GzN0RISkPGl5tfNVD5HE 5wFNwpZ3s987t+EhqXASYMYT0vImRHqXtj/84CLeUhGJCQL6RG7hlhcplW5VKtKHZSzP85QksDfk IsYKpiKsBAIfA9+YVerV6nolxjTxUIJjYHtjOKQ+QX3N0tueMu8y+EqU1As+E4eaNbEoDDYY1fRD TmSHCXSEWcsDOQE/7pO7ykMMSwUbLa9qPl5l+2KlIGJqCW2Jrmc+OV1OEIzqhk6Eg4Kw1mtsXtgt +BsAU4u4brfb6dYKfgaAfR8szXQpYxu9jVp7yrMEyoaLvDvVZrVh40v81xbwm+12u7lp4Q0oGzYW 8BvV9cZO3cIbUDZsLurf3ul01i28AWXD9QV878LmesPGG1DEaDJaQOt4FpEpIEPOrjjhGwDfmCbA DFUpZVdGn6hluRbjO1z0AGCCixVNkJqkZIh9wHVwPBAUawF4i+DSTrbky4UlLQtJX9BUtbyPUwwV MYO8ePrji6eP0cm9Jyf3fjm5f//k3s8Oqis4CctUz7//4u+Hn6K/Hn/3/MFXbrws43//6bPffv3S DVRl4LOvH/3x5NGzbz7/84cHDviOwIMyvE9jItF1cowOeAyGOQSQgXg9in6EaZliJwklTrCmcaC7 KrLQ1yeY5dGxcG1ie/CWgBbgAl4e37EUPozEWFEH8GoUW8A9zlmbC6dNV7WsshfGSegWLsZl3AHG Ry7Znbn4dscp5PI0LW1oRCw19xmEHIckIQrpPT4ixEF2m1LLr3vUF1zyoUK3KWpj6nRJnw6sbJoR XaExxGXiUhDibflm7xZqc+Ziv0uObCRUBWYuloRZbryMxwrHTo1xzMrIa1hFLiUPJ8K3HC4VRDok jKNuQKR00dwQE0vdqxh6kTPse2wS20ih6MiFvIY5LyN3+agT4Th16kyTqIz9SI4gRTHa58qpBLcr RM8hDjhZGu5blFjhfnVt36ShpdIsQfTOWOR92+rAMU1e1o4ZhX581u0YGuCzbx/+jxrxDryTXJUw 336X4eabboeLgL79PXcXj5N9Amn+vuW+b7nvYstdVs+rNtpZbzXH5emh2PCLl56Qh5SxQzVh5Jo0 XVmC0kEPFs3EEBUH8jSCYS7OwoUCmzESXH1CVXQY4RTE1IyEUOasQ4lSLuEaYJadvPUGvBVUttac XgABjdUeD7LltfLFsGBjZqG5fE4FrWkGqwpbu3A6YbUMuKK0mlFtUVphslOaeeTehGpAWF/7a+v1 TDRkDGYk0H7PGEzDcuYhkhEOSB4jbfeiITXjtxXcpi95q0vb1GxPIW2VIJXFNZaIm0bvNFGaMphF SdftXDmyxJ6hY9CqWW96yMdpyxvCIQqGcQr8pG5AmIVJy/NVbsori3neYHda1qpLDbZEpEKqXSyj jMps5UQsmelfbza0H87GAEc3Wk2LtY3af6iFeZRDS4ZD4qslK7NpvsfHiojDKDhGAzYWBxj01qkK 9gRUwjvD5JqeCKhQswMzu/LzKpj/fSavDszSCOc9SZfo1MIMbsaFDmZWUq+Yzen+hqaYkj8jU8pp /I6ZojMXjq1rgR76cAwQGOkcbXlcqIhDF0oj6vcEHByMLNALQVlolRDTvzZrXcnRrG9lPExBwTlE HdAQCQqdTkWCkH2V2/kKZrW8K+aVkTPK+0yhrkyz54AcEdbX1buu7fdQNO0muSMMbj5o9jx3xiDU hfq2nnyytHnd48FMUEa/qrBS0y+9CjZPp8JrvmqzjrUgrt5c+VWbwuUD6S9o3FT4bHa+7fMDiD5i 0xMlgkQ8lx08kC7FbDQAnbPFTJpmlUn4t45RsxAUcuecXS6OM3R2cVyac/bLxb25s/OR5etyHjlc XVks0UrpImNmC/868cEdkL0LF6UxU9LYR+7CVbMz/b8A+GQSDen2PwAAAP//AwBQSwMEFAAGAAgA AAAhAPnuIpc5AwAAUAwAABEAAAB3b3JkL2NvbW1lbnRzLnhtbNyWyW7bMBCG7wX6DoTOcbTEih0h duClCQKkRdHl0htDjS2iFMmSlBW/fYeyvDVd5OZS1AebJjnfDOefoXR981QKsgJjuZKjID6PAgKS qZzL5Sj4/Om2NwyIdVTmVCgJo2ANNrgZv351XWdMlSVIZwkipM1qzUZB4ZzOwtCyAkpqz0vOjLJq 4c5xc6gWC84grJXJwySKo2akjWJgLfqbUbmiNmhx7KkbLTe0RmMP7IesoMbB054RnwxJw6tw+COo fH40pUHi4kKZkjr8a5ZhSc3XSveQq6njj1xwt0ZkdLnFqFFQGZm1iN4uFG+SbUJpf7YWpovfjclc scrr0XgMDQiMQUlbcL3Lafm3NFwstpDV7w6xKsV2X63j/ssKYr5RZQ/sEn4rZSk2kf+eGEcdFPGI nUWXEI59biMpKZd7x3+VmoPkxulpgOQZ4NLCaYi0RYR2Xe5bo9bLl6l8Z1Sl9zT+Mtq9/Lpj+fvq BFZbLYcVbF8WzMeCamzlkmX3S6kMfRQYEWpPUD7SKEB8lwTj/W1K6oznoyC5CnBEK1covAJm1Ch5 Ru6qtZ/NqUNMEiVxLxr2ksGnuJ8laRZFX/wql9xxKjDy2V0D1uipn2lq6L0H9ycX6XyC17yfxSvO +dk0mUyH8fTCA/BRkH8YBVF0278YXAx3U3NY0Eq4g5WG/t40Px/dWuBpshUV6HlzFsoNBOH4Otxt 23y14yOTt9R8qyCHNg0Hpu12KqVyzZX2ARbtyg7pvGKZ1ZRhZrQBC2YFwfidcoSSHBZcQk5AQJNh b+q2AB9b8906fi5F6nN1ihTDrlJM+tNhejU4lmLQfo6kmEWD4Xw/dSBFu/IPSTGe+eefwfIndUHd DbkDtTRUF5wRbI0nXuJj8YxYbCfpOKNCrAkTysIZKmTh5kR5kqQp0e76pFFXfd6k0eRqFnfQZ57E k2nyM33alX++VW6VIf7FRYADibfXGeGYYVWJnDwCkXjLEacIl0xUOQ4LOG6jnfgW5RXUPCi2ef14 8HJD/rPNbbT19lxxlB6f4xehEuqc4Y+Vg1NLJU1PLJV+x1K5xCaMB2+m/1mpjD9rn5Y/pHk/tuPv AAAA//8DAFBLAwQUAAYACAAAACEAQr1viQ4EAADqCgAAEQAAAHdvcmQvc2V0dGluZ3MueG1svFZL b+M2EL4X6H8wdK7WeliWo8ZZOH7spkjaYp1eeqMk2ibCh0DSdryL/vcOSTGyE7XI9tCTyfnm+zgz 5Ix8/fGZ0cEBS0UEnwbxhygYYF6JmvDtNPjjcRVOgoHSiNeICo6nwQmr4OPNjz9cHwuFtQY3NQAJ rgpWTYOd1k0xHKpqhxlSH0SDOYAbIRnSsJXbIUPyad+ElWAN0qQklOjTMImicdDKiGmwl7xoJUJG KimU2GhDKcRmQyrc/niGfM+5jrIQ1Z5hru2JQ4kpxCC42pFGeTX2X9UA3HmRw78lcWDU+x3j6B3p HoWsXxjvCc8QGikqrBRcEKM+QMK7g0dvhF7O/gBntylaKaDHkV2dR559n0DyRmCs8PdJZK3EUJ0Y fvZCir6nJA66J6VE0j24th6sKu62XEhUUggH6jKA1AY2uuAGXvlXIdjgWDRYVnDV0CJZFAwNoCWq nr7gAzGto6ypxhu0p/oRlWstGmAdEASXJy1jd2p2mNsn9yc0k8dHSebwWqIj3NcnSerPQpKvgmtE 1w2qwOid47gVq4lqKDp1jouOvYSGPnlG4vyrHYKANZat4BxIUlDvVYtfhZ5DV0p4NG24tVzvUIMX Lit1cy0KZQxtmmpwKPAzlATXRMOUaEjN0DMcGGVXRqH1hiDFXl/4Gsw4N5cKNdKojXd4QYZ9XzjH YiOE5kLj3+X5DnIi9TQIY5fHK7Ot3/A1F/P6zeaVzqXVy1wQ3Vgzqz19lIjY28Ou/hZau5kJGhwx eG8Xc/BB1DDUgCvJ+xvDENzLcIU7DwKmem3rZBZfIF/vG0WzqzRL7TU5tEPSq3G0GvchWRQlUdqH 5Gk0vu3lTJZZMln2IVeLPFtO+pB/jm0e5ZNF3ocsknh22z71V8g4jha956zSLJ73nrMapXnazxnH WbzqReY5yLV30FaeFearYN6GW62g6QbMMeaIlZKgwYP5bgyNRymfbgn3eIlhfuFzZL0vPRiGDlAM UbqCxvaAfZbMTgdoFLumD0huO93WQ/ZaobV/edEyAw/LT1LsG4ceJWrueI27JOLRqGUSru8J83a1 L9eexWHinkF7Xv92kLZOXXlgnMI7x6Y+96ibdhsZzmeu2BWVa9ML+AE1jWuhchtPA0q2Ox2bLtCw q+Hvhd2U26TFEoslDrMbVJnMwLtddLbE2878Um9LO9vI20adLfO2rLONvW1sbDD/saSEP0F3+6Wx bwSl4ojrzx3+xuSKYGfi/zyP7fTrmcevYjFfv4rAc1yfWNl9V35ygVOiYPY18AnSQnrsZ4vFo6IW 1R10EqysPZst02V+6y4+zl7gzMHfJvPZJF8uV+FynM7C0TLLwlmercJ5drXKklm+Wtwmf7WN6P+k 3vwNAAD//wMAUEsDBBQABgAIAAAAIQAFDgqo+QAAAA0CAAAUAAAAd29yZC93ZWJTZXR0aW5ncy54 bWyUz8FOwzAMBuA7Eu8Q5b6mndiEqnW7ICTOwAOkmdtGi+Mozuj69kSlwGGX7WbL9if/u8MFnfiC yJZ8I6uilAK8oaP1fSM/P15Xz1Jw0v6oHXlo5AQsD/vHh91Yj9C+Q0p5k0VWPNdoGjmkFGql2AyA mgsK4POwo4g65Tb2CnU8ncPKEAadbGudTZNal+VWLky8RaGuswZeyJwRfJrvVQSXRfI82MC/2niL NlI8hkgGmHMedD8eauv/mOrpCkJrIjF1qchhlo9mKp9X5Vyh+wc29wHrK2DLcB+xWQjFE8JFCjT1 W+8p6tZlKUcS+Ssxw1LtvwEAAP//AwBQSwMEFAAGAAgAAAAhAIp5v/QoAgAATgQAABAACAFkb2NQ cm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnFTBbtswDL0P 2D8Ivju2kyBLAkVFl27oIVsDxG3PmkwnwmTJkJig2dePthPPWXeaT+QjRT2ST+Z3b5VhJ/BBO7uK slEaMbDKFdruV9Fz/jWeRyygtIU0zsIqOkOI7sTHD3zrXQ0eNQRGJWxYRQfEepkkQR2gkmFEYUuR 0vlKIrl+n7iy1AoenDpWYDEZp+ksgTcEW0AR133BqKu4POH/Fi2caviFl/xcUz3Bc6hqIxHE9+ak GRUOK570KM8dSpPrCsQ4Jbz3+FbuIYhszpPO4q/OF0FMF+mUJ53N1wfppUIaohjPFp8mPBkg/L6u jVYSacDim1beBVcie2pZs6YCT4YpnDrZgTp6jWdBXIYu32hLHMZjursziZ+Xey/rQxCzSUOyd/lO SQNrGoMopQnAkz8AfwTZrHgrdUPxhMsTKHSeBf2LljyO2A8ZoBneKjpJr6XFqEvrnNY2dUAvco2e avd+aw7ThraeiqxNIOM2sXVaDmTfsqMbDISnknrDf5DNhmRbDh3Vjk7hZYmxBixjUDTEOOhKG+lj 47qBx+mCxeyebdwuZ60Ym6fA0DEPePSWKUciAQRGj4BdTrPraaZt6d51f+3jL+ZrqiTtWXz+stmQ Ri5es9Sf4bnO3UMjxcuubsGBxF41Hna1VLT8STbPpkOxDWJ8RygUpJ5++z3AH2lW3jQ30Fm7h+Ka 8z7QyPel+z2IbDZK6Wv1esVIcv27Fb8BAAD//wMAUEsDBBQABgAIAAAAIQAJg4oy9wwAAJJ+AAAP AAAAd29yZC9zdHlsZXMueG1s1J1Lc9s4EsfvW7XfgaXT7iGR305S45lynHjj2sTxjJzNGSIhCWOS 0PAR2/vpFwBJCVQTFBvsuGpPtkj1jwD+3Q00H+Ivvz0lcfCDZ7mQ6cXk8PXBJOBpKCORLi8m3+6v X72ZBHnB0ojFMuUXk2eeT3779e9/++XxXV48xzwPFCDN3yXhxWRVFOt302kernjC8tdyzVO1cyGz hBXqY7acJix7KNevQpmsWSHmIhbF8/To4OBsUmOyIRS5WIiQf5BhmfC0MPbTjMeKKNN8JdZ5Q3sc QnuUWbTOZMjzXHU6iStewkS6wRyeAFAiwkzmclG8Vp2pW2RQyvzwwPyXxFvAKQ5wBABnOcchTmvE NH9O+NMkSMJ3N8tUZmweK5LqUqBaFRjw5FelZiTDD3zByrjI9cfsLqs/1p/Mn2uZFnnw+I7loRD3 qhUKlQhF/XSZ5mKi9nCWF5e5YJ07V/qfzj1hXlib34tITKb6iPl/1c4fLL6YHB01W650C1rbYpYu m208ffVtZrfE2jRX3IsJy17NLrXhtO5Y9dfq7nr3k/7zKCL5eKUGIJNxc7CD6visLORszZRPfnTu uW3tmdbY6u/mYFOgg/Jq5eOzKtTUXr74LMMHHs0KtUPDqo3fbu4yITMVTheTt2/rjTOeiE8iinhq fTFdiYh/X/H0W86j7fbfr01I1BtCWabq/+PzQ+MbcR59fAr5WgeY2psyrdStNoj1t0uxPbgx/6uB Hdb6dNmvONNZJjjcRZjmoxBH2iK3etvNLHf6br6FOtDxSx3o5KUOdPpSBzp7qQOdv9SB3rzUgQzm Zx5IpBF/qgIRHgZQ93Ec0YjmOIINzXHEEprjCBU0xxEJaI7D0dEchx+jOQ43RXAKGbq80HL2Y4e3 93P3zxF+3P1Tgh93/wzgx92f8P24+/O7H3d/Ovfj7s/eftz9yRrPrZZawY0Ks7QYHWULKYtUFjwo +NN4GksVy5ReNDw96fGMpJMEmCqz1RPxaFrIzOf9HmKC1H8+L3SRF8hFsBDLMlMV+9iG8/QHj1Xt HLAoUjxCYMaLMnOMiI9PZ3zBM56GnNKx6aCxSHmQlsmcwDfXbEnG4mlEPHwNkSQpbBxa1dMrHSSC wKkTFmZyfNMkI8sPn0U+fqw0JHhfxjEnYt3SuJhhja8NDGZ8aWAw4ysDgxlfGFiaUQ1RTSMaqZpG NGA1jWjcKv+kGreaRjRuNY1o3Gra+HG7F0VsUry96jgcfu7uKpb6ZPnodszEMmVqATB+uqnPmQZ3 LGPLjK1XgT5X3Y21+4w9znsZPQf3zjltP3roEG8ORLXsNx6kz1+LtBw/3i0aVexteETRt+ERxd+G Nz4Cv6hVtF6/faIpd2blvOiM6eEON2NxWa13xwcjK8Z72DYArkWWk4VBN5bAg2/1alfLSZEYt60c 37Ata3xY7WYl0ubVSIJWxjJ86MnSCNSn5zXPVNX2MJp0LeNYPvKIjjgrMln5mh3yR0aSQSH/MVmv WC5MKdVCDF8JNFfhgy9sPbpDdzETKY1uH18lTMQB3QLj0/2Xz8G9XOsqVA8MDfC9LAqZkDHrE4X/ +M7n/6Rp4KWqkdNnot5eEp09MrArQTDJVCQZEZHUKlSkgmQONbx/8+e5ZFlEQ7vLeHXjS8GJiDOW rKtFB0Fsqbz4qPIPwWrI8P7DMqFPG1EF1T0JzDqrmJfzP3k4PtXdyoDkxNHXsjCnJ81S11jT4cYv E1q48UsEo6aaHrT/EnS2hRvf2RaOqrNXMctz4bzC6s2j6m7Do+7v+OKv5slYZosyphvABkg2gg2Q bAhlXCZpTtljwyPssOFR95fQZQyP4Iyd4f0rExGZGAZGpYSBUclgYFQaGBipAONv4LFg4+/isWDj b+WpYERLAAtG5Wek0z/RRSALRuVnBkblZwZG5WcGRuVnxx8CvlioRTDdFGMhqXzOQtJNNGnBk7XM WPZMhPwY8yUjOEFa0e4yudBPRMi0usebAKnPUceEi+0KRyXydz4na5pmUbaL4Iwoi2Mpic6tbScc Y9m+tW2fmXn8Y3QT7mIW8pWMI545+uS2VfWyfiSjPk0PLtkNOu35WSxXRTBbbc7225iz+uGPHsum YG+Z7T9g15ifNQ/BdJl94ZEok6ah8FmLs+PhxsajW8Yn+423K4mW5elAS3jMs/2W21Vyy/J8oCU8 5puBliZOW5Z98fCBZQ+djnDe5z+bGs/hfOd9XrQx7jxsnyNtLLtc8LzPi1qhElyGob5aANUZFjNu +2HB47bHRJGbggknN2VwXLkRfQH2B/8h9MyOSZrmeJubK0DeN4voQZnz91JW5+1bF5yGP/N1oxZO ac6DTs7x8AtXrSzjHsfB6caNGJx33IjBCciNGJSJnOaolOSmDM5NbsTgJOVGoLMVnBFw2Qra47IV tPfJVpDik61GrALciMHLATcCHagQgQ7UESsFNwIVqMDcK1AhBR2oEIEOVIhABypcgOECFdrjAhXa +wQqpPgEKqSgAxUi0IEKEehAhQh0oEIEOlA91/ZOc69AhRR0oEIEOlAhAh2oZr04IlChPS5Qob1P oEKKT6BCCjpQIQIdqBCBDlSIQAcqRKADFSJQgQrMvQIVUtCBChHoQIUIdKBWTyL6Byq0xwUqtPcJ VEjxCVRIQQcqRKADFSLQgQoR6ECFCHSgQgQqUIG5V6BCCjpQIQIdqBCBDlRzsXBEoEJ7XKBCe59A hRSfQIUUdKBCBDpQIQIdqBCBDlSIQAcqRKACFZh7BSqkoAMVItCBChF9/llfonTdZn+IP+vpvGN/ +KWrulF/2E9626jj4aimVW7W8GcR3kv5EHQ+l3hs6o1hEDGPhTSnqB2X1W2uuSUCdeHz61X/Ez42 feRvMtXPQphrpgB+MtQSnFM56XN52xIUeSd9nm5bglXnSV/2tS3BNHjSl3RNXDY3pajpCBj3pRnL +NBh3petLXM4xH052jKEI9yXmS1DOMB9+dgyPA10ct61Ph04Tmeb+0sBoc8dLcK5m9DnllCrJh3D wBgqmpswVD03YaiMbgJKTycGL6wbhVbYjfKTGoYZVmr/QHUTsFJDgpfUAOMvNUR5Sw1RflLDxIiV GhKwUvsnZzfBS2qA8Zcaorylhig/qeFUhpUaErBSQwJW6pETshPjLzVEeUsNUX5Sw8UdVmpIwEoN CVipIcFLaoDxlxqivKWGKD+pQZWMlhoSsFJDAlZqSPCSGmD8pYYob6khqk9qcxalJTVKYcsctwiz DHETsmWIS86WoUe1ZFl7VksWwbNaglo1muOqJVs0N2Goem7CUBndBJSeTgxeWDcKrbAb5Sc1rlrq kto/UN0ErNS4askpNa5a6pUaVy31So2rltxS46qlLqlx1VKX1P7J2U3wkhpXLfVKjauWeqXGVUtu qXHVUpfUuGqpS2pctdQl9cgJ2YnxlxpXLfVKjauW3FLjqqUuqXHVUpfUuGqpS2pcteSUGlct9UqN q5Z6pcZVS26pcdVSl9S4aqlLaly11CU1rlpySo2rlnqlxlVLvVI7qqXpY+v9TJptXoqmvlw8r7n+ iW7rgZmo+onS+iKg+eJNtHmPkjbWLQnq10TVm02Dt0du9tY9qa8kmv8739GlL2OXmeBZcMsf9WG3 b8Xa2WHezQW2hnl7U9Xp5q1Zpg+w1+FKdTusf8jJ0es7GQslAcsitbsAvXf8nGv/aLQvtlZNdTSx 0EL3NM84Ait7tam8xdWmt7X7by8Sd7dRtWgeV9Kpf27SSAEe6/doVW2NnliFUvuveBx/YdW35dr9 1Zgvimrv4YF5WH9n/7z63TmnfWYSlBMwbTem+tjvFNUP1ddXzh2jflmGZcpjFYnVO+naY27u5Rg7 3ANcIixzNTYmpDvdwuEUVe7oD9vmHXZ7fcIO7J/rH117Ed4Bd3v4RitNbgb7SmbrPOL6BQLQHba/ w1y1mKmR+6qz+ajkuX3d4GHjT9brBqtt+/Nfd3c2qYxHDhc3U9D2GUuSjtUvLxTGb7Tqau56a1Yu K5YuhX7L58m5ucvCeiXhkH7ti5JtP7oDhbSfWC204ygZ5vp36HPoW/aPJexrnf4l103PbOwVy8bP DVkutHDG6uDg9ODg6KC+Dccx3c/4UvLg2401pdub9Hy++Vw7+GZU6yVfy+XNNuSU3+cauyMEnEN/ IYh4UH0l2IzijgQ764d+KZA6jBr0fQusF1djM/YqHf9VqjEJZaJ/sZeJDKagzpfeDB1/Oke/Pjk+ P64HAKbmujxqjYzZ5puar4aNiHmVDSYfWNyfkA16B+moLptar8ttXj1LFMw73dsdOWu3dxjbyowJ 4o6x+umFEpUc3T77df4nL6JyYDA3vzXbpQEY41T/GLtrp60ObMPLuPm86sZVTurO3b3ZHVTzrSAq A+t7TvfuSgD9A/h/6OW2Gr4+3/yX//o/AAAA//8DAFBLAwQUAAYACAAAACEAGNtjBywBAACTAgAA EwAIAWRvY1Byb3BzL2N1c3RvbS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AACskk9PwyAYh+8mfgfCnUGZc2vTdnHtdvJg4vTgDVu6kRRo4F11MX532V/16ky4kPfHw/Pykk7f dYt66byyJsPRgGEkTWVrZVYZflouyAQjD8LUorVGZngrPZ7m11fpg7OddKCkRwFhfIbXAF1Cqa/W Ugs/CGUTKo11WkDYuhW1TaMqWdpqo6UByhm7pdXGg9WkO+PwgZf08FdkbaudnX9ebrvAy9MjfIsa DarO8Ec5KspyxEaEz+OCRCyakXgYjwmbMMZnvFjEd/NPjLpdmGNkhA6tF04KkHXg9ZA0qpWgtMw5 41E4R/h4yViyXy8p/ZlI6en+C02Gv0ysO5i03ZsHl69Bt7zzp1miMEr0KkGM9zLH0L+p3JxU7oWH R9Ff+Cz0+zflXwAAAP//AwBQSwMEFAAGAAgAAAAhAHwzIKkQAgAATQcAABIAAAB3b3JkL2ZvbnRU YWJsZS54bWzElNFu2jAUhu8n7R0s35c4IUCJGiq1A6k3u9jaBzDGAWuxHfkEAm+/YyfQSZSNTGqb KJLz2/5if7F9d7/XJdlJB8qanMYDRok0wq6UWef05Xlxc0sJ1NyseGmNzOlBAr2fff1y12SFNTUQ 7G8g0yKnm7qusigCsZGaw8BW0mBlYZ3mNb66daS5+7WtboTVFa/VUpWqPkQJY2PaYdw1FFsUSshv Vmy1NHXoHzlZItEa2KgKjrTmGlpj3apyVkgAnLMuW57mypwwcXoG0ko4C7aoBziZbkQBhd1jFkq6 fAWM+gGSM8AYZD/EqENEcNByT4kW2dPaWMeXJZJwSgRHRQKYzrqfSZrMcI3Vz0pLIN9lQ35YzU1o UHFjQcbYZsfLnLIE7zEbshFL8UmwlNLINxQb7kB6WNuQtXHBtSoPx9QFbqioVC02x3zHnfJDbKtA rbFiC0uW0zljLJkvFrRN4pw+YjK5HT10SeK/Fa5plwxPCfOJCJzwGrccETinNvjNqDVxZuSRl2rp 1AUTi2DA3yl6SHqZgEYB9DORvmUiSScfY8JunZLOr44LNiboYBpseCtpLxvarqR7a2EUai9X16+K dPgRLn7KtZXk5emCiIdOQPvgFvmEZTFPJ8fknTeIxv3BL5jwR0R7VPgjo98G+b+jgo3/NJEmfoOc Em8ieZ33301M/2WiK8DsNwAAAP//AwBQSwMEFAAGAAgAAAAhAKZFCqXmAQAAKAYAAA8AAAB3b3Jk L3Blb3BsZS54bWyklNtuozAQhu9X2ndAvl5izAKhKKRaNdoq190+gGucYBV7LJtD8vZrEgg9SBVp JCQw9nzz279nVvcHWXktN1aAyhFZBMjjikEh1D5Hz//++inybE1VQStQPEdHbtH9+uePVUfiTHPQ FfccQtms0yxHZV3rDGPLSi6pXUjBDFjY1QsGEsNuJxjHHZgChwEJTl/aAOPWunwPVLXUogHHDvNo haGdC+6BEWYlNTU/TAxyNSTGdzj9CJKftwaaKze5AyNp7YZmjyU1r432HVfTWryIStRHhwySEQM5 aozKBoR/kdKHZGcpw2uMMHPynkM2wBrJVX3KiA2vnAZQthT6cqbyuzQ3WY6Q9qtNtLIa13WaRLdd iM3ZlQk4R/5gpazOyr8mkmCGIz3iEjFHwvucoxJJhZoSf+to3hwuia8DhJ8AieXXIeIBge1RTqXR 6f1tLj8aaPREE7fRtur1wur71RWs4ba8vcH2NjFPJdWulCXLtnsFhr5UTpHz3nP2eScHvL5K0Hro psaC6ucy2tQluNp/oAbUL++xOY5rDLeuP/Ot2sFppUvWioKbbZGjPxt0+tfY8/jJJ37sh8Q94V2a LJOI+CSK0vD3Mu0/kzROkngZ+NFyGaUIr1d40nEZ9C1+/R8AAP//AwBQSwMEFAAGAAgAAAAhALtY aVNdAwAAEhYAABIAAAB3b3JkL251bWJlcmluZy54bWzUVllu2zAQ/S/QOxgC8ulolyUhTuDWcZGi KAo0PQAt07YQLgJJefnrWXq0nqSkNkdx4Vqx6aBflIYzj/OG5PDd3G0w6q0g4yklQ8O+toweJAmd pWQxNH48Tvqh0eMCkBlAlMChsYXcuLt9/+5mHZMcTyGTjj2JQXi8zpKhsRQii02TJ0uIAb/GacIo p3NxnVBs0vk8TaC5pmxmOpZtFV8ZownkXOJ8BGQFuFHBJZvj0GYMrGWwAvTMZAmYgJsdht0ZxDcj M3wJhPep0QwSOTmnDAMhf9nCxIA95Vlf4mZApNMUpWIrIa2ghqFDI2ckriD6TSoqJC5TqYY6gh2z bhkypkmOIRHFiiaDSOZACV+mWVNT/Fo0ObmsQVaHSKwwqv3Wme2ddiDG5a7sAI9Jv9pKjMrMDyPa 1hE7oiCaiGNSaK9ZZ4JBSnYLv6o0z4pr+90AnD2AgMNuEH4FYfIt3l2NdbY4bZc/MZpnO7T0NLQH 8tRgqYbVAas6Lc9PMD8tme9LkMmrjJP4YUEoA1MkM5J735Pb1yt2oKduiXEr2ymYcsFAIr7muNf6 e5gNDdmWZUjMoOzFTBnLzjuaC8g+MAielItCITydyfAVQEPDnVj3nmfdG6aawTkS6Re4guhxm8Ha p7AiZS29BM5QPReNfM9yJ6NyBq3URCqHeq0il9rZLr3kozDBjXEGkxSDClpGPsJNM3dlXzf2z0lt RXAuSnP2jakhJYqPMsuEfFvWIV4CsijeJ28QKF+zcWbVMKFEcOWZEqGymANJs4TlGUjUm1Wt16/y Xjc8LK/CLMDMIr+X/O3z8L9yOpfA9pygVYOB7Z69BlH07xI45XFr0Z3mCMFqjRdsf//81ZWq40SD E6kepuBqp+DaA18rhbJ16KTgWb6rlYKvn0LktvvGuSkE2in4oRVqpTDQTiEIwlM712EKoXYKAz/w zkzBbD31KvagDlDnuLMOGFh+5LkfxiWv7jpgfB84E39UvLXtkr+RDvCjdlfVoQOOeQPfTgaErqNd BRylhPTLgNBT4vd/VgF2ZOmloF8FOFGgl8IFVIDl6KVwARVghXopXEAF2Jqv8wVUgHP267yvAkjx +pP61VemlhSoMy2atll47oWVvfmvYdbzsHIslcTtHwAAAP//AwBQSwMEFAAGAAgAAAAhALoMpmDE AQAAaAYAABkAAAB3b3JkL2NvbW1lbnRzRXh0ZW5kZWQueG1spJVbb4IwGIbvl+w/kN5rqRMPZGjc dIvX235ALVUa6SFtFf33K8pBZ2JgXkGh7/O99G0/XqcHnnp7qg2TIgKo6wOPCiJjJjYR+Pn+6IyA ZywWMU6loBE4UgOmk+en1wwFIZGcU2HN4uA5jDBhpkgEEmtVCKEhCeXYdDkjWhq5tl03Hcr1mhEK M6lj2PORf7pTWhJqjKv5jsUeG1DgyKEZLdY4c+Ic2IckwdrSQ81ArSEBHMPRXxC//TSpqHAv11Jz bN1QbyDHertTHcdV2LIVS5k9OqQ/KDEyAjstwgLRqazkkvBspbiUCt2k7lkyl2SXJ3KqCDVNnQcp TMJUtab8vzT3Mikh+3sfsedpOS9TqP/YhpifU6mBTewXUfL07Pw+EfkNEskRlaKJheuapROOmagL /2tpLhYXBe0AvRvAwNB2iKBAQHPk9dHI1OaxlD+13Kmaxh6jLcW2YuU9qwWr2C2XO9g8ZuYrwcod ZU7C5UZIjVepc+Sy91x83ikBLz8lYHLZUV1DzUcKa7yMI9Drz16C+cz15vxpfGrEPoB3JbP+2ygY D9tIFoE/G7+jFpLBcDRHw8XbjQRe/x4mvwAAAP//AwBQSwMEFAAGAAgAAAAhANztC9mcAQAADwMA ABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AIxSTWvcMBC9F/ofhE4tVCt7t2k3xuvQpqSXBArZktKbkMYbEesDaTZe//taytrJlhxyHN7HPM1T fXEwHXmEELWzG1ouCkrASqe03W3o7+0VW1MSUVglOmdhQweI9KJ5/66WvpIuwK/gPATUEMnoZGMl /YbeI/qK8yjvwYi4GBl2BFsXjMBxDDvuhXwQO+DLovjCDaBQAgVPhszPjvRoqeRs6fehywZKcujA gMXIy0XJn7kIwcRXBRl5wTQaBw+vUidwZh+inol93y/6VaaO+Uv+5+b6Nj+VaZtuJYE2tZIVauyg UUG0yDRgy0AGjSxqozsRWOekwPHsrDgnjHwj1+52S+CAYFMZBB0JgPtgiXTGd4BAxhrIUU0mNdG2 dTWf16XFMoBAF5oPHzMwjamzBxh6F1TM2Ms5gZ2IeDN232pQ34fmUgRnP5Gf+yFT/0OTIMCjTmGb VWbMY32s4Wk1KDKer3o69oTcrS5/bK9osyyWJSvWbPl1W55X5eeqKP6m1Cf6Z0NzDPBmx7P1qeNk 0OTEp1+4+QcAAP//AwBQSwECLQAUAAYACAAAACEAhJ8ZlLsBAAA/CgAAEwAAAAAAAAAAAAAAAAAA AAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQCZVX4F/gAAAOECAAALAAAAAAAA AAAAAAAAAPQDAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQCoTqC87wMAAI8pAAAcAAAAAAAA AAAAAAAAACMHAAB3b3JkL19yZWxzL2RvY3VtZW50LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAHKl jUVabgAAZuYDABEAAAAAAAAAAAAAAAAAVAwAAHdvcmQvZG9jdW1lbnQueG1sUEsBAi0AFAAGAAgA AAAhAP8BM+fiAwAA2A4AABAAAAAAAAAAAAAAAAAA3XoAAHdvcmQvZm9vdGVyMi54bWxQSwECLQAU AAYACAAAACEANg+INoQEAAA/EQAAEAAAAAAAAAAAAAAAAADtfgAAd29yZC9mb290ZXIxLnhtbFBL AQItABQABgAIAAAAIQAUURW56wMAAOIOAAAQAAAAAAAAAAAAAAAAAJ+DAAB3b3JkL2hlYWRlcjEu eG1sUEsBAi0AFAAGAAgAAAAhAKDbs9oCAgAAEwcAABIAAAAAAAAAAAAAAAAAuIcAAHdvcmQvZm9v dG5vdGVzLnhtbFBLAQItABQABgAIAAAAIQAYBtL9AgIAAA0HAAARAAAAAAAAAAAAAAAAAOqJAAB3 b3JkL2VuZG5vdGVzLnhtbFBLAQItABQABgAIAAAAIQCWta3i8QUAAFAbAAAVAAAAAAAAAAAAAAAA ABuMAAB3b3JkL3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEA+e4ilzkDAABQDAAAEQAA AAAAAAAAAAAAAAA/kgAAd29yZC9jb21tZW50cy54bWxQSwECLQAUAAYACAAAACEAQr1viQ4EAADq CgAAEQAAAAAAAAAAAAAAAACnlQAAd29yZC9zZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEABQ4K qPkAAAANAgAAFAAAAAAAAAAAAAAAAADkmQAAd29yZC93ZWJTZXR0aW5ncy54bWxQSwECLQAUAAYA CAAAACEAinm/9CgCAABOBAAAEAAAAAAAAAAAAAAAAAAPmwAAZG9jUHJvcHMvYXBwLnhtbFBLAQIt ABQABgAIAAAAIQAJg4oy9wwAAJJ+AAAPAAAAAAAAAAAAAAAAAG2eAAB3b3JkL3N0eWxlcy54bWxQ SwECLQAUAAYACAAAACEAGNtjBywBAACTAgAAEwAAAAAAAAAAAAAAAACRqwAAZG9jUHJvcHMvY3Vz dG9tLnhtbFBLAQItABQABgAIAAAAIQB8MyCpEAIAAE0HAAASAAAAAAAAAAAAAAAAAPatAAB3b3Jk L2ZvbnRUYWJsZS54bWxQSwECLQAUAAYACAAAACEApkUKpeYBAAAoBgAADwAAAAAAAAAAAAAAAAA2 sAAAd29yZC9wZW9wbGUueG1sUEsBAi0AFAAGAAgAAAAhALtYaVNdAwAAEhYAABIAAAAAAAAAAAAA AAAASbIAAHdvcmQvbnVtYmVyaW5nLnhtbFBLAQItABQABgAIAAAAIQC6DKZgxAEAAGgGAAAZAAAA AAAAAAAAAAAAANa1AAB3b3JkL2NvbW1lbnRzRXh0ZW5kZWQueG1sUEsBAi0AFAAGAAgAAAAhANzt C9mcAQAADwMAABEAAAAAAAAAAAAAAAAA0bcAAGRvY1Byb3BzL2NvcmUueG1sUEsFBgAAAAAVABUA PgUAAKS6AAAAAA== --_004_6fdb8f42317d4dfc99783a4d834b6c85bellca_-- From nobody Fri Aug 27 13:27:07 2021 Return-Path: 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 CC9323A162A for ; Fri, 27 Aug 2021 13:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, 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 GKqRgh03B8bx for ; Fri, 27 Aug 2021 13:26:59 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9C16B3A1628 for ; Fri, 27 Aug 2021 13:26:59 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 27 Aug 2021 13:26:58 -0700 From: "Randall Gellens" To: "Caron, Guy" Cc: "Brian Rosen" , "Caron, Guy" , ECRIT Date: Fri, 27 Aug 2021 13:26:58 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <15C9A523-5C22-44BD-A931-9056381C10BC@randy.pensive.org> In-Reply-To: References: <1120BD41-A143-4AC1-B1A7-6CFF40658FF7@randy.pensive.org> <26184A64-2B40-4230-A09B-9A2D00D5F150@brianrosen.net> <0a255415fb484766990e467518d50ed3@bell.ca> <0c8729663d2d458994d40a2e6334c3d8@bell.ca> <63CCAD69-474C-4D7C-9DFB-618446ABF143@brianrosen.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2021 20:27:06 -0000 I don't see any benefit to changing "invalidated" to "impacted", but if you want a neutral term, just call it "notification" or "revalidateNotification". It's a notification that the client should revalidate any of its records for which notification was requested and for which the ID was returned when notification was requested. --Randall On 27 Aug 2021, at 10:23, Caron, Guy wrote: > Yes. The Client requesting notification of planned changes only needs > to store the ID against locations it validates. > > Thanks, > > Guy > > -----Message d'origine----- > De : Brian Rosen > Envoyé : 27 août 2021 13:18 > À : Caron, Guy > Cc : Caron, Guy ; Randall Gellens > ; ECRIT > Objet : [EXT]Re: [Ecrit] Problem in -planned-changes: unique records > in LoST server may not match unique records in LIS > > Good idea. I’ll do it that way: the response contains an ID which > is also present in the Notification. The client still has to > recognize that more than one of its records may have the same ID, but > it is simpler for both, I agree. > > Brian > >> On Aug 27, 2021, at 1:10 PM, Caron, Guy wrote: >> >> Less burden on the Servers too since they would no longer need to >> replace the URI. >> >> Guy >> >> -----Message d'origine----- >> De : Ecrit De la part de Caron, Guy Envoyé >> : >> 27 août 2021 13:08 À : Brian Rosen ; Randall >> Gellens Cc : ECRIT Objet >> : [EXT]Re: [Ecrit] Problem in -planned-changes: unique records in >> LoST >> server may not match unique records in LIS >> >> I too prefer the solution with an ID. >> >> One side benefit to this solution is that the Client no longer needs >> a different URI for each location it validates. It only need a >> generic one (but specific to itself) since the revalidation request >> to the Server will include the ID received in the >> field of the notification. >> >> Less burden on the Clients. We may want to say that. >> >> I still think we need to change to something like >> . >> >> Thanks, >> >> Guy >> >> -----Message d'origine----- >> De : Ecrit De la part de Brian Rosen Envoyé >> : >> 25 août 2021 17:58 À : Randall Gellens >> Cc >> : ECRIT Objet : [EXT]Re: [Ecrit] Problem in >> -planned-changes: unique records in LoST server may not match unique >> records in LIS >> >> Yeah, of the two options, I like the second. I would like to wait to >> here from Guy, who didn’t like either. >> >> Either of the two I came up with can be added quickly to the doc. >> >> Brian >> >> >>> On Aug 25, 2021, at 5:56 PM, Randall Gellens >>> wrote: >>> >>> Either approach would work: the server returning the prior URI if it >>> replaces it, or the server always returning a "unique location ID" >>> whenever it stores a URI. In the latter case, we'd want to add this >>> ID to the object. The latter seems a bit >>> cleaner, as then the server always returns an ID, and a client >>> always stores this ID whenever it sends a URI, and uses the ID to >>> re-validate locations when it gets a object. >>> >>> --Randall >>> >>> On 24 Aug 2021, at 13:08, Brian Rosen wrote: >>> >>>> I realized we have a problem with -planned-changes. The text >>>> notes: >>>> Each client of the server may only store one URI against a >>>> location, where “location†is defined by policy at the server, >>>> since a given unique location may have many combinations of >>>> location elements that resolve to the same location. If the server >>>> receives a ‘uri’ for the same location from the same client, >>>> the URI in the request replaces the URI it previously retained. >>>> >>>> But this means that multiple records in the LIS may be one record >>>> in the LoST server and when the LIS associates unique URIs with >>>> what it thinks is multiple records, only one is retained and it >>>> doesn’t know that. >>>> >>>> The easiest fix is to return the replaced URI. The client would >>>> then be able to spot that the records are linked and do the book >>>> keeping to track what it should do. >>>> Another way to fix this is to return a unique ID of the record in >>>> the LoST server when you use the extension. The LIS can then keep >>>> an internal record of all the related entries it has that are one >>>> record to the server. >>>> >>>> Brian >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> ---------------------------------------------------------------------- >> -------- External Email: Please use caution when opening links and >> attachments / Courriel externe: Soyez prudent avec les liens et >> documents joints _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> ---------------------------------------------------------------------- >> -------- External Email: Please use caution when opening links and >> attachments / Courriel externe: Soyez prudent avec les liens et >> documents joints > > ------------------------------------------------------------------------------ > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints From nobody Fri Aug 27 13:33:41 2021 Return-Path: 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 4E0943A16D3 for ; Fri, 27 Aug 2021 13:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-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=bell.ca 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 1QAZMmwJCwPa for ; Fri, 27 Aug 2021 13:33:34 -0700 (PDT) Received: from ESA4-Dor.bell.ca (esa4-dor.bell.ca [204.101.223.61]) (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 0A1603A16D2 for ; Fri, 27 Aug 2021 13:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1630096414; x=1661632414; h=from:to:cc:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=Fbfvu5qTWeP8wkEa9tMKKGp0fZC1w7onCcBRliZJhjo=; b=eTunn8/bdNbItiecxMcV4eCVKaRAcxhNxUou1fNvEBd37lB0yC44d3SJ wxLmRIq5T62fyraVngoK+d3qE2JhMFjo5sFgSOEb+rFSV3QbwQK/HkM1b Pbz/ob5d/ZxTCnYL4SfDa4hcYU5Um9OiZ0HTyTd+weu/Vo2wTILhi+p29 1DpQMa56fTYcr07pofVk7zn9Cy/IauHQCllhQEXXlrjSae/++YfxRpKBQ wPZ/cKgBmrp+TtRTIhbLpfDogD3845+8UlXukqV40ii3D+VeLw6n0Rccn hrJPAVGMO60EHHg8yEfvKrANhfGggvcHBGOzV+e5UpzxpzxnAycexxpH+ w==; IronPort-SDR: k46ue5bigtgOv9Fj7VbxxjQ9N+gpIa4PbtoWk9V+fjZujE5fkcuHKwXH1o00LKf69uBTjT2SLd osBYLveeTZog== Received: from dc5cmz-d01.bellca.int.bell.ca (HELO DG4MBX01-WYN.bell.corp.bce.ca) ([198.235.121.232]) by esa04corp-dor.bell.corp.bce.ca with ESMTP; 27 Aug 2021 16:33:32 -0400 Received: from DG12MBX04-WYN.bell.corp.bce.ca (142.182.18.49) by DG4MBX01-WYN.bell.corp.bce.ca (142.182.18.27) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Fri, 27 Aug 2021 16:33:31 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX04-WYN.bell.corp.bce.ca (142.182.18.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Fri, 27 Aug 2021 16:33:31 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Fri, 27 Aug 2021 16:33:31 -0400 From: "Caron, Guy" To: Randall Gellens CC: Brian Rosen , "Caron, Guy" , ECRIT Thread-Topic: [EXT]Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS Thread-Index: AQHXm4HkzxSyi5E9eU6NhJYRvaNShquHzSxA Date: Fri, 27 Aug 2021 20:33:31 +0000 Message-ID: <8db1469d73e344489db561ca22da84fe@bell.ca> References: <1120BD41-A143-4AC1-B1A7-6CFF40658FF7@randy.pensive.org> <26184A64-2B40-4230-A09B-9A2D00D5F150@brianrosen.net> <0a255415fb484766990e467518d50ed3@bell.ca> <0c8729663d2d458994d40a2e6334c3d8@bell.ca> <63CCAD69-474C-4D7C-9DFB-618446ABF143@brianrosen.net> <15C9A523-5C22-44BD-A931-9056381C10BC@randy.pensive.org> In-Reply-To: <15C9A523-5C22-44BD-A931-9056381C10BC@randy.pensive.org> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.112.69] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2021 20:33:41 -0000 IkludmFsaWRhdGVkIiBpbmRpY2F0ZXMgZXhwbGljaXRseSB0aGF0IHRoZSBsb2NhdGlvbiBpcyAg bm93IGludmFsaWQgd2hlcmVieSBJbXBhY3RlZCBpbmRpY2F0ZXMgdGhhdCBpdCBtYXkgYmUgaW52 YWxpZGF0ZWQuIEkgc2VlIGEgYmlnIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgdHdvLg0KDQpUaGF0 IHNhaWQsIEkgY291bGQgZ28gd2l0aCBzb21ldGhpbmcgbGlrZSA8cmV2YWxpZGF0ZUxvY2F0aW9u Piwgd2hpY2ggd291bGQgYmUgaW5kaWNhdGl2ZSBvZiB0aGUgYWN0aW9uIHRvIHRha2UgYnkgdGhl IENsaWVudCByYXRoZXIgdGhhbiB0aGUgc3RhdHVzIG9mIHRoZSBsb2NhdGlvbi4NCg0KR3V5DQoN Ci0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogUmFuZGFsbCBHZWxsZW5zIDxyZytp ZXRmQHJhbmR5LnBlbnNpdmUub3JnPiANCkVudm95w6nCoDogMjcgYW/Du3QgMjAyMSAxNjoyNw0K w4DCoDogQ2Fyb24sIEd1eSA8Zy5jYXJvbkBiZWxsLmNhPg0KQ2PCoDogQnJpYW4gUm9zZW4gPGJy QGJyaWFucm9zZW4ubmV0PjsgQ2Fyb24sIEd1eSA8Zy5jYXJvbj00MGJlbGwuY2FAZG1hcmMuaWV0 Zi5vcmc+OyBFQ1JJVCA8ZWNyaXRAaWV0Zi5vcmc+DQpPYmpldMKgOiBbRVhUXVJlOiBbRWNyaXRd IFByb2JsZW0gaW4gLXBsYW5uZWQtY2hhbmdlczogdW5pcXVlIHJlY29yZHMgaW4gTG9TVCBzZXJ2 ZXIgbWF5IG5vdCBtYXRjaCB1bmlxdWUgcmVjb3JkcyBpbiBMSVMNCg0KSSBkb24ndCBzZWUgYW55 IGJlbmVmaXQgdG8gY2hhbmdpbmcgImludmFsaWRhdGVkIiB0byAiaW1wYWN0ZWQiLCBidXQgaWYg eW91IHdhbnQgYSBuZXV0cmFsIHRlcm0sIGp1c3QgY2FsbCBpdCAibm90aWZpY2F0aW9uIiBvciAi cmV2YWxpZGF0ZU5vdGlmaWNhdGlvbiIuICBJdCdzIGEgbm90aWZpY2F0aW9uIHRoYXQgdGhlIGNs aWVudCBzaG91bGQgcmV2YWxpZGF0ZSBhbnkgb2YgaXRzIHJlY29yZHMgZm9yIHdoaWNoIG5vdGlm aWNhdGlvbiB3YXMgcmVxdWVzdGVkIGFuZCBmb3Igd2hpY2ggdGhlIElEIHdhcyByZXR1cm5lZCB3 aGVuIG5vdGlmaWNhdGlvbiB3YXMgcmVxdWVzdGVkLg0KDQotLVJhbmRhbGwNCg0KT24gMjcgQXVn IDIwMjEsIGF0IDEwOjIzLCBDYXJvbiwgR3V5IHdyb3RlOg0KDQo+IFllcy4gVGhlIENsaWVudCBy ZXF1ZXN0aW5nIG5vdGlmaWNhdGlvbiBvZiBwbGFubmVkIGNoYW5nZXMgb25seSBuZWVkcyANCj4g dG8gc3RvcmUgdGhlIElEIGFnYWluc3QgbG9jYXRpb25zIGl0IHZhbGlkYXRlcy4NCj4NCj4gVGhh bmtzLA0KPg0KPiBHdXkNCj4NCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6 IEJyaWFuIFJvc2VuIDxickBicmlhbnJvc2VuLm5ldD4NCj4gRW52b3nDqcKgOiAyNyBhb8O7dCAy MDIxIDEzOjE4DQo+IMOAwqA6IENhcm9uLCBHdXkgPGcuY2Fyb25AYmVsbC5jYT4NCj4gQ2PCoDog Q2Fyb24sIEd1eSA8Zy5jYXJvbj00MGJlbGwuY2FAZG1hcmMuaWV0Zi5vcmc+OyBSYW5kYWxsIEdl bGxlbnMgDQo+IDxyZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnPjsgRUNSSVQgPGVjcml0QGlldGYu b3JnPiBPYmpldMKgOiBbRVhUXVJlOiANCj4gW0Vjcml0XSBQcm9ibGVtIGluIC1wbGFubmVkLWNo YW5nZXM6IHVuaXF1ZSByZWNvcmRzIGluIExvU1Qgc2VydmVyIG1heSANCj4gbm90IG1hdGNoIHVu aXF1ZSByZWNvcmRzIGluIExJUw0KPg0KPiBHb29kIGlkZWEuICBJ4oCZbGwgZG8gaXQgdGhhdCB3 YXk6IHRoZSByZXNwb25zZSBjb250YWlucyBhbiBJRCB3aGljaCBpcyANCj4gYWxzbyBwcmVzZW50 IGluIHRoZSBOb3RpZmljYXRpb24uICBUaGUgY2xpZW50IHN0aWxsIGhhcyB0byByZWNvZ25pemUg DQo+IHRoYXQgbW9yZSB0aGFuIG9uZSBvZiBpdHMgcmVjb3JkcyBtYXkgaGF2ZSB0aGUgc2FtZSBJ RCwgYnV0IGl0IGlzIA0KPiBzaW1wbGVyIGZvciBib3RoLCBJIGFncmVlLg0KPg0KPiBCcmlhbg0K Pg0KPj4gT24gQXVnIDI3LCAyMDIxLCBhdCAxOjEwIFBNLCBDYXJvbiwgR3V5IDxnLmNhcm9uQGJl bGwuY2E+IHdyb3RlOg0KPj4NCj4+IExlc3MgYnVyZGVuIG9uIHRoZSBTZXJ2ZXJzIHRvbyBzaW5j ZSB0aGV5IHdvdWxkIG5vIGxvbmdlciBuZWVkIHRvIA0KPj4gcmVwbGFjZSB0aGUgVVJJLg0KPj4N Cj4+IEd1eQ0KPj4NCj4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4gRGUgOiBFY3Jp dCA8ZWNyaXQtYm91bmNlc0BpZXRmLm9yZz4gRGUgbGEgcGFydCBkZSBDYXJvbiwgR3V5IEVudm95 w6kNCj4+IDoNCj4+IDI3IGFvw7t0IDIwMjEgMTM6MDggw4AgOiBCcmlhbiBSb3NlbiA8YnJAYnJp YW5yb3Nlbi5uZXQ+OyBSYW5kYWxsIA0KPj4gR2VsbGVucyA8cmcraWV0ZkByYW5keS5wZW5zaXZl Lm9yZz4gQ2MgOiBFQ1JJVCA8ZWNyaXRAaWV0Zi5vcmc+IE9iamV0DQo+PiA6IFtFWFRdUmU6IFtF Y3JpdF0gUHJvYmxlbSBpbiAtcGxhbm5lZC1jaGFuZ2VzOiB1bmlxdWUgcmVjb3JkcyBpbiANCj4+ IExvU1Qgc2VydmVyIG1heSBub3QgbWF0Y2ggdW5pcXVlIHJlY29yZHMgaW4gTElTDQo+Pg0KPj4g SSB0b28gcHJlZmVyIHRoZSBzb2x1dGlvbiB3aXRoIGFuIElELg0KPj4NCj4+IE9uZSBzaWRlIGJl bmVmaXQgdG8gdGhpcyBzb2x1dGlvbiBpcyB0aGF0IHRoZSBDbGllbnQgbm8gbG9uZ2VyIG5lZWRz IA0KPj4gYSBkaWZmZXJlbnQgVVJJIGZvciBlYWNoIGxvY2F0aW9uIGl0IHZhbGlkYXRlcy4gSXQg b25seSBuZWVkIGEgDQo+PiBnZW5lcmljIG9uZSAoYnV0IHNwZWNpZmljIHRvIGl0c2VsZikgc2lu Y2UgdGhlIHJldmFsaWRhdGlvbiByZXF1ZXN0IA0KPj4gdG8gdGhlIFNlcnZlciB3aWxsIGluY2x1 ZGUgdGhlIElEIHJlY2VpdmVkIGluIHRoZSANCj4+IDxsb2NhdGlvbkludmFsaWRhdGVkPiBmaWVs ZCBvZiB0aGUgbm90aWZpY2F0aW9uLg0KPj4NCj4+IExlc3MgYnVyZGVuIG9uIHRoZSBDbGllbnRz LiBXZSBtYXkgd2FudCB0byBzYXkgdGhhdC4NCj4+DQo+PiBJIHN0aWxsIHRoaW5rIHdlIG5lZWQg dG8gY2hhbmdlIDxsb2NhdGlvbkludmFsaWRlZD4gdG8gc29tZXRoaW5nIGxpa2UgDQo+PiA8bG9j YXRpb25JbXBhY3RlZD4uDQo+Pg0KPj4gVGhhbmtzLA0KPj4NCj4+IEd1eQ0KPj4NCj4+IC0tLS0t TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4gRGUgOiBFY3JpdCA8ZWNyaXQtYm91bmNlc0BpZXRm Lm9yZz4gRGUgbGEgcGFydCBkZSBCcmlhbiBSb3NlbiBFbnZvecOpDQo+PiA6DQo+PiAyNSBhb8O7 dCAyMDIxIDE3OjU4IMOAIDogUmFuZGFsbCBHZWxsZW5zIDxyZytpZXRmQHJhbmR5LnBlbnNpdmUu b3JnPiBDYw0KPj4gOiBFQ1JJVCA8ZWNyaXRAaWV0Zi5vcmc+IE9iamV0IDogW0VYVF1SZTogW0Vj cml0XSBQcm9ibGVtIGluDQo+PiAtcGxhbm5lZC1jaGFuZ2VzOiB1bmlxdWUgcmVjb3JkcyBpbiBM b1NUIHNlcnZlciBtYXkgbm90IG1hdGNoIHVuaXF1ZSANCj4+IHJlY29yZHMgaW4gTElTDQo+Pg0K Pj4gWWVhaCwgb2YgdGhlIHR3byBvcHRpb25zLCBJIGxpa2UgdGhlIHNlY29uZC4gIEkgd291bGQg bGlrZSB0byB3YWl0IHRvIA0KPj4gaGVyZSBmcm9tIEd1eSwgd2hvIGRpZG7igJl0IGxpa2UgZWl0 aGVyLg0KPj4NCj4+IEVpdGhlciBvZiB0aGUgdHdvIEkgY2FtZSB1cCB3aXRoIGNhbiBiZSBhZGRl ZCBxdWlja2x5IHRvIHRoZSBkb2MuDQo+Pg0KPj4gQnJpYW4NCj4+DQo+Pg0KPj4+IE9uIEF1ZyAy NSwgMjAyMSwgYXQgNTo1NiBQTSwgUmFuZGFsbCBHZWxsZW5zIA0KPj4+IDxyZytpZXRmQHJhbmR5 LnBlbnNpdmUub3JnPiB3cm90ZToNCj4+Pg0KPj4+IEVpdGhlciBhcHByb2FjaCB3b3VsZCB3b3Jr OiB0aGUgc2VydmVyIHJldHVybmluZyB0aGUgcHJpb3IgVVJJIGlmIGl0IA0KPj4+IHJlcGxhY2Vz IGl0LCBvciB0aGUgc2VydmVyIGFsd2F5cyByZXR1cm5pbmcgYSAidW5pcXVlIGxvY2F0aW9uIElE Ig0KPj4+IHdoZW5ldmVyIGl0IHN0b3JlcyBhIFVSSS4gIEluIHRoZSBsYXR0ZXIgY2FzZSwgd2Un ZCB3YW50IHRvIGFkZCB0aGlzIA0KPj4+IElEIHRvIHRoZSA8bG9jYXRpb25JbnZhbGlkYXRlZD4g b2JqZWN0LiAgVGhlIGxhdHRlciBzZWVtcyBhIGJpdCANCj4+PiBjbGVhbmVyLCBhcyB0aGVuIHRo ZSBzZXJ2ZXIgYWx3YXlzIHJldHVybnMgYW4gSUQsIGFuZCBhIGNsaWVudCANCj4+PiBhbHdheXMg c3RvcmVzIHRoaXMgSUQgd2hlbmV2ZXIgaXQgc2VuZHMgYSBVUkksIGFuZCB1c2VzIHRoZSBJRCB0 byANCj4+PiByZS12YWxpZGF0ZSBsb2NhdGlvbnMgd2hlbiBpdCBnZXRzIGEgPGxvY2F0aW9uSW52 YWxpZGF0ZWQ+IG9iamVjdC4NCj4+Pg0KPj4+IC0tUmFuZGFsbA0KPj4+DQo+Pj4gT24gMjQgQXVn IDIwMjEsIGF0IDEzOjA4LCBCcmlhbiBSb3NlbiB3cm90ZToNCj4+Pg0KPj4+PiBJIHJlYWxpemVk IHdlIGhhdmUgYSBwcm9ibGVtIHdpdGggLXBsYW5uZWQtY2hhbmdlcy4gIFRoZSB0ZXh0DQo+Pj4+ IG5vdGVzOg0KPj4+PiBFYWNoIGNsaWVudCBvZiB0aGUgc2VydmVyIG1heSBvbmx5IHN0b3JlIG9u ZSBVUkkgYWdhaW5zdCBhIA0KPj4+PiBsb2NhdGlvbiwgd2hlcmUg4oCcbG9jYXRpb27igJ0gaXMg ZGVmaW5lZCBieSBwb2xpY3kgYXQgdGhlIHNlcnZlciwgDQo+Pj4+IHNpbmNlIGEgZ2l2ZW4gdW5p cXVlIGxvY2F0aW9uIG1heSBoYXZlIG1hbnkgY29tYmluYXRpb25zIG9mIA0KPj4+PiBsb2NhdGlv biBlbGVtZW50cyB0aGF0IHJlc29sdmUgdG8gdGhlIHNhbWUgbG9jYXRpb24uICBJZiB0aGUgc2Vy dmVyIA0KPj4+PiByZWNlaXZlcyBhIOKAmHVyaeKAmSBmb3IgdGhlIHNhbWUgbG9jYXRpb24gZnJv bSB0aGUgc2FtZSBjbGllbnQsIHRoZSANCj4+Pj4gVVJJIGluIHRoZSByZXF1ZXN0IHJlcGxhY2Vz IHRoZSBVUkkgaXQgcHJldmlvdXNseSByZXRhaW5lZC4NCj4+Pj4NCj4+Pj4gQnV0IHRoaXMgbWVh bnMgdGhhdCBtdWx0aXBsZSByZWNvcmRzIGluIHRoZSBMSVMgbWF5IGJlIG9uZSByZWNvcmQgDQo+ Pj4+IGluIHRoZSBMb1NUIHNlcnZlciBhbmQgd2hlbiB0aGUgTElTIGFzc29jaWF0ZXMgdW5pcXVl IFVSSXMgd2l0aCANCj4+Pj4gd2hhdCBpdCB0aGlua3MgaXMgbXVsdGlwbGUgcmVjb3Jkcywgb25s eSBvbmUgaXMgcmV0YWluZWQgYW5kIGl0IA0KPj4+PiBkb2VzbuKAmXQga25vdyB0aGF0Lg0KPj4+ Pg0KPj4+PiBUaGUgZWFzaWVzdCBmaXggaXMgdG8gcmV0dXJuIHRoZSByZXBsYWNlZCBVUkkuICBU aGUgY2xpZW50IHdvdWxkIA0KPj4+PiB0aGVuIGJlIGFibGUgdG8gc3BvdCB0aGF0IHRoZSByZWNv cmRzIGFyZSBsaW5rZWQgYW5kIGRvIHRoZSBib29rIA0KPj4+PiBrZWVwaW5nIHRvIHRyYWNrIHdo YXQgaXQgc2hvdWxkIGRvLg0KPj4+PiBBbm90aGVyIHdheSB0byBmaXggdGhpcyBpcyB0byByZXR1 cm4gYSB1bmlxdWUgSUQgb2YgdGhlIHJlY29yZCBpbiANCj4+Pj4gdGhlIExvU1Qgc2VydmVyIHdo ZW4geW91IHVzZSB0aGUgZXh0ZW5zaW9uLiAgVGhlIExJUyBjYW4gdGhlbiBrZWVwIA0KPj4+PiBh biBpbnRlcm5hbCByZWNvcmQgb2YgYWxsIHRoZSByZWxhdGVkIGVudHJpZXMgaXQgaGFzIHRoYXQg YXJlIG9uZSANCj4+Pj4gcmVjb3JkIHRvIHRoZSBzZXJ2ZXIuDQo+Pj4+DQo+Pj4+IEJyaWFuDQo+ Pj4+DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4+IEVjcml0IG1haWxpbmcgbGlzdA0KPj4+PiBFY3JpdEBpZXRmLm9yZw0KPj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+Pg0KPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IEVjcml0IG1haWxpbmcg bGlzdA0KPj4gRWNyaXRAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZWNyaXQNCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gLQ0KPj4gLS0tLS0tLS0gRXh0ZXJu YWwgRW1haWw6IFBsZWFzZSB1c2UgY2F1dGlvbiB3aGVuIG9wZW5pbmcgbGlua3MgYW5kIA0KPj4g YXR0YWNobWVudHMgLyBDb3VycmllbCBleHRlcm5lOiBTb3lleiBwcnVkZW50IGF2ZWMgbGVzIGxp ZW5zIGV0IA0KPj4gZG9jdW1lbnRzIGpvaW50cyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+PiBFY3JpdEBpZXRm Lm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KPj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+PiAtDQo+PiAtLS0tLS0tLSBFeHRlcm5hbCBFbWFpbDogUGxlYXNlIHVz ZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQgDQo+PiBhdHRhY2htZW50cyAvIENvdXJy aWVsIGV4dGVybmU6IFNveWV6IHBydWRlbnQgYXZlYyBsZXMgbGllbnMgZXQgDQo+PiBkb2N1bWVu dHMgam9pbnRzDQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0tLS0tLS0gRXh0ZXJuYWwgRW1haWw6 IFBsZWFzZSB1c2UgY2F1dGlvbiB3aGVuIG9wZW5pbmcgbGlua3MgYW5kIA0KPiBhdHRhY2htZW50 cyAvIENvdXJyaWVsIGV4dGVybmU6IFNveWV6IHBydWRlbnQgYXZlYyBsZXMgbGllbnMgZXQgDQo+ IGRvY3VtZW50cyBqb2ludHMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRXh0ZXJuYWwgRW1haWw6 IFBsZWFzZSB1c2UgY2F1dGlvbiB3aGVuIG9wZW5pbmcgbGlua3MgYW5kIGF0dGFjaG1lbnRzIC8g Q291cnJpZWwgZXh0ZXJuZTogU295ZXogcHJ1ZGVudCBhdmVjIGxlcyBsaWVucyBldCBkb2N1bWVu dHMgam9pbnRzDQo= From nobody Fri Aug 27 14:28:05 2021 Return-Path: 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 A6DFE3A1ABC for ; Fri, 27 Aug 2021 14:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 a6O38Jd5Z9VF for ; Fri, 27 Aug 2021 14:27:56 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE033A1AB5 for ; Fri, 27 Aug 2021 14:27:56 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 27 Aug 2021 14:27:55 -0700 From: "Randall Gellens" To: "Caron, Guy" Cc: "Brian Rosen" , "Caron, Guy" , ECRIT Date: Fri, 27 Aug 2021 14:27:55 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: <8db1469d73e344489db561ca22da84fe@bell.ca> References: <1120BD41-A143-4AC1-B1A7-6CFF40658FF7@randy.pensive.org> <26184A64-2B40-4230-A09B-9A2D00D5F150@brianrosen.net> <0a255415fb484766990e467518d50ed3@bell.ca> <0c8729663d2d458994d40a2e6334c3d8@bell.ca> <63CCAD69-474C-4D7C-9DFB-618446ABF143@brianrosen.net> <15C9A523-5C22-44BD-A931-9056381C10BC@randy.pensive.org> <8db1469d73e344489db561ca22da84fe@bell.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2021 21:28:03 -0000 On 27 Aug 2021, at 13:33, Caron, Guy wrote: > "Invalidated" indicates explicitly that the location is now invalid > whereby Impacted indicates that it may be invalidated. I see a big > difference between the two. Yes, of course there's a difference in meaning. I said I don't see a benefit in changing from one to the other. The location the client previously validated isn't necessarily invalidated nor impacted. > That said, I could go with something like , which > would be indicative of the action to take by the Client rather than > the status of the location. Works for me. Brian, are you OK with this? > -----Message d'origine----- > De : Randall Gellens > Envoyé : 27 août 2021 16:27 > À : Caron, Guy > Cc : Brian Rosen ; Caron, Guy > ; ECRIT > Objet : [EXT]Re: [Ecrit] Problem in -planned-changes: unique records > in LoST server may not match unique records in LIS > > I don't see any benefit to changing "invalidated" to "impacted", but > if you want a neutral term, just call it "notification" or > "revalidateNotification". It's a notification that the client should > revalidate any of its records for which notification was requested and > for which the ID was returned when notification was requested. > > --Randall > > On 27 Aug 2021, at 10:23, Caron, Guy wrote: > >> Yes. The Client requesting notification of planned changes only needs >> to store the ID against locations it validates. >> >> Thanks, >> >> Guy >> >> -----Message d'origine----- >> De : Brian Rosen >> Envoyé : 27 août 2021 13:18 >> À : Caron, Guy >> Cc : Caron, Guy ; Randall Gellens >> ; ECRIT Objet : [EXT]Re: >> [Ecrit] Problem in -planned-changes: unique records in LoST server >> may >> not match unique records in LIS >> >> Good idea. I’ll do it that way: the response contains an ID which >> is >> also present in the Notification. The client still has to recognize >> that more than one of its records may have the same ID, but it is >> simpler for both, I agree. >> >> Brian >> >>> On Aug 27, 2021, at 1:10 PM, Caron, Guy wrote: >>> >>> Less burden on the Servers too since they would no longer need to >>> replace the URI. >>> >>> Guy >>> >>> -----Message d'origine----- >>> De : Ecrit De la part de Caron, Guy Envoyé >>> : >>> 27 août 2021 13:08 À : Brian Rosen ; Randall >>> Gellens Cc : ECRIT >>> Objet >>> : [EXT]Re: [Ecrit] Problem in -planned-changes: unique records in >>> LoST server may not match unique records in LIS >>> >>> I too prefer the solution with an ID. >>> >>> One side benefit to this solution is that the Client no longer needs >>> a different URI for each location it validates. It only need a >>> generic one (but specific to itself) since the revalidation request >>> to the Server will include the ID received in the >>> field of the notification. >>> >>> Less burden on the Clients. We may want to say that. >>> >>> I still think we need to change to something >>> like >>> . >>> >>> Thanks, >>> >>> Guy >>> >>> -----Message d'origine----- >>> De : Ecrit De la part de Brian Rosen >>> Envoyé >>> : >>> 25 août 2021 17:58 À : Randall Gellens >>> Cc >>> : ECRIT Objet : [EXT]Re: [Ecrit] Problem in >>> -planned-changes: unique records in LoST server may not match unique >>> records in LIS >>> >>> Yeah, of the two options, I like the second. I would like to wait >>> to >>> here from Guy, who didn’t like either. >>> >>> Either of the two I came up with can be added quickly to the doc. >>> >>> Brian >>> >>> >>>> On Aug 25, 2021, at 5:56 PM, Randall Gellens >>>> wrote: >>>> >>>> Either approach would work: the server returning the prior URI if >>>> it >>>> replaces it, or the server always returning a "unique location ID" >>>> whenever it stores a URI. In the latter case, we'd want to add >>>> this >>>> ID to the object. The latter seems a bit >>>> cleaner, as then the server always returns an ID, and a client >>>> always stores this ID whenever it sends a URI, and uses the ID to >>>> re-validate locations when it gets a object. >>>> >>>> --Randall >>>> >>>> On 24 Aug 2021, at 13:08, Brian Rosen wrote: >>>> >>>>> I realized we have a problem with -planned-changes. The text >>>>> notes: >>>>> Each client of the server may only store one URI against a >>>>> location, where “location†is defined by policy at the server, >>>>> since a given unique location may have many combinations of >>>>> location elements that resolve to the same location. If the >>>>> server >>>>> receives a ‘uri’ for the same location from the same client, >>>>> the >>>>> URI in the request replaces the URI it previously retained. >>>>> >>>>> But this means that multiple records in the LIS may be one record >>>>> in the LoST server and when the LIS associates unique URIs with >>>>> what it thinks is multiple records, only one is retained and it >>>>> doesn’t know that. >>>>> >>>>> The easiest fix is to return the replaced URI. The client would >>>>> then be able to spot that the records are linked and do the book >>>>> keeping to track what it should do. >>>>> Another way to fix this is to return a unique ID of the record in >>>>> the LoST server when you use the extension. The LIS can then keep >>>>> an internal record of all the related entries it has that are one >>>>> record to the server. >>>>> >>>>> Brian >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> --------------------------------------------------------------------- >>> - >>> -------- External Email: Please use caution when opening links and >>> attachments / Courriel externe: Soyez prudent avec les liens et >>> documents joints _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> --------------------------------------------------------------------- >>> - >>> -------- External Email: Please use caution when opening links and >>> attachments / Courriel externe: Soyez prudent avec les liens et >>> documents joints >> >> ---------------------------------------------------------------------- >> -------- External Email: Please use caution when opening links and >> attachments / Courriel externe: Soyez prudent avec les liens et >> documents joints > ------------------------------------------------------------------------------ > External Email: Please use caution when opening links and attachments > / Courriel externe: Soyez prudent avec les liens et documents joints From nobody Fri Aug 27 14:41:14 2021 Return-Path: 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 2DDE13A1B1C for ; Fri, 27 Aug 2021 14:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01] 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 wtq-LBS5HqP9 for ; Fri, 27 Aug 2021 14:41:10 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5813A1B1A for ; Fri, 27 Aug 2021 14:41:10 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Fri, 27 Aug 2021 14:41:09 -0700 From: "Randall Gellens" To: ECRIT Date: Fri, 27 Aug 2021 14:41:09 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: [Ecrit] planned-changes: two questions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2021 21:41:13 -0000 I think we're moving to a model where: - In a query, a client can request to be notified when the location should be revalidated; - In the response, the server provides an ID which the client associates with the location it just validated; - The server sends a notification to the URI, containing the ID; - The client revalidates each location with which that ID is associated. Question 1: Does the server delete/inactivate the URI once it has sent the notification? Question 2: Presumably, when the client revalidates the location(s), it will again request notification. Does the server return the same ID as before, or a different ID? A different ID could perhaps be useful in edge cases where the server didn't send or the client didn't get the notification, but any utility seems small. If it's the same ID, then the answer to question 1 can be that the URI remains active until the client asks to no longer be notified (by sending an empty URI?). --Randall From nobody Mon Aug 30 05:39:04 2021 Return-Path: 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 9E6D83A0DBA for ; Mon, 30 Aug 2021 05:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.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 BJgsEnuVjbo9 for ; Mon, 30 Aug 2021 05:38:56 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 C3B263A0DBB for ; Mon, 30 Aug 2021 05:38:56 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id y18so19687922ioc.1 for ; Mon, 30 Aug 2021 05:38:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xsx6uRRMh+LrZtsNxGAU8Oo/ccEf7Yg3/wtRFN/TSq0=; b=0fLhO+jPhBzia/FOEet77D819jazCKFXyTI6lPlFNFpMtSPMiS1eEgZyE7hM3UPy2k YN+y6VW2sHO0D5lVHjjRU2aBMcWPedOmPDmWinN3tmuTqiIHR2ROToDE3V7yna639tXL dCio68dVddgCTqfi4dA7Z0Zyc3RolOpk0JVUTaljAS4fwbQ2eQay5FO2NUJK4LgZXZGZ +QdqeMMZDcsPkYss0jFUgf9ns9IBrYbQMslGXx0Bz8Cekm1scsWvitGQELiIDMCJvcO5 W0ui9Luv7qoQ1phi8jui3HaUeC50l1GYZQe0AhfRJ/rF+cK6SV0VZOzZgRoiovFuh9m6 jjDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xsx6uRRMh+LrZtsNxGAU8Oo/ccEf7Yg3/wtRFN/TSq0=; b=d2K3y4NxUX64lSJskIpnrZc+eaDTxaHozUYTqXoZ61JOVJCuKHKDXTOYUFwVY/awUl g4oNzWs1yMaxgNEPcFOfrvgzO2rZhBnJrr1pW2rYveLcb6+A4ILvuvqVY/IfqqqySbrv nQHbRehHUKy7iStdHqYLeqe7/rEGrzxKSFV0Vc24qJ6kq/Ahk7JBCxTVvlngmykHRecE QtBawtLsvNdaX7wRTWuCbX/EvOOLQJ3PuC8UEG0zAuUKuOiDuRoAC2b80wA+s8rJyK6f XNi353LC5kDGY0LLO6BUo2SLROt21ebESy0wh3fZQ6BlHwhlyENgkOxH6vEE9aZhmhx9 2vkQ== X-Gm-Message-State: AOAM530w96vWWZD+rlCxVZVi4fmFFeVhQ7ObFdGFnb1iWIwrQNO9r7V9 xkK7y4tx4qp2Eymi9/sMnReNRX/L1D71Qbfk X-Google-Smtp-Source: ABdhPJykjo+shrVR4/K9SYm8eUORXHCB9MydebCSFBe7SMScbWOrpHscG+ZRvPfFH+dUKKn5BbrqWw== X-Received: by 2002:a05:6638:5b5:: with SMTP id b21mr5039993jar.109.1630327134961; Mon, 30 Aug 2021 05:38:54 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id x12sm6092485ilm.56.2021.08.30.05.38.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Aug 2021 05:38:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Brian Rosen In-Reply-To: Date: Mon, 30 Aug 2021 08:38:53 -0400 Cc: "Caron, Guy" , "Caron, Guy" , ECRIT Content-Transfer-Encoding: quoted-printable Message-Id: <26F7F4EF-7340-41D2-BEF4-EFB75211878E@brianrosen.net> References: <1120BD41-A143-4AC1-B1A7-6CFF40658FF7@randy.pensive.org> <26184A64-2B40-4230-A09B-9A2D00D5F150@brianrosen.net> <0a255415fb484766990e467518d50ed3@bell.ca> <0c8729663d2d458994d40a2e6334c3d8@bell.ca> <63CCAD69-474C-4D7C-9DFB-618446ABF143@brianrosen.net> <15C9A523-5C22-44BD-A931-9056381C10BC@randy.pensive.org> <8db1469d73e344489db561ca22da84fe@bell.ca> To: Randall Gellens X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Ecrit] Problem in -planned-changes: unique records in LoST server may not match unique records in LIS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2021 12:39:03 -0000 Yeah, I can do that. Brian > On Aug 27, 2021, at 5:27 PM, Randall Gellens = wrote: >=20 > On 27 Aug 2021, at 13:33, Caron, Guy wrote: >=20 >> "Invalidated" indicates explicitly that the location is now invalid = whereby Impacted indicates that it may be invalidated. I see a big = difference between the two. >=20 > Yes, of course there's a difference in meaning. I said I don't see a = benefit in changing from one to the other. The location the client = previously validated isn't necessarily invalidated nor impacted. >=20 >> That said, I could go with something like , which = would be indicative of the action to take by the Client rather than the = status of the location. >=20 > Works for me. Brian, are you OK with this? >=20 >=20 >> -----Message d'origine----- >> De : Randall Gellens >> Envoy=C3=A9 : 27 ao=C3=BBt 2021 16:27 >> =C3=80 : Caron, Guy >> Cc : Brian Rosen ; Caron, Guy = ; ECRIT >> Objet : [EXT]Re: [Ecrit] Problem in -planned-changes: unique records = in LoST server may not match unique records in LIS >>=20 >> I don't see any benefit to changing "invalidated" to "impacted", but = if you want a neutral term, just call it "notification" or = "revalidateNotification". It's a notification that the client should = revalidate any of its records for which notification was requested and = for which the ID was returned when notification was requested. >>=20 >> --Randall >>=20 >> On 27 Aug 2021, at 10:23, Caron, Guy wrote: >>=20 >>> Yes. The Client requesting notification of planned changes only = needs >>> to store the ID against locations it validates. >>>=20 >>> Thanks, >>>=20 >>> Guy >>>=20 >>> -----Message d'origine----- >>> De : Brian Rosen >>> Envoy=C3=A9 : 27 ao=C3=BBt 2021 13:18 >>> =C3=80 : Caron, Guy >>> Cc : Caron, Guy ; Randall = Gellens >>> ; ECRIT Objet : [EXT]Re: >>> [Ecrit] Problem in -planned-changes: unique records in LoST server = may >>> not match unique records in LIS >>>=20 >>> Good idea. I=E2=80=99ll do it that way: the response contains an ID = which is >>> also present in the Notification. The client still has to recognize >>> that more than one of its records may have the same ID, but it is >>> simpler for both, I agree. >>>=20 >>> Brian >>>=20 >>>> On Aug 27, 2021, at 1:10 PM, Caron, Guy wrote: >>>>=20 >>>> Less burden on the Servers too since they would no longer need to >>>> replace the URI. >>>>=20 >>>> Guy >>>>=20 >>>> -----Message d'origine----- >>>> De : Ecrit De la part de Caron, Guy = Envoy=C3=A9 >>>> : >>>> 27 ao=C3=BBt 2021 13:08 =C3=80 : Brian Rosen ; = Randall >>>> Gellens Cc : ECRIT = Objet >>>> : [EXT]Re: [Ecrit] Problem in -planned-changes: unique records in >>>> LoST server may not match unique records in LIS >>>>=20 >>>> I too prefer the solution with an ID. >>>>=20 >>>> One side benefit to this solution is that the Client no longer = needs >>>> a different URI for each location it validates. It only need a >>>> generic one (but specific to itself) since the revalidation request >>>> to the Server will include the ID received in the >>>> field of the notification. >>>>=20 >>>> Less burden on the Clients. We may want to say that. >>>>=20 >>>> I still think we need to change to something = like >>>> . >>>>=20 >>>> Thanks, >>>>=20 >>>> Guy >>>>=20 >>>> -----Message d'origine----- >>>> De : Ecrit De la part de Brian Rosen = Envoy=C3=A9 >>>> : >>>> 25 ao=C3=BBt 2021 17:58 =C3=80 : Randall Gellens = Cc >>>> : ECRIT Objet : [EXT]Re: [Ecrit] Problem in >>>> -planned-changes: unique records in LoST server may not match = unique >>>> records in LIS >>>>=20 >>>> Yeah, of the two options, I like the second. I would like to wait = to >>>> here from Guy, who didn=E2=80=99t like either. >>>>=20 >>>> Either of the two I came up with can be added quickly to the doc. >>>>=20 >>>> Brian >>>>=20 >>>>=20 >>>>> On Aug 25, 2021, at 5:56 PM, Randall Gellens >>>>> wrote: >>>>>=20 >>>>> Either approach would work: the server returning the prior URI if = it >>>>> replaces it, or the server always returning a "unique location ID" >>>>> whenever it stores a URI. In the latter case, we'd want to add = this >>>>> ID to the object. The latter seems a bit >>>>> cleaner, as then the server always returns an ID, and a client >>>>> always stores this ID whenever it sends a URI, and uses the ID to >>>>> re-validate locations when it gets a object. >>>>>=20 >>>>> --Randall >>>>>=20 >>>>> On 24 Aug 2021, at 13:08, Brian Rosen wrote: >>>>>=20 >>>>>> I realized we have a problem with -planned-changes. The text >>>>>> notes: >>>>>> Each client of the server may only store one URI against a >>>>>> location, where =E2=80=9Clocation=E2=80=9D is defined by policy = at the server, >>>>>> since a given unique location may have many combinations of >>>>>> location elements that resolve to the same location. If the = server >>>>>> receives a =E2=80=98uri=E2=80=99 for the same location from the = same client, the >>>>>> URI in the request replaces the URI it previously retained. >>>>>>=20 >>>>>> But this means that multiple records in the LIS may be one record >>>>>> in the LoST server and when the LIS associates unique URIs with >>>>>> what it thinks is multiple records, only one is retained and it >>>>>> doesn=E2=80=99t know that. >>>>>>=20 >>>>>> The easiest fix is to return the replaced URI. The client would >>>>>> then be able to spot that the records are linked and do the book >>>>>> keeping to track what it should do. >>>>>> Another way to fix this is to return a unique ID of the record in >>>>>> the LoST server when you use the extension. The LIS can then = keep >>>>>> an internal record of all the related entries it has that are one >>>>>> record to the server. >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> = --------------------------------------------------------------------- >>>> - >>>> -------- External Email: Please use caution when opening links and >>>> attachments / Courriel externe: Soyez prudent avec les liens et >>>> documents joints _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> = --------------------------------------------------------------------- >>>> - >>>> -------- External Email: Please use caution when opening links and >>>> attachments / Courriel externe: Soyez prudent avec les liens et >>>> documents joints >>>=20 >>> = ---------------------------------------------------------------------- >>> -------- External Email: Please use caution when opening links and >>> attachments / Courriel externe: Soyez prudent avec les liens et >>> documents joints >> = --------------------------------------------------------------------------= ---- >> External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints From nobody Mon Aug 30 08:08:11 2021 Return-Path: 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 EDDF73A15C3 for ; Mon, 30 Aug 2021 08:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=bell.ca 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 DsR0tG4SX9F1 for ; Mon, 30 Aug 2021 08:08:02 -0700 (PDT) Received: from ESA2-Wyn.bell.ca (esa2-wyn.bell.ca [67.69.243.180]) (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 480903A15C1 for ; Mon, 30 Aug 2021 08:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1630336082; x=1661872082; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=3OaGMSVERrI/UehGgOKZF0v+liu8mitujkvawI+ATRo=; b=SzI7ug/m7vdGKAmZZ1wnRe+ieAUp7ovyzv2ow1sSkl5Giw76GLmfL8te agPt4vaGG0TLp6qAdTtdIVzrLVOEqXYbCXFZlBJ6YrmCL7667UAXhmN7W zUYQ2R46AdzlX9Q+2mmPcPjGwIPrqDjW4fA8p9LdnDs3ktwxn2uviI/ni YeU69iGp1m8qaYJqkBGrWZ+9ZniWnej35dDW83ebK39QHmS3pbXMACFFK /xvFIo+j6+7BN2hB3dKgwa/z1HLVoSwdRvQXxdFhe0bOTEeIbizg46/ex 3QY2Tn/NYoWyzg4PkCxvF5LgD+US88EUIirGcwUXck7CUPHDj1pTTOukZ g==; IronPort-SDR: 5KWvcUUgFhPMZdz5tBGGPary/4I5makYCfQO9JVkp+u8YKPb0pYu2LtjdUWi1a2194uAje6WAa XMBe7yYeVQbQ== Received: from dm5czo-d00.bellca.int.bell.ca (HELO DG4MBX02-WYN.bell.corp.bce.ca) ([198.235.102.32]) by esa02corp-wyn.bell.corp.bce.ca with ESMTP; 30 Aug 2021 11:08:00 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG4MBX02-WYN.bell.corp.bce.ca (142.182.18.28) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 30 Aug 2021 11:07:59 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Mon, 30 Aug 2021 11:08:00 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Mon, 30 Aug 2021 11:08:00 -0400 From: "Caron, Guy" To: Randall Gellens , ECRIT Thread-Topic: [EXT][Ecrit] planned-changes: two questions Thread-Index: AQHXm4xEiutevUjX90u7ARN+kxSt5KuMFIuw Date: Mon, 30 Aug 2021 15:08:00 +0000 Message-ID: <8e2c9e0402394081ad580a36a01788f2@bell.ca> References: In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.112.64] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] planned-changes: two questions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2021 15:08:09 -0000 My thoughts Inline below. Guy -----Message d'origine----- De=A0: Ecrit De la part de Randall Gellens Envoy=E9=A0: 27 ao=FBt 2021 17:41 =C0=A0: ECRIT Objet=A0: [EXT][Ecrit] planned-changes: two questions I think we're moving to a model where: - In a query, a client can request to be notified when the location should = be revalidated; - In the response, the server provides an ID which the client associates wi= th the location it just validated; - The server sends a notification to the URI, containing the ID; - The client revalidates each location with which that ID is associated. Question 1: Does the server delete/inactivate the URI once it has sent the = notification? [GC] The URI is now a static one that is specific to a Client (rather than = a location stored by the Client). I think it should remain active until the= Client sends a new one (for whatever reason). Question 2: Presumably, when the client revalidates the location(s), it wil= l again request notification. [GC] Yes, by providing with the same generic URI or a new = one (for whatever reason). Does the server return the same ID as before, or a different ID? [GC] It would be the same ID since it is associated with a location (define= d by policy at the Server) unless the "location" has changed (the location = itself or the policy defining it). An example of such change is when the un= derlying data structure for a set of locations has changed, such as address= points being added on top of road centerline data.=20 A different ID could perhaps be useful in edge cases where the server did= n't send or the client didn't get the notification, but any utility seems s= mall. If it's the same ID, then the answer to question 1 can be that the U= RI remains active until the client asks to no longer be notified (by sendin= g an empty URI?). [GC] You bring a good point about the Client asking to no longer be notifie= d. I think this needs to be supported although I don't see why a Client sup= porting planned-changes would want to stop using it. Do we do so by providi= ng an empty or by not providing at all? = In either case, we need some text on the Client and Server behaviours. --Randall _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --- External Email: Please use caution when opening links and attachments / Cou= rriel externe: Soyez prudent avec les liens et documents joints From nobody Mon Aug 30 08:22:27 2021 Return-Path: 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 BB2F03A163A for ; Mon, 30 Aug 2021 08:22:25 -0700 (PDT) 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.20150623.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 cMA958j3A0SH for ; Mon, 30 Aug 2021 08:22:20 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 41CDE3A1634 for ; Mon, 30 Aug 2021 08:22:20 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id a13so20357705iol.5 for ; Mon, 30 Aug 2021 08:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rYNvGd98kSnUun0OI+W6iDvHxEE5CBnQMIHyAzwI/qA=; b=H9UKnpEQZcIouLImlJHoTBc87jXFj9dc/bUB8Lr2p/J/m2xh7sqtGPdiXT0BKDzfot yXSYFw+/jYPNJAm0T6/GEPxlCEOZ24s+PiTv2DykeCl5D0EdANj1m1+xb2HeRWh290tT G9Hwi5sf5PLZY/21TMr7APsxGVzJBTDD0xjkdwEsc2eitFgE5+/TLIar2+cpA6LNH4kO elBIHxJLM6ZcUDnNf1gtxUuPWFWf20W/bTJnFZ0AGvjVTggjruLOOw7lh3rLr+2Vq9Kq MsMs5/ApL186UqzqdK5kG7NYVmzbaYJvef6pg5js+OU4HPfnyNhIawOCEKBG3jawMUmf i0rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rYNvGd98kSnUun0OI+W6iDvHxEE5CBnQMIHyAzwI/qA=; b=tKT/xoRvGxoAXju6wb3Yytw+ZHorpKrUfgt4PnfIg2Ara6AyJmCepgGX0dYb73ZrVR D5m/DuSgilzpEL7ggeMwyP2xLc/mFIBWp6AqJoLisSFMONnOCch4W6m/QTQUnjvE1Kd/ 2AyH4I7kJ1pegDq0b5ALtzCJ8Tsti2SE5/3ZuPxer08E4x6ivHO9taVAZOrrqURgnmCT LyFxCcN1/zQZJvju3qsolx1f0V4zLUjYBSPGL9VyYDRtIbi5EwU+ij2WUn0oWSUhlvNA 1Cd2dV1Rgs7K0D+K0BV+JtbHvl0C5L9oeoQUX4PrWVgIJt1xOPU5hEpNN4Go3DGVzG+r ncCQ== X-Gm-Message-State: AOAM5306CTXMrzVeQE/1JSgiy+0TD8psNyrrNtZzt08300tSqcl6Fh8n +CtgwLriY8mYC3xSy9pFqk293tqnBWYIuISz X-Google-Smtp-Source: ABdhPJx0pTz03Q9ulZLxfEh2wG9sn4lx/laqa/QzTMzKsl93fS/AynpwmuScNMm3d0NYMps+Ler9dQ== X-Received: by 2002:a5d:9707:: with SMTP id h7mr19338578iol.28.1630336937963; Mon, 30 Aug 2021 08:22:17 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id c16sm8677405ilh.50.2021.08.30.08.22.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Aug 2021 08:22:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Brian Rosen In-Reply-To: Date: Mon, 30 Aug 2021 11:22:14 -0400 Cc: ECRIT Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Randall Gellens X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Ecrit] planned-changes: two questions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2021 15:22:26 -0000 Answer 1: yes. Since there is going to be a revalidation, just deleting = the setting seems right to me. Answer 2: Up to server. If I were implementing, I would hash the real = ID with the URI and some kind of predictable nonce. =20 We probably have to say more about how the server identifies the client, = so that replacement of the URI works. Could we say we use the domain of = the URI (the entire domain with all the dots) to identify the client, = and anything can occur after it (meaning a slash and whatever)? If we = do that, then how would delete the notification? Force there to be = something other than the domain (ugly). Explicit delete request? Hmmm, we=E2=80=99ve opened a DoS attack: a rogue client stores a bunch = of URIs for servers it wants to victimize. In North America we have a = real simple solution for that, because we have a PKI, so we know, for = sure, who the client is, and could restrict who we allow to store URIs, = but that wouldn=E2=80=99t be true in general. Also, it would be nice = for the client to have confidence the mechanism worked before it needed = it. So Let=E2=80=99s add a =E2=80=9Ccommand=E2=80=9D to plannedChange in the = findService request. And, have the client have a response to the = notification which is the ID (json with the 200) The client starts by sending a command of =E2=80=9Cinitialize=E2=80=9D. = The domain is the identity of the client. The response is an immediate = notification to the with whatever LI was in the request and an ID. The = response by the client (which is the notification web server) is a piece = of json containing the ID. We can say that the LI in this initialize = command could be something simple like the Country Code that wouldn=E2=80=99= t get a planned change. Thereafter, the LoST server (notification client) periodically repeats = this keepalive notification every day or week with the initialize LI. = The client has to respond with the ID. The regular notification request is a command of =E2=80=9Cnotify=E2=80=9D.= The server ignores a request for notification from an uninitialized = client. The notification can be deleted with a command of =E2=80=9Cdelete=E2=80=9D= . If you delete the initialize LI, then the server won=E2=80=99t send = any more notifications to that client and deletes all URIs it was saving = for that client. The client would have to re-initialize to reset. Brian > On Aug 27, 2021, at 5:41 PM, Randall Gellens = wrote: >=20 > I think we're moving to a model where: > - In a query, a client can request to be notified when the location = should be revalidated; > - In the response, the server provides an ID which the client = associates with the location it just validated; > - The server sends a notification to the URI, containing the ID; > - The client revalidates each location with which that ID is = associated. >=20 > Question 1: Does the server delete/inactivate the URI once it has sent = the notification? >=20 > Question 2: Presumably, when the client revalidates the location(s), = it will again request notification. Does the server return the same ID = as before, or a different ID? A different ID could perhaps be useful in = edge cases where the server didn't send or the client didn't get the = notification, but any utility seems small. If it's the same ID, then = the answer to question 1 can be that the URI remains active until the = client asks to no longer be notified (by sending an empty URI?). >=20 > --Randall >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Mon Aug 30 14:52:01 2021 Return-Path: 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 B731C3A23C5 for ; Mon, 30 Aug 2021 14:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, 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 4O7HDpQJYrwn for ; Mon, 30 Aug 2021 14:51:53 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3F83A23C4 for ; Mon, 30 Aug 2021 14:51:52 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Mon, 30 Aug 2021 14:51:52 -0700 From: "Randall Gellens" To: "Brian Rosen" Cc: ECRIT Date: Mon, 30 Aug 2021 14:51:52 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <0B800196-C284-45B6-B1A4-75A9CDB505BC@randy.pensive.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ecrit] planned-changes: two questions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2021 21:51:59 -0000 Works for me, but the draft should be updated to say this (once a server successfully sends a notification, it deletes the URI, and the ID returned is entirely up to the server and might or might not be different on a subsequent request for the same location). --Randall On 30 Aug 2021, at 8:22, Brian Rosen wrote: > Answer 1: yes. Since there is going to be a revalidation, just > deleting the setting seems right to me. > Answer 2: Up to server. If I were implementing, I would hash the real > ID with the URI and some kind of predictable nonce. > > We probably have to say more about how the server identifies the > client, so that replacement of the URI works. Could we say we use the > domain of the URI (the entire domain with all the dots) to identify > the client, and anything can occur after it (meaning a slash and > whatever)? If we do that, then how would delete the notification? > Force there to be something other than the domain (ugly). Explicit > delete request? > > Hmmm, we’ve opened a DoS attack: a rogue client stores a bunch of > URIs for servers it wants to victimize. In North America we have a > real simple solution for that, because we have a PKI, so we know, for > sure, who the client is, and could restrict who we allow to store > URIs, but that wouldn’t be true in general. Also, it would be nice > for the client to have confidence the mechanism worked before it > needed it. > > So > Let’s add a “command†to plannedChange in the findService > request. And, have the client have a response to the notification > which is the ID (json with the 200) > > > The client starts by sending a command of “initializeâ€. The > domain is the identity of the client. The response is an immediate > notification to the with whatever LI was in the request and an ID. > The response by the client (which is the notification web server) is > a piece of json containing the ID. We can say that the LI in this > initialize command could be something simple like the Country Code > that wouldn’t get a planned change. > > Thereafter, the LoST server (notification client) periodically repeats > this keepalive notification every day or week with the initialize LI. > The client has to respond with the ID. > > The regular notification request is a command of “notifyâ€. The > server ignores a request for notification from an uninitialized > client. > The notification can be deleted with a command of “deleteâ€. If > you delete the initialize LI, then the server won’t send any more > notifications to that client and deletes all URIs it was saving for > that client. The client would have to re-initialize to reset. > > Brian > >> On Aug 27, 2021, at 5:41 PM, Randall Gellens >> wrote: >> >> I think we're moving to a model where: >> - In a query, a client can request to be notified when the location >> should be revalidated; >> - In the response, the server provides an ID which the client >> associates with the location it just validated; >> - The server sends a notification to the URI, containing the ID; >> - The client revalidates each location with which that ID is >> associated. >> >> Question 1: Does the server delete/inactivate the URI once it has >> sent the notification? >> >> Question 2: Presumably, when the client revalidates the location(s), >> it will again request notification. Does the server return the same >> ID as before, or a different ID? A different ID could perhaps be >> useful in edge cases where the server didn't send or the client >> didn't get the notification, but any utility seems small. If it's >> the same ID, then the answer to question 1 can be that the URI >> remains active until the client asks to no longer be notified (by >> sending an empty URI?). >> >> --Randall >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit From nobody Mon Aug 30 14:57:57 2021 Return-Path: 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 72BAD3A23F3 for ; Mon, 30 Aug 2021 14:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, 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.20150623.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 Rn1AdDfJ6fgN for ; Mon, 30 Aug 2021 14:57:47 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 AC8AB3A23EF for ; Mon, 30 Aug 2021 14:57:47 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id b10so22145559ioq.9 for ; Mon, 30 Aug 2021 14:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0exZFY8oJ0eWupRJPIDHYmvESFO2r7ebMeX49GUZpH8=; b=RfBFAuywHMatRrh/WGWpryGJCxkWoUcBR8Oz6yCL8ryIub1OtNu854EeHIURVXxMbb eKsbD6agNcDGDIs7qtMqP1JpIOhzYLgDpOGtkwdd9ENPpBXUF41JfRZ4PPJ38EiV618r ybiYjeppjvyjjAeGA9cE2fMiTgv9V89HRvbgluK+Z32XVoqW6B/w1Sq0jR52P0Do9Nr3 AkEWI7J7/h9JzPfh4zAc+LP5BvGkCiWwjIwiV5GBQLdz7/KysRv11UXeRB4io/dzF34U B649dV3N8tecsyXAPyK+7v74y+v2gcMM3SFt/aS7H/F+4v1Mu98XAiQG5f4nXL0BigtO d5NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0exZFY8oJ0eWupRJPIDHYmvESFO2r7ebMeX49GUZpH8=; b=a2mrZfdJ2jB11kFV8FUQdDco5IEdZsL+YixQj+rQIdsBpnBiAnzqBIEBJPZV4GmV4m JWdfAFx68CTBpCGXiUesXuFFBQj8COcLyEiWHubr49EZtne5Gc4jPnq4u0LYm/7Y7HYr Ru3oRti2CpiZq4FiNTnD738OpHAmCr/vWGzYVWn2Rov8AHY978SVhkuz8y+uUn/v8rV/ JDOyGAlfFzFgd77T6dWdwdeRpXCaoDDu01zm3tEopFRzpRm5XJ2NZeZVZGD31mR05FUK S5azCAJQFkaBHrUpPVDaOmIw8vK8AFefuLPlgdR5V0oOlYbDOPm36pSDAiXjMb2Rmzig v/Og== X-Gm-Message-State: AOAM53126Z/cR9MO6gfXXO8l2wJ9c1uarYAeNNHyMkAkK7IoitITyGgX Y93N7w7P/8Urnaw/wdqaNyTjloAXtw2zkWrm3vCZHR5h9IZmSQ== X-Google-Smtp-Source: ABdhPJzhpX9VdNZgvN2rkNc46z5t4xd4lffXjhPh4FWEnfbONIIrjzarJ8124Z6rzxTIsF4K/yLr+5C0IuOOeK67Uks= X-Received: by 2002:a5d:8d1a:: with SMTP id p26mr5226858ioj.141.1630360665236; Mon, 30 Aug 2021 14:57:45 -0700 (PDT) MIME-Version: 1.0 References: <0B800196-C284-45B6-B1A4-75A9CDB505BC@randy.pensive.org> In-Reply-To: <0B800196-C284-45B6-B1A4-75A9CDB505BC@randy.pensive.org> From: Brian Rosen Date: Mon, 30 Aug 2021 17:57:34 -0400 Message-ID: To: Randall Gellens Cc: ECRIT Content-Type: multipart/alternative; boundary="0000000000004eb74505cacdec76" Archived-At: Subject: Re: [Ecrit] planned-changes: two questions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2021 21:57:55 -0000 --0000000000004eb74505cacdec76 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, I agree. Brian On Mon, Aug 30, 2021 at 5:51 PM Randall Gellens wrote: > Works for me, but the draft should be updated to say this (once a server > successfully sends a notification, it deletes the URI, and the ID > returned is entirely up to the server and might or might not be > different on a subsequent request for the same location). > > --Randall > > On 30 Aug 2021, at 8:22, Brian Rosen wrote: > > > Answer 1: yes. Since there is going to be a revalidation, just > > deleting the setting seems right to me. > > Answer 2: Up to server. If I were implementing, I would hash the real > > ID with the URI and some kind of predictable nonce. > > > > We probably have to say more about how the server identifies the > > client, so that replacement of the URI works. Could we say we use the > > domain of the URI (the entire domain with all the dots) to identify > > the client, and anything can occur after it (meaning a slash and > > whatever)? If we do that, then how would delete the notification? > > Force there to be something other than the domain (ugly). Explicit > > delete request? > > > > Hmmm, we=E2=80=99ve opened a DoS attack: a rogue client stores a bunch = of > > URIs for servers it wants to victimize. In North America we have a > > real simple solution for that, because we have a PKI, so we know, for > > sure, who the client is, and could restrict who we allow to store > > URIs, but that wouldn=E2=80=99t be true in general. Also, it would be = nice > > for the client to have confidence the mechanism worked before it > > needed it. > > > > So > > Let=E2=80=99s add a =E2=80=9Ccommand=E2=80=9D to plannedChange in the f= indService > > request. And, have the client have a response to the notification > > which is the ID (json with the 200) > > > > > > The client starts by sending a command of =E2=80=9Cinitialize=E2=80=9D.= The > > domain is the identity of the client. The response is an immediate > > notification to the with whatever LI was in the request and an ID. > > The response by the client (which is the notification web server) is > > a piece of json containing the ID. We can say that the LI in this > > initialize command could be something simple like the Country Code > > that wouldn=E2=80=99t get a planned change. > > > > Thereafter, the LoST server (notification client) periodically repeats > > this keepalive notification every day or week with the initialize LI. > > The client has to respond with the ID. > > > > The regular notification request is a command of =E2=80=9Cnotify=E2=80= =9D. The > > server ignores a request for notification from an uninitialized > > client. > > The notification can be deleted with a command of =E2=80=9Cdelete=E2=80= =9D. If > > you delete the initialize LI, then the server won=E2=80=99t send any mo= re > > notifications to that client and deletes all URIs it was saving for > > that client. The client would have to re-initialize to reset. > > > > Brian > > > >> On Aug 27, 2021, at 5:41 PM, Randall Gellens > >> wrote: > >> > >> I think we're moving to a model where: > >> - In a query, a client can request to be notified when the location > >> should be revalidated; > >> - In the response, the server provides an ID which the client > >> associates with the location it just validated; > >> - The server sends a notification to the URI, containing the ID; > >> - The client revalidates each location with which that ID is > >> associated. > >> > >> Question 1: Does the server delete/inactivate the URI once it has > >> sent the notification? > >> > >> Question 2: Presumably, when the client revalidates the location(s), > >> it will again request notification. Does the server return the same > >> ID as before, or a different ID? A different ID could perhaps be > >> useful in edge cases where the server didn't send or the client > >> didn't get the notification, but any utility seems small. If it's > >> the same ID, then the answer to question 1 can be that the URI > >> remains active until the client asks to no longer be notified (by > >> sending an empty URI?). > >> > >> --Randall > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > --0000000000004eb74505cacdec76 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, I agree.=C2=A0

Brian

On Mon, Aug 30= , 2021 at 5:51 PM Randall Gellens <rg+ietf@randy.pensive.org> wrote:
Works for me, but the draft should be updated to say this (= once a server
successfully sends a notification, it deletes the URI, and the ID
returned is entirely up to the server and might or might not be
different on a subsequent request for the same location).

--Randall

On 30 Aug 2021, at 8:22, Brian Rosen wrote:

> Answer 1: yes.=C2=A0 Since there is going to be a revalidation, just <= br> > deleting the setting seems right to me.
> Answer 2: Up to server.=C2=A0 If I were implementing, I would hash the= real
> ID with the URI and some kind of predictable nonce.
>
> We probably have to say more about how the server identifies the
> client, so that replacement of the URI works.=C2=A0 Could we say we us= e the
> domain of the URI (the entire domain with all the dots) to identify > the client, and anything can occur after it (meaning a slash and
> whatever)?=C2=A0 If we do that, then how would delete the notification= ?=C2=A0
> Force there to be something other than the domain (ugly).=C2=A0 Explic= it
> delete request?
>
> Hmmm, we=E2=80=99ve opened a DoS attack: a rogue client stores a bunch= of
> URIs for servers it wants to victimize.=C2=A0 In North America we have= a
> real simple solution for that, because we have a PKI, so we know, for =
> sure, who the client is, and could restrict who we allow to store
> URIs, but that wouldn=E2=80=99t be true in general.=C2=A0 Also, it wou= ld be nice
> for the client to have confidence the mechanism worked before it
> needed it.
>
> So
> Let=E2=80=99s add a =E2=80=9Ccommand=E2=80=9D to plannedChange in the = findService
> request.=C2=A0 And, have the client have a response to the notificatio= n
> which is the ID (json with the 200)
>
>
> The client starts by sending a command of =E2=80=9Cinitialize=E2=80=9D= .=C2=A0 The
> domain is the identity of the client.=C2=A0 The response is an immedia= te
> notification to the with whatever LI was in the request and an ID.=C2= =A0
> The=C2=A0 response by the client (which is the notification web server= ) is
> a piece of json containing the ID.=C2=A0 We can say that the LI in thi= s
> initialize command could be something simple like the Country Code > that wouldn=E2=80=99t get a planned change.
>
> Thereafter, the LoST server (notification client) periodically repeats=
> this keepalive notification every day or week with the initialize LI.= =C2=A0
> The client has to respond with the ID.
>
> The regular notification request is a command of =E2=80=9Cnotify=E2=80= =9D.=C2=A0 The
> server ignores a request for notification from an uninitialized
> client.
> The notification can be deleted with a command of =E2=80=9Cdelete=E2= =80=9D.=C2=A0 If
> you delete the initialize LI, then the server won=E2=80=99t send any m= ore
> notifications to that client and deletes all URIs it was saving for > that client.=C2=A0 The client would have to re-initialize to reset. >
> Brian
>
>> On Aug 27, 2021, at 5:41 PM, Randall Gellens
>> <rg+ietf@randy.pensive.org> wrote:
>>
>> I think we're moving to a model where:
>> - In a query, a client can request to be notified when the locatio= n
>> should be revalidated;
>> - In the response, the server provides an ID which the client
>> associates with the location it just validated;
>> - The server sends a notification to the URI, containing the ID; >> - The client revalidates each location with which that ID is
>> associated.
>>
>> Question 1: Does the server delete/inactivate the URI once it has =
>> sent the notification?
>>
>> Question 2: Presumably, when the client revalidates the location(s= ),
>> it will again request notification.=C2=A0 Does the server return t= he same
>> ID as before, or a different ID?=C2=A0 A different ID could perhap= s be
>> useful in edge cases where the server didn't send or the clien= t
>> didn't get the notification, but any utility seems small.=C2= =A0 If it's
>> the same ID, then the answer to question 1 can be that the URI >> remains active until the client asks to no longer be notified (by =
>> sending an empty URI?).
>>
>> --Randall
>>
>> _______________________________________________
>> Ecrit mailing list
>> Ecrit@ietf.org=
>> https://www.ietf.org/mailman/listinfo/ecrit<= br>
--0000000000004eb74505cacdec76-- From nobody Tue Aug 31 04:38:13 2021 Return-Path: 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 8D2763A0E22 for ; Tue, 31 Aug 2021 04:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=bell.ca 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 1uLygfxbwjXu for ; Tue, 31 Aug 2021 04:37:54 -0700 (PDT) Received: from ESA3-Dor.bell.ca (esa3-dor.bell.ca [204.101.223.60]) (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 94B5D3A0DEE for ; Tue, 31 Aug 2021 04:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1630409874; x=1661945874; h=from:to:cc:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=CuoQr55k8S18gC7SacUblA55Bvq//+jew5InaMxxAkE=; b=B1OLzKKg+72/qOHIJB+shDcITyq0jQw9f8QTE7M/RIVQgrd1uD32PVg6 yCvHW/j6xN+1IWH8vAoLbQPj75yLC6JvViV6FJE4uGVzh9PFgZbM3oeHU FWppJ+bKx8VGsoyw5tsaSKha+xPR2a89aGJPQqajvJZh+r0EkRcF0vHYi q/NRCLor9vPYT1x4DnOUfv2as0eSzwyPEAesZSzRDlRXLqM41QCED2UDz 38oIwQ/AIlZ9LBwddZdqPETHA2XbtfQXk/L+Kmla3ef29f63w0Zp6XNDy f5J6prKOpIohbl1axsp+SGhun4HlEEaqeSEXJopTn3tAdaPkoRWnGBcNY w==; IronPort-SDR: ZpKyxZeYnp4qr/iKUZckuia51fkfRqLflb1T6gL1iJTY8ly7j4Qpba1tkydy6qMQFaBXrBe7Nv TZoT+cv5RmDg== Received: from dc5cmz-d00.bellca.int.bell.ca (HELO DG1MBX02-WYN.bell.corp.bce.ca) ([198.235.121.231]) by esa03corp-dor.bell.corp.bce.ca with ESMTP; 31 Aug 2021 07:37:52 -0400 Received: from DG12MBX03-WYN.bell.corp.bce.ca (142.182.18.48) by DG1MBX02-WYN.bell.corp.bce.ca (142.182.18.12) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Tue, 31 Aug 2021 07:37:52 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX03-WYN.bell.corp.bce.ca (142.182.18.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Tue, 31 Aug 2021 07:37:52 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Tue, 31 Aug 2021 07:37:52 -0400 From: "Caron, Guy" To: Brian Rosen , Randall Gellens CC: ECRIT Thread-Topic: [EXT]Re: [Ecrit] planned-changes: two questions Thread-Index: AQHXnbLZ8xDlKKXTXU23cWH8anqQbauNeTZQ Date: Tue, 31 Aug 2021 11:37:52 +0000 Message-ID: <5577e2e6daa4405bbe12ef61675e1f55@bell.ca> References: In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.74] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] planned-changes: two questions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 11:38:10 -0000 V2VsbCwgdGhpcyBpcyBub3QgZ29pbmcgaW4gdGhlIGRpcmVjdGlvbiBJIHRob3VnaHQuDQoNCldo YXQgaXMgdGhlIHB1cnBvc2Ugb2YgZGVsZXRpbmcgdGhlIFVSSXMgYXQgdGhlIFNlcnZlciBwb3N0 LXZhbGlkYXRpb24/DQoNClJlZ2FyZGluZyBvcGVuaW5nIGEgbmV3IERvUywgSSBndWVzcyBJJ20g bm90IGZvbGxvd2luZy4gV291bGRuJ3QgdGhpcyBjYXNlIGJlIGNvdmVyZWQgYnkgdGhlIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIGluIFJGQyA1MjIyPw0KDQpXaGF0IHlvdSdyZSBwcm9wb3Npbmcg cHV0cyBiYWNrIHNpZ25pZmljYW50IGxvYWQgb24gdGhlIFNlcnZlcnMgKGEga2V5IGNvbnNpZGVy YXRpb24gZm9yIGNyZWF0aW5nIHBsYW5uZWQtY2hhbmdlcyBpbiB0aGUgZmlyc3QgcGxhY2UpIGFu ZCBjb21wbGljYXRlcyB0aGUgbWVjaGFuaXNtLg0KDQpHdXkNCg0KDQotLS0tLU1lc3NhZ2UgZCdv cmlnaW5lLS0tLS0NCkRlwqA6IEVjcml0IDxlY3JpdC1ib3VuY2VzQGlldGYub3JnPiBEZSBsYSBw YXJ0IGRlIEJyaWFuIFJvc2VuDQpFbnZvecOpwqA6IDMwIGFvw7t0IDIwMjEgMTE6MjINCsOAwqA6 IFJhbmRhbGwgR2VsbGVucyA8cmcraWV0ZkByYW5keS5wZW5zaXZlLm9yZz4NCkNjwqA6IEVDUklU IDxlY3JpdEBpZXRmLm9yZz4NCk9iamV0wqA6IFtFWFRdUmU6IFtFY3JpdF0gcGxhbm5lZC1jaGFu Z2VzOiB0d28gcXVlc3Rpb25zDQoNCkFuc3dlciAxOiB5ZXMuICBTaW5jZSB0aGVyZSBpcyBnb2lu ZyB0byBiZSBhIHJldmFsaWRhdGlvbiwganVzdCBkZWxldGluZyB0aGUgc2V0dGluZyBzZWVtcyBy aWdodCB0byBtZS4NCkFuc3dlciAyOiBVcCB0byBzZXJ2ZXIuICBJZiBJIHdlcmUgaW1wbGVtZW50 aW5nLCBJIHdvdWxkIGhhc2ggdGhlIHJlYWwgSUQgd2l0aCB0aGUgVVJJIGFuZCBzb21lIGtpbmQg b2YgcHJlZGljdGFibGUgbm9uY2UuICANCg0KV2UgcHJvYmFibHkgaGF2ZSB0byBzYXkgbW9yZSBh Ym91dCBob3cgdGhlIHNlcnZlciBpZGVudGlmaWVzIHRoZSBjbGllbnQsIHNvIHRoYXQgcmVwbGFj ZW1lbnQgb2YgdGhlIFVSSSB3b3Jrcy4gIENvdWxkIHdlIHNheSB3ZSB1c2UgdGhlIGRvbWFpbiBv ZiB0aGUgVVJJICh0aGUgZW50aXJlIGRvbWFpbiB3aXRoIGFsbCB0aGUgZG90cykgdG8gaWRlbnRp ZnkgdGhlIGNsaWVudCwgYW5kIGFueXRoaW5nIGNhbiBvY2N1ciBhZnRlciBpdCAobWVhbmluZyBh IHNsYXNoIGFuZCB3aGF0ZXZlcik/ICBJZiB3ZSBkbyB0aGF0LCB0aGVuIGhvdyB3b3VsZCBkZWxl dGUgdGhlIG5vdGlmaWNhdGlvbj8gIEZvcmNlIHRoZXJlIHRvIGJlIHNvbWV0aGluZyBvdGhlciB0 aGFuIHRoZSBkb21haW4gKHVnbHkpLiAgRXhwbGljaXQgZGVsZXRlIHJlcXVlc3Q/DQoNCkhtbW0s IHdl4oCZdmUgb3BlbmVkIGEgRG9TIGF0dGFjazogYSByb2d1ZSBjbGllbnQgc3RvcmVzIGEgYnVu Y2ggb2YgVVJJcyBmb3Igc2VydmVycyBpdCB3YW50cyB0byB2aWN0aW1pemUuICBJbiBOb3J0aCBB bWVyaWNhIHdlIGhhdmUgYSByZWFsIHNpbXBsZSBzb2x1dGlvbiBmb3IgdGhhdCwgYmVjYXVzZSB3 ZSBoYXZlIGEgUEtJLCBzbyB3ZSBrbm93LCBmb3Igc3VyZSwgd2hvIHRoZSBjbGllbnQgaXMsIGFu ZCBjb3VsZCByZXN0cmljdCB3aG8gd2UgYWxsb3cgdG8gc3RvcmUgVVJJcywgYnV0IHRoYXQgd291 bGRu4oCZdCBiZSB0cnVlIGluIGdlbmVyYWwuICBBbHNvLCBpdCB3b3VsZCBiZSBuaWNlIGZvciB0 aGUgY2xpZW50IHRvIGhhdmUgY29uZmlkZW5jZSB0aGUgbWVjaGFuaXNtIHdvcmtlZCBiZWZvcmUg aXQgbmVlZGVkIGl0Lg0KDQpTbw0KTGV04oCZcyBhZGQgYSDigJxjb21tYW5k4oCdIHRvIHBsYW5u ZWRDaGFuZ2UgaW4gdGhlIGZpbmRTZXJ2aWNlIHJlcXVlc3QuICBBbmQsIGhhdmUgdGhlIGNsaWVu dCBoYXZlIGEgcmVzcG9uc2UgdG8gdGhlIG5vdGlmaWNhdGlvbiB3aGljaCBpcyB0aGUgSUQgKGpz b24gd2l0aCB0aGUgMjAwKQ0KDQoNClRoZSBjbGllbnQgc3RhcnRzIGJ5IHNlbmRpbmcgYSBjb21t YW5kIG9mIOKAnGluaXRpYWxpemXigJ0uICBUaGUgZG9tYWluIGlzIHRoZSBpZGVudGl0eSBvZiB0 aGUgY2xpZW50LiAgVGhlIHJlc3BvbnNlIGlzIGFuIGltbWVkaWF0ZSBub3RpZmljYXRpb24gdG8g dGhlIHdpdGggd2hhdGV2ZXIgTEkgd2FzIGluIHRoZSByZXF1ZXN0IGFuZCBhbiBJRC4gIFRoZSAg cmVzcG9uc2UgYnkgdGhlIGNsaWVudCAod2hpY2ggaXMgdGhlIG5vdGlmaWNhdGlvbiB3ZWIgc2Vy dmVyKSBpcyBhIHBpZWNlIG9mIGpzb24gY29udGFpbmluZyB0aGUgSUQuICBXZSBjYW4gc2F5IHRo YXQgdGhlIExJIGluIHRoaXMgaW5pdGlhbGl6ZSBjb21tYW5kIGNvdWxkIGJlIHNvbWV0aGluZyBz aW1wbGUgbGlrZSB0aGUgQ291bnRyeSBDb2RlIHRoYXQgd291bGRu4oCZdCBnZXQgYSBwbGFubmVk IGNoYW5nZS4NCg0KVGhlcmVhZnRlciwgdGhlIExvU1Qgc2VydmVyIChub3RpZmljYXRpb24gY2xp ZW50KSBwZXJpb2RpY2FsbHkgcmVwZWF0cyB0aGlzIGtlZXBhbGl2ZSBub3RpZmljYXRpb24gZXZl cnkgZGF5IG9yIHdlZWsgd2l0aCB0aGUgaW5pdGlhbGl6ZSBMSS4gIFRoZSBjbGllbnQgaGFzIHRv IHJlc3BvbmQgd2l0aCB0aGUgSUQuDQoNClRoZSByZWd1bGFyIG5vdGlmaWNhdGlvbiByZXF1ZXN0 IGlzIGEgY29tbWFuZCBvZiDigJxub3RpZnnigJ0uICBUaGUgc2VydmVyIGlnbm9yZXMgYSByZXF1 ZXN0IGZvciBub3RpZmljYXRpb24gZnJvbSBhbiB1bmluaXRpYWxpemVkIGNsaWVudC4NClRoZSBu b3RpZmljYXRpb24gY2FuIGJlIGRlbGV0ZWQgd2l0aCBhIGNvbW1hbmQgb2Yg4oCcZGVsZXRl4oCd LiAgSWYgeW91IGRlbGV0ZSB0aGUgaW5pdGlhbGl6ZSBMSSwgdGhlbiB0aGUgc2VydmVyIHdvbuKA mXQgc2VuZCBhbnkgbW9yZSBub3RpZmljYXRpb25zIHRvIHRoYXQgY2xpZW50IGFuZCBkZWxldGVz IGFsbCBVUklzIGl0IHdhcyBzYXZpbmcgZm9yIHRoYXQgY2xpZW50LiAgVGhlIGNsaWVudCB3b3Vs ZCBoYXZlIHRvIHJlLWluaXRpYWxpemUgdG8gcmVzZXQuDQoNCkJyaWFuDQoNCj4gT24gQXVnIDI3 LCAyMDIxLCBhdCA1OjQxIFBNLCBSYW5kYWxsIEdlbGxlbnMgPHJnK2lldGZAcmFuZHkucGVuc2l2 ZS5vcmc+IHdyb3RlOg0KPiANCj4gSSB0aGluayB3ZSdyZSBtb3ZpbmcgdG8gYSBtb2RlbCB3aGVy ZToNCj4gLSBJbiBhIHF1ZXJ5LCBhIGNsaWVudCBjYW4gcmVxdWVzdCB0byBiZSBub3RpZmllZCB3 aGVuIHRoZSBsb2NhdGlvbiBzaG91bGQgYmUgcmV2YWxpZGF0ZWQ7DQo+IC0gSW4gdGhlIHJlc3Bv bnNlLCB0aGUgc2VydmVyIHByb3ZpZGVzIGFuIElEIHdoaWNoIHRoZSBjbGllbnQgYXNzb2NpYXRl cyB3aXRoIHRoZSBsb2NhdGlvbiBpdCBqdXN0IHZhbGlkYXRlZDsNCj4gLSBUaGUgc2VydmVyIHNl bmRzIGEgbm90aWZpY2F0aW9uIHRvIHRoZSBVUkksIGNvbnRhaW5pbmcgdGhlIElEOw0KPiAtIFRo ZSBjbGllbnQgcmV2YWxpZGF0ZXMgZWFjaCBsb2NhdGlvbiB3aXRoIHdoaWNoIHRoYXQgSUQgaXMg YXNzb2NpYXRlZC4NCj4gDQo+IFF1ZXN0aW9uIDE6IERvZXMgdGhlIHNlcnZlciBkZWxldGUvaW5h Y3RpdmF0ZSB0aGUgVVJJIG9uY2UgaXQgaGFzIHNlbnQgdGhlIG5vdGlmaWNhdGlvbj8NCj4gDQo+ IFF1ZXN0aW9uIDI6IFByZXN1bWFibHksIHdoZW4gdGhlIGNsaWVudCByZXZhbGlkYXRlcyB0aGUg bG9jYXRpb24ocyksIGl0IHdpbGwgYWdhaW4gcmVxdWVzdCBub3RpZmljYXRpb24uICBEb2VzIHRo ZSBzZXJ2ZXIgcmV0dXJuIHRoZSBzYW1lIElEIGFzIGJlZm9yZSwgb3IgYSBkaWZmZXJlbnQgSUQ/ ICBBIGRpZmZlcmVudCBJRCBjb3VsZCBwZXJoYXBzIGJlIHVzZWZ1bCBpbiBlZGdlIGNhc2VzIHdo ZXJlIHRoZSBzZXJ2ZXIgZGlkbid0IHNlbmQgb3IgdGhlIGNsaWVudCBkaWRuJ3QgZ2V0IHRoZSBu b3RpZmljYXRpb24sIGJ1dCBhbnkgdXRpbGl0eSBzZWVtcyBzbWFsbC4gIElmIGl0J3MgdGhlIHNh bWUgSUQsIHRoZW4gdGhlIGFuc3dlciB0byBxdWVzdGlvbiAxIGNhbiBiZSB0aGF0IHRoZSBVUkkg cmVtYWlucyBhY3RpdmUgdW50aWwgdGhlIGNsaWVudCBhc2tzIHRvIG5vIGxvbmdlciBiZSBub3Rp ZmllZCAoYnkgc2VuZGluZyBhbiBlbXB0eSBVUkk/KS4NCj4gDQo+IC0tUmFuZGFsbA0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRWNyaXQg bWFpbGluZyBsaXN0DQo+IEVjcml0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZWNyaXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkVjcml0IG1haWxpbmcgbGlzdA0KRWNyaXRAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KRXh0ZXJuYWwgRW1haWw6IFBsZWFzZSB1c2UgY2F1dGlvbiB3aGVuIG9wZW5pbmcgbGlu a3MgYW5kIGF0dGFjaG1lbnRzIC8gQ291cnJpZWwgZXh0ZXJuZTogU295ZXogcHJ1ZGVudCBhdmVj IGxlcyBsaWVucyBldCBkb2N1bWVudHMgam9pbnRzDQo= From nobody Tue Aug 31 05:10:44 2021 Return-Path: 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 2DB5C3A116F for ; Tue, 31 Aug 2021 05:10:43 -0700 (PDT) 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.20150623.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 hHgLZC3C3gQi for ; Tue, 31 Aug 2021 05:10:37 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 638C13A116C for ; Tue, 31 Aug 2021 05:10:37 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id f6so24492218iox.0 for ; Tue, 31 Aug 2021 05:10:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qMpvX5vPtQEL9MeZAP9lYdayyRqi+SII/rzMpZiRagM=; b=c3vWG1viUhaeP23eWRl9XkQsb4/d6FNCSjdjwHDlh4f5ffbKW5dR631moEge9+ezcN SPH9W0fsas6wunArjwo1x0VYP0bhBrX1OrpD4jFsw/Es20wwyhCwTsRRamXnM8z88ApB 6mpXup+wwFDiP0s/7La9O+0fIRHAMJJiMcvzOvgedoqQm/nfcjt7F5KjKL0FXSGTB56z DBEIOj0ymVyEMxRaSS7/JXuR6WGjUNgLY5tFiEdTDRsY/RIOrXpgZKskvafVcxpzwA0Q Y20K8rCvNyOqnDOMZUU8yAJ6KTiHPLCjiWwuozZygrEFPMUVRERgo8k9fzycflWWpf3W 4oEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qMpvX5vPtQEL9MeZAP9lYdayyRqi+SII/rzMpZiRagM=; b=ogwLIphhfnhCG18lknj2T4UrPUzmE4ZHfRrW2xopDkp/K/g5U6KAvkhMqqdZ0JFVuF nh5NO3n1pCNnMa0zvu3SbbavMyVUdwkQWrmTUaG15TsfGymT/JFxlJgWjdbdA4S0Fl9f JBhR3JgxM36zstuRJbkDd+pqHxdBG3ytFgAuADC/abhqv5zou/2pBRvGM0DkJmcVnFzf P6zJNmgq1DAEX7yHjQINxHUe4Do+pr7VgbZ6E7UgpWrZ9oKmY0K82Xvpm4YJGI8rUDyW 1xxv5q0g0y7fZECToAWKPN/+1HLPpZMFR8xVJLbjwd2J0PDk1rgaPKuW8xKM7djHL2DA s2Ww== X-Gm-Message-State: AOAM5310H7m1FpTUp1yz6IDxMEzAJg25PVQXHvS6dRp4Pl1OX9URDVIJ 6gOzEdNxnI90uBK8NniDGOilTOa/HuttnFrR X-Google-Smtp-Source: ABdhPJxztZHPnhXX/ccgeQeRTXfVQumuKoBfNTHXJaDamo0IzcMNVqjL8ZGb9QFva9FSA5Zg7vdRxg== X-Received: by 2002:a02:b092:: with SMTP id v18mr2591272jah.51.1630411835162; Tue, 31 Aug 2021 05:10:35 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id z15sm9425624ioh.28.2021.08.31.05.10.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Aug 2021 05:10:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Brian Rosen In-Reply-To: <5577e2e6daa4405bbe12ef61675e1f55@bell.ca> Date: Tue, 31 Aug 2021 08:10:33 -0400 Cc: Randall Gellens , ECRIT Content-Transfer-Encoding: quoted-printable Message-Id: References: <5577e2e6daa4405bbe12ef61675e1f55@bell.ca> To: "Caron, Guy" X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Ecrit] planned-changes: two questions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 12:10:44 -0000 You delete the URI when you delete the record in the LIS. I don=E2=80=99t think this is covered in 5222. The mechanism causes the = LoST server to send notifications to the client, but the client is = allowed to put any URI in the record, and it can add it to as many = records as it wants. An evil implementation could record URIs against = multiple targets that were unaware that the evil implementation did it, = until they got a large number of PUSH transactions they didn=E2=80=99t = expect or understand as a result of a large planned change. The proposed mechanism qualifies the client URI before its used in a = planned change. Brian > On Aug 31, 2021, at 7:37 AM, Caron, Guy wrote: >=20 > Well, this is not going in the direction I thought. >=20 > What is the purpose of deleting the URIs at the Server = post-validation? >=20 > Regarding opening a new DoS, I guess I'm not following. Wouldn't this = case be covered by the security considerations in RFC 5222? >=20 > What you're proposing puts back significant load on the Servers (a key = consideration for creating planned-changes in the first place) and = complicates the mechanism. >=20 > Guy >=20 >=20 > -----Message d'origine----- > De : Ecrit De la part de Brian Rosen > Envoy=C3=A9 : 30 ao=C3=BBt 2021 11:22 > =C3=80 : Randall Gellens > Cc : ECRIT > Objet : [EXT]Re: [Ecrit] planned-changes: two questions >=20 > Answer 1: yes. Since there is going to be a revalidation, just = deleting the setting seems right to me. > Answer 2: Up to server. If I were implementing, I would hash the real = ID with the URI and some kind of predictable nonce. =20 >=20 > We probably have to say more about how the server identifies the = client, so that replacement of the URI works. Could we say we use the = domain of the URI (the entire domain with all the dots) to identify the = client, and anything can occur after it (meaning a slash and whatever)? = If we do that, then how would delete the notification? Force there to = be something other than the domain (ugly). Explicit delete request? >=20 > Hmmm, we=E2=80=99ve opened a DoS attack: a rogue client stores a bunch = of URIs for servers it wants to victimize. In North America we have a = real simple solution for that, because we have a PKI, so we know, for = sure, who the client is, and could restrict who we allow to store URIs, = but that wouldn=E2=80=99t be true in general. Also, it would be nice = for the client to have confidence the mechanism worked before it needed = it. >=20 > So > Let=E2=80=99s add a =E2=80=9Ccommand=E2=80=9D to plannedChange in the = findService request. And, have the client have a response to the = notification which is the ID (json with the 200) >=20 >=20 > The client starts by sending a command of =E2=80=9Cinitialize=E2=80=9D. = The domain is the identity of the client. The response is an immediate = notification to the with whatever LI was in the request and an ID. The = response by the client (which is the notification web server) is a piece = of json containing the ID. We can say that the LI in this initialize = command could be something simple like the Country Code that wouldn=E2=80=99= t get a planned change. >=20 > Thereafter, the LoST server (notification client) periodically repeats = this keepalive notification every day or week with the initialize LI. = The client has to respond with the ID. >=20 > The regular notification request is a command of =E2=80=9Cnotify=E2=80=9D= . The server ignores a request for notification from an uninitialized = client. > The notification can be deleted with a command of =E2=80=9Cdelete=E2=80=9D= . If you delete the initialize LI, then the server won=E2=80=99t send = any more notifications to that client and deletes all URIs it was saving = for that client. The client would have to re-initialize to reset. >=20 > Brian >=20 >> On Aug 27, 2021, at 5:41 PM, Randall Gellens = wrote: >>=20 >> I think we're moving to a model where: >> - In a query, a client can request to be notified when the location = should be revalidated; >> - In the response, the server provides an ID which the client = associates with the location it just validated; >> - The server sends a notification to the URI, containing the ID; >> - The client revalidates each location with which that ID is = associated. >>=20 >> Question 1: Does the server delete/inactivate the URI once it has = sent the notification? >>=20 >> Question 2: Presumably, when the client revalidates the location(s), = it will again request notification. Does the server return the same ID = as before, or a different ID? A different ID could perhaps be useful in = edge cases where the server didn't send or the client didn't get the = notification, but any utility seems small. If it's the same ID, then = the answer to question 1 can be that the URI remains active until the = client asks to no longer be notified (by sending an empty URI?). >>=20 >> --Randall >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = --------------------------------------------------------------------------= ---- > External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints From nobody Tue Aug 31 06:01:59 2021 Return-Path: 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 0DEE63A13DE for ; Tue, 31 Aug 2021 06:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=bell.ca 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 cYz_HjQ1AaWg for ; Tue, 31 Aug 2021 06:01:51 -0700 (PDT) Received: from ESA1-Wyn.bell.ca (esa1-wyn.bell.ca [67.69.243.161]) (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 A3F1A3A13CC for ; Tue, 31 Aug 2021 06:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1630414910; x=1661950910; h=from:to:cc:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=IjHOx8X3IiP0PsqUfTJU420GepQo/eEiLrYbS4Ht5Ts=; b=Z7kgbjRrKj9Z1oBEjwekmHHMjAgKus6cxp0VkM3caoQOteiCqiGEqOPa VWxm4KLZEVtQBrqlgR9P+fT+17Ftb/OsXA18dbM6AuLzt3vj2zkeHhTRz NU1b2tWl4aBh3weUofVynl7Oc7L+8gmOZZUt8hI2xQOBNIt8R62uTj8pq s3psDVzmaRcBhSiE1UymCPDp6RNbXxmYEU5kbk8s0ZPF/PvwWIiAiy12q NL+hUXs8PtnpaWj1lIw4m1dbnS9Ot1g2peI4Kpn3CiRSkkBCEEGa+i1Jk nVpYsaKc6O236/OfelsN1SF9ekYsuX9VUddSI7EhEAVIKXwH27xLzIrGd w==; IronPort-SDR: wzoCbBdEqJ/lljClxgwnRJ+9vHZDXrg9XmwwrsCZvKqQ3mQ7ucnaSgNefIxPElUIur/A2Ihi/x v+WPtBv4dDsQ== Received: from dm5cch-d00.bellca.int.bell.ca (HELO DG6MBX02-WYN.bell.corp.bce.ca) ([198.235.102.30]) by esa01corp-wyn.bell.corp.bce.ca with ESMTP; 31 Aug 2021 09:01:49 -0400 Received: from DG12MBX04-WYN.bell.corp.bce.ca (142.182.18.49) by DG6MBX02-WYN.bell.corp.bce.ca (142.182.18.37) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Tue, 31 Aug 2021 09:01:48 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX04-WYN.bell.corp.bce.ca (142.182.18.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Tue, 31 Aug 2021 09:01:48 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Tue, 31 Aug 2021 09:01:48 -0400 From: "Caron, Guy" To: Brian Rosen CC: Randall Gellens , ECRIT Thread-Topic: [EXT]Re: [Ecrit] planned-changes: two questions Thread-Index: AQHXnbLZ8xDlKKXTXU23cWH8anqQbauNeTZQgABQ14D//8deMA== Date: Tue, 31 Aug 2021 13:01:48 +0000 Message-ID: References: <5577e2e6daa4405bbe12ef61675e1f55@bell.ca> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.74] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] planned-changes: two questions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 13:01:57 -0000 SW5saW5lLg0KDQpHdXkNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBCcmlh biBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ+IA0KRW52b3nDqcKgOiAzMSBhb8O7dCAyMDIxIDA4 OjExDQrDgMKgOiBDYXJvbiwgR3V5IDxnLmNhcm9uQGJlbGwuY2E+DQpDY8KgOiBSYW5kYWxsIEdl bGxlbnMgPHJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmc+OyBFQ1JJVCA8ZWNyaXRAaWV0Zi5vcmc+ DQpPYmpldMKgOiBbRVhUXVJlOiBbRWNyaXRdIHBsYW5uZWQtY2hhbmdlczogdHdvIHF1ZXN0aW9u cw0KDQpZb3UgZGVsZXRlIHRoZSBVUkkgd2hlbiB5b3UgZGVsZXRlIHRoZSByZWNvcmQgaW4gdGhl IExJUy4NCltHQ10gVGhhdCdzIGZpbmUgYnV0IHRoYXQgd2FzIG5vdCB0aGUgcXVlc3Rpb24gUmFu ZGFsbCBwb3NlZC4gSGUgYXNrZWQgd2hldGhlciB0aGUgVVJJIGlzIGRlbGV0ZWQgYWZ0ZXIgYSBu b3RpZmljYXRpb24uIEkgYWdyZWUgdGhhdCBpZiB0aGUgQ2xpZW50IGRvZXMgbm90IGhvc3QgdGhl IGxvY2F0aW9uIGFueW1vcmUgdGhhdCB0aGUgVVJJIGFzc29jaWF0ZWQgd2l0aCB0aGF0IGxvY2F0 aW9uIGluIHRoZSBTZXJ2ZXIgc2hvdWxkIGJlIGRlbGV0ZWQuIFRoaXMgY291bGQgYmUgYWNoaWV2 ZWQgd2l0aCBhbiBlbXB0eSA8cGxhbm5lZENoYW5nZT4uDQoNCkkgZG9u4oCZdCB0aGluayB0aGlz IGlzIGNvdmVyZWQgaW4gNTIyMi4gIFRoZSBtZWNoYW5pc20gY2F1c2VzIHRoZSBMb1NUIHNlcnZl ciB0byBzZW5kIG5vdGlmaWNhdGlvbnMgdG8gdGhlIGNsaWVudCwgYnV0IHRoZSBjbGllbnQgaXMg YWxsb3dlZCB0byBwdXQgYW55IFVSSSBpbiB0aGUgcmVjb3JkLCBhbmQgaXQgY2FuIGFkZCBpdCB0 byBhcyBtYW55IHJlY29yZHMgYXMgaXQgd2FudHMuDQpbR0NdIEkgdGhvdWdodCB3ZSBhZ3JlZWQg b24gdXNpbmcgb25lIGdlbmVyaWMgVVJJIHBlciBDbGllbnQuIENsaWVudHMgc2hvdWxkIGJlIGF1 dGhlbnRpY2F0ZWQgYnkgdGhlIFNlcnZlcnMuDQogIEFuIGV2aWwgaW1wbGVtZW50YXRpb24gY291 bGQgcmVjb3JkIFVSSXMgYWdhaW5zdCBtdWx0aXBsZSB0YXJnZXRzIHRoYXQgd2VyZSB1bmF3YXJl IHRoYXQgdGhlIGV2aWwgaW1wbGVtZW50YXRpb24gZGlkIGl0LCB1bnRpbCB0aGV5IGdvdCBhIGxh cmdlIG51bWJlciBvZiBQVVNIIHRyYW5zYWN0aW9ucyB0aGV5IGRpZG7igJl0IGV4cGVjdCBvciB1 bmRlcnN0YW5kIGFzIGEgcmVzdWx0IG9mIGEgbGFyZ2UgcGxhbm5lZCBjaGFuZ2UuDQpbR0NdIE9u bHkgYXV0aGVudGljYXRlZCBDbGllbnRzIHNob3VsZCBiZSBhbGxvd2VkIHRvIHByb3ZpZGUgVVJJ cyB0byBiZSBzdG9yZWQgYnkgdGhlIFNlcnZlcnMuDQoNClRoZSBwcm9wb3NlZCBtZWNoYW5pc20g cXVhbGlmaWVzIHRoZSBjbGllbnQgVVJJIGJlZm9yZSBpdHMgdXNlZCBpbiBhIHBsYW5uZWQgY2hh bmdlLg0KDQpCcmlhbg0KDQo+IE9uIEF1ZyAzMSwgMjAyMSwgYXQgNzozNyBBTSwgQ2Fyb24sIEd1 eSA8Zy5jYXJvbkBiZWxsLmNhPiB3cm90ZToNCj4gDQo+IFdlbGwsIHRoaXMgaXMgbm90IGdvaW5n IGluIHRoZSBkaXJlY3Rpb24gSSB0aG91Z2h0Lg0KPiANCj4gV2hhdCBpcyB0aGUgcHVycG9zZSBv ZiBkZWxldGluZyB0aGUgVVJJcyBhdCB0aGUgU2VydmVyIHBvc3QtdmFsaWRhdGlvbj8NCj4gDQo+ IFJlZ2FyZGluZyBvcGVuaW5nIGEgbmV3IERvUywgSSBndWVzcyBJJ20gbm90IGZvbGxvd2luZy4g V291bGRuJ3QgdGhpcyBjYXNlIGJlIGNvdmVyZWQgYnkgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIGluIFJGQyA1MjIyPw0KPiANCj4gV2hhdCB5b3UncmUgcHJvcG9zaW5nIHB1dHMgYmFjayBz aWduaWZpY2FudCBsb2FkIG9uIHRoZSBTZXJ2ZXJzIChhIGtleSBjb25zaWRlcmF0aW9uIGZvciBj cmVhdGluZyBwbGFubmVkLWNoYW5nZXMgaW4gdGhlIGZpcnN0IHBsYWNlKSBhbmQgY29tcGxpY2F0 ZXMgdGhlIG1lY2hhbmlzbS4NCj4gDQo+IEd1eQ0KPiANCj4gDQo+IC0tLS0tTWVzc2FnZSBkJ29y aWdpbmUtLS0tLQ0KPiBEZSA6IEVjcml0IDxlY3JpdC1ib3VuY2VzQGlldGYub3JnPiBEZSBsYSBw YXJ0IGRlIEJyaWFuIFJvc2VuIEVudm95w6kgOiANCj4gMzAgYW/Du3QgMjAyMSAxMToyMiDDgCA6 IFJhbmRhbGwgR2VsbGVucyA8cmcraWV0ZkByYW5keS5wZW5zaXZlLm9yZz4gQ2MgDQo+IDogRUNS SVQgPGVjcml0QGlldGYub3JnPiBPYmpldCA6IFtFWFRdUmU6IFtFY3JpdF0gcGxhbm5lZC1jaGFu Z2VzOiB0d28gDQo+IHF1ZXN0aW9ucw0KPiANCj4gQW5zd2VyIDE6IHllcy4gIFNpbmNlIHRoZXJl IGlzIGdvaW5nIHRvIGJlIGEgcmV2YWxpZGF0aW9uLCBqdXN0IGRlbGV0aW5nIHRoZSBzZXR0aW5n IHNlZW1zIHJpZ2h0IHRvIG1lLg0KPiBBbnN3ZXIgMjogVXAgdG8gc2VydmVyLiAgSWYgSSB3ZXJl IGltcGxlbWVudGluZywgSSB3b3VsZCBoYXNoIHRoZSByZWFsIElEIHdpdGggdGhlIFVSSSBhbmQg c29tZSBraW5kIG9mIHByZWRpY3RhYmxlIG5vbmNlLiAgDQo+IA0KPiBXZSBwcm9iYWJseSBoYXZl IHRvIHNheSBtb3JlIGFib3V0IGhvdyB0aGUgc2VydmVyIGlkZW50aWZpZXMgdGhlIGNsaWVudCwg c28gdGhhdCByZXBsYWNlbWVudCBvZiB0aGUgVVJJIHdvcmtzLiAgQ291bGQgd2Ugc2F5IHdlIHVz ZSB0aGUgZG9tYWluIG9mIHRoZSBVUkkgKHRoZSBlbnRpcmUgZG9tYWluIHdpdGggYWxsIHRoZSBk b3RzKSB0byBpZGVudGlmeSB0aGUgY2xpZW50LCBhbmQgYW55dGhpbmcgY2FuIG9jY3VyIGFmdGVy IGl0IChtZWFuaW5nIGEgc2xhc2ggYW5kIHdoYXRldmVyKT8gIElmIHdlIGRvIHRoYXQsIHRoZW4g aG93IHdvdWxkIGRlbGV0ZSB0aGUgbm90aWZpY2F0aW9uPyAgRm9yY2UgdGhlcmUgdG8gYmUgc29t ZXRoaW5nIG90aGVyIHRoYW4gdGhlIGRvbWFpbiAodWdseSkuICBFeHBsaWNpdCBkZWxldGUgcmVx dWVzdD8NCj4gDQo+IEhtbW0sIHdl4oCZdmUgb3BlbmVkIGEgRG9TIGF0dGFjazogYSByb2d1ZSBj bGllbnQgc3RvcmVzIGEgYnVuY2ggb2YgVVJJcyBmb3Igc2VydmVycyBpdCB3YW50cyB0byB2aWN0 aW1pemUuICBJbiBOb3J0aCBBbWVyaWNhIHdlIGhhdmUgYSByZWFsIHNpbXBsZSBzb2x1dGlvbiBm b3IgdGhhdCwgYmVjYXVzZSB3ZSBoYXZlIGEgUEtJLCBzbyB3ZSBrbm93LCBmb3Igc3VyZSwgd2hv IHRoZSBjbGllbnQgaXMsIGFuZCBjb3VsZCByZXN0cmljdCB3aG8gd2UgYWxsb3cgdG8gc3RvcmUg VVJJcywgYnV0IHRoYXQgd291bGRu4oCZdCBiZSB0cnVlIGluIGdlbmVyYWwuICBBbHNvLCBpdCB3 b3VsZCBiZSBuaWNlIGZvciB0aGUgY2xpZW50IHRvIGhhdmUgY29uZmlkZW5jZSB0aGUgbWVjaGFu aXNtIHdvcmtlZCBiZWZvcmUgaXQgbmVlZGVkIGl0Lg0KPiANCj4gU28NCj4gTGV04oCZcyBhZGQg YSDigJxjb21tYW5k4oCdIHRvIHBsYW5uZWRDaGFuZ2UgaW4gdGhlIGZpbmRTZXJ2aWNlIHJlcXVl c3QuICANCj4gQW5kLCBoYXZlIHRoZSBjbGllbnQgaGF2ZSBhIHJlc3BvbnNlIHRvIHRoZSBub3Rp ZmljYXRpb24gd2hpY2ggaXMgdGhlIA0KPiBJRCAoanNvbiB3aXRoIHRoZSAyMDApDQo+IA0KPiAN Cj4gVGhlIGNsaWVudCBzdGFydHMgYnkgc2VuZGluZyBhIGNvbW1hbmQgb2Yg4oCcaW5pdGlhbGl6 ZeKAnS4gIFRoZSBkb21haW4gaXMgdGhlIGlkZW50aXR5IG9mIHRoZSBjbGllbnQuICBUaGUgcmVz cG9uc2UgaXMgYW4gaW1tZWRpYXRlIG5vdGlmaWNhdGlvbiB0byB0aGUgd2l0aCB3aGF0ZXZlciBM SSB3YXMgaW4gdGhlIHJlcXVlc3QgYW5kIGFuIElELiAgVGhlICByZXNwb25zZSBieSB0aGUgY2xp ZW50ICh3aGljaCBpcyB0aGUgbm90aWZpY2F0aW9uIHdlYiBzZXJ2ZXIpIGlzIGEgcGllY2Ugb2Yg anNvbiBjb250YWluaW5nIHRoZSBJRC4gIFdlIGNhbiBzYXkgdGhhdCB0aGUgTEkgaW4gdGhpcyBp bml0aWFsaXplIGNvbW1hbmQgY291bGQgYmUgc29tZXRoaW5nIHNpbXBsZSBsaWtlIHRoZSBDb3Vu dHJ5IENvZGUgdGhhdCB3b3VsZG7igJl0IGdldCBhIHBsYW5uZWQgY2hhbmdlLg0KPiANCj4gVGhl cmVhZnRlciwgdGhlIExvU1Qgc2VydmVyIChub3RpZmljYXRpb24gY2xpZW50KSBwZXJpb2RpY2Fs bHkgcmVwZWF0cyB0aGlzIGtlZXBhbGl2ZSBub3RpZmljYXRpb24gZXZlcnkgZGF5IG9yIHdlZWsg d2l0aCB0aGUgaW5pdGlhbGl6ZSBMSS4gIFRoZSBjbGllbnQgaGFzIHRvIHJlc3BvbmQgd2l0aCB0 aGUgSUQuDQo+IA0KPiBUaGUgcmVndWxhciBub3RpZmljYXRpb24gcmVxdWVzdCBpcyBhIGNvbW1h bmQgb2Yg4oCcbm90aWZ54oCdLiAgVGhlIHNlcnZlciBpZ25vcmVzIGEgcmVxdWVzdCBmb3Igbm90 aWZpY2F0aW9uIGZyb20gYW4gdW5pbml0aWFsaXplZCBjbGllbnQuDQo+IFRoZSBub3RpZmljYXRp b24gY2FuIGJlIGRlbGV0ZWQgd2l0aCBhIGNvbW1hbmQgb2Yg4oCcZGVsZXRl4oCdLiAgSWYgeW91 IGRlbGV0ZSB0aGUgaW5pdGlhbGl6ZSBMSSwgdGhlbiB0aGUgc2VydmVyIHdvbuKAmXQgc2VuZCBh bnkgbW9yZSBub3RpZmljYXRpb25zIHRvIHRoYXQgY2xpZW50IGFuZCBkZWxldGVzIGFsbCBVUklz IGl0IHdhcyBzYXZpbmcgZm9yIHRoYXQgY2xpZW50LiAgVGhlIGNsaWVudCB3b3VsZCBoYXZlIHRv IHJlLWluaXRpYWxpemUgdG8gcmVzZXQuDQo+IA0KPiBCcmlhbg0KPiANCj4+IE9uIEF1ZyAyNywg MjAyMSwgYXQgNTo0MSBQTSwgUmFuZGFsbCBHZWxsZW5zIDxyZytpZXRmQHJhbmR5LnBlbnNpdmUu b3JnPiB3cm90ZToNCj4+IA0KPj4gSSB0aGluayB3ZSdyZSBtb3ZpbmcgdG8gYSBtb2RlbCB3aGVy ZToNCj4+IC0gSW4gYSBxdWVyeSwgYSBjbGllbnQgY2FuIHJlcXVlc3QgdG8gYmUgbm90aWZpZWQg d2hlbiB0aGUgbG9jYXRpb24gDQo+PiBzaG91bGQgYmUgcmV2YWxpZGF0ZWQ7DQo+PiAtIEluIHRo ZSByZXNwb25zZSwgdGhlIHNlcnZlciBwcm92aWRlcyBhbiBJRCB3aGljaCB0aGUgY2xpZW50IA0K Pj4gYXNzb2NpYXRlcyB3aXRoIHRoZSBsb2NhdGlvbiBpdCBqdXN0IHZhbGlkYXRlZDsNCj4+IC0g VGhlIHNlcnZlciBzZW5kcyBhIG5vdGlmaWNhdGlvbiB0byB0aGUgVVJJLCBjb250YWluaW5nIHRo ZSBJRDsNCj4+IC0gVGhlIGNsaWVudCByZXZhbGlkYXRlcyBlYWNoIGxvY2F0aW9uIHdpdGggd2hp Y2ggdGhhdCBJRCBpcyBhc3NvY2lhdGVkLg0KPj4gDQo+PiBRdWVzdGlvbiAxOiBEb2VzIHRoZSBz ZXJ2ZXIgZGVsZXRlL2luYWN0aXZhdGUgdGhlIFVSSSBvbmNlIGl0IGhhcyBzZW50IHRoZSBub3Rp ZmljYXRpb24/DQo+PiANCj4+IFF1ZXN0aW9uIDI6IFByZXN1bWFibHksIHdoZW4gdGhlIGNsaWVu dCByZXZhbGlkYXRlcyB0aGUgbG9jYXRpb24ocyksIGl0IHdpbGwgYWdhaW4gcmVxdWVzdCBub3Rp ZmljYXRpb24uICBEb2VzIHRoZSBzZXJ2ZXIgcmV0dXJuIHRoZSBzYW1lIElEIGFzIGJlZm9yZSwg b3IgYSBkaWZmZXJlbnQgSUQ/ICBBIGRpZmZlcmVudCBJRCBjb3VsZCBwZXJoYXBzIGJlIHVzZWZ1 bCBpbiBlZGdlIGNhc2VzIHdoZXJlIHRoZSBzZXJ2ZXIgZGlkbid0IHNlbmQgb3IgdGhlIGNsaWVu dCBkaWRuJ3QgZ2V0IHRoZSBub3RpZmljYXRpb24sIGJ1dCBhbnkgdXRpbGl0eSBzZWVtcyBzbWFs bC4gIElmIGl0J3MgdGhlIHNhbWUgSUQsIHRoZW4gdGhlIGFuc3dlciB0byBxdWVzdGlvbiAxIGNh biBiZSB0aGF0IHRoZSBVUkkgcmVtYWlucyBhY3RpdmUgdW50aWwgdGhlIGNsaWVudCBhc2tzIHRv IG5vIGxvbmdlciBiZSBub3RpZmllZCAoYnkgc2VuZGluZyBhbiBlbXB0eSBVUkk/KS4NCj4+IA0K Pj4gLS1SYW5kYWxsDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4+IEVjcml0QGlldGYub3JnDQo+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBFY3JpdCBtYWls aW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9lY3JpdA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tLS0tLS0tIEV4dGVybmFsIEVt YWlsOiBQbGVhc2UgdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxpbmtzIGFuZCANCj4gYXR0YWNo bWVudHMgLyBDb3VycmllbCBleHRlcm5lOiBTb3lleiBwcnVkZW50IGF2ZWMgbGVzIGxpZW5zIGV0 IA0KPiBkb2N1bWVudHMgam9pbnRzDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRXh0ZXJuYWwg RW1haWw6IFBsZWFzZSB1c2UgY2F1dGlvbiB3aGVuIG9wZW5pbmcgbGlua3MgYW5kIGF0dGFjaG1l bnRzIC8gQ291cnJpZWwgZXh0ZXJuZTogU295ZXogcHJ1ZGVudCBhdmVjIGxlcyBsaWVucyBldCBk b2N1bWVudHMgam9pbnRzDQo= From nobody Tue Aug 31 06:04:57 2021 Return-Path: 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 CBA423A13FD for ; Tue, 31 Aug 2021 06:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=bell.ca 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 wIz8ZXJ8WGla for ; Tue, 31 Aug 2021 06:04:50 -0700 (PDT) Received: from ESA1-Dor.bell.ca (esa1-dor.bell.ca [204.101.223.58]) (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 D44D33A13F9 for ; Tue, 31 Aug 2021 06:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1630415089; x=1661951089; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=cHTHMQAb6JBbZt7uMN2dPWH+lyhnkFoDdrB2gC0dIUs=; b=KJUpGxRcdPXyOILtFz64TL6OPwUCow8Cwc/w5PfNB30iMr0Ob0DaNSaM bVOB509rbsX+eNDH9LswzKTxG5Pq4OgSFFVtBH+Rfi92v6YJAPn8vQ32Z oxIFPvwzW+FYhg70VDgzGJxOQ4APm35IAMiRI1dEO7ZBUQfU9riYWZU7O M6kjEywyO7vZqlZ0RfF+YsFmaKm8i8gQAS7fDnAhFdpuSI76nkLmHrBQe BbrBlm11p266H/JEEiUZvDCtvpY97OLOveZw1VOmY22jXCZvjlFUiEE6i XEkQtdVQyOKEuqbnhB1tFZViziiklHuOXjdtXMAY5LnFO8E0Gp/1fzAdT w==; IronPort-SDR: kGIismMqNuz+DEDtqopiLDvKz16bciRPwuW7stD10YKZf+TkhkGgAAW9BdyLhgxMT6ZcSdwAoP TLNThljyY3GA== Received: from dc5cmy-d00.bellca.int.bell.ca (HELO DG4MBX02-WYN.bell.corp.bce.ca) ([198.235.121.229]) by esa01corp-dor.bell.corp.bce.ca with ESMTP; 31 Aug 2021 09:04:48 -0400 Received: from DG12MBX02-WYN.bell.corp.bce.ca (142.182.18.47) by DG4MBX02-WYN.bell.corp.bce.ca (142.182.18.28) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Tue, 31 Aug 2021 09:04:48 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX02-WYN.bell.corp.bce.ca (142.182.18.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Tue, 31 Aug 2021 09:04:47 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Tue, 31 Aug 2021 09:04:47 -0400 From: "Caron, Guy" To: ECRIT Thread-Topic: similar-location-09: GCaron Review Thread-Index: Adebe1KGR57xvilqQAOgCtIx5j1+GgABAJmwALpQr5A= Date: Tue, 31 Aug 2021 13:04:47 +0000 Message-ID: <07be5a05ac8b4146adc2f0ba56f0e106@bell.ca> References: <6fdb8f42317d4dfc99783a4d834b6c85@bell.ca> In-Reply-To: <6fdb8f42317d4dfc99783a4d834b6c85@bell.ca> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.239.74] Content-Type: multipart/alternative; boundary="_000_07be5a05ac8b4146adc2f0ba56f0e106bellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] similar-location-09: GCaron Review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 13:04:56 -0000 --_000_07be5a05ac8b4146adc2f0ba56f0e106bellca_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Can someone confirm that the attachment was delivered through the ECRIT lis= t? I got it myself but want to be sure everyone got it. Thanks, Guy De : Ecrit De la part de Caron, Guy Envoy=E9 : 27 ao=FBt 2021 16:09 =C0 : ECRIT Objet : [EXT][Ecrit] TR: similar-location-09: GCaron Review Resending to the ECRIT list. Guy De : Caron, Guy Envoy=E9 : 27 ao=FBt 2021 16:01 =C0 : 'draft-ietf-ecrit-similar-location@ietf.org' > Objet : similar-location-09: GCaron Review Hi, I reviewed this document and think it is mostly in good shape. I have a few= comments to offer: 1. The document does not use a convention to express XML types such a= s for elements, 'boobooboo' for attributes, "heyheyhey" for val= ues, etc. in the text. Should it? 2. The document defines terms in section 2, which are spelled with ca= pital first letters however, when used in the text after section 2, a numbe= r of instances do no use the same style and should. 3. Section 2, in the Invalid Location definition, the term locationIn= valid is used however, there is no defined element in here or anywhere else= . Was that suppose to refer to lost-planned-changes ? 4. Section 2, the Similar Location definition says "A suggested civic= location that is comparatively close to the civic location which was input= ". Comparing what? Geographic proximity, semantically close, else? 5. For completeness, it would be nice to include the 'similarLocation= sLimited' attribute in the example in section 5.2. 6. There are two errors in the XML schema in section 6: a. xmlns=3D"urn:ietf:params:xml:ns:lost-rli1=E2 should be xmlns=3D"ur= n:ietf:params:xml:ns:lost-rli1" b. should be 7. The reference to planned-changes in section 9.1 should be updated I'm trying to attach a MSWord version with track-change here that includes = resolutions to 2 and 5, with additional proposed editorial and non-subtativ= e changes. If it does not pass the mail server, I will send directly to the= authors. Thanks, Guy --_000_07be5a05ac8b4146adc2f0ba56f0e106bellca_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Can som= eone confirm that the attachment was delivered through the ECRIT list?=

&n= bsp;

I got i= t myself but want to be sure everyone got it.

&n= bsp;

Thanks,=

&n= bsp;

Guy

 

De : Ecrit <ecrit-bounces@ietf.org> De la part de Caron, Guy
Envoy=E9 : 27 ao=FBt 2021 16:09
=C0 : ECRIT <ecrit@ietf.org>
Objet : [EXT][Ecrit] TR: similar-location-09: GCaron Review

 

Resendi= ng to the ECRIT list.

 <= /span>

Guy

 

De : Caron, Guy
Envoy=E9 : 27 ao=FBt 2021 16:01
=C0 : 'draft-ietf-ecrit-similar-location@ietf.org' <draft-ietf-ecrit-sim= ilar-location@ietf.org>
Objet : similar-location-09: GCaron Review

 

Hi,

 

I reviewed this document and= think it is mostly in good shape. I have a few comments to offer:

 

1.       The document does not use a co= nvention to express XML types such as <blablabla> for elements, ̵= 6;boobooboo’ for attributes, “heyheyhey” for values, etc.= in the text. Should it?

2.       The document defines terms in = section 2, which are spelled with capital first letters however, when used = in the text after section 2, a number of instances do no use the same style= and should.

3.       Section 2, in the Invalid Loca= tion definition, the term locationInvalid is used however, there is no defi= ned element in here or anywhere else. Was that suppose to refer to lost-pla= nned-changes <locationInvalidated>?

4.       Section 2, the Similar Locatio= n definition says “A suggested civic location that is comparatively c= lose to the civic location which was input”. Comparing what? Geograph= ic proximity, semantically close, else?

5.       For completeness, it would be = nice to include the ‘similarLocationsLimited’ attribute in the = example <findServiceResponse> in section 5.2.

6.       There are two errors in the XM= L schema in section 6:

a.       xmlns=3D"urn:ietf:params:= xml:ns:lost-rli1=E2 should be xmlns=3D"urn:ietf:params:xml:ns:lost-rli= 1"

b.       <xs:minInclusive value=3D&q= uot;1"> should be <xs:minInclusive value=3D"1"/>

7.       The reference to planned-chang= es in section 9.1 should be updated

 

I’m trying to attach a= MSWord version with track-change here that includes resolutions to 2 and 5= , with additional proposed editorial and non-subtative changes. If it does = not pass the mail server, I will send directly to the authors.

 

Thanks,

 

Guy

--_000_07be5a05ac8b4146adc2f0ba56f0e106bellca_-- From nobody Tue Aug 31 10:27:49 2021 Return-Path: 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 AA9E03A1E78 for ; Tue, 31 Aug 2021 10:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, 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.20150623.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 bYv0bJLmsSwN for ; Tue, 31 Aug 2021 10:27:41 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 013563A1E73 for ; Tue, 31 Aug 2021 10:27:41 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id q3so25922626iot.3 for ; Tue, 31 Aug 2021 10:27:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=tcGaAiyC7lHZOLJTLXn0yu1e8qgQgGoM9LTE1BDdGP8=; b=BCg+EdtZUwYHDwbD+aqhiQpdA5OZbxLbdlXNTLAy4K0HHarzLx7zYa8vDyFFBNy3qV HkscoTgJfr2OpfK6oSzyUcDFX0jHQRb5lsNrUj5kcteJSU78gCW38p8zWMTLF1am6T2a mJVoB2rlMjA21zwKQY/dAJmpWZlx6syGopNeXS/u5Xf5U1MQ0YmmzchcDRaBiI6VoP5H lS83W437qjoKHSm95E/dK8BWf20yj/YzgrBO0mBuKn1+81E0xlkBdYGq0mu7VakHWdCC u8wJnREigblgryobG89SpVv+hr834Hiz3RbVBab4tUS5VnKgLwqj4cM+VuB5m1vQpc/t KvpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=tcGaAiyC7lHZOLJTLXn0yu1e8qgQgGoM9LTE1BDdGP8=; b=Lgshs8kom94PI4/E6lwIAMEQHMNe+LuaNqYW5fYQo8sMOTUH+p27tgw6+xD4CV98eI HAgNQwn2ry6y+o9ZZgl+cHMDT1BF9qRGXCi8Al/0UkyAbF/Q4HDz0bA+zBTzWV0YNCyW 0IyX48+nJUleudMM0HbuSoQa7sCbel4mfeXDEC4n06EOPQ+3DrOCbx4z2SPoMLU1/uSf 67ZguVsQes0YMy/MByM+yiT4Kdbma2/uFPBxM8w/a/CJqPLtqYQVozergD5LPImYXQaH Pi2od57xvZhBsRuq1F7J4QDtFUdQKrW6j8EmM/bVickF1vUOfz3bJ1b2iptAdiMtjMLr 1+eg== X-Gm-Message-State: AOAM532qgrvxR6ikpnkCp8xCasevRW1F//GsEtZkb4XfKsAVM2hwByPg o8Fug6V8Q/YyrXV8L/cNwmkEKA== X-Google-Smtp-Source: ABdhPJyEEUYYN2LJEYS8+q3nAnLt0/tgQS85s4sdueg5oUdaSYVXs0nEcDQIK3gU2A1cumyd5bzlhw== X-Received: by 2002:a6b:f919:: with SMTP id j25mr24205632iog.2.1630430858082; Tue, 31 Aug 2021 10:27:38 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id k6sm10537368ilu.41.2021.08.31.10.27.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Aug 2021 10:27:34 -0700 (PDT) From: Brian Rosen Message-Id: <3AD58DEC-1DC9-4BC0-B55C-4E782E4AAA74@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_7854DCA6-C7AD-43D9-8A29-5BE2DBD2EC3B" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 31 Aug 2021 13:27:32 -0400 In-Reply-To: Cc: Randall Gellens , ECRIT To: "Caron, Guy" References: <5577e2e6daa4405bbe12ef61675e1f55@bell.ca> X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Ecrit] planned-changes: two questions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 17:27:48 -0000 --Apple-Mail=_7854DCA6-C7AD-43D9-8A29-5BE2DBD2EC3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 If the work group wants to have the LoST server keep the URI until = expressly deleted, that=E2=80=99s okay with me. Authenticating the client to the server doesn=E2=80=99t mean the URI is = authenticated. We can=E2=80=99t restrict the URI to be the same entity = as the client running the LoST transaction. And the clients are wide = ranging. Could be an enterprise running its own LIS for example. We = can=E2=80=99t assume the North American PKI is workable everywhere, and = even that doesn=E2=80=99t extend to an enterprise LIS. ISTM we have to = run a test transaction with the notification service to make sure it=E2=80= =99s what we think it is. Brian > On Aug 31, 2021, at 9:01 AM, Caron, Guy wrote: >=20 > Inline. >=20 > Guy >=20 > -----Message d'origine----- > De : Brian Rosen >=20 > Envoy=C3=A9 : 31 ao=C3=BBt 2021 08:11 > =C3=80 : Caron, Guy > > Cc : Randall Gellens >; ECRIT > > Objet : [EXT]Re: [Ecrit] planned-changes: two questions >=20 > You delete the URI when you delete the record in the LIS. > [GC] That's fine but that was not the question Randall posed. He asked = whether the URI is deleted after a notification. I agree that if the = Client does not host the location anymore that the URI associated with = that location in the Server should be deleted. This could be achieved = with an empty . >=20 > I don=E2=80=99t think this is covered in 5222. The mechanism causes = the LoST server to send notifications to the client, but the client is = allowed to put any URI in the record, and it can add it to as many = records as it wants. > [GC] I thought we agreed on using one generic URI per Client. Clients = should be authenticated by the Servers. > An evil implementation could record URIs against multiple targets = that were unaware that the evil implementation did it, until they got a = large number of PUSH transactions they didn=E2=80=99t expect or = understand as a result of a large planned change. > [GC] Only authenticated Clients should be allowed to provide URIs to = be stored by the Servers. >=20 > The proposed mechanism qualifies the client URI before its used in a = planned change. >=20 > Brian >=20 >> On Aug 31, 2021, at 7:37 AM, Caron, Guy wrote: >>=20 >> Well, this is not going in the direction I thought. >>=20 >> What is the purpose of deleting the URIs at the Server = post-validation? >>=20 >> Regarding opening a new DoS, I guess I'm not following. Wouldn't this = case be covered by the security considerations in RFC 5222? >>=20 >> What you're proposing puts back significant load on the Servers (a = key consideration for creating planned-changes in the first place) and = complicates the mechanism. >>=20 >> Guy >>=20 >>=20 >> -----Message d'origine----- >> De : Ecrit De la part de Brian Rosen Envoy=C3=A9= :=20 >> 30 ao=C3=BBt 2021 11:22 =C3=80 : Randall Gellens = Cc=20 >> : ECRIT Objet : [EXT]Re: [Ecrit] planned-changes: = two=20 >> questions >>=20 >> Answer 1: yes. Since there is going to be a revalidation, just = deleting the setting seems right to me. >> Answer 2: Up to server. If I were implementing, I would hash the = real ID with the URI and some kind of predictable nonce. =20 >>=20 >> We probably have to say more about how the server identifies the = client, so that replacement of the URI works. Could we say we use the = domain of the URI (the entire domain with all the dots) to identify the = client, and anything can occur after it (meaning a slash and whatever)? = If we do that, then how would delete the notification? Force there to = be something other than the domain (ugly). Explicit delete request? >>=20 >> Hmmm, we=E2=80=99ve opened a DoS attack: a rogue client stores a = bunch of URIs for servers it wants to victimize. In North America we = have a real simple solution for that, because we have a PKI, so we know, = for sure, who the client is, and could restrict who we allow to store = URIs, but that wouldn=E2=80=99t be true in general. Also, it would be = nice for the client to have confidence the mechanism worked before it = needed it. >>=20 >> So >> Let=E2=80=99s add a =E2=80=9Ccommand=E2=80=9D to plannedChange in the = findService request. =20 >> And, have the client have a response to the notification which is the=20= >> ID (json with the 200) >>=20 >>=20 >> The client starts by sending a command of =E2=80=9Cinitialize=E2=80=9D.= The domain is the identity of the client. The response is an = immediate notification to the with whatever LI was in the request and an = ID. The response by the client (which is the notification web server) = is a piece of json containing the ID. We can say that the LI in this = initialize command could be something simple like the Country Code that = wouldn=E2=80=99t get a planned change. >>=20 >> Thereafter, the LoST server (notification client) periodically = repeats this keepalive notification every day or week with the = initialize LI. The client has to respond with the ID. >>=20 >> The regular notification request is a command of =E2=80=9Cnotify=E2=80=9D= . The server ignores a request for notification from an uninitialized = client. >> The notification can be deleted with a command of =E2=80=9Cdelete=E2=80= =9D. If you delete the initialize LI, then the server won=E2=80=99t = send any more notifications to that client and deletes all URIs it was = saving for that client. The client would have to re-initialize to = reset. >>=20 >> Brian >>=20 >>> On Aug 27, 2021, at 5:41 PM, Randall Gellens = wrote: >>>=20 >>> I think we're moving to a model where: >>> - In a query, a client can request to be notified when the location=20= >>> should be revalidated; >>> - In the response, the server provides an ID which the client=20 >>> associates with the location it just validated; >>> - The server sends a notification to the URI, containing the ID; >>> - The client revalidates each location with which that ID is = associated. >>>=20 >>> Question 1: Does the server delete/inactivate the URI once it has = sent the notification? >>>=20 >>> Question 2: Presumably, when the client revalidates the location(s), = it will again request notification. Does the server return the same ID = as before, or a different ID? A different ID could perhaps be useful in = edge cases where the server didn't send or the client didn't get the = notification, but any utility seems small. If it's the same ID, then = the answer to question 1 can be that the URI remains active until the = client asks to no longer be notified (by sending an empty URI?). >>>=20 >>> --Randall >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> = ---------------------------------------------------------------------- >> -------- External Email: Please use caution when opening links and=20 >> attachments / Courriel externe: Soyez prudent avec les liens et=20 >> documents joints >=20 > = --------------------------------------------------------------------------= ---- > External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints --Apple-Mail=_7854DCA6-C7AD-43D9-8A29-5BE2DBD2EC3B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 If = the work group wants to have the LoST server keep the URI until = expressly deleted, that=E2=80=99s okay with me.

Authenticating the client to the server = doesn=E2=80=99t mean the URI is authenticated.  We can=E2=80=99t = restrict the URI to be the same entity as the client running the LoST = transaction.  And the clients are wide ranging.  Could be an = enterprise running its own LIS for example.  We can=E2=80=99t = assume the North American PKI is workable everywhere, and even that = doesn=E2=80=99t extend to an enterprise LIS.  ISTM we have to run a = test transaction with the notification service to make sure it=E2=80=99s = what we think it is.

Brian



On Aug = 31, 2021, at 9:01 AM, Caron, Guy <g.caron@bell.ca> wrote:

Inline.

Guy

-----Message d'origine-----
De : Brian Rosen <br@brianrosen.net> 
Envoy=C3=A9 : 31 ao=C3=BBt = 2021 08:11
=C3=80 : = Caron, Guy <g.caron@bell.ca>
Cc : Randall Gellens <rg+ietf@randy.pensive.org>; ECRIT <ecrit@ietf.org>
Objet : [EXT]Re: [Ecrit] planned-changes: two = questions

You delete = the URI when you delete the record in the LIS.
[GC] That's fine but that was = not the question Randall posed. He asked whether the URI is deleted = after a notification. I agree that if the Client does not host the = location anymore that the URI associated with that location in the = Server should be deleted. This could be achieved with an empty = <plannedChange>.

I don=E2=80=99t think this is covered in 5222.  The = mechanism causes the LoST server to send notifications to the client, = but the client is allowed to put any URI in the record, and it can add = it to as many records as it wants.
[GC] I thought we agreed on using one generic URI per Client. = Clients should be authenticated by the Servers.
 An evil implementation = could record URIs against multiple targets that were unaware that the = evil implementation did it, until they got a large number of PUSH = transactions they didn=E2=80=99t expect or understand as a result of a = large planned change.
[GC] Only authenticated Clients should be allowed to provide = URIs to be stored by the Servers.

The proposed mechanism qualifies the client URI before its = used in a planned change.

Brian

On Aug 31, 2021, at 7:37 AM, Caron, = Guy <g.caron@bell.ca> wrote:

Well, this is not going in the direction I thought.

What is the purpose of deleting the URIs at = the Server post-validation?

Regarding = opening a new DoS, I guess I'm not following. Wouldn't this case be = covered by the security considerations in RFC 5222?

What you're proposing puts back significant load on the = Servers (a key consideration for creating planned-changes in the first = place) and complicates the mechanism.

Guy


-----Message d'origine-----
De : Ecrit <ecrit-bounces@ietf.org> De la part de Brian Rosen = Envoy=C3=A9 : 
30 ao=C3=BBt 2021 11:22 =C3=80 : Randall Gellens <rg+ietf@randy.pensive.org> Cc 
: ECRIT = <ecrit@ietf.org> = Objet : [EXT]Re: [Ecrit] planned-changes: two 
questions

Answer 1: yes.  Since there is going to = be a revalidation, just deleting the setting seems right to me.
Answer 2: Up to server.  If I were implementing, I would = hash the real ID with the URI and some kind of predictable nonce. =  

We probably have to say more about = how the server identifies the client, so that replacement of the URI = works.  Could we say we use the domain of the URI (the entire = domain with all the dots) to identify the client, and anything can occur = after it (meaning a slash and whatever)?  If we do that, then how = would delete the notification?  Force there to be something other = than the domain (ugly).  Explicit delete request?

Hmmm, we=E2=80=99ve opened a DoS attack: a rogue client = stores a bunch of URIs for servers it wants to victimize.  In North = America we have a real simple solution for that, because we have a PKI, = so we know, for sure, who the client is, and could restrict who we allow = to store URIs, but that wouldn=E2=80=99t be true in general.  Also, = it would be nice for the client to have confidence the mechanism worked = before it needed it.

So
Let=E2=80= =99s add a =E2=80=9Ccommand=E2=80=9D to plannedChange in the findService = request.  
And, have the client have a response to = the notification which is the 
ID (json = with the 200)


The client = starts by sending a command of =E2=80=9Cinitialize=E2=80=9D.  The = domain is the identity of the client.  The response is an immediate = notification to the with whatever LI was in the request and an ID. =  The  response by the client (which is the notification web = server) is a piece of json containing the ID.  We can say that the = LI in this initialize command could be something simple like the Country = Code that wouldn=E2=80=99t get a planned change.

Thereafter, the LoST server (notification client) = periodically repeats this keepalive notification every day or week with = the initialize LI.  The client has to respond with the ID.

The regular notification request is a command = of =E2=80=9Cnotify=E2=80=9D.  The server ignores a request for = notification from an uninitialized client.
The = notification can be deleted with a command of =E2=80=9Cdelete=E2=80=9D. =  If you delete the initialize LI, then the server won=E2=80=99t = send any more notifications to that client and deletes all URIs it was = saving for that client.  The client would have to re-initialize to = reset.

Brian

On Aug 27, 2021, at 5:41 = PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

I think we're moving to a model where:
- In a = query, a client can request to be notified when the location 
should be = revalidated;
- In the response, the server provides an ID = which the client 
associates with the location it just validated;
-= The server sends a notification to the URI, containing the ID;
- The client revalidates each location with which that ID is = associated.

Question 1: Does the server = delete/inactivate the URI once it has sent the notification?

Question 2: Presumably, when the client = revalidates the location(s), it will again request notification. =  Does the server return the same ID as before, or a different ID? =  A different ID could perhaps be useful in edge cases where the = server didn't send or the client didn't get the notification, but any = utility seems small.  If it's the same ID, then the answer to = question 1 can be that the URI remains active until the client asks to = no longer be notified (by sending an empty URI?).

--Randall

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
---------------------------------------------------------------= -------
-------- External Email: Please use caution when = opening links and 
attachments / Courriel externe: Soyez prudent avec les liens = et 
documents joints

---------------------------------------------------------------= ---------------
External Email: Please use caution when opening links and = attachments / Courriel externe: Soyez prudent avec les liens et = documents joints

= --Apple-Mail=_7854DCA6-C7AD-43D9-8A29-5BE2DBD2EC3B-- From nobody Tue Aug 31 10:35:43 2021 Return-Path: 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 730733A1EEC for ; Tue, 31 Aug 2021 10:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, T_SPF_TEMPERROR=0.01, 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 5-wrcaQrNM8z for ; Tue, 31 Aug 2021 10:35:35 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 48F9C3A1EE9 for ; Tue, 31 Aug 2021 10:35:35 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 31 Aug 2021 10:35:34 -0700 From: "Randall Gellens" To: "Brian Rosen" Cc: "Caron, Guy" , ECRIT Date: Tue, 31 Aug 2021 10:35:33 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: <3AD58DEC-1DC9-4BC0-B55C-4E782E4AAA74@brianrosen.net> References: <5577e2e6daa4405bbe12ef61675e1f55@bell.ca> <3AD58DEC-1DC9-4BC0-B55C-4E782E4AAA74@brianrosen.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_122F53A7-DD6A-4878-BB89-D1C436425E4C_=" Embedded-HTML: [{"HTML":[989, 28109], "plain":[658, 7339], "uuid":"85167882-4707-4DA7-AF04-D76EDFA3EC1F"}] Archived-At: Subject: Re: [Ecrit] planned-changes: two questions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 17:35:42 -0000 --=_MailMate_122F53A7-DD6A-4878-BB89-D1C436425E4C_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable If a malicious client registers a URI that is designed to attack a third = site, the test transaction causes the LoST server to connect to it and = POST a command. Without a test transaction, the LoST server stores the = URI and at a future time connects to it and sends a command. Either = way, a LoST client can register potentially one URI per queried = location, and a LoST server will connect to that URI and POST a message. = A queried location could be tied to many other locations, so there = could be many locations for which a change would trigger the LoST server = to use the URI, but is that worse? --Randall On 31 Aug 2021, at 10:27, Brian Rosen wrote: > If the work group wants to have the LoST server keep the URI until = > expressly deleted, that=E2=80=99s okay with me. > > Authenticating the client to the server doesn=E2=80=99t mean the URI is= = > authenticated. We can=E2=80=99t restrict the URI to be the same entity= as = > the client running the LoST transaction. And the clients are wide = > ranging. Could be an enterprise running its own LIS for example. We = > can=E2=80=99t assume the North American PKI is workable everywhere, and= even = > that doesn=E2=80=99t extend to an enterprise LIS. ISTM we have to run = a = > test transaction with the notification service to make sure it=E2=80=99= s = > what we think it is. > > Brian > > > >> On Aug 31, 2021, at 9:01 AM, Caron, Guy wrote: >> >> Inline. >> >> Guy >> >> -----Message d'origine----- >> De : Brian Rosen > >> Envoy=C3=A9 : 31 ao=C3=BBt 2021 08:11 >> =C3=80 : Caron, Guy > >> Cc : Randall Gellens > >; ECRIT > > >> Objet : [EXT]Re: [Ecrit] planned-changes: two questions >> >> You delete the URI when you delete the record in the LIS. >> [GC] That's fine but that was not the question Randall posed. He = >> asked whether the URI is deleted after a notification. I agree that = >> if the Client does not host the location anymore that the URI = >> associated with that location in the Server should be deleted. This = >> could be achieved with an empty . >> >> I don=E2=80=99t think this is covered in 5222. The mechanism causes t= he = >> LoST server to send notifications to the client, but the client is = >> allowed to put any URI in the record, and it can add it to as many = >> records as it wants. >> [GC] I thought we agreed on using one generic URI per Client. Clients = >> should be authenticated by the Servers. >> An evil implementation could record URIs against multiple targets = >> that were unaware that the evil implementation did it, until they got = >> a large number of PUSH transactions they didn=E2=80=99t expect or = >> understand as a result of a large planned change. >> [GC] Only authenticated Clients should be allowed to provide URIs to = >> be stored by the Servers. >> >> The proposed mechanism qualifies the client URI before its used in a = >> planned change. >> >> Brian >> >>> On Aug 31, 2021, at 7:37 AM, Caron, Guy wrote: >>> >>> Well, this is not going in the direction I thought. >>> >>> What is the purpose of deleting the URIs at the Server = >>> post-validation? >>> >>> Regarding opening a new DoS, I guess I'm not following. Wouldn't = >>> this case be covered by the security considerations in RFC 5222? >>> >>> What you're proposing puts back significant load on the Servers (a = >>> key consideration for creating planned-changes in the first place) = >>> and complicates the mechanism. >>> >>> Guy >>> >>> >>> -----Message d'origine----- >>> De : Ecrit De la part de Brian Rosen = >>> Envoy=C3=A9 : >>> 30 ao=C3=BBt 2021 11:22 =C3=80 : Randall Gellens = >>> Cc >>> : ECRIT Objet : [EXT]Re: [Ecrit] planned-changes: = >>> two >>> questions >>> >>> Answer 1: yes. Since there is going to be a revalidation, just = >>> deleting the setting seems right to me. >>> Answer 2: Up to server. If I were implementing, I would hash the = >>> real ID with the URI and some kind of predictable nonce. >>> >>> We probably have to say more about how the server identifies the = >>> client, so that replacement of the URI works. Could we say we use = >>> the domain of the URI (the entire domain with all the dots) to = >>> identify the client, and anything can occur after it (meaning a = >>> slash and whatever)? If we do that, then how would delete the = >>> notification? Force there to be something other than the domain = >>> (ugly). Explicit delete request? >>> >>> Hmmm, we=E2=80=99ve opened a DoS attack: a rogue client stores a bunc= h of = >>> URIs for servers it wants to victimize. In North America we have a = >>> real simple solution for that, because we have a PKI, so we know, = >>> for sure, who the client is, and could restrict who we allow to = >>> store URIs, but that wouldn=E2=80=99t be true in general. Also, it w= ould = >>> be nice for the client to have confidence the mechanism worked = >>> before it needed it. >>> >>> So >>> Let=E2=80=99s add a =E2=80=9Ccommand=E2=80=9D to plannedChange in the= findService = >>> request. >>> And, have the client have a response to the notification which is = >>> the >>> ID (json with the 200) >>> >>> >>> The client starts by sending a command of =E2=80=9Cinitialize=E2=80=9D= =2E The = >>> domain is the identity of the client. The response is an immediate = >>> notification to the with whatever LI was in the request and an ID. = >>> The response by the client (which is the notification web server) = >>> is a piece of json containing the ID. We can say that the LI in = >>> this initialize command could be something simple like the Country = >>> Code that wouldn=E2=80=99t get a planned change. >>> >>> Thereafter, the LoST server (notification client) periodically = >>> repeats this keepalive notification every day or week with the = >>> initialize LI. The client has to respond with the ID. >>> >>> The regular notification request is a command of =E2=80=9Cnotify=E2=80= =9D. The = >>> server ignores a request for notification from an uninitialized = >>> client. >>> The notification can be deleted with a command of =E2=80=9Cdelete=E2=80= =9D. If = >>> you delete the initialize LI, then the server won=E2=80=99t send any = more = >>> notifications to that client and deletes all URIs it was saving for = >>> that client. The client would have to re-initialize to reset. >>> >>> Brian >>> >>>> On Aug 27, 2021, at 5:41 PM, Randall Gellens = >>>> wrote: >>>> >>>> I think we're moving to a model where: >>>> - In a query, a client can request to be notified when the location >>>> should be revalidated; >>>> - In the response, the server provides an ID which the client >>>> associates with the location it just validated; >>>> - The server sends a notification to the URI, containing the ID; >>>> - The client revalidates each location with which that ID is = >>>> associated. >>>> >>>> Question 1: Does the server delete/inactivate the URI once it has = >>>> sent the notification? >>>> >>>> Question 2: Presumably, when the client revalidates the = >>>> location(s), it will again request notification. Does the server = >>>> return the same ID as before, or a different ID? A different ID = >>>> could perhaps be useful in edge cases where the server didn't send = >>>> or the client didn't get the notification, but any utility seems = >>>> small. If it's the same ID, then the answer to question 1 can be = >>>> that the URI remains active until the client asks to no longer be = >>>> notified (by sending an empty URI?). >>>> >>>> --Randall >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> ---------------------------------------------------------------------= - >>> -------- External Email: Please use caution when opening links and >>> attachments / Courriel externe: Soyez prudent avec les liens et >>> documents joints >> >> ----------------------------------------------------------------------= -------- >> External Email: Please use caution when opening links and attachments = >> / Courriel externe: Soyez prudent avec les liens et documents joints --=_MailMate_122F53A7-DD6A-4878-BB89-D1C436425E4C_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">If a malicious client registers a URI that is designed to = attack a third site, the test transaction causes the LoST server to conne= ct to it and POST a command. Without a test transaction, the LoST server= stores the URI and at a future time connects to it and sends a command. = Either way, a LoST client can register potentially one URI per queried l= ocation, and a LoST server will connect to that URI and POST a message. = A queried location could be tied to many other locations, so there could = be many locations for which a change would trigger the LoST server to use= the URI, but is that worse?

--Randall

On 31 Aug 2021, at 10:27, Brian Rosen wrote:

If the work group wants to have the LoST s= erver keep the URI until expressly deleted, that=E2=80=99s okay with me.<= div class=3D"">
Authenticating the cl= ient to the server doesn=E2=80=99t mean the URI is authenticated.  W= e can=E2=80=99t restrict the URI to be the same entity as the client runn= ing the LoST transaction.  And the clients are wide ranging.  C= ould be an enterprise running its own LIS for example.  We can=E2=80= =99t assume the North American PKI is workable everywhere, and even that = doesn=E2=80=99t extend to an enterprise LIS.  ISTM we have to run a = test transaction with the notification service to make sure it=E2=80=99s = what we think it is.

Brian


On Aug 31, 2021, at 9:01 AM, Caron, Guy= <g.caron@bell.ca>= ; wrote:

Inline.

Guy

-----Message d'origine-----
De : Brian Rosen <br@brianrosen.net> 
Envoy=C3=A9 : 31 ao=C3=BBt 2021 08:11
=C3=80 := Caron, Guy <g.caron@bell.ca>
Cc : Randall Gellens <rg+ietf= @randy.pensive.org>; ECRIT <ecrit@ietf.org>
Objet : [EXT]Re: [Ecrit] pla= nned-changes: two questions

Y= ou delete the URI when you delete the record in the LIS.
[GC] That's fine but = that was not the question Randall posed. He asked whether the URI is dele= ted after a notification. I agree that if the Client does not host the lo= cation anymore that the URI associated with that location in the Server s= hould be deleted. This could be achieved with an empty <plannedChange&= gt;.

I don=E2=80=99t think th= is is covered in 5222.  The mechanism causes the LoST server to send= notifications to the client, but the client is allowed to put any URI in= the record, and it can add it to as many records as it wants.
[GC] I though= t we agreed on using one generic URI per Client. Clients should be authen= ticated by the Servers.
 An evil implementation could record URIs agains= t multiple targets that were unaware that the evil implementation did it,= until they got a large number of PUSH transactions they didn=E2=80=99t e= xpect or understand as a result of a large planned change.
[GC] Only authent= icated Clients should be allowed to provide URIs to be stored by the Serv= ers.

The proposed mechanism q= ualifies the client URI before its used in a planned change.

Brian

On Aug 31, 2021, at 7:37 AM, Caron, Guy <g.caron@bell.ca> wrote:

Well, this is not going in the direction I thou= ght.

What is the purpose of deleting the URI= s at the Server post-validation?

Regarding o= pening a new DoS, I guess I'm not following. Wouldn't this case be covere= d by the security considerations in RFC 5222?

What you're proposing puts back significant load on the Servers (a key = consideration for creating planned-changes in the first place) and compli= cates the mechanism.

Guy


-----Message d'origine-----
De : E= crit <ecrit-bounc= es@ietf.org> De la part de Brian Rosen Envoy=C3=A9 : 
30 ao=C3=BBt 2021 11:= 22 =C3=80 : Randall Gellens <rg+ietf@randy.pensive.org> Cc 
: ECRIT <ecrit@ietf.org> Objet : [EXT]Re: [Ecri= t] planned-changes: two 
questions

Answer 1: yes. &nb= sp;Since there is going to be a revalidation, just deleting the setting s= eems right to me.
Answer 2: Up to server.  If I were i= mplementing, I would hash the real ID with the URI and some kind of predi= ctable nonce.  

We probably have to say= more about how the server identifies the client, so that replacement of = the URI works.  Could we say we use the domain of the URI (the entir= e domain with all the dots) to identify the client, and anything can occu= r after it (meaning a slash and whatever)?  If we do that, then how = would delete the notification?  Force there to be something other th= an the domain (ugly).  Explicit delete request?

Hmmm, we=E2=80=99ve opened a DoS attack: a rogue client stores a= bunch of URIs for servers it wants to victimize.  In North America = we have a real simple solution for that, because we have a PKI, so we kno= w, for sure, who the client is, and could restrict who we allow to store = URIs, but that wouldn=E2=80=99t be true in general.  Also, it would = be nice for the client to have confidence the mechanism worked before it = needed it.

So
Let=E2=80=99s ad= d a =E2=80=9Ccommand=E2=80=9D to plannedChange in the findService request= =2E  
And, have the client have a response to the noti= fication which is the <= br class=3D"">ID (json with the 200)


The client starts by sending a command of =E2=80=9Cinitialize=E2=80= =9D.  The domain is the identity of the client.  The response i= s an immediate notification to the with whatever LI was in the request an= d an ID.  The  response by the client (which is the notificatio= n web server) is a piece of json containing the ID.  We can say that= the LI in this initialize command could be something simple like the Cou= ntry Code that wouldn=E2=80=99t get a planned change.

Thereafter, the LoST server (notification client) periodically = repeats this keepalive notification every day or week with the initialize= LI.  The client has to respond with the ID.

The regular notification request is a command of =E2=80=9Cnotify=E2= =80=9D.  The server ignores a request for notification from an unini= tialized client.
The notification can be deleted with a com= mand of =E2=80=9Cdelete=E2=80=9D.  If you delete the initialize LI, = then the server won=E2=80=99t send any more notifications to that client = and deletes all URIs it was saving for that client.  The client woul= d have to re-initialize to reset.

Brian

On Aug 27, = 2021, at 5:41 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

I think we're moving to a model where:
- = In a query, a client can request to be notified when the location 
should be reval= idated;
- In the response, the server provides an ID which = the client 
associates with the location it just validated;
- The se= rver sends a notification to the URI, containing the ID;
- = The client revalidates each location with which that ID is associated.
Question 1: Does the server delete/inactivate = the URI once it has sent the notification?

Q= uestion 2: Presumably, when the client revalidates the location(s), it wi= ll again request notification.  Does the server return the same ID a= s before, or a different ID?  A different ID could perhaps be useful= in edge cases where the server didn't send or the client didn't get the = notification, but any utility seems small.  If it's the same ID, the= n the answer to question 1 can be that the URI remains active until the c= lient asks to no longer be notified (by sending an empty URI?).

--Randall

________________= _______________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/m= ailman/listinfo/ecrit
-------------------------------------= ---------------------------------
-------- External Email: = Please use caution when opening links and 
attachments / Courriel externe: Soyez p= rudent avec les liens et 
documents joints

---------------------= ---------------------------------------------------------
External Email: Pl= ease use caution when opening links and attachments / Courriel externe: S= oyez prudent avec les liens et documents joints
=

--=_MailMate_122F53A7-DD6A-4878-BB89-D1C436425E4C_=-- From nobody Tue Aug 31 10:53:54 2021 Return-Path: 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 581DD3A0141 for ; Tue, 31 Aug 2021 10:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, 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.20150623.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 EJuDpyN4nzkd for ; Tue, 31 Aug 2021 10:53:40 -0700 (PDT) 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 648DD3A0121 for ; Tue, 31 Aug 2021 10:53:40 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id a15so26053513iot.2 for ; Tue, 31 Aug 2021 10:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=r7DhXvH4LtfXaeMP5ngjj6O2WPmsfWiFGLvyBENBeXA=; b=k/cYeiLzbaVX7h0AhHbDXqnQN4gDibk+DrU3DI0OLyROQAED3zYzaSCNGhRrO/hZa2 M5OrGi2YNa4UX2K3aWQPhHqtq4pvSbGZ7H7+yoI9XKf63xZLVpB7AMP7mIzWh9e+fKYs /L62rAbBjrsDccOAoOmLKBnFTADgmInkydt4qXe9tyUr7LVEDlxe8gHH8m2Bs/rnX5EL HS4V3Cv6S7ZU9c0wtp8GntepgILatYECxowgq0HN+Q1ReADnBJR8V866UGx4IEwtxIqK XEnWKSLPjv4Y37xDLc+s/NVMObTvqhDURzxwUETDrQxyVeWe/XBn51sbeIvGHk9HhTP+ rXQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=r7DhXvH4LtfXaeMP5ngjj6O2WPmsfWiFGLvyBENBeXA=; b=adYuVcyh2a9gtd3R67ITUIIUePG3x5U02GdV07JaW0OK7bXzmQOwLcj2v+1Ckcmjfy MCsUfXQNUk6lmWp9LkmQuV/y8oj0zdnDP7vfb3o4IRTNf0R7g0E4zaZsyw/dDlv76AdG 9F1c8Le9myVKWgorfMkx/CAQXOJ9C/zt0L7Hk0/Jd2eEr/JDYXUgfUMCVNGtTpEw+ODn YrhFSXcTK1i1deUovb6SzsCO3Kuj6ZpAxFcTFLvpc+Ihun26qzjnReDzGIave0Zqe149 C44X8jT2qfOXYwKNeO5Yw1tRvIk/K0jTElMI4ifyaLmGNRJ1VYyRlODkOAO7bNxkfcIB hbxQ== X-Gm-Message-State: AOAM530HZXwaRbXScB+lK+BRAxlAktQ/20gApeiLjftrludiBrf95lRb cAxUP4e6iYQsW3K8Xt5syY/1lw== X-Google-Smtp-Source: ABdhPJxuU8gqjEISQ9usaRG1iAVrVfKFLJ2PCaQPs77dJKc/x1Wbx3qVkxkvM1nAsHGMHy9b8euu/Q== X-Received: by 2002:a6b:5a04:: with SMTP id o4mr23337915iob.44.1630432418722; Tue, 31 Aug 2021 10:53:38 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id x21sm7387773ioh.55.2021.08.31.10.53.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Aug 2021 10:53:38 -0700 (PDT) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A713010B-F9B6-413F-86BB-623B4F3C9637" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 31 Aug 2021 13:53:37 -0400 In-Reply-To: Cc: "Caron, Guy" , ECRIT To: Randall Gellens References: <5577e2e6daa4405bbe12ef61675e1f55@bell.ca> <3AD58DEC-1DC9-4BC0-B55C-4E782E4AAA74@brianrosen.net> X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Ecrit] planned-changes: two questions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 17:53:51 -0000 --Apple-Mail=_A713010B-F9B6-413F-86BB-623B4F3C9637 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Of course an attacker would conceal itself and register multiple URIs = under different identities. But the bigger problem is that if a large = planned change occurred, the victim could receive a large number of = notifications it didn=E2=80=99t expect. With a test transition, we know that the client expects to see = notifications, we only need one per URI (we could specify one per domain = =E2=80=94 after the scheme and before the first slash). If we don=E2=80=99= t get the ID, we know not to allow that URI to be provisioned. So = it=E2=80=99s one test transaction vs a large number of planned change = transactions. Brian > On Aug 31, 2021, at 1:35 PM, Randall Gellens = wrote: >=20 > If a malicious client registers a URI that is designed to attack a = third site, the test transaction causes the LoST server to connect to it = and POST a command. Without a test transaction, the LoST server stores = the URI and at a future time connects to it and sends a command. Either = way, a LoST client can register potentially one URI per queried = location, and a LoST server will connect to that URI and POST a message. = A queried location could be tied to many other locations, so there could = be many locations for which a change would trigger the LoST server to = use the URI, but is that worse? >=20 > --Randall >=20 > On 31 Aug 2021, at 10:27, Brian Rosen wrote: >=20 > If the work group wants to have the LoST server keep the URI until = expressly deleted, that=E2=80=99s okay with me. >=20 > Authenticating the client to the server doesn=E2=80=99t mean the URI = is authenticated. We can=E2=80=99t restrict the URI to be the same = entity as the client running the LoST transaction. And the clients are = wide ranging. Could be an enterprise running its own LIS for example. = We can=E2=80=99t assume the North American PKI is workable everywhere, = and even that doesn=E2=80=99t extend to an enterprise LIS. ISTM we have = to run a test transaction with the notification service to make sure = it=E2=80=99s what we think it is. >=20 > Brian >=20 >=20 >=20 >> On Aug 31, 2021, at 9:01 AM, Caron, Guy > wrote: >>=20 >> Inline. >>=20 >> Guy >>=20 >> -----Message d'origine----- >> De : Brian Rosen >=20 >> Envoy=C3=A9 : 31 ao=C3=BBt 2021 08:11 >> =C3=80 : Caron, Guy > >> Cc : Randall Gellens >; ECRIT > >> Objet : [EXT]Re: [Ecrit] planned-changes: two questions >>=20 >> You delete the URI when you delete the record in the LIS. >> [GC] That's fine but that was not the question Randall posed. He = asked whether the URI is deleted after a notification. I agree that if = the Client does not host the location anymore that the URI associated = with that location in the Server should be deleted. This could be = achieved with an empty . >>=20 >> I don=E2=80=99t think this is covered in 5222. The mechanism causes = the LoST server to send notifications to the client, but the client is = allowed to put any URI in the record, and it can add it to as many = records as it wants. >> [GC] I thought we agreed on using one generic URI per Client. Clients = should be authenticated by the Servers. >> An evil implementation could record URIs against multiple targets = that were unaware that the evil implementation did it, until they got a = large number of PUSH transactions they didn=E2=80=99t expect or = understand as a result of a large planned change. >> [GC] Only authenticated Clients should be allowed to provide URIs to = be stored by the Servers. >>=20 >> The proposed mechanism qualifies the client URI before its used in a = planned change. >>=20 >> Brian >>=20 >>> On Aug 31, 2021, at 7:37 AM, Caron, Guy > wrote: >>>=20 >>> Well, this is not going in the direction I thought. >>>=20 >>> What is the purpose of deleting the URIs at the Server = post-validation? >>>=20 >>> Regarding opening a new DoS, I guess I'm not following. Wouldn't = this case be covered by the security considerations in RFC 5222? >>>=20 >>> What you're proposing puts back significant load on the Servers (a = key consideration for creating planned-changes in the first place) and = complicates the mechanism. >>>=20 >>> Guy >>>=20 >>>=20 >>> -----Message d'origine----- >>> De : Ecrit > = De la part de Brian Rosen Envoy=C3=A9 :=20 >>> 30 ao=C3=BBt 2021 11:22 =C3=80 : Randall Gellens = > Cc=20 >>> : ECRIT > Objet : [EXT]Re: = [Ecrit] planned-changes: two=20 >>> questions >>>=20 >>> Answer 1: yes. Since there is going to be a revalidation, just = deleting the setting seems right to me. >>> Answer 2: Up to server. If I were implementing, I would hash the = real ID with the URI and some kind of predictable nonce. =20 >>>=20 >>> We probably have to say more about how the server identifies the = client, so that replacement of the URI works. Could we say we use the = domain of the URI (the entire domain with all the dots) to identify the = client, and anything can occur after it (meaning a slash and whatever)? = If we do that, then how would delete the notification? Force there to = be something other than the domain (ugly). Explicit delete request? >>>=20 >>> Hmmm, we=E2=80=99ve opened a DoS attack: a rogue client stores a = bunch of URIs for servers it wants to victimize. In North America we = have a real simple solution for that, because we have a PKI, so we know, = for sure, who the client is, and could restrict who we allow to store = URIs, but that wouldn=E2=80=99t be true in general. Also, it would be = nice for the client to have confidence the mechanism worked before it = needed it. >>>=20 >>> So >>> Let=E2=80=99s add a =E2=80=9Ccommand=E2=80=9D to plannedChange in = the findService request. =20 >>> And, have the client have a response to the notification which is = the=20 >>> ID (json with the 200) >>>=20 >>>=20 >>> The client starts by sending a command of =E2=80=9Cinitialize=E2=80=9D= . The domain is the identity of the client. The response is an = immediate notification to the with whatever LI was in the request and an = ID. The response by the client (which is the notification web server) = is a piece of json containing the ID. We can say that the LI in this = initialize command could be something simple like the Country Code that = wouldn=E2=80=99t get a planned change. >>>=20 >>> Thereafter, the LoST server (notification client) periodically = repeats this keepalive notification every day or week with the = initialize LI. The client has to respond with the ID. >>>=20 >>> The regular notification request is a command of =E2=80=9Cnotify=E2=80= =9D. The server ignores a request for notification from an = uninitialized client. >>> The notification can be deleted with a command of =E2=80=9Cdelete=E2=80= =9D. If you delete the initialize LI, then the server won=E2=80=99t = send any more notifications to that client and deletes all URIs it was = saving for that client. The client would have to re-initialize to = reset. >>>=20 >>> Brian >>>=20 >>>> On Aug 27, 2021, at 5:41 PM, Randall Gellens = > wrote: >>>>=20 >>>> I think we're moving to a model where: >>>> - In a query, a client can request to be notified when the location=20= >>>> should be revalidated; >>>> - In the response, the server provides an ID which the client=20 >>>> associates with the location it just validated; >>>> - The server sends a notification to the URI, containing the ID; >>>> - The client revalidates each location with which that ID is = associated. >>>>=20 >>>> Question 1: Does the server delete/inactivate the URI once it has = sent the notification? >>>>=20 >>>> Question 2: Presumably, when the client revalidates the = location(s), it will again request notification. Does the server return = the same ID as before, or a different ID? A different ID could perhaps = be useful in edge cases where the server didn't send or the client = didn't get the notification, but any utility seems small. If it's the = same ID, then the answer to question 1 can be that the URI remains = active until the client asks to no longer be notified (by sending an = empty URI?). >>>>=20 >>>> --Randall >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> = ---------------------------------------------------------------------- >>> -------- External Email: Please use caution when opening links and=20= >>> attachments / Courriel externe: Soyez prudent avec les liens et=20 >>> documents joints >>=20 >> = --------------------------------------------------------------------------= ---- >> External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints >=20 --Apple-Mail=_A713010B-F9B6-413F-86BB-623B4F3C9637 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Of = course an attacker would conceal itself and register multiple URIs under = different identities.  But the bigger  problem is that if a = large planned change occurred, the victim could receive a large number = of notifications it didn=E2=80=99t expect.

With a test transition, we know that = the client expects to see notifications, we only need one per URI (we = could specify one per domain =E2=80=94 after the scheme and before the = first slash).  If we don=E2=80=99t get the ID, we know not to allow = that URI to be provisioned.  So it=E2=80=99s one test transaction = vs a large number of planned change transactions.
Brian


On Aug 31, 2021, at 1:35 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

If a = malicious client registers a URI that is designed to attack a third = site, the test transaction causes the LoST server to connect to it and = POST a command. Without a test transaction, the LoST server stores the = URI and at a future time connects to it and sends a command. Either = way, a LoST client can register potentially one URI per queried = location, and a LoST server will connect to that URI and POST a message. = A queried location could be tied to many other locations, so there = could be many locations for which a change would trigger the LoST server = to use the URI, but is that worse?

--Randall

On 31 Aug 2021, at = 10:27, Brian Rosen wrote:

If the work group wants to have the LoST = server keep the URI until expressly deleted, that=E2=80=99s okay with = me.

Authenticating = the client to the server doesn=E2=80=99t mean the URI is authenticated. =  We can=E2=80=99t restrict the URI to be the same entity as the = client running the LoST transaction.  And the clients are wide = ranging.  Could be an enterprise running its own LIS for example. =  We can=E2=80=99t assume the North American PKI is workable = everywhere, and even that doesn=E2=80=99t extend to an enterprise LIS. =  ISTM we have to run a test transaction with the notification = service to make sure it=E2=80=99s what we think it is.

Brian



On Aug 31, 2021, at 9:01 AM, Caron, Guy = <g.caron@bell.ca> = wrote:

Inline.

Guy

-----Message d'origine-----
De : Brian Rosen <br@brianrosen.net> 
Envoy=C3=A9 : 31 ao=C3=BBt = 2021 08:11
=C3=80 : = Caron, Guy <g.caron@bell.ca>
Cc : Randall Gellens <rg+ietf@randy.pensive.org>; ECRIT <ecrit@ietf.org>
Objet : [EXT]Re: [Ecrit] planned-changes: two = questions

You delete = the URI when you delete the record in the LIS.
[GC] That's fine but that was = not the question Randall posed. He asked whether the URI is deleted = after a notification. I agree that if the Client does not host the = location anymore that the URI associated with that location in the = Server should be deleted. This could be achieved with an empty = <plannedChange>.

I don=E2=80=99t think this is covered in 5222.  The = mechanism causes the LoST server to send notifications to the client, = but the client is allowed to put any URI in the record, and it can add = it to as many records as it wants.
[GC] I thought we agreed on using one generic URI per Client. = Clients should be authenticated by the Servers.
 An evil implementation = could record URIs against multiple targets that were unaware that the = evil implementation did it, until they got a large number of PUSH = transactions they didn=E2=80=99t expect or understand as a result of a = large planned change.
[GC] Only authenticated Clients should be allowed to provide = URIs to be stored by the Servers.

The proposed mechanism qualifies the client URI before its = used in a planned change.

Brian

On Aug 31, 2021, at 7:37 AM, Caron, = Guy <g.caron@bell.ca> wrote:

Well, this is not going in the direction I thought.

What is the purpose of deleting the URIs at = the Server post-validation?

Regarding = opening a new DoS, I guess I'm not following. Wouldn't this case be = covered by the security considerations in RFC 5222?

What you're proposing puts back significant load on the = Servers (a key consideration for creating planned-changes in the first = place) and complicates the mechanism.

Guy


-----Message d'origine-----
De : Ecrit <ecrit-bounces@ietf.org> De la part de Brian Rosen = Envoy=C3=A9 : 
30 ao=C3=BBt 2021 11:22 =C3=80 : Randall Gellens <rg+ietf@randy.pensive.org> Cc 
: ECRIT = <ecrit@ietf.org> = Objet : [EXT]Re: [Ecrit] planned-changes: two 
questions

Answer 1: yes.  Since there is going to = be a revalidation, just deleting the setting seems right to me.
Answer 2: Up to server.  If I were implementing, I would = hash the real ID with the URI and some kind of predictable nonce. =  

We probably have to say more about = how the server identifies the client, so that replacement of the URI = works.  Could we say we use the domain of the URI (the entire = domain with all the dots) to identify the client, and anything can occur = after it (meaning a slash and whatever)?  If we do that, then how = would delete the notification?  Force there to be something other = than the domain (ugly).  Explicit delete request?

Hmmm, we=E2=80=99ve opened a DoS attack: a rogue client = stores a bunch of URIs for servers it wants to victimize.  In North = America we have a real simple solution for that, because we have a PKI, = so we know, for sure, who the client is, and could restrict who we allow = to store URIs, but that wouldn=E2=80=99t be true in general.  Also, = it would be nice for the client to have confidence the mechanism worked = before it needed it.

So
Let=E2=80= =99s add a =E2=80=9Ccommand=E2=80=9D to plannedChange in the findService = request.  
And, have the client have a response to = the notification which is the 
ID (json = with the 200)


The client = starts by sending a command of =E2=80=9Cinitialize=E2=80=9D.  The = domain is the identity of the client.  The response is an immediate = notification to the with whatever LI was in the request and an ID. =  The  response by the client (which is the notification web = server) is a piece of json containing the ID.  We can say that the = LI in this initialize command could be something simple like the Country = Code that wouldn=E2=80=99t get a planned change.

Thereafter, the LoST server (notification client) = periodically repeats this keepalive notification every day or week with = the initialize LI.  The client has to respond with the ID.

The regular notification request is a command = of =E2=80=9Cnotify=E2=80=9D.  The server ignores a request for = notification from an uninitialized client.
The = notification can be deleted with a command of =E2=80=9Cdelete=E2=80=9D. =  If you delete the initialize LI, then the server won=E2=80=99t = send any more notifications to that client and deletes all URIs it was = saving for that client.  The client would have to re-initialize to = reset.

Brian

On Aug 27, 2021, at 5:41 = PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

I think we're moving to a model where:
- In a = query, a client can request to be notified when the location 
should be = revalidated;
- In the response, the server provides an ID = which the client 
associates with the location it just validated;
-= The server sends a notification to the URI, containing the ID;
- The client revalidates each location with which that ID is = associated.

Question 1: Does the server = delete/inactivate the URI once it has sent the notification?

Question 2: Presumably, when the client = revalidates the location(s), it will again request notification. =  Does the server return the same ID as before, or a different ID? =  A different ID could perhaps be useful in edge cases where the = server didn't send or the client didn't get the notification, but any = utility seems small.  If it's the same ID, then the answer to = question 1 can be that the URI remains active until the client asks to = no longer be notified (by sending an empty URI?).

--Randall

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
---------------------------------------------------------------= -------
-------- External Email: Please use caution when = opening links and 
attachments / Courriel externe: Soyez prudent avec les liens = et 
documents joints

---------------------------------------------------------------= ---------------
External Email: Please use caution when opening links and = attachments / Courriel externe: Soyez prudent avec les liens et = documents joints


= --Apple-Mail=_A713010B-F9B6-413F-86BB-623B4F3C9637-- From nobody Tue Aug 31 11:56:22 2021 Return-Path: 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 49FA13A0D3D for ; Tue, 31 Aug 2021 11:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, 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 o5Q_tWeAmITx for ; Tue, 31 Aug 2021 11:56:14 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB763A0D35 for ; Tue, 31 Aug 2021 11:56:13 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 31 Aug 2021 11:56:12 -0700 From: "Randall Gellens" To: "Brian Rosen" Cc: "Caron, Guy" , ECRIT Date: Tue, 31 Aug 2021 11:56:12 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: References: <5577e2e6daa4405bbe12ef61675e1f55@bell.ca> <3AD58DEC-1DC9-4BC0-B55C-4E782E4AAA74@brianrosen.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_09FA322B-445C-4EC6-82EF-50358392A826_=" Embedded-HTML: [{"HTML":[957, 30691], "plain":[626, 9034], "uuid":"2F42742C-4F55-4E29-8BB7-008296866A51"}] Archived-At: Subject: Re: [Ecrit] planned-changes: two questions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 18:56:20 -0000 --=_MailMate_09FA322B-445C-4EC6-82EF-50358392A826_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable i understand that the concern is allowing a client to leverage the LoST = server to attack a large number of targets, I'm just not clear = mechanically how such leverage potentially works. Each validation query = can store a URI, and that URI may get associated with a large number of = locations. Maybe there's a street name change or an annexation. So = maybe thousands or tens or hundreds of thousands of locations are = potentially invalidated. They all have the same URI associated with = them, so the LoST server connects to the URI once and POSTs one = notification, no? --Randall On 31 Aug 2021, at 10:53, Brian Rosen wrote: > Of course an attacker would conceal itself and register multiple URIs = > under different identities. But the bigger problem is that if a = > large planned change occurred, the victim could receive a large number = > of notifications it didn=E2=80=99t expect. > > With a test transition, we know that the client expects to see = > notifications, we only need one per URI (we could specify one per = > domain =E2=80=94 after the scheme and before the first slash). If we = > don=E2=80=99t get the ID, we know not to allow that URI to be provision= ed. = > So it=E2=80=99s one test transaction vs a large number of planned chang= e = > transactions. > > Brian > > >> On Aug 31, 2021, at 1:35 PM, Randall Gellens = >> wrote: >> >> If a malicious client registers a URI that is designed to attack a = >> third site, the test transaction causes the LoST server to connect to = >> it and POST a command. Without a test transaction, the LoST server = >> stores the URI and at a future time connects to it and sends a = >> command. Either way, a LoST client can register potentially one URI = >> per queried location, and a LoST server will connect to that URI and = >> POST a message. A queried location could be tied to many other = >> locations, so there could be many locations for which a change would = >> trigger the LoST server to use the URI, but is that worse? >> >> --Randall >> >> On 31 Aug 2021, at 10:27, Brian Rosen wrote: >> >> If the work group wants to have the LoST server keep the URI until = >> expressly deleted, that=E2=80=99s okay with me. >> >> Authenticating the client to the server doesn=E2=80=99t mean the URI i= s = >> authenticated. We can=E2=80=99t restrict the URI to be the same entit= y as = >> the client running the LoST transaction. And the clients are wide = >> ranging. Could be an enterprise running its own LIS for example. We = >> can=E2=80=99t assume the North American PKI is workable everywhere, an= d = >> even that doesn=E2=80=99t extend to an enterprise LIS. ISTM we have t= o run = >> a test transaction with the notification service to make sure it=E2=80= =99s = >> what we think it is. >> >> Brian >> >> >> >>> On Aug 31, 2021, at 9:01 AM, Caron, Guy >> > wrote: >>> >>> Inline. >>> >>> Guy >>> >>> -----Message d'origine----- >>> De : Brian Rosen > >>> Envoy=C3=A9 : 31 ao=C3=BBt 2021 08:11 >>> =C3=80 : Caron, Guy > >>> Cc : Randall Gellens >> >; ECRIT >> > >>> Objet : [EXT]Re: [Ecrit] planned-changes: two questions >>> >>> You delete the URI when you delete the record in the LIS. >>> [GC] That's fine but that was not the question Randall posed. He = >>> asked whether the URI is deleted after a notification. I agree that = >>> if the Client does not host the location anymore that the URI = >>> associated with that location in the Server should be deleted. This = >>> could be achieved with an empty . >>> >>> I don=E2=80=99t think this is covered in 5222. The mechanism causes = the = >>> LoST server to send notifications to the client, but the client is = >>> allowed to put any URI in the record, and it can add it to as many = >>> records as it wants. >>> [GC] I thought we agreed on using one generic URI per Client. = >>> Clients should be authenticated by the Servers. >>> An evil implementation could record URIs against multiple targets = >>> that were unaware that the evil implementation did it, until they = >>> got a large number of PUSH transactions they didn=E2=80=99t expect or= = >>> understand as a result of a large planned change. >>> [GC] Only authenticated Clients should be allowed to provide URIs to = >>> be stored by the Servers. >>> >>> The proposed mechanism qualifies the client URI before its used in a = >>> planned change. >>> >>> Brian >>> >>>> On Aug 31, 2021, at 7:37 AM, Caron, Guy >>> > wrote: >>>> >>>> Well, this is not going in the direction I thought. >>>> >>>> What is the purpose of deleting the URIs at the Server = >>>> post-validation? >>>> >>>> Regarding opening a new DoS, I guess I'm not following. Wouldn't = >>>> this case be covered by the security considerations in RFC 5222? >>>> >>>> What you're proposing puts back significant load on the Servers (a = >>>> key consideration for creating planned-changes in the first place) = >>>> and complicates the mechanism. >>>> >>>> Guy >>>> >>>> >>>> -----Message d'origine----- >>>> De : Ecrit > = >>>> De la part de Brian Rosen Envoy=C3=A9 : >>>> 30 ao=C3=BBt 2021 11:22 =C3=80 : Randall Gellens >>> > Cc >>>> : ECRIT > Objet : [EXT]Re: = >>>> [Ecrit] planned-changes: two >>>> questions >>>> >>>> Answer 1: yes. Since there is going to be a revalidation, just = >>>> deleting the setting seems right to me. >>>> Answer 2: Up to server. If I were implementing, I would hash the = >>>> real ID with the URI and some kind of predictable nonce. >>>> >>>> We probably have to say more about how the server identifies the = >>>> client, so that replacement of the URI works. Could we say we use = >>>> the domain of the URI (the entire domain with all the dots) to = >>>> identify the client, and anything can occur after it (meaning a = >>>> slash and whatever)? If we do that, then how would delete the = >>>> notification? Force there to be something other than the domain = >>>> (ugly). Explicit delete request? >>>> >>>> Hmmm, we=E2=80=99ve opened a DoS attack: a rogue client stores a bun= ch of = >>>> URIs for servers it wants to victimize. In North America we have a = >>>> real simple solution for that, because we have a PKI, so we know, = >>>> for sure, who the client is, and could restrict who we allow to = >>>> store URIs, but that wouldn=E2=80=99t be true in general. Also, it = would = >>>> be nice for the client to have confidence the mechanism worked = >>>> before it needed it. >>>> >>>> So >>>> Let=E2=80=99s add a =E2=80=9Ccommand=E2=80=9D to plannedChange in th= e findService = >>>> request. >>>> And, have the client have a response to the notification which is = >>>> the >>>> ID (json with the 200) >>>> >>>> >>>> The client starts by sending a command of =E2=80=9Cinitialize=E2=80=9D= =2E The = >>>> domain is the identity of the client. The response is an immediate = >>>> notification to the with whatever LI was in the request and an ID. = >>>> The response by the client (which is the notification web server) = >>>> is a piece of json containing the ID. We can say that the LI in = >>>> this initialize command could be something simple like the Country = >>>> Code that wouldn=E2=80=99t get a planned change. >>>> >>>> Thereafter, the LoST server (notification client) periodically = >>>> repeats this keepalive notification every day or week with the = >>>> initialize LI. The client has to respond with the ID. >>>> >>>> The regular notification request is a command of =E2=80=9Cnotify=E2=80= =9D. The = >>>> server ignores a request for notification from an uninitialized = >>>> client. >>>> The notification can be deleted with a command of =E2=80=9Cdelete=E2= =80=9D. If = >>>> you delete the initialize LI, then the server won=E2=80=99t send any= more = >>>> notifications to that client and deletes all URIs it was saving for = >>>> that client. The client would have to re-initialize to reset. >>>> >>>> Brian >>>> >>>>> On Aug 27, 2021, at 5:41 PM, Randall Gellens = >>>>> > = >>>>> wrote: >>>>> >>>>> I think we're moving to a model where: >>>>> - In a query, a client can request to be notified when the = >>>>> location >>>>> should be revalidated; >>>>> - In the response, the server provides an ID which the client >>>>> associates with the location it just validated; >>>>> - The server sends a notification to the URI, containing the ID; >>>>> - The client revalidates each location with which that ID is = >>>>> associated. >>>>> >>>>> Question 1: Does the server delete/inactivate the URI once it has = >>>>> sent the notification? >>>>> >>>>> Question 2: Presumably, when the client revalidates the = >>>>> location(s), it will again request notification. Does the server = >>>>> return the same ID as before, or a different ID? A different ID = >>>>> could perhaps be useful in edge cases where the server didn't send = >>>>> or the client didn't get the notification, but any utility seems = >>>>> small. If it's the same ID, then the answer to question 1 can be = >>>>> that the URI remains active until the client asks to no longer be = >>>>> notified (by sending an empty URI?). >>>>> >>>>> --Randall >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> --------------------------------------------------------------------= -- >>>> -------- External Email: Please use caution when opening links and >>>> attachments / Courriel externe: Soyez prudent avec les liens et >>>> documents joints >>> >>> ---------------------------------------------------------------------= --------- >>> External Email: Please use caution when opening links and = >>> attachments / Courriel externe: Soyez prudent avec les liens et = >>> documents joints >> --=_MailMate_09FA322B-445C-4EC6-82EF-50358392A826_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">i understand that the concern is allowing a client to leve= rage the LoST server to attack a large number of targets, I'm just not cl= ear mechanically how such leverage potentially works. Each validation qu= ery can store a URI, and that URI may get associated with a large number = of locations. Maybe there's a street name change or an annexation. So m= aybe thousands or tens or hundreds of thousands of locations are potentia= lly invalidated. They all have the same URI associated with them, so the= LoST server connects to the URI once and POSTs one notification, no?

=

--Randall

On 31 Aug 2021, at 10:53, Brian Rosen wrote:

Of course an attacker would conceal itself= and register multiple URIs under different identities.  But the big= ger  problem is that if a large planned change occurred, the victim = could receive a large number of notifications it didn=E2=80=99t expect.
With a test transition= , we know that the client expects to see notifications, we only need one = per URI (we could specify one per domain =E2=80=94 after the scheme and b= efore the first slash).  If we don=E2=80=99t get the ID, we know not= to allow that URI to be provisioned.  So it=E2=80=99s one test tran= saction vs a large number of planned change transactions.

Brian

On Aug 31, 2021, at 1:35 PM, Randall Gellens <rg+ietf@randy.pensive.org= > wrote:

=

If a malicious client reg= isters a URI that is designed to attack a third site, the test transactio= n causes the LoST server to connect to it and POST a command. Without a = test transaction, the LoST server stores the URI and at a future time con= nects to it and sends a command. Either way, a LoST client can register = potentially one URI per queried location, and a LoST server will connect = to that URI and POST a message. A queried location could be tied to many= other locations, so there could be many locations for which a change wou= ld trigger the LoST server to use the URI, but is that worse?

--Randall

On 31 Aug 2021,= at 10:27, Brian Rosen wrote:

If the work group wa= nts to have the LoST server keep the URI until expressly deleted, that=E2= =80=99s okay with me.

Authenticating the client to the server doesn=E2=80=99t mean the URI is = authenticated.  We can=E2=80=99t restrict the URI to be the same ent= ity as the client running the LoST transaction.  And the clients are= wide ranging.  Could be an enterprise running its own LIS for examp= le.  We can=E2=80=99t assume the North American PKI is workable ever= ywhere, and even that doesn=E2=80=99t extend to an enterprise LIS.  = ISTM we have to run a test transaction with the notification service to m= ake sure it=E2=80=99s what we think it is.

Brian


<= br class=3D"">
On Aug= 31, 2021, at 9:01 AM, Caron, Guy <g.caron@bell.ca> wrote:

Inline.
Guy
-----Message d'origine-----De : Br= ian Rosen <br@brianrosen.net> 
Envoy=C3=A9 = : 31 ao=C3=BBt 2021 08:11
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : Randall Gellens <rg+ietf@randy.pensive.org>; ECRIT <ecrit@ietf.org>
Objet : [EXT]Re: [Ecrit] planned-changes: two questions
You delete the URI when you delete the= record in the LIS.
= [GC] That's fine but that was not the question Randall p= osed. He asked whether the URI is deleted after a notification. I agree t= hat if the Client does not host the location anymore that the URI associa= ted with that location in the Server should be deleted. This could be ach= ieved with an empty <plannedChange>.

I don=E2=80=99t think this is covered in 5222.  The me= chanism causes the LoST server to send notifications to the client, but t= he client is allowed to put any URI in the record, and it can add it to a= s many records as it wants.
[GC] I thought we agreed on using one generic UR= I per Client. Clients should be authenticated by the Servers.
 An evil = implementation could record URIs against multiple targets that were unawa= re that the evil implementation did it, until they got a large number of = PUSH transactions they didn=E2=80=99t expect or understand as a result of= a large planned change.
[GC] Only authenticated Clients should be allowed to = provide URIs to be stored by the Servers.

The proposed mechanism qualifies the client URI before its u= sed in a planned change.

Brian<= /span>

On Aug 31, 2021,= at 7:37 AM, Caron, Guy <g.caron@bell.ca> wrote:

Well, this i= s not going in the direction I thought.

What= is the purpose of deleting the URIs at the Server post-validation?

Regarding opening a new DoS, I guess I'm not foll= owing. Wouldn't this case be covered by the security considerations in RF= C 5222?

What you're proposing puts back sign= ificant load on the Servers (a key consideration for creating planned-cha= nges in the first place) and complicates the mechanism.
Guy


-----Message = d'origine-----
De : Ecrit <ecrit-bounces@ietf.org> De la part de Bria= n Rosen Envoy=C3=A9 : <= br class=3D"">30 ao=C3=BBt 2021 11:22 =C3=80 : Randall Gellens <rg+ietf@randy.pensive.o= rg> Cc 
: ECRIT <ecrit@ietf= =2Eorg> Objet : [EXT]Re: [Ecrit] planned-changes: two 
questions

Answer 1: yes.  Since there is going to be a reval= idation, just deleting the setting seems right to me.
Answe= r 2: Up to server.  If I were implementing, I would hash the real ID= with the URI and some kind of predictable nonce.  
We probably have to say more about how the server identifies= the client, so that replacement of the URI works.  Could we say we = use the domain of the URI (the entire domain with all the dots) to identi= fy the client, and anything can occur after it (meaning a slash and whate= ver)?  If we do that, then how would delete the notification?  = Force there to be something other than the domain (ugly).  Explicit = delete request?

Hmmm, we=E2=80=99ve opened a= DoS attack: a rogue client stores a bunch of URIs for servers it wants t= o victimize.  In North America we have a real simple solution for th= at, because we have a PKI, so we know, for sure, who the client is, and c= ould restrict who we allow to store URIs, but that wouldn=E2=80=99t be tr= ue in general.  Also, it would be nice for the client to have confid= ence the mechanism worked before it needed it.

So
Let=E2=80=99s add a =E2=80=9Ccommand=E2=80=9D to plan= nedChange in the findService request.  
And, have the = client have a response to the notification which is the 
ID (json with the 200)

The client starts by sending a = command of =E2=80=9Cinitialize=E2=80=9D.  The domain is the identity= of the client.  The response is an immediate notification to the wi= th whatever LI was in the request and an ID.  The  response by = the client (which is the notification web server) is a piece of json cont= aining the ID.  We can say that the LI in this initialize command co= uld be something simple like the Country Code that wouldn=E2=80=99t get a= planned change.

Thereafter, the LoST server= (notification client) periodically repeats this keepalive notification e= very day or week with the initialize LI.  The client has to respond = with the ID.

The regular notification reques= t is a command of =E2=80=9Cnotify=E2=80=9D.  The server ignores a re= quest for notification from an uninitialized client.
The no= tification can be deleted with a command of =E2=80=9Cdelete=E2=80=9D. &nb= sp;If you delete the initialize LI, then the server won=E2=80=99t send an= y more notifications to that client and deletes all URIs it was saving fo= r that client.  The client would have to re-initialize to reset.

Brian

On Aug 27, 2021, at 5:41 PM, Randall Gellens <= ;rg+ietf@randy.pe= nsive.org> wrote:

I think we're movin= g to a model where:
- In a query, a client can request to b= e notified when the location <= /span>
should be revalidated;
- In the respon= se, the server provides an ID which the client 
associates with the location it ju= st validated;
- The server sends a notification to the URI,= containing the ID;
- The client revalidates each location = with which that ID is associated.

Question 1= : Does the server delete/inactivate the URI once it has sent the notifica= tion?

Question 2: Presumably, when the clien= t revalidates the location(s), it will again request notification.  = Does the server return the same ID as before, or a different ID?  A = different ID could perhaps be useful in edge cases where the server didn'= t send or the client didn't get the notification, but any utility seems s= mall.  If it's the same ID, then the answer to question 1 can be tha= t the URI remains active until the client asks to no longer be notified (= by sending an empty URI?).

--Randall

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/l= istinfo/ecrit

_____________= __________________________________
Ecrit mailing list
Ecrit@ietf.org<= br class=3D"">https://www.ietf.org/mailman/listinfo/ecrit
---= -------------------------------------------------------------------
-------- External Email: Please use caution when opening links a= nd 
attac= hments / Courriel externe: Soyez prudent avec les liens et 
documents joints

------------------------------------------------------------= ------------------
<= span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-siz= e: 12px; font-style: normal; font-variant-caps: normal; font-weight: norm= al; letter-spacing: normal; text-align: start; text-indent: 0px; text-tra= nsform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke= -width: 0px; text-decoration: none; float: none; display: inline !importa= nt;" class=3D"">External Email: Please use caution when opening links and= attachments / Courriel externe: Soyez prudent avec les liens et document= s joints

=

--=_MailMate_09FA322B-445C-4EC6-82EF-50358392A826_=-- From nobody Tue Aug 31 11:59:51 2021 Return-Path: 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 E2BAD3A0DA5 for ; Tue, 31 Aug 2021 11:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 7pKaLtmCeDEB for ; Tue, 31 Aug 2021 11:59:36 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7013A0DA0 for ; Tue, 31 Aug 2021 11:59:36 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 31 Aug 2021 11:59:35 -0700 From: "Randall Gellens" To: "Caron, Guy" Cc: ECRIT Date: Tue, 31 Aug 2021 11:59:32 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: <07be5a05ac8b4146adc2f0ba56f0e106@bell.ca> References: <6fdb8f42317d4dfc99783a4d834b6c85@bell.ca> <07be5a05ac8b4146adc2f0ba56f0e106@bell.ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_2D2DCD4D-8ED3-499C-B50A-DE1950B0F0DC_=" Embedded-HTML: [{"HTML":[468, 10968], "plain":[137, 2345], "uuid":"2F8D0642-D643-4104-B1B2-DD5BB1A24F1B"}] Archived-At: Subject: Re: [Ecrit] similar-location-09: GCaron Review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 18:59:50 -0000 --=_MailMate_2D2DCD4D-8ED3-499C-B50A-DE1950B0F0DC_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable I received an email from you via the list on 8/27 that contains an = attachment. --Randall On 31 Aug 2021, at 6:04, Caron, Guy wrote: > Can someone confirm that the attachment was delivered through the = > ECRIT list? > > I got it myself but want to be sure everyone got it. > > Thanks, > > Guy > > De : Ecrit De la part de Caron, Guy > Envoy=C3=A9 : 27 ao=C3=BBt 2021 16:09 > =C3=80 : ECRIT > Objet : [EXT][Ecrit] TR: similar-location-09: GCaron Review > > Resending to the ECRIT list. > > Guy > > De : Caron, Guy > Envoy=C3=A9 : 27 ao=C3=BBt 2021 16:01 > =C3=80 : 'draft-ietf-ecrit-similar-location@ietf.org' = > > > Objet : similar-location-09: GCaron Review > > > Hi, > > > > I reviewed this document and think it is mostly in good shape. I have = > a few comments to offer: > > > > 1. The document does not use a convention to express XML types = > such as for elements, 'boobooboo' for attributes, = > "heyheyhey" for values, etc. in the text. Should it? > > 2. The document defines terms in section 2, which are spelled = > with capital first letters however, when used in the text after = > section 2, a number of instances do no use the same style and should. > > 3. Section 2, in the Invalid Location definition, the term = > locationInvalid is used however, there is no defined element in here = > or anywhere else. Was that suppose to refer to lost-planned-changes = > ? > > 4. Section 2, the Similar Location definition says "A suggested = > civic location that is comparatively close to the civic location which = > was input". Comparing what? Geographic proximity, semantically close, = > else? > > 5. For completeness, it would be nice to include the = > 'similarLocationsLimited' attribute in the example = > in section 5.2. > > 6. There are two errors in the XML schema in section 6: > > a. xmlns=3D"urn:ietf:params:xml:ns:lost-rli1=C3=A2 should be = > xmlns=3D"urn:ietf:params:xml:ns:lost-rli1" > > b. should be value=3D"1"/> > > 7. The reference to planned-changes in section 9.1 should be = > updated > > > > I'm trying to attach a MSWord version with track-change here that = > includes resolutions to 2 and 5, with additional proposed editorial = > and non-subtative changes. If it does not pass the mail server, I will = > send directly to the authors. > > > > Thanks, > > > > Guy > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --=_MailMate_2D2DCD4D-8ED3-499C-B50A-DE1950B0F0DC_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">I received an email from you via the list on 8/27 that con= tains an attachment.

--Randall

On 31 Aug 2021, at 6:04, Caron, Guy wrote:

Can someone confirm that the attachment was deliv= ered through the ECRIT list?

=C2=A0

I got it myself but want to be sure everyone got = it.

=C2=A0

Thanks,

=C2=A0

Guy

= =C2=A0

De=C2=A0: Ecrit <ecrit-bounces@ietf.org&= gt; De la part de Caron, Guy
Envoy=C3=A9=C2=A0: 27 ao=C3=BBt 2021 16:09
=C3=80=C2=A0: ECRIT <ecrit@ietf.org>
Objet=C2=A0: [EXT][Ecrit] TR: similar-location-09: GCaron Review

=C2=A0

Resending to the ECRIT list.

=C2=A0

Guy

= =C2=A0

De=C2=A0: Caron, Guy
Envoy=C3=A9=C2=A0: 27 ao=C3=BBt 2021 16:01
=C3=80=C2=A0: 'draft-ietf-ecrit-similar-location@ietf.org' <draft-ietf-ecr= it-similar-location@ietf.org>
Objet=C2=A0: similar-location-09: GCaron Review

=C2=A0

Hi,

=C2=A0

=

I reviewed this d= ocument and think it is mostly in good shape. I have a few comments to of= fer:

=C2=A0

=

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The document does not use a convention= to express XML types such as <blablabla> for elements, =E2=80=98bo= obooboo=E2=80=99 for attributes, =E2=80=9Cheyheyhey=E2=80=9D for values, = etc. in the text. Should it?

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The document defines terms in section = 2, which are spelled with capital first letters however, when used in the= text after section 2, a number of instances do no use the same style and= should.

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 2, in the Invalid Location def= inition, the term locationInvalid is used however, there is no defined el= ement in here or anywhere else. Was that suppose to refer to lost-planned= -changes <locationInvalidated>?

4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 2, the Similar Location defini= tion says =E2=80=9CA suggested civic location that is comparatively close= to the civic location which was input=E2=80=9D. Comparing what? Geograph= ic proximity, semantically close, else?

5.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For completeness, it would be nice to = include the =E2=80=98similarLocationsLimited=E2=80=99 attribute in the ex= ample <findServiceResponse> in section 5.2.

6.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 There are two errors in the XML schema= in section 6:

a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 xmlns=3D"urn:ietf:params:xml:ns:lost-r= li1=C3=A2 should be xmlns=3D"urn:ietf:params:xml:ns:lost-rli1"

=

b.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <xs:minInclusive value=3D"1"> sh= ould be <xs:minInclusive value=3D"1"/>

7.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The reference to planned-changes in se= ction 9.1 should be updated

=C2=A0

=

I=E2=80=99m tryin= g to attach a MSWord version with track-change here that includes resolut= ions to 2 and 5, with additional proposed editorial and non-subtative cha= nges. If it does not pass the mail server, I will send directly to the authors.

=C2=A0

=

Thanks,

=C2=A0

=

Guy

______________________= _________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

--=_MailMate_2D2DCD4D-8ED3-499C-B50A-DE1950B0F0DC_=-- From nobody Tue Aug 31 12:35:10 2021 Return-Path: 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 CDAA43A00E1 for ; Tue, 31 Aug 2021 12:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, 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.20150623.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 TA7G1PD1kyNr for ; Tue, 31 Aug 2021 12:35:00 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 D096C3A00DE for ; Tue, 31 Aug 2021 12:34:59 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id v2so279500ilg.12 for ; Tue, 31 Aug 2021 12:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=G+iWWT98tHGIyNSQSFPUjbdymNHSN6dH5NZnG0zZySk=; b=AKChPa/RVvSfmBXMgoGbj1TX2/F2InUuyjm5EgrSRA+lvDHJijjwytNzI+Vi9FhWmO 9ymjG+El8C71GdFRR1BVTCeVAZgzBCIPduDIDx02bA3NXFwC14KuYX/4Y9zR3/p72NIl Pc4Q5eSPA/hNvgqAyc19oGtT7NWQ8F5m5zRGMT+13znGzeJyglSqt9uhA6Q/llO3nceL //CwVa40xxSFKtf7YPuEee8aII/XLc+PTHZj/xz66xLPwgnp4/MUlegWpjzRAnYdq1bS /JA/lOpSfK3NuAZb3QFJs3ABhazOYFaAZThXdMS/1X78r4Bw3F3n9GqFlql0Dn3QuzhD uf5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=G+iWWT98tHGIyNSQSFPUjbdymNHSN6dH5NZnG0zZySk=; b=kKJoi6/c+Y3nRvJy34P8vfQLXqWvCq9QGi+c+i5Kfm/jChiQyLPsWHM4RJNHESxD4w LOcpEsQGjEJPRSqaInMjH0DB/tGzdZUhMTkFQXIMNbMI7r+hKkIzasIePyRnK4rJZ9Jv 702Q+NtKer0Fe4zjSJaChaLFcTRMlCFBt+p1JXFK4GpGh2rguaC+2zD7PBaDKCBD79th wuhBRGlYrspyGOIw2xwfimdwDDIqsLK1Ourc+qe9iFM2R1IBniDxqxmkXBxgrojfyKTc EtPrdnDoaQvLmTjdySgXsntjERk1xkxUX+3n8jahPAj9LNvEfy3hg9WjOWfSFVzPaujG 750g== X-Gm-Message-State: AOAM530TZS27PzRIaYXmBu3O6cVqhH2USaKMoDjYGBR4bZbDiCovdTlE XR2gWa1fJUO41GxOrhUVbmszBA== X-Google-Smtp-Source: ABdhPJy8xenCoC3KZ57qM4w3t5r6kJz7o0l0wpHh7tPp1PmrzG8jj97xjHxW+Hzfz/y3yoe+Oc6/zw== X-Received: by 2002:a92:d2cb:: with SMTP id w11mr21357169ilg.17.1630438497883; Tue, 31 Aug 2021 12:34:57 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id o5sm10047587iow.48.2021.08.31.12.34.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Aug 2021 12:34:57 -0700 (PDT) From: Brian Rosen Message-Id: <9433989A-85D7-41B9-96EA-313ADC0F02CD@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_EF5841C7-34E7-42E8-80E4-274B07E505B5" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 31 Aug 2021 15:34:56 -0400 In-Reply-To: Cc: "Caron, Guy" , ECRIT To: Randall Gellens References: <5577e2e6daa4405bbe12ef61675e1f55@bell.ca> <3AD58DEC-1DC9-4BC0-B55C-4E782E4AAA74@brianrosen.net> X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Ecrit] planned-changes: two questions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 19:35:07 -0000 --Apple-Mail=_EF5841C7-34E7-42E8-80E4-274B07E505B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 No. =20 There is one URI, but many IDs, one per unique record at the LoST server = that is involved in a planned change. The one URI will receive one = notification per ID it has registered for. > On Aug 31, 2021, at 2:56 PM, Randall Gellens = wrote: >=20 > i understand that the concern is allowing a client to leverage the = LoST server to attack a large number of targets, I'm just not clear = mechanically how such leverage potentially works. Each validation query = can store a URI, and that URI may get associated with a large number of = locations. Maybe there's a street name change or an annexation. So maybe = thousands or tens or hundreds of thousands of locations are potentially = invalidated. They all have the same URI associated with them, so the = LoST server connects to the URI once and POSTs one notification, no? >=20 > --Randall >=20 > On 31 Aug 2021, at 10:53, Brian Rosen wrote: >=20 > Of course an attacker would conceal itself and register multiple URIs = under different identities. But the bigger problem is that if a large = planned change occurred, the victim could receive a large number of = notifications it didn=E2=80=99t expect. >=20 > With a test transition, we know that the client expects to see = notifications, we only need one per URI (we could specify one per domain = =E2=80=94 after the scheme and before the first slash). If we don=E2=80=99= t get the ID, we know not to allow that URI to be provisioned. So = it=E2=80=99s one test transaction vs a large number of planned change = transactions. >=20 > Brian >=20 >=20 >> On Aug 31, 2021, at 1:35 PM, Randall Gellens = > wrote: >>=20 >> If a malicious client registers a URI that is designed to attack a = third site, the test transaction causes the LoST server to connect to it = and POST a command. Without a test transaction, the LoST server stores = the URI and at a future time connects to it and sends a command. Either = way, a LoST client can register potentially one URI per queried = location, and a LoST server will connect to that URI and POST a message. = A queried location could be tied to many other locations, so there could = be many locations for which a change would trigger the LoST server to = use the URI, but is that worse? >>=20 >> --Randall >>=20 >> On 31 Aug 2021, at 10:27, Brian Rosen wrote: >>=20 >> If the work group wants to have the LoST server keep the URI until = expressly deleted, that=E2=80=99s okay with me. >>=20 >> Authenticating the client to the server doesn=E2=80=99t mean the URI = is authenticated. We can=E2=80=99t restrict the URI to be the same = entity as the client running the LoST transaction. And the clients are = wide ranging. Could be an enterprise running its own LIS for example. = We can=E2=80=99t assume the North American PKI is workable everywhere, = and even that doesn=E2=80=99t extend to an enterprise LIS. ISTM we have = to run a test transaction with the notification service to make sure = it=E2=80=99s what we think it is. >>=20 >> Brian >>=20 >>=20 >>=20 >>> On Aug 31, 2021, at 9:01 AM, Caron, Guy > wrote: >>>=20 >>> Inline. >>>=20 >>> Guy >>>=20 >>> -----Message d'origine----- >>> De : Brian Rosen >=20 >>> Envoy=C3=A9 : 31 ao=C3=BBt 2021 08:11 >>> =C3=80 : Caron, Guy > >>> Cc : Randall Gellens >; ECRIT > >>> Objet : [EXT]Re: [Ecrit] planned-changes: two questions >>>=20 >>> You delete the URI when you delete the record in the LIS. >>> [GC] That's fine but that was not the question Randall posed. He = asked whether the URI is deleted after a notification. I agree that if = the Client does not host the location anymore that the URI associated = with that location in the Server should be deleted. This could be = achieved with an empty . >>>=20 >>> I don=E2=80=99t think this is covered in 5222. The mechanism causes = the LoST server to send notifications to the client, but the client is = allowed to put any URI in the record, and it can add it to as many = records as it wants. >>> [GC] I thought we agreed on using one generic URI per Client. = Clients should be authenticated by the Servers. >>> An evil implementation could record URIs against multiple targets = that were unaware that the evil implementation did it, until they got a = large number of PUSH transactions they didn=E2=80=99t expect or = understand as a result of a large planned change. >>> [GC] Only authenticated Clients should be allowed to provide URIs to = be stored by the Servers. >>>=20 >>> The proposed mechanism qualifies the client URI before its used in a = planned change. >>>=20 >>> Brian >>>=20 >>>> On Aug 31, 2021, at 7:37 AM, Caron, Guy > wrote: >>>>=20 >>>> Well, this is not going in the direction I thought. >>>>=20 >>>> What is the purpose of deleting the URIs at the Server = post-validation? >>>>=20 >>>> Regarding opening a new DoS, I guess I'm not following. Wouldn't = this case be covered by the security considerations in RFC 5222? >>>>=20 >>>> What you're proposing puts back significant load on the Servers (a = key consideration for creating planned-changes in the first place) and = complicates the mechanism. >>>>=20 >>>> Guy >>>>=20 >>>>=20 >>>> -----Message d'origine----- >>>> De : Ecrit > = De la part de Brian Rosen Envoy=C3=A9 :=20 >>>> 30 ao=C3=BBt 2021 11:22 =C3=80 : Randall Gellens = > Cc=20 >>>> : ECRIT > Objet : [EXT]Re: = [Ecrit] planned-changes: two=20 >>>> questions >>>>=20 >>>> Answer 1: yes. Since there is going to be a revalidation, just = deleting the setting seems right to me. >>>> Answer 2: Up to server. If I were implementing, I would hash the = real ID with the URI and some kind of predictable nonce. =20 >>>>=20 >>>> We probably have to say more about how the server identifies the = client, so that replacement of the URI works. Could we say we use the = domain of the URI (the entire domain with all the dots) to identify the = client, and anything can occur after it (meaning a slash and whatever)? = If we do that, then how would delete the notification? Force there to = be something other than the domain (ugly). Explicit delete request? >>>>=20 >>>> Hmmm, we=E2=80=99ve opened a DoS attack: a rogue client stores a = bunch of URIs for servers it wants to victimize. In North America we = have a real simple solution for that, because we have a PKI, so we know, = for sure, who the client is, and could restrict who we allow to store = URIs, but that wouldn=E2=80=99t be true in general. Also, it would be = nice for the client to have confidence the mechanism worked before it = needed it. >>>>=20 >>>> So >>>> Let=E2=80=99s add a =E2=80=9Ccommand=E2=80=9D to plannedChange in = the findService request. =20 >>>> And, have the client have a response to the notification which is = the=20 >>>> ID (json with the 200) >>>>=20 >>>>=20 >>>> The client starts by sending a command of =E2=80=9Cinitialize=E2=80=9D= . The domain is the identity of the client. The response is an = immediate notification to the with whatever LI was in the request and an = ID. The response by the client (which is the notification web server) = is a piece of json containing the ID. We can say that the LI in this = initialize command could be something simple like the Country Code that = wouldn=E2=80=99t get a planned change. >>>>=20 >>>> Thereafter, the LoST server (notification client) periodically = repeats this keepalive notification every day or week with the = initialize LI. The client has to respond with the ID. >>>>=20 >>>> The regular notification request is a command of =E2=80=9Cnotify=E2=80= =9D. The server ignores a request for notification from an = uninitialized client. >>>> The notification can be deleted with a command of =E2=80=9Cdelete=E2=80= =9D. If you delete the initialize LI, then the server won=E2=80=99t = send any more notifications to that client and deletes all URIs it was = saving for that client. The client would have to re-initialize to = reset. >>>>=20 >>>> Brian >>>>=20 >>>>> On Aug 27, 2021, at 5:41 PM, Randall Gellens = > wrote: >>>>>=20 >>>>> I think we're moving to a model where: >>>>> - In a query, a client can request to be notified when the = location=20 >>>>> should be revalidated; >>>>> - In the response, the server provides an ID which the client=20 >>>>> associates with the location it just validated; >>>>> - The server sends a notification to the URI, containing the ID; >>>>> - The client revalidates each location with which that ID is = associated. >>>>>=20 >>>>> Question 1: Does the server delete/inactivate the URI once it has = sent the notification? >>>>>=20 >>>>> Question 2: Presumably, when the client revalidates the = location(s), it will again request notification. Does the server return = the same ID as before, or a different ID? A different ID could perhaps = be useful in edge cases where the server didn't send or the client = didn't get the notification, but any utility seems small. If it's the = same ID, then the answer to question 1 can be that the URI remains = active until the client asks to no longer be notified (by sending an = empty URI?). >>>>>=20 >>>>> --Randall >>>>>=20 >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit = >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit = >>>> = ---------------------------------------------------------------------- >>>> -------- External Email: Please use caution when opening links and=20= >>>> attachments / Courriel externe: Soyez prudent avec les liens et=20 >>>> documents joints >>>=20 >>> = --------------------------------------------------------------------------= ---- >>> External Email: Please use caution when opening links and = attachments / Courriel externe: Soyez prudent avec les liens et = documents joints >>=20 >=20 --Apple-Mail=_EF5841C7-34E7-42E8-80E4-274B07E505B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 No. =  

There is one = URI, but many IDs, one per unique record at the LoST server that is = involved in a planned change.  The one URI will receive one = notification per ID it has registered for.



On Aug = 31, 2021, at 2:56 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

i = understand that the concern is allowing a client to leverage the LoST = server to attack a large number of targets, I'm just not clear = mechanically how such leverage potentially works. Each validation query = can store a URI, and that URI may get associated with a large number of = locations. Maybe there's a street name change or an annexation. So = maybe thousands or tens or hundreds of thousands of locations are = potentially invalidated. They all have the same URI associated with = them, so the LoST server connects to the URI once and POSTs one = notification, no?

--Randall

On 31 Aug 2021, at 10:53, Brian Rosen wrote:

Of course an attacker would conceal = itself and register multiple URIs under different identities.  But = the bigger  problem is that if a large planned change occurred, the = victim could receive a large number of notifications it didn=E2=80=99t = expect.

With a test = transition, we know that the client expects to see notifications, we = only need one per URI (we could specify one per domain =E2=80=94 after = the scheme and before the first slash).  If we don=E2=80=99t get = the ID, we know not to allow that URI to be provisioned.  So it=E2=80= =99s one test transaction vs a large number of planned change = transactions.

Brian


On Aug = 31, 2021, at 1:35 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

If a = malicious client registers a URI that is designed to attack a third = site, the test transaction causes the LoST server to connect to it and = POST a command. Without a test transaction, the LoST server stores the = URI and at a future time connects to it and sends a command. Either = way, a LoST client can register potentially one URI per queried = location, and a LoST server will connect to that URI and POST a message. = A queried location could be tied to many other locations, so there = could be many locations for which a change would trigger the LoST server = to use the URI, but is that worse?

--Randall

On 31 Aug 2021, at = 10:27, Brian Rosen wrote:

If the work group wants to have the LoST = server keep the URI until expressly deleted, that=E2=80=99s okay with = me.

Authenticating = the client to the server doesn=E2=80=99t mean the URI is authenticated. =  We can=E2=80=99t restrict the URI to be the same entity as the = client running the LoST transaction.  And the clients are wide = ranging.  Could be an enterprise running its own LIS for example. =  We can=E2=80=99t assume the North American PKI is workable = everywhere, and even that doesn=E2=80=99t extend to an enterprise LIS. =  ISTM we have to run a test transaction with the notification = service to make sure it=E2=80=99s what we think it is.

Brian



On Aug 31, 2021, at 9:01 AM, Caron, Guy = <g.caron@bell.ca> = wrote:

Inline.

Guy

-----Message d'origine-----
De : Brian Rosen <br@brianrosen.net> 
Envoy=C3=A9 : 31 ao=C3=BBt = 2021 08:11
=C3=80 : = Caron, Guy <g.caron@bell.ca>
Cc : Randall Gellens <rg+ietf@randy.pensive.org>; ECRIT <ecrit@ietf.org>
Objet : [EXT]Re: [Ecrit] planned-changes: two = questions

You delete = the URI when you delete the record in the LIS.
[GC] That's fine but that was = not the question Randall posed. He asked whether the URI is deleted = after a notification. I agree that if the Client does not host the = location anymore that the URI associated with that location in the = Server should be deleted. This could be achieved with an empty = <plannedChange>.

I don=E2=80=99t think this is covered in 5222.  The = mechanism causes the LoST server to send notifications to the client, = but the client is allowed to put any URI in the record, and it can add = it to as many records as it wants.
[GC] I thought we agreed on using one generic URI per Client. = Clients should be authenticated by the Servers.
 An evil implementation = could record URIs against multiple targets that were unaware that the = evil implementation did it, until they got a large number of PUSH = transactions they didn=E2=80=99t expect or understand as a result of a = large planned change.
[GC] Only authenticated Clients should be allowed to provide = URIs to be stored by the Servers.

The proposed mechanism qualifies the client URI before its = used in a planned change.

Brian

On Aug 31, 2021, at 7:37 AM, Caron, = Guy <g.caron@bell.ca> wrote:

Well, this is not going in the direction I thought.

What is the purpose of deleting the URIs at = the Server post-validation?

Regarding = opening a new DoS, I guess I'm not following. Wouldn't this case be = covered by the security considerations in RFC 5222?

What you're proposing puts back significant load on the = Servers (a key consideration for creating planned-changes in the first = place) and complicates the mechanism.

Guy


-----Message d'origine-----
De : Ecrit <ecrit-bounces@ietf.org> De la part de Brian Rosen = Envoy=C3=A9 : 
30 ao=C3=BBt 2021 11:22 =C3=80 : Randall Gellens <rg+ietf@randy.pensive.org> Cc 
: ECRIT = <ecrit@ietf.org> = Objet : [EXT]Re: [Ecrit] planned-changes: two 
questions

Answer 1: yes.  Since there is going to = be a revalidation, just deleting the setting seems right to me.
Answer 2: Up to server.  If I were implementing, I would = hash the real ID with the URI and some kind of predictable nonce. =  

We probably have to say more about = how the server identifies the client, so that replacement of the URI = works.  Could we say we use the domain of the URI (the entire = domain with all the dots) to identify the client, and anything can occur = after it (meaning a slash and whatever)?  If we do that, then how = would delete the notification?  Force there to be something other = than the domain (ugly).  Explicit delete request?

Hmmm, we=E2=80=99ve opened a DoS attack: a rogue client = stores a bunch of URIs for servers it wants to victimize.  In North = America we have a real simple solution for that, because we have a PKI, = so we know, for sure, who the client is, and could restrict who we allow = to store URIs, but that wouldn=E2=80=99t be true in general.  Also, = it would be nice for the client to have confidence the mechanism worked = before it needed it.

So
Let=E2=80= =99s add a =E2=80=9Ccommand=E2=80=9D to plannedChange in the findService = request.  
And, have the client have a response to = the notification which is the 
ID (json = with the 200)


The client = starts by sending a command of =E2=80=9Cinitialize=E2=80=9D.  The = domain is the identity of the client.  The response is an immediate = notification to the with whatever LI was in the request and an ID. =  The  response by the client (which is the notification web = server) is a piece of json containing the ID.  We can say that the = LI in this initialize command could be something simple like the Country = Code that wouldn=E2=80=99t get a planned change.

Thereafter, the LoST server (notification client) = periodically repeats this keepalive notification every day or week with = the initialize LI.  The client has to respond with the ID.

The regular notification request is a command = of =E2=80=9Cnotify=E2=80=9D.  The server ignores a request for = notification from an uninitialized client.
The = notification can be deleted with a command of =E2=80=9Cdelete=E2=80=9D. =  If you delete the initialize LI, then the server won=E2=80=99t = send any more notifications to that client and deletes all URIs it was = saving for that client.  The client would have to re-initialize to = reset.

Brian

On Aug 27, 2021, at 5:41 = PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

I think we're moving to a model where:
- In a = query, a client can request to be notified when the location 
should be = revalidated;
- In the response, the server provides an ID = which the client 
associates with the location it just validated;
-= The server sends a notification to the URI, containing the ID;
- The client revalidates each location with which that ID is = associated.

Question 1: Does the server = delete/inactivate the URI once it has sent the notification?

Question 2: Presumably, when the client = revalidates the location(s), it will again request notification. =  Does the server return the same ID as before, or a different ID? =  A different ID could perhaps be useful in edge cases where the = server didn't send or the client didn't get the notification, but any = utility seems small.  If it's the same ID, then the answer to = question 1 can be that the URI remains active until the client asks to = no longer be notified (by sending an empty URI?).

--Randall

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
---------------------------------------------------------------= -------
-------- External Email: Please use caution when = opening links and 
attachments / Courriel externe: Soyez prudent avec les liens = et 
documents joints

---------------------------------------------------------------= ---------------
External Email: Please use caution when opening links and = attachments / Courriel externe: Soyez prudent avec les liens et = documents joints



= --Apple-Mail=_EF5841C7-34E7-42E8-80E4-274B07E505B5-- From nobody Tue Aug 31 13:30:31 2021 Return-Path: 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 B4C883A0A00 for ; Tue, 31 Aug 2021 13:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=bell.ca 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 J-rMp4L6a_S5 for ; Tue, 31 Aug 2021 13:30:20 -0700 (PDT) Received: from ESA2-Dor.bell.ca (esa2-dor.bell.ca [204.101.223.59]) (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 90C6D3A0AAA for ; Tue, 31 Aug 2021 13:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1630441806; x=1661977806; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=q3LxcQ9NkAK/M8BiaIlsvFVdqvrp8XavCfPjL4UmgV4=; b=UpjzWZK2lM/RgR89gsJxbd7M6ZSuCJsu+JUcTKvC3O0BoygIuHQ86FTc +Lxy28DOpSmf0S+ytX5FhmC0QHaRjXFrlVB7NBJns9itkU6AEzSVNyU/o rZParoSPXzRWD6jS7lQgnvXbpC8+BTUZeSQgjwZsD7sznxVInNc84crw1 MWvPmq13UMhzfvo+Kbd+SpvX1QL2ryGsz0Cya3cPKmgg/317zk2U/mb8v 3joPjhp0HIZ3NJhheC3dHETCZIYOdrbXSEpo/423Q5EvXlNpcKv6a5UF3 Bnd3RxJhKes5pws8FzX/XrokjZxRTtjuePC/Y+ntYXGE2E1sZn7XgL1AZ g==; IronPort-SDR: JjU0MaXaGVHi+EB4xsx0lbmbeyMWvTiUNXJcc3pVnTYtWdD+7kAlHmrhubrJVyGBp8CvHAH+w3 gXfGiYLfBGxQ== Received: from dc5cmy-d01.bellca.int.bell.ca (HELO DG3MBX04-WYN.bell.corp.bce.ca) ([198.235.121.230]) by esa02corp-dor.bell.corp.bce.ca with ESMTP; 31 Aug 2021 16:30:04 -0400 Received: from DG12MBX02-WYN.bell.corp.bce.ca (142.182.18.47) by DG3MBX04-WYN.bell.corp.bce.ca (142.182.18.26) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Tue, 31 Aug 2021 16:30:03 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX02-WYN.bell.corp.bce.ca (142.182.18.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Tue, 31 Aug 2021 16:30:04 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Tue, 31 Aug 2021 16:30:04 -0400 From: "Caron, Guy" To: Randall Gellens CC: ECRIT Thread-Topic: [EXT]Re: [Ecrit] similar-location-09: GCaron Review Thread-Index: Adebe1KGR57xvilqQAOgCtIx5j1+GgABAJmwALpQr5AAFNEeAAAF9/xw Date: Tue, 31 Aug 2021 20:30:04 +0000 Message-ID: References: <6fdb8f42317d4dfc99783a4d834b6c85@bell.ca> <07be5a05ac8b4146adc2f0ba56f0e106@bell.ca> In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.112.70] Content-Type: multipart/alternative; boundary="_000_c0503e0fee414892b6fb2dfa0cfd839dbellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] similar-location-09: GCaron Review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 20:30:28 -0000 --_000_c0503e0fee414892b6fb2dfa0cfd839dbellca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGFsbCB0aGF0IGNvbmZpcm1lZCB0aGUgcmVjZXB0aW9uIG9mIHRoZSBhdHRhY2htZW50 IG9uIHRoZSBsaXN0Lg0KDQpJIHdhcyB3b25kZXJpbmcgc2luY2UgdGhlIHBvc3RpbmcgZGlkIG5v dCBzcGFyayBhbnkgcmVhY3Rpb24uDQoNCkd1eQ0KDQpEZSA6IFJhbmRhbGwgR2VsbGVucyA8cmcr aWV0ZkByYW5keS5wZW5zaXZlLm9yZz4NCkVudm95w6kgOiAzMSBhb8O7dCAyMDIxIDE1OjAwDQrD gCA6IENhcm9uLCBHdXkgPGcuY2Fyb25AYmVsbC5jYT4NCkNjIDogRUNSSVQgPGVjcml0QGlldGYu b3JnPg0KT2JqZXQgOiBbRVhUXVJlOiBbRWNyaXRdIHNpbWlsYXItbG9jYXRpb24tMDk6IEdDYXJv biBSZXZpZXcNCg0KDQpJIHJlY2VpdmVkIGFuIGVtYWlsIGZyb20geW91IHZpYSB0aGUgbGlzdCBv biA4LzI3IHRoYXQgY29udGFpbnMgYW4gYXR0YWNobWVudC4NCg0KLS1SYW5kYWxsDQoNCk9uIDMx IEF1ZyAyMDIxLCBhdCA2OjA0LCBDYXJvbiwgR3V5IHdyb3RlOg0KDQpDYW4gc29tZW9uZSBjb25m aXJtIHRoYXQgdGhlIGF0dGFjaG1lbnQgd2FzIGRlbGl2ZXJlZCB0aHJvdWdoIHRoZSBFQ1JJVCBs aXN0Pw0KDQoNCg0KSSBnb3QgaXQgbXlzZWxmIGJ1dCB3YW50IHRvIGJlIHN1cmUgZXZlcnlvbmUg Z290IGl0Lg0KDQoNCg0KVGhhbmtzLA0KDQoNCg0KR3V5DQoNCg0KDQpEZSA6IEVjcml0IDxlY3Jp dC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnPj4gRGUgbGEg cGFydCBkZSBDYXJvbiwgR3V5DQpFbnZvecOpIDogMjcgYW/Du3QgMjAyMSAxNjowOQ0Kw4AgOiBF Q1JJVCA8ZWNyaXRAaWV0Zi5vcmc8bWFpbHRvOmVjcml0QGlldGYub3JnPj4NCk9iamV0IDogW0VY VF1bRWNyaXRdIFRSOiBzaW1pbGFyLWxvY2F0aW9uLTA5OiBHQ2Fyb24gUmV2aWV3DQoNCg0KDQpS ZXNlbmRpbmcgdG8gdGhlIEVDUklUIGxpc3QuDQoNCg0KDQpHdXkNCg0KDQoNCkRlIDogQ2Fyb24s IEd1eQ0KRW52b3nDqSA6IDI3IGFvw7t0IDIwMjEgMTY6MDENCsOAIDogJ2RyYWZ0LWlldGYtZWNy aXQtc2ltaWxhci1sb2NhdGlvbkBpZXRmLm9yZycgPGRyYWZ0LWlldGYtZWNyaXQtc2ltaWxhci1s b2NhdGlvbkBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1lY3JpdC1zaW1pbGFyLWxvY2F0aW9u QGlldGYub3JnPj4NCk9iamV0IDogc2ltaWxhci1sb2NhdGlvbi0wOTogR0Nhcm9uIFJldmlldw0K DQoNCg0KSGksDQoNCg0KDQpJIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYW5kIHRoaW5rIGl0IGlz IG1vc3RseSBpbiBnb29kIHNoYXBlLiBJIGhhdmUgYSBmZXcgY29tbWVudHMgdG8gb2ZmZXI6DQoN Cg0KDQoxLiAgICAgICBUaGUgZG9jdW1lbnQgZG9lcyBub3QgdXNlIGEgY29udmVudGlvbiB0byBl eHByZXNzIFhNTCB0eXBlcyBzdWNoIGFzIDxibGFibGFibGE+IGZvciBlbGVtZW50cywg4oCYYm9v Ym9vYm9v4oCZIGZvciBhdHRyaWJ1dGVzLCDigJxoZXloZXloZXnigJ0gZm9yIHZhbHVlcywgZXRj LiBpbiB0aGUgdGV4dC4gU2hvdWxkIGl0Pw0KDQoyLiAgICAgICBUaGUgZG9jdW1lbnQgZGVmaW5l cyB0ZXJtcyBpbiBzZWN0aW9uIDIsIHdoaWNoIGFyZSBzcGVsbGVkIHdpdGggY2FwaXRhbCBmaXJz dCBsZXR0ZXJzIGhvd2V2ZXIsIHdoZW4gdXNlZCBpbiB0aGUgdGV4dCBhZnRlciBzZWN0aW9uIDIs IGEgbnVtYmVyIG9mIGluc3RhbmNlcyBkbyBubyB1c2UgdGhlIHNhbWUgc3R5bGUgYW5kIHNob3Vs ZC4NCg0KMy4gICAgICAgU2VjdGlvbiAyLCBpbiB0aGUgSW52YWxpZCBMb2NhdGlvbiBkZWZpbml0 aW9uLCB0aGUgdGVybSBsb2NhdGlvbkludmFsaWQgaXMgdXNlZCBob3dldmVyLCB0aGVyZSBpcyBu byBkZWZpbmVkIGVsZW1lbnQgaW4gaGVyZSBvciBhbnl3aGVyZSBlbHNlLiBXYXMgdGhhdCBzdXBw b3NlIHRvIHJlZmVyIHRvIGxvc3QtcGxhbm5lZC1jaGFuZ2VzIDxsb2NhdGlvbkludmFsaWRhdGVk Pj8NCg0KNC4gICAgICAgU2VjdGlvbiAyLCB0aGUgU2ltaWxhciBMb2NhdGlvbiBkZWZpbml0aW9u IHNheXMg4oCcQSBzdWdnZXN0ZWQgY2l2aWMgbG9jYXRpb24gdGhhdCBpcyBjb21wYXJhdGl2ZWx5 IGNsb3NlIHRvIHRoZSBjaXZpYyBsb2NhdGlvbiB3aGljaCB3YXMgaW5wdXTigJ0uIENvbXBhcmlu ZyB3aGF0PyBHZW9ncmFwaGljIHByb3hpbWl0eSwgc2VtYW50aWNhbGx5IGNsb3NlLCBlbHNlPw0K DQo1LiAgICAgICBGb3IgY29tcGxldGVuZXNzLCBpdCB3b3VsZCBiZSBuaWNlIHRvIGluY2x1ZGUg dGhlIOKAmHNpbWlsYXJMb2NhdGlvbnNMaW1pdGVk4oCZIGF0dHJpYnV0ZSBpbiB0aGUgZXhhbXBs ZSA8ZmluZFNlcnZpY2VSZXNwb25zZT4gaW4gc2VjdGlvbiA1LjIuDQoNCjYuICAgICAgIFRoZXJl IGFyZSB0d28gZXJyb3JzIGluIHRoZSBYTUwgc2NoZW1hIGluIHNlY3Rpb24gNjoNCg0KYS4gICAg ICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bG9zdC1ybGkxw6Igc2hvdWxkIGJlIHht bG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmxvc3QtcmxpMSINCg0KYi4gICAgICAgPHhzOm1p bkluY2x1c2l2ZSB2YWx1ZT0iMSI+IHNob3VsZCBiZSA8eHM6bWluSW5jbHVzaXZlIHZhbHVlPSIx Ii8+DQoNCjcuICAgICAgIFRoZSByZWZlcmVuY2UgdG8gcGxhbm5lZC1jaGFuZ2VzIGluIHNlY3Rp b24gOS4xIHNob3VsZCBiZSB1cGRhdGVkDQoNCg0KDQpJ4oCZbSB0cnlpbmcgdG8gYXR0YWNoIGEg TVNXb3JkIHZlcnNpb24gd2l0aCB0cmFjay1jaGFuZ2UgaGVyZSB0aGF0IGluY2x1ZGVzIHJlc29s dXRpb25zIHRvIDIgYW5kIDUsIHdpdGggYWRkaXRpb25hbCBwcm9wb3NlZCBlZGl0b3JpYWwgYW5k IG5vbi1zdWJ0YXRpdmUgY2hhbmdlcy4gSWYgaXQgZG9lcyBub3QgcGFzcyB0aGUgbWFpbCBzZXJ2 ZXIsIEkgd2lsbCBzZW5kIGRpcmVjdGx5IHRvIHRoZSBhdXRob3JzLg0KDQoNCg0KVGhhbmtzLA0K DQoNCg0KR3V5DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpFY3JpdCBtYWlsaW5nIGxpc3QNCkVjcml0QGlldGYub3JnPG1haWx0bzpFY3JpdEBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkV4dGVybmFsIEVtYWlsOiBQbGVhc2UgdXNl IGNhdXRpb24gd2hlbiBvcGVuaW5nIGxpbmtzIGFuZCBhdHRhY2htZW50cyAvIENvdXJyaWVsIGV4 dGVybmU6IFNveWV6IHBydWRlbnQgYXZlYyBsZXMgbGllbnMgZXQgZG9jdW1lbnRzIGpvaW50cw0K --_000_c0503e0fee414892b6fb2dfa0cfd839dbellca_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJ e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBw dCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUi1DQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5UaGFua3MgYWxsIHRoYXQgY29uZmlybWVkIHRoZSByZWNlcHRpb24gb2YgdGhlIGF0dGFj aG1lbnQgb24gdGhlIGxpc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgd2FzIHdvbmRlcmluZyBzaW5jZSB0aGUgcG9z dGluZyBkaWQgbm90IHNwYXJrIGFueSByZWFjdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+R3V5PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+IFJhbmRhbGwgR2VsbGVucyAmbHQ7cmcmIzQzO2lldGZAcmFu ZHkucGVuc2l2ZS5vcmcmZ3Q7DQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gMzEgYW/Du3Qg MjAyMSAxNTowMDxicj4NCjxiPsOAJm5ic3A7OjwvYj4gQ2Fyb24sIEd1eSAmbHQ7Zy5jYXJvbkBi ZWxsLmNhJmd0Ozxicj4NCjxiPkNjJm5ic3A7OjwvYj4gRUNSSVQgJmx0O2Vjcml0QGlldGYub3Jn Jmd0Ozxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gW0VYVF1SZTogW0Vjcml0XSBzaW1pbGFyLWxv Y2F0aW9uLTA5OiBHQ2Fyb24gUmV2aWV3PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cD48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkkgcmVjZWl2ZWQgYW4gZW1haWwgZnJvbSB5b3UgdmlhIHRo ZSBsaXN0IG9uIDgvMjcgdGhhdCBjb250YWlucyBhbiBhdHRhY2htZW50LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+LS1SYW5kYWxsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj5PbiAzMSBBdWcgMjAyMSwgYXQgNjowNCwgQ2Fyb24sIEd1eSB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjNzc3Nzc3IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQ7bWFyZ2luLWxlZnQ6MGNtO21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTtt YXJnaW4tYm90dG9tOjMuNzVwdCI+DQo8ZGl2IGlkPSIyRjhEMDY0Mi1ENjQzLTQxMDQtQjFCMi1E RDVCQjFBMjRGMUIiPg0KPGRpdj4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206 LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DYW4gc29tZW9uZSBjb25maXJtIHRoYXQgdGhlIGF0dGFj aG1lbnQgd2FzIGRlbGl2ZXJlZCB0aHJvdWdoIHRoZSBFQ1JJVCBsaXN0Pzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3Nzc7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90 dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBnb3QgaXQgbXlzZWxmIGJ1dCB3YW50IHRvIGJl IHN1cmUgZXZlcnlvbmUgZ290IGl0Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM3Nzc3Nzc7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNzc3Nzc3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3Ms PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3O21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJn aW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3 Nzc3Nzc7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkd1eTwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3Nzttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRv bTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3Nzttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAw MDFwdCI+PGI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij5EZSZuYnNw Ozo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+IEVj cml0ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmciPjxz cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmVjcml0LWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9h PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+Jmd0Ow0KPGI+RGUgbGEg cGFydCBkZTwvYj4gQ2Fyb24sIEd1eTxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiAyNyBhb8O7 dCAyMDIxIDE2OjA5PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBFQ1JJVCAmbHQ7PC9zcGFuPjxhIGhy ZWY9Im1haWx0bzplY3JpdEBpZXRmLm9yZyI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ZWNy aXRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3 Nzc3NyI+Jmd0Ozxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gW0VYVF1bRWNyaXRdIFRSOiBzaW1p bGFyLWxvY2F0aW9uLTA5OiBHQ2Fyb24gUmV2aWV3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNzc3Nzc3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTou MDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3Nzttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjow Y207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlc2VuZGluZyB0byB0aGUg RUNSSVQgbGlzdC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3 Nzc3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3Nztt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+R3V5PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojNzc3Nzc3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48 Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPkRlJm5ic3A7Ojwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij4gQ2Fyb24sIEd1 eQ0KPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IDI3IGFvw7t0IDIwMjEgMTY6MDE8YnI+DQo8 Yj7DgCZuYnNwOzo8L2I+ICdkcmFmdC1pZXRmLWVjcml0LXNpbWlsYXItbG9jYXRpb25AaWV0Zi5v cmcnICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtZWNyaXQtc2ltaWxhci1s b2NhdGlvbkBpZXRmLm9yZyI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ZHJhZnQtaWV0Zi1l Y3JpdC1zaW1pbGFyLWxvY2F0aW9uQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJGUiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPiZndDs8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IHNp bWlsYXItbG9jYXRpb24tMDk6IEdDYXJvbiBSZXZpZXc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiM3Nzc3Nzc7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9t Oi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3O21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2lu OjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6Izc3Nzc3Nzttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3Nzc7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJn aW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojNzc3Nzc3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIHJldmlld2VkIHRo aXMgZG9jdW1lbnQgYW5kIHRoaW5rIGl0IGlzIG1vc3RseSBpbiBnb29kIHNoYXBlLiBJIGhhdmUg YSBmZXcgY29tbWVudHMgdG8gb2ZmZXI6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiM3Nzc3Nzc7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21h cmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWxlZnQ6MzYuMHB0O21hcmdp bi1ib3R0b206LjAwMDFwdDt0ZXh0LWluZGVudDotMTguMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3Nzttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+MS48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6Izc3 Nzc3Nzttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj Nzc3Nzc3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgZG9jdW1lbnQgZG9lcyBub3Qg dXNlIGEgY29udmVudGlvbiB0byBleHByZXNzIFhNTCB0eXBlcyBzdWNoIGFzICZsdDtibGFibGFi bGEmZ3Q7IGZvciBlbGVtZW50cywg4oCYYm9vYm9vYm9v4oCZIGZvciBhdHRyaWJ1dGVzLCDigJxo ZXloZXloZXnigJ0NCiBmb3IgdmFsdWVzLCBldGMuIGluIHRoZSB0ZXh0LiBTaG91bGQgaXQ/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFy Z2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tbGVmdDozNi4wcHQ7bWFyZ2lu LWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50Oi0xOC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4yLjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojNzc3 Nzc3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3 Nzc3Nzc7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZSBkb2N1bWVudCBkZWZpbmVzIHRl cm1zIGluIHNlY3Rpb24gMiwgd2hpY2ggYXJlIHNwZWxsZWQgd2l0aCBjYXBpdGFsIGZpcnN0IGxl dHRlcnMgaG93ZXZlciwgd2hlbiB1c2VkIGluIHRoZSB0ZXh0IGFmdGVyIHNlY3Rpb24gMiwNCiBh IG51bWJlciBvZiBpbnN0YW5jZXMgZG8gbm8gdXNlIHRoZSBzYW1lIHN0eWxlIGFuZCBzaG91bGQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207 bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tbGVmdDozNi4wcHQ7bWFy Z2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50Oi0xOC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4z Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjoj Nzc3Nzc3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM3Nzc3Nzc7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlNlY3Rpb24gMiwgaW4gdGhlIElu dmFsaWQgTG9jYXRpb24gZGVmaW5pdGlvbiwgdGhlIHRlcm0gbG9jYXRpb25JbnZhbGlkIGlzIHVz ZWQgaG93ZXZlciwgdGhlcmUgaXMgbm8gZGVmaW5lZCBlbGVtZW50IGluIGhlcmUgb3IgYW55d2hl cmUNCiBlbHNlLiBXYXMgdGhhdCBzdXBwb3NlIHRvIHJlZmVyIHRvIGxvc3QtcGxhbm5lZC1jaGFu Z2VzICZsdDtsb2NhdGlvbkludmFsaWRhdGVkJmd0Oz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1i b3R0b206MGNtO21hcmdpbi1sZWZ0OjM2LjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQ7dGV4dC1p bmRlbnQ6LTE4LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3 Nzc7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiM3Nzc3Nzc7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3Nzttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+U2VjdGlvbiAyLCB0aGUgU2ltaWxhciBMb2NhdGlvbiBkZWZpbml0aW9uIHNh eXMg4oCcQSBzdWdnZXN0ZWQgY2l2aWMgbG9jYXRpb24gdGhhdCBpcyBjb21wYXJhdGl2ZWx5IGNs b3NlIHRvIHRoZSBjaXZpYyBsb2NhdGlvbiB3aGljaA0KIHdhcyBpbnB1dOKAnS4gQ29tcGFyaW5n IHdoYXQ/IEdlb2dyYXBoaWMgcHJveGltaXR5LCBzZW1hbnRpY2FsbHkgY2xvc2UsIGVsc2U/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFy Z2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tbGVmdDozNi4wcHQ7bWFyZ2lu LWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50Oi0xOC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj41Ljwv c3Bhbj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojNzc3 Nzc3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3 Nzc3Nzc7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkZvciBjb21wbGV0ZW5lc3MsIGl0IHdv dWxkIGJlIG5pY2UgdG8gaW5jbHVkZSB0aGUg4oCYc2ltaWxhckxvY2F0aW9uc0xpbWl0ZWTigJkg YXR0cmlidXRlIGluIHRoZSBleGFtcGxlICZsdDtmaW5kU2VydmljZVJlc3BvbnNlJmd0OyBpbiBz ZWN0aW9uDQogNS4yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWxl ZnQ6MzYuMHB0O21hcmdpbi1ib3R0b206LjAwMDFwdDt0ZXh0LWluZGVudDotMTguMHB0Ij4NCjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3Nzttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+Ni48L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 Ny4wcHQ7Y29sb3I6Izc3Nzc3Nzttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojNzc3Nzc3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGVyZSBh cmUgdHdvIGVycm9ycyBpbiB0aGUgWE1MIHNjaGVtYSBpbiBzZWN0aW9uIDY6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0 OjBjbTttYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tbGVmdDo3Mi4wcHQ7bWFyZ2luLWJvdHRvbTou MDAwMXB0O3RleHQtaW5kZW50Oi0xOC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojNzc3Nzc3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5hLjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojNzc3Nzc3O21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3Nzc7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPnhtbG5zPSZxdW90O3VybjppZXRmOnBhcmFtczp4bWw6 bnM6bG9zdC1ybGkxw6Igc2hvdWxkIGJlIHhtbG5zPSZxdW90O3VybjppZXRmOnBhcmFtczp4bWw6 bnM6bG9zdC1ybGkxJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjBjbTttYXJn aW4tbGVmdDo3Mi4wcHQ7bWFyZ2luLWJvdHRvbTouMDAwMXB0O3RleHQtaW5kZW50Oi0xOC4wcHQi Pg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3O21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5iLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtjb2xvcjojNzc3Nzc3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3Nzc7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZs dDt4czptaW5JbmNsdXNpdmUgdmFsdWU9JnF1b3Q7MSZxdW90OyZndDsgc2hvdWxkIGJlICZsdDt4 czptaW5JbmNsdXNpdmUgdmFsdWU9JnF1b3Q7MSZxdW90Oy8mZ3Q7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTtt YXJnaW4tYm90dG9tOjBjbTttYXJnaW4tbGVmdDozNi4wcHQ7bWFyZ2luLWJvdHRvbTouMDAwMXB0 O3RleHQtaW5kZW50Oi0xOC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNzc3Nzc3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj43Ljwvc3Bhbj48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojNzc3Nzc3O21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3Nzc7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZSByZWZlcmVuY2UgdG8gcGxhbm5lZC1jaGFuZ2VzIGluIHNl Y3Rpb24gOS4xIHNob3VsZCBiZSB1cGRhdGVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM3Nzc3Nzc7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0 b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3O21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5J4oCZbSB0cnlpbmcgdG8gYXR0YWNoIGEgTVNXb3Jk IHZlcnNpb24gd2l0aCB0cmFjay1jaGFuZ2UgaGVyZSB0aGF0IGluY2x1ZGVzIHJlc29sdXRpb25z IHRvIDIgYW5kDQogNSwgd2l0aCBhZGRpdGlvbmFsIHByb3Bvc2VkIGVkaXRvcmlhbCBhbmQgbm9u LXN1YnRhdGl2ZSBjaGFuZ2VzLiBJZiBpdCBkb2VzIG5vdCBwYXNzIHRoZSBtYWlsIHNlcnZlciwg SSB3aWxsIHNlbmQgZGlyZWN0bHkgdG8gdGhlIGF1dGhvcnMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3Nzc7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21h cmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj Nzc3Nzc3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3Bh biBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3Nzc7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojNzc3Nzc3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5HdXk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjNzc3Nzc3IDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQ7bWFyZ2luLWxlZnQ6MGNtO21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjMuNzVwdCI+DQo8cD48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6Izc3Nzc3NyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpFY3JpdCBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOkVj cml0QGlldGYub3JnIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkVjcml0QGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6Izc3Nzc3NyI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0PC9zcGFuPjwvYT48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6Izc3Nzc3NyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5 bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249 ImNlbnRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzdHJvbmc+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj5FeHRlcm5hbCBFbWFpbDo8L3NwYW4+ PC9pPjwvc3Ryb25nPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUi PiBQbGVhc2UgdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxpbmtzIGFuZCBhdHRhY2htZW50cyAv DQo8L3NwYW4+PC9lbT48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29s b3I6Ymx1ZSI+Q291cnJpZWwgZXh0ZXJuZTo8L3NwYW4+PC9pPjwvc3Ryb25nPjxlbT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPiBTb3lleiBwcnVkZW50IGF2ZWMgbGVz IGxpZW5zIGV0IGRvY3VtZW50cyBqb2ludHMNCjwvc3Bhbj48L2VtPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_c0503e0fee414892b6fb2dfa0cfd839dbellca_-- From nobody Tue Aug 31 13:38:51 2021 Return-Path: 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 854F13A0AB9 for ; Tue, 31 Aug 2021 13:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=bell.ca 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 6VBf522cjZO8 for ; Tue, 31 Aug 2021 13:38:42 -0700 (PDT) Received: from ESA4-Dor.bell.ca (esa4-dor.bell.ca [204.101.223.61]) (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 4E4673A0AB7 for ; Tue, 31 Aug 2021 13:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1630442322; x=1661978322; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=ghnf1NX4HqLluJbut9+RpHs+nWbsZJUDRnLfcG1sJQI=; b=VWN5EYg/0XeLyX0SB8PxX5b2ghBhtB3LxhPfL55wXx8062fnwu/lIYE6 bFMiLBGw4slOgXF34mJlmNplb5PBTS9Y2lJo1RGmnIzstirLOS+sev8Sm H3Tha3/CyUSgdiHeejm7iLRDWpa7S80gyRolM1fteZNlQouFu9Nw+K48z uut2TBLGzdklsU+lf6wko6srM+G793m7ORgRfu04+xI6jc+5rYGgHRvlB 3VsfMjqH7+amvPy9X/cWZF6DKEo/UmfAYwD5cPOV8Wj8yptfYYFQMvWyl TrE7OAFUyZkKHO7CaolILwLvldISJqv7iIb3qkO41aNuxrzyhFuiPIxk7 Q==; IronPort-SDR: +lwwKba8gLCoSL7f3BzeLMQEX01K9JUMrPsyK7boNIECwZB1Yi/guPPWhHxxfJsGhQsDD/oEHJ yGFnrWgLfxFQ== Received: from dc5cmz-d01.bellca.int.bell.ca (HELO DG4MBX04-WYN.bell.corp.bce.ca) ([198.235.121.232]) by esa04corp-dor.bell.corp.bce.ca with ESMTP; 31 Aug 2021 16:38:40 -0400 Received: from DG12MBX04-WYN.bell.corp.bce.ca (142.182.18.49) by DG4MBX04-WYN.bell.corp.bce.ca (142.182.18.30) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Tue, 31 Aug 2021 16:38:40 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX04-WYN.bell.corp.bce.ca (142.182.18.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Tue, 31 Aug 2021 16:38:40 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Tue, 31 Aug 2021 16:38:40 -0400 From: "Caron, Guy" To: Brian Rosen , Randall Gellens CC: ECRIT Thread-Topic: [EXT]Re: [Ecrit] planned-changes: two questions Thread-Index: AQHXnbLZ8xDlKKXTXU23cWH8anqQbauNeTZQgABQ14D//8deMIAAkTMAgAACPYCAAAUMgIAAEX0AgAAK0gD//83iAA== Date: Tue, 31 Aug 2021 20:38:39 +0000 Message-ID: <851c82ef56714b8a917761d98234093a@bell.ca> References: <5577e2e6daa4405bbe12ef61675e1f55@bell.ca> <3AD58DEC-1DC9-4BC0-B55C-4E782E4AAA74@brianrosen.net> <9433989A-85D7-41B9-96EA-313ADC0F02CD@brianrosen.net> In-Reply-To: <9433989A-85D7-41B9-96EA-313ADC0F02CD@brianrosen.net> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.112.70] Content-Type: multipart/alternative; boundary="_000_851c82ef56714b8a917761d98234093abellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] planned-changes: two questions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 20:38:50 -0000 --_000_851c82ef56714b8a917761d98234093abellca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgd2UgbWFrZSA8cmV2YWxpZGF0ZUxvY2F0aW9uPiBhIGxpc3Qgb2YgSURzLCBvbmUgbm90aWZp Y2F0aW9uIHBlciBVUkkgcGVyIHBsYW5uZWQgY2hhbmdlIHdvdWxkIGJlIHN1ZmZpY2llbnQuDQoN Ckd1eQ0KDQpEZSA6IEJyaWFuIFJvc2VuIDxickBicmlhbnJvc2VuLm5ldD4NCkVudm95w6kgOiAz MSBhb8O7dCAyMDIxIDE1OjM1DQrDgCA6IFJhbmRhbGwgR2VsbGVucyA8cmcraWV0ZkByYW5keS5w ZW5zaXZlLm9yZz4NCkNjIDogQ2Fyb24sIEd1eSA8Zy5jYXJvbkBiZWxsLmNhPjsgRUNSSVQgPGVj cml0QGlldGYub3JnPg0KT2JqZXQgOiBbRVhUXVJlOiBbRWNyaXRdIHBsYW5uZWQtY2hhbmdlczog dHdvIHF1ZXN0aW9ucw0KDQpOby4NCg0KVGhlcmUgaXMgb25lIFVSSSwgYnV0IG1hbnkgSURzLCBv bmUgcGVyIHVuaXF1ZSByZWNvcmQgYXQgdGhlIExvU1Qgc2VydmVyIHRoYXQgaXMgaW52b2x2ZWQg aW4gYSBwbGFubmVkIGNoYW5nZS4gIFRoZSBvbmUgVVJJIHdpbGwgcmVjZWl2ZSBvbmUgbm90aWZp Y2F0aW9uIHBlciBJRCBpdCBoYXMgcmVnaXN0ZXJlZCBmb3IuDQoNCg0KDQoNCk9uIEF1ZyAzMSwg MjAyMSwgYXQgMjo1NiBQTSwgUmFuZGFsbCBHZWxsZW5zIDxyZytpZXRmQHJhbmR5LnBlbnNpdmUu b3JnPG1haWx0bzpyZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnPj4gd3JvdGU6DQoNCmkgdW5kZXJz dGFuZCB0aGF0IHRoZSBjb25jZXJuIGlzIGFsbG93aW5nIGEgY2xpZW50IHRvIGxldmVyYWdlIHRo ZSBMb1NUIHNlcnZlciB0byBhdHRhY2sgYSBsYXJnZSBudW1iZXIgb2YgdGFyZ2V0cywgSSdtIGp1 c3Qgbm90IGNsZWFyIG1lY2hhbmljYWxseSBob3cgc3VjaCBsZXZlcmFnZSBwb3RlbnRpYWxseSB3 b3Jrcy4gRWFjaCB2YWxpZGF0aW9uIHF1ZXJ5IGNhbiBzdG9yZSBhIFVSSSwgYW5kIHRoYXQgVVJJ IG1heSBnZXQgYXNzb2NpYXRlZCB3aXRoIGEgbGFyZ2UgbnVtYmVyIG9mIGxvY2F0aW9ucy4gTWF5 YmUgdGhlcmUncyBhIHN0cmVldCBuYW1lIGNoYW5nZSBvciBhbiBhbm5leGF0aW9uLiBTbyBtYXli ZSB0aG91c2FuZHMgb3IgdGVucyBvciBodW5kcmVkcyBvZiB0aG91c2FuZHMgb2YgbG9jYXRpb25z IGFyZSBwb3RlbnRpYWxseSBpbnZhbGlkYXRlZC4gVGhleSBhbGwgaGF2ZSB0aGUgc2FtZSBVUkkg YXNzb2NpYXRlZCB3aXRoIHRoZW0sIHNvIHRoZSBMb1NUIHNlcnZlciBjb25uZWN0cyB0byB0aGUg VVJJIG9uY2UgYW5kIFBPU1RzIG9uZSBub3RpZmljYXRpb24sIG5vPw0KLS1SYW5kYWxsDQpPbiAz MSBBdWcgMjAyMSwgYXQgMTA6NTMsIEJyaWFuIFJvc2VuIHdyb3RlOg0KT2YgY291cnNlIGFuIGF0 dGFja2VyIHdvdWxkIGNvbmNlYWwgaXRzZWxmIGFuZCByZWdpc3RlciBtdWx0aXBsZSBVUklzIHVu ZGVyIGRpZmZlcmVudCBpZGVudGl0aWVzLiAgQnV0IHRoZSBiaWdnZXIgIHByb2JsZW0gaXMgdGhh dCBpZiBhIGxhcmdlIHBsYW5uZWQgY2hhbmdlIG9jY3VycmVkLCB0aGUgdmljdGltIGNvdWxkIHJl Y2VpdmUgYSBsYXJnZSBudW1iZXIgb2Ygbm90aWZpY2F0aW9ucyBpdCBkaWRu4oCZdCBleHBlY3Qu DQoNCldpdGggYSB0ZXN0IHRyYW5zaXRpb24sIHdlIGtub3cgdGhhdCB0aGUgY2xpZW50IGV4cGVj dHMgdG8gc2VlIG5vdGlmaWNhdGlvbnMsIHdlIG9ubHkgbmVlZCBvbmUgcGVyIFVSSSAod2UgY291 bGQgc3BlY2lmeSBvbmUgcGVyIGRvbWFpbiDigJQgYWZ0ZXIgdGhlIHNjaGVtZSBhbmQgYmVmb3Jl IHRoZSBmaXJzdCBzbGFzaCkuICBJZiB3ZSBkb27igJl0IGdldCB0aGUgSUQsIHdlIGtub3cgbm90 IHRvIGFsbG93IHRoYXQgVVJJIHRvIGJlIHByb3Zpc2lvbmVkLiAgU28gaXTigJlzIG9uZSB0ZXN0 IHRyYW5zYWN0aW9uIHZzIGEgbGFyZ2UgbnVtYmVyIG9mIHBsYW5uZWQgY2hhbmdlIHRyYW5zYWN0 aW9ucy4NCg0KQnJpYW4NCg0KDQoNCk9uIEF1ZyAzMSwgMjAyMSwgYXQgMTozNSBQTSwgUmFuZGFs bCBHZWxsZW5zIDxyZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnPG1haWx0bzpyZytpZXRmQHJhbmR5 LnBlbnNpdmUub3JnPj4gd3JvdGU6DQoNCklmIGEgbWFsaWNpb3VzIGNsaWVudCByZWdpc3RlcnMg YSBVUkkgdGhhdCBpcyBkZXNpZ25lZCB0byBhdHRhY2sgYSB0aGlyZCBzaXRlLCB0aGUgdGVzdCB0 cmFuc2FjdGlvbiBjYXVzZXMgdGhlIExvU1Qgc2VydmVyIHRvIGNvbm5lY3QgdG8gaXQgYW5kIFBP U1QgYSBjb21tYW5kLiBXaXRob3V0IGEgdGVzdCB0cmFuc2FjdGlvbiwgdGhlIExvU1Qgc2VydmVy IHN0b3JlcyB0aGUgVVJJIGFuZCBhdCBhIGZ1dHVyZSB0aW1lIGNvbm5lY3RzIHRvIGl0IGFuZCBz ZW5kcyBhIGNvbW1hbmQuIEVpdGhlciB3YXksIGEgTG9TVCBjbGllbnQgY2FuIHJlZ2lzdGVyIHBv dGVudGlhbGx5IG9uZSBVUkkgcGVyIHF1ZXJpZWQgbG9jYXRpb24sIGFuZCBhIExvU1Qgc2VydmVy IHdpbGwgY29ubmVjdCB0byB0aGF0IFVSSSBhbmQgUE9TVCBhIG1lc3NhZ2UuIEEgcXVlcmllZCBs b2NhdGlvbiBjb3VsZCBiZSB0aWVkIHRvIG1hbnkgb3RoZXIgbG9jYXRpb25zLCBzbyB0aGVyZSBj b3VsZCBiZSBtYW55IGxvY2F0aW9ucyBmb3Igd2hpY2ggYSBjaGFuZ2Ugd291bGQgdHJpZ2dlciB0 aGUgTG9TVCBzZXJ2ZXIgdG8gdXNlIHRoZSBVUkksIGJ1dCBpcyB0aGF0IHdvcnNlPw0KLS1SYW5k YWxsDQpPbiAzMSBBdWcgMjAyMSwgYXQgMTA6MjcsIEJyaWFuIFJvc2VuIHdyb3RlOg0KSWYgdGhl IHdvcmsgZ3JvdXAgd2FudHMgdG8gaGF2ZSB0aGUgTG9TVCBzZXJ2ZXIga2VlcCB0aGUgVVJJIHVu dGlsIGV4cHJlc3NseSBkZWxldGVkLCB0aGF04oCZcyBva2F5IHdpdGggbWUuDQoNCkF1dGhlbnRp Y2F0aW5nIHRoZSBjbGllbnQgdG8gdGhlIHNlcnZlciBkb2VzbuKAmXQgbWVhbiB0aGUgVVJJIGlz IGF1dGhlbnRpY2F0ZWQuICBXZSBjYW7igJl0IHJlc3RyaWN0IHRoZSBVUkkgdG8gYmUgdGhlIHNh bWUgZW50aXR5IGFzIHRoZSBjbGllbnQgcnVubmluZyB0aGUgTG9TVCB0cmFuc2FjdGlvbi4gIEFu ZCB0aGUgY2xpZW50cyBhcmUgd2lkZSByYW5naW5nLiAgQ291bGQgYmUgYW4gZW50ZXJwcmlzZSBy dW5uaW5nIGl0cyBvd24gTElTIGZvciBleGFtcGxlLiAgV2UgY2Fu4oCZdCBhc3N1bWUgdGhlIE5v cnRoIEFtZXJpY2FuIFBLSSBpcyB3b3JrYWJsZSBldmVyeXdoZXJlLCBhbmQgZXZlbiB0aGF0IGRv ZXNu4oCZdCBleHRlbmQgdG8gYW4gZW50ZXJwcmlzZSBMSVMuICBJU1RNIHdlIGhhdmUgdG8gcnVu IGEgdGVzdCB0cmFuc2FjdGlvbiB3aXRoIHRoZSBub3RpZmljYXRpb24gc2VydmljZSB0byBtYWtl IHN1cmUgaXTigJlzIHdoYXQgd2UgdGhpbmsgaXQgaXMuDQoNCkJyaWFuDQoNCg0KDQoNCk9uIEF1 ZyAzMSwgMjAyMSwgYXQgOTowMSBBTSwgQ2Fyb24sIEd1eSA8Zy5jYXJvbkBiZWxsLmNhPG1haWx0 bzpnLmNhcm9uQGJlbGwuY2E+PiB3cm90ZToNCg0KSW5saW5lLg0KDQpHdXkNCg0KLS0tLS1NZXNz YWdlIGQnb3JpZ2luZS0tLS0tDQpEZSA6IEJyaWFuIFJvc2VuIDxickBicmlhbnJvc2VuLm5ldDxt YWlsdG86YnJAYnJpYW5yb3Nlbi5uZXQ+Pg0KRW52b3nDqSA6IDMxIGFvw7t0IDIwMjEgMDg6MTEN CsOAIDogQ2Fyb24sIEd1eSA8Zy5jYXJvbkBiZWxsLmNhPG1haWx0bzpnLmNhcm9uQGJlbGwuY2E+ Pg0KQ2MgOiBSYW5kYWxsIEdlbGxlbnMgPHJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmc8bWFpbHRv OnJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmc+PjsgRUNSSVQgPGVjcml0QGlldGYub3JnPG1haWx0 bzplY3JpdEBpZXRmLm9yZz4+DQpPYmpldCA6IFtFWFRdUmU6IFtFY3JpdF0gcGxhbm5lZC1jaGFu Z2VzOiB0d28gcXVlc3Rpb25zDQoNCllvdSBkZWxldGUgdGhlIFVSSSB3aGVuIHlvdSBkZWxldGUg dGhlIHJlY29yZCBpbiB0aGUgTElTLg0KW0dDXSBUaGF0J3MgZmluZSBidXQgdGhhdCB3YXMgbm90 IHRoZSBxdWVzdGlvbiBSYW5kYWxsIHBvc2VkLiBIZSBhc2tlZCB3aGV0aGVyIHRoZSBVUkkgaXMg ZGVsZXRlZCBhZnRlciBhIG5vdGlmaWNhdGlvbi4gSSBhZ3JlZSB0aGF0IGlmIHRoZSBDbGllbnQg ZG9lcyBub3QgaG9zdCB0aGUgbG9jYXRpb24gYW55bW9yZSB0aGF0IHRoZSBVUkkgYXNzb2NpYXRl ZCB3aXRoIHRoYXQgbG9jYXRpb24gaW4gdGhlIFNlcnZlciBzaG91bGQgYmUgZGVsZXRlZC4gVGhp cyBjb3VsZCBiZSBhY2hpZXZlZCB3aXRoIGFuIGVtcHR5IDxwbGFubmVkQ2hhbmdlPi4NCg0KSSBk b27igJl0IHRoaW5rIHRoaXMgaXMgY292ZXJlZCBpbiA1MjIyLiAgVGhlIG1lY2hhbmlzbSBjYXVz ZXMgdGhlIExvU1Qgc2VydmVyIHRvIHNlbmQgbm90aWZpY2F0aW9ucyB0byB0aGUgY2xpZW50LCBi dXQgdGhlIGNsaWVudCBpcyBhbGxvd2VkIHRvIHB1dCBhbnkgVVJJIGluIHRoZSByZWNvcmQsIGFu ZCBpdCBjYW4gYWRkIGl0IHRvIGFzIG1hbnkgcmVjb3JkcyBhcyBpdCB3YW50cy4NCltHQ10gSSB0 aG91Z2h0IHdlIGFncmVlZCBvbiB1c2luZyBvbmUgZ2VuZXJpYyBVUkkgcGVyIENsaWVudC4gQ2xp ZW50cyBzaG91bGQgYmUgYXV0aGVudGljYXRlZCBieSB0aGUgU2VydmVycy4NCiBBbiBldmlsIGlt cGxlbWVudGF0aW9uIGNvdWxkIHJlY29yZCBVUklzIGFnYWluc3QgbXVsdGlwbGUgdGFyZ2V0cyB0 aGF0IHdlcmUgdW5hd2FyZSB0aGF0IHRoZSBldmlsIGltcGxlbWVudGF0aW9uIGRpZCBpdCwgdW50 aWwgdGhleSBnb3QgYSBsYXJnZSBudW1iZXIgb2YgUFVTSCB0cmFuc2FjdGlvbnMgdGhleSBkaWRu 4oCZdCBleHBlY3Qgb3IgdW5kZXJzdGFuZCBhcyBhIHJlc3VsdCBvZiBhIGxhcmdlIHBsYW5uZWQg Y2hhbmdlLg0KW0dDXSBPbmx5IGF1dGhlbnRpY2F0ZWQgQ2xpZW50cyBzaG91bGQgYmUgYWxsb3dl ZCB0byBwcm92aWRlIFVSSXMgdG8gYmUgc3RvcmVkIGJ5IHRoZSBTZXJ2ZXJzLg0KDQpUaGUgcHJv cG9zZWQgbWVjaGFuaXNtIHF1YWxpZmllcyB0aGUgY2xpZW50IFVSSSBiZWZvcmUgaXRzIHVzZWQg aW4gYSBwbGFubmVkIGNoYW5nZS4NCg0KQnJpYW4NCg0KDQpPbiBBdWcgMzEsIDIwMjEsIGF0IDc6 MzcgQU0sIENhcm9uLCBHdXkgPGcuY2Fyb25AYmVsbC5jYTxtYWlsdG86Zy5jYXJvbkBiZWxsLmNh Pj4gd3JvdGU6DQoNCldlbGwsIHRoaXMgaXMgbm90IGdvaW5nIGluIHRoZSBkaXJlY3Rpb24gSSB0 aG91Z2h0Lg0KDQpXaGF0IGlzIHRoZSBwdXJwb3NlIG9mIGRlbGV0aW5nIHRoZSBVUklzIGF0IHRo ZSBTZXJ2ZXIgcG9zdC12YWxpZGF0aW9uPw0KDQpSZWdhcmRpbmcgb3BlbmluZyBhIG5ldyBEb1Ms IEkgZ3Vlc3MgSSdtIG5vdCBmb2xsb3dpbmcuIFdvdWxkbid0IHRoaXMgY2FzZSBiZSBjb3ZlcmVk IGJ5IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpbiBSRkMgNTIyMj8NCg0KV2hhdCB5b3Un cmUgcHJvcG9zaW5nIHB1dHMgYmFjayBzaWduaWZpY2FudCBsb2FkIG9uIHRoZSBTZXJ2ZXJzIChh IGtleSBjb25zaWRlcmF0aW9uIGZvciBjcmVhdGluZyBwbGFubmVkLWNoYW5nZXMgaW4gdGhlIGZp cnN0IHBsYWNlKSBhbmQgY29tcGxpY2F0ZXMgdGhlIG1lY2hhbmlzbS4NCg0KR3V5DQoNCg0KLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZSA6IEVjcml0IDxlY3JpdC1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnPj4gRGUgbGEgcGFydCBkZSBCcmlhbiBS b3NlbiBFbnZvecOpIDoNCjMwIGFvw7t0IDIwMjEgMTE6MjIgw4AgOiBSYW5kYWxsIEdlbGxlbnMg PHJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmc8bWFpbHRvOnJnK2lldGZAcmFuZHkucGVuc2l2ZS5v cmc+PiBDYw0KOiBFQ1JJVCA8ZWNyaXRAaWV0Zi5vcmc8bWFpbHRvOmVjcml0QGlldGYub3JnPj4g T2JqZXQgOiBbRVhUXVJlOiBbRWNyaXRdIHBsYW5uZWQtY2hhbmdlczogdHdvDQpxdWVzdGlvbnMN Cg0KQW5zd2VyIDE6IHllcy4gIFNpbmNlIHRoZXJlIGlzIGdvaW5nIHRvIGJlIGEgcmV2YWxpZGF0 aW9uLCBqdXN0IGRlbGV0aW5nIHRoZSBzZXR0aW5nIHNlZW1zIHJpZ2h0IHRvIG1lLg0KQW5zd2Vy IDI6IFVwIHRvIHNlcnZlci4gIElmIEkgd2VyZSBpbXBsZW1lbnRpbmcsIEkgd291bGQgaGFzaCB0 aGUgcmVhbCBJRCB3aXRoIHRoZSBVUkkgYW5kIHNvbWUga2luZCBvZiBwcmVkaWN0YWJsZSBub25j ZS4NCg0KV2UgcHJvYmFibHkgaGF2ZSB0byBzYXkgbW9yZSBhYm91dCBob3cgdGhlIHNlcnZlciBp ZGVudGlmaWVzIHRoZSBjbGllbnQsIHNvIHRoYXQgcmVwbGFjZW1lbnQgb2YgdGhlIFVSSSB3b3Jr cy4gIENvdWxkIHdlIHNheSB3ZSB1c2UgdGhlIGRvbWFpbiBvZiB0aGUgVVJJICh0aGUgZW50aXJl IGRvbWFpbiB3aXRoIGFsbCB0aGUgZG90cykgdG8gaWRlbnRpZnkgdGhlIGNsaWVudCwgYW5kIGFu eXRoaW5nIGNhbiBvY2N1ciBhZnRlciBpdCAobWVhbmluZyBhIHNsYXNoIGFuZCB3aGF0ZXZlcik/ ICBJZiB3ZSBkbyB0aGF0LCB0aGVuIGhvdyB3b3VsZCBkZWxldGUgdGhlIG5vdGlmaWNhdGlvbj8g IEZvcmNlIHRoZXJlIHRvIGJlIHNvbWV0aGluZyBvdGhlciB0aGFuIHRoZSBkb21haW4gKHVnbHkp LiAgRXhwbGljaXQgZGVsZXRlIHJlcXVlc3Q/DQoNCkhtbW0sIHdl4oCZdmUgb3BlbmVkIGEgRG9T IGF0dGFjazogYSByb2d1ZSBjbGllbnQgc3RvcmVzIGEgYnVuY2ggb2YgVVJJcyBmb3Igc2VydmVy cyBpdCB3YW50cyB0byB2aWN0aW1pemUuICBJbiBOb3J0aCBBbWVyaWNhIHdlIGhhdmUgYSByZWFs IHNpbXBsZSBzb2x1dGlvbiBmb3IgdGhhdCwgYmVjYXVzZSB3ZSBoYXZlIGEgUEtJLCBzbyB3ZSBr bm93LCBmb3Igc3VyZSwgd2hvIHRoZSBjbGllbnQgaXMsIGFuZCBjb3VsZCByZXN0cmljdCB3aG8g d2UgYWxsb3cgdG8gc3RvcmUgVVJJcywgYnV0IHRoYXQgd291bGRu4oCZdCBiZSB0cnVlIGluIGdl bmVyYWwuICBBbHNvLCBpdCB3b3VsZCBiZSBuaWNlIGZvciB0aGUgY2xpZW50IHRvIGhhdmUgY29u ZmlkZW5jZSB0aGUgbWVjaGFuaXNtIHdvcmtlZCBiZWZvcmUgaXQgbmVlZGVkIGl0Lg0KDQpTbw0K TGV04oCZcyBhZGQgYSDigJxjb21tYW5k4oCdIHRvIHBsYW5uZWRDaGFuZ2UgaW4gdGhlIGZpbmRT ZXJ2aWNlIHJlcXVlc3QuDQpBbmQsIGhhdmUgdGhlIGNsaWVudCBoYXZlIGEgcmVzcG9uc2UgdG8g dGhlIG5vdGlmaWNhdGlvbiB3aGljaCBpcyB0aGUNCklEIChqc29uIHdpdGggdGhlIDIwMCkNCg0K DQpUaGUgY2xpZW50IHN0YXJ0cyBieSBzZW5kaW5nIGEgY29tbWFuZCBvZiDigJxpbml0aWFsaXpl 4oCdLiAgVGhlIGRvbWFpbiBpcyB0aGUgaWRlbnRpdHkgb2YgdGhlIGNsaWVudC4gIFRoZSByZXNw b25zZSBpcyBhbiBpbW1lZGlhdGUgbm90aWZpY2F0aW9uIHRvIHRoZSB3aXRoIHdoYXRldmVyIExJ IHdhcyBpbiB0aGUgcmVxdWVzdCBhbmQgYW4gSUQuICBUaGUgIHJlc3BvbnNlIGJ5IHRoZSBjbGll bnQgKHdoaWNoIGlzIHRoZSBub3RpZmljYXRpb24gd2ViIHNlcnZlcikgaXMgYSBwaWVjZSBvZiBq c29uIGNvbnRhaW5pbmcgdGhlIElELiAgV2UgY2FuIHNheSB0aGF0IHRoZSBMSSBpbiB0aGlzIGlu aXRpYWxpemUgY29tbWFuZCBjb3VsZCBiZSBzb21ldGhpbmcgc2ltcGxlIGxpa2UgdGhlIENvdW50 cnkgQ29kZSB0aGF0IHdvdWxkbuKAmXQgZ2V0IGEgcGxhbm5lZCBjaGFuZ2UuDQoNClRoZXJlYWZ0 ZXIsIHRoZSBMb1NUIHNlcnZlciAobm90aWZpY2F0aW9uIGNsaWVudCkgcGVyaW9kaWNhbGx5IHJl cGVhdHMgdGhpcyBrZWVwYWxpdmUgbm90aWZpY2F0aW9uIGV2ZXJ5IGRheSBvciB3ZWVrIHdpdGgg dGhlIGluaXRpYWxpemUgTEkuICBUaGUgY2xpZW50IGhhcyB0byByZXNwb25kIHdpdGggdGhlIElE Lg0KDQpUaGUgcmVndWxhciBub3RpZmljYXRpb24gcmVxdWVzdCBpcyBhIGNvbW1hbmQgb2Yg4oCc bm90aWZ54oCdLiAgVGhlIHNlcnZlciBpZ25vcmVzIGEgcmVxdWVzdCBmb3Igbm90aWZpY2F0aW9u IGZyb20gYW4gdW5pbml0aWFsaXplZCBjbGllbnQuDQpUaGUgbm90aWZpY2F0aW9uIGNhbiBiZSBk ZWxldGVkIHdpdGggYSBjb21tYW5kIG9mIOKAnGRlbGV0ZeKAnS4gIElmIHlvdSBkZWxldGUgdGhl IGluaXRpYWxpemUgTEksIHRoZW4gdGhlIHNlcnZlciB3b27igJl0IHNlbmQgYW55IG1vcmUgbm90 aWZpY2F0aW9ucyB0byB0aGF0IGNsaWVudCBhbmQgZGVsZXRlcyBhbGwgVVJJcyBpdCB3YXMgc2F2 aW5nIGZvciB0aGF0IGNsaWVudC4gIFRoZSBjbGllbnQgd291bGQgaGF2ZSB0byByZS1pbml0aWFs aXplIHRvIHJlc2V0Lg0KDQpCcmlhbg0KDQoNCk9uIEF1ZyAyNywgMjAyMSwgYXQgNTo0MSBQTSwg UmFuZGFsbCBHZWxsZW5zIDxyZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnPG1haWx0bzpyZytpZXRm QHJhbmR5LnBlbnNpdmUub3JnPj4gd3JvdGU6DQoNCkkgdGhpbmsgd2UncmUgbW92aW5nIHRvIGEg bW9kZWwgd2hlcmU6DQotIEluIGEgcXVlcnksIGEgY2xpZW50IGNhbiByZXF1ZXN0IHRvIGJlIG5v dGlmaWVkIHdoZW4gdGhlIGxvY2F0aW9uDQpzaG91bGQgYmUgcmV2YWxpZGF0ZWQ7DQotIEluIHRo ZSByZXNwb25zZSwgdGhlIHNlcnZlciBwcm92aWRlcyBhbiBJRCB3aGljaCB0aGUgY2xpZW50DQph c3NvY2lhdGVzIHdpdGggdGhlIGxvY2F0aW9uIGl0IGp1c3QgdmFsaWRhdGVkOw0KLSBUaGUgc2Vy dmVyIHNlbmRzIGEgbm90aWZpY2F0aW9uIHRvIHRoZSBVUkksIGNvbnRhaW5pbmcgdGhlIElEOw0K LSBUaGUgY2xpZW50IHJldmFsaWRhdGVzIGVhY2ggbG9jYXRpb24gd2l0aCB3aGljaCB0aGF0IElE IGlzIGFzc29jaWF0ZWQuDQoNClF1ZXN0aW9uIDE6IERvZXMgdGhlIHNlcnZlciBkZWxldGUvaW5h Y3RpdmF0ZSB0aGUgVVJJIG9uY2UgaXQgaGFzIHNlbnQgdGhlIG5vdGlmaWNhdGlvbj8NCg0KUXVl c3Rpb24gMjogUHJlc3VtYWJseSwgd2hlbiB0aGUgY2xpZW50IHJldmFsaWRhdGVzIHRoZSBsb2Nh dGlvbihzKSwgaXQgd2lsbCBhZ2FpbiByZXF1ZXN0IG5vdGlmaWNhdGlvbi4gIERvZXMgdGhlIHNl cnZlciByZXR1cm4gdGhlIHNhbWUgSUQgYXMgYmVmb3JlLCBvciBhIGRpZmZlcmVudCBJRD8gIEEg ZGlmZmVyZW50IElEIGNvdWxkIHBlcmhhcHMgYmUgdXNlZnVsIGluIGVkZ2UgY2FzZXMgd2hlcmUg dGhlIHNlcnZlciBkaWRuJ3Qgc2VuZCBvciB0aGUgY2xpZW50IGRpZG4ndCBnZXQgdGhlIG5vdGlm aWNhdGlvbiwgYnV0IGFueSB1dGlsaXR5IHNlZW1zIHNtYWxsLiAgSWYgaXQncyB0aGUgc2FtZSBJ RCwgdGhlbiB0aGUgYW5zd2VyIHRvIHF1ZXN0aW9uIDEgY2FuIGJlIHRoYXQgdGhlIFVSSSByZW1h aW5zIGFjdGl2ZSB1bnRpbCB0aGUgY2xpZW50IGFza3MgdG8gbm8gbG9uZ2VyIGJlIG5vdGlmaWVk IChieSBzZW5kaW5nIGFuIGVtcHR5IFVSST8pLg0KDQotLVJhbmRhbGwNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkVjcml0IG1haWxpbmcgbGlzdA0K RWNyaXRAaWV0Zi5vcmc8bWFpbHRvOkVjcml0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KRWNyaXQgbWFpbGluZyBsaXN0DQpFY3JpdEBpZXRmLm9yZzxt YWlsdG86RWNyaXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2Vjcml0DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQotLS0tLS0tLSBFeHRlcm5hbCBFbWFpbDogUGxlYXNl IHVzZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQNCmF0dGFjaG1lbnRzIC8gQ291cnJp ZWwgZXh0ZXJuZTogU295ZXogcHJ1ZGVudCBhdmVjIGxlcyBsaWVucyBldA0KZG9jdW1lbnRzIGpv aW50cw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkV4dGVybmFsIEVtYWlsOiBQbGVhc2UgdXNl IGNhdXRpb24gd2hlbiBvcGVuaW5nIGxpbmtzIGFuZCBhdHRhY2htZW50cyAvIENvdXJyaWVsIGV4 dGVybmU6IFNveWV6IHBydWRlbnQgYXZlYyBsZXMgbGllbnMgZXQgZG9jdW1lbnRzIGpvaW50cw0K DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkV4dGVybmFsIEVtYWlsOiBQ bGVhc2UgdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxpbmtzIGFuZCBhdHRhY2htZW50cyAvIENv dXJyaWVsIGV4dGVybmU6IFNveWV6IHBydWRlbnQgYXZlYyBsZXMgbGllbnMgZXQgZG9jdW1lbnRz IGpvaW50cw0K --_000_851c82ef56714b8a917761d98234093abellca_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0K CXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFt ZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRlItQ0EiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SWYgd2Ug bWFrZSAmbHQ7cmV2YWxpZGF0ZUxvY2F0aW9uJmd0OyBhIGxpc3Qgb2YgSURzLCBvbmUgbm90aWZp Y2F0aW9uIHBlciBVUkkgcGVyIHBsYW5uZWQgY2hhbmdlIHdvdWxkIGJlIHN1ZmZpY2llbnQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPkd1eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5E ZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBCcmlhbiBS b3NlbiAmbHQ7YnJAYnJpYW5yb3Nlbi5uZXQmZ3Q7DQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7Ojwv Yj4gMzEgYW/Du3QgMjAyMSAxNTozNTxicj4NCjxiPsOAJm5ic3A7OjwvYj4gUmFuZGFsbCBHZWxs ZW5zICZsdDtyZyYjNDM7aWV0ZkByYW5keS5wZW5zaXZlLm9yZyZndDs8YnI+DQo8Yj5DYyZuYnNw Ozo8L2I+IENhcm9uLCBHdXkgJmx0O2cuY2Fyb25AYmVsbC5jYSZndDs7IEVDUklUICZsdDtlY3Jp dEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFtFWFRdUmU6IFtFY3JpdF0g cGxhbm5lZC1jaGFuZ2VzOiB0d28gcXVlc3Rpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1DQSI+Tm8uICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t Q0EiPlRoZXJlIGlzIG9uZSBVUkksIGJ1dCBtYW55IElEcywgb25lIHBlciB1bmlxdWUgcmVjb3Jk IGF0IHRoZSBMb1NUIHNlcnZlciB0aGF0IGlzIGludm9sdmVkIGluIGEgcGxhbm5lZCBjaGFuZ2Uu ICZuYnNwO1RoZSBvbmUgVVJJIHdpbGwgcmVjZWl2ZSBvbmUgbm90aWZpY2F0aW9uIHBlciBJRCBp dCBoYXMgcmVnaXN0ZXJlZCBmb3IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIj5PbiBBdWcgMzEsIDIwMjEsIGF0IDI6NTYgUE0sIFJhbmRhbGwgR2VsbGVucyAmbHQ7PC9z cGFuPjxhIGhyZWY9Im1haWx0bzpyZyYjNDM7aWV0ZkByYW5keS5wZW5zaXZlLm9yZyI+PHNwYW4g bGFuZz0iRU4tQ0EiPnJnJiM0MztpZXRmQHJhbmR5LnBlbnNpdmUub3JnPC9zcGFuPjwvYT48c3Bh biBsYW5nPSJFTi1DQSI+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPmkgdW5kZXJzdGFuZCB0aGF0IHRoZSBjb25jZXJuIGlzIGFsbG93 aW5nIGEgY2xpZW50IHRvIGxldmVyYWdlIHRoZSBMb1NUIHNlcnZlciB0byBhdHRhY2sgYSBsYXJn ZSBudW1iZXIgb2YgdGFyZ2V0cywgSSdtDQoganVzdCBub3QgY2xlYXIgbWVjaGFuaWNhbGx5IGhv dyBzdWNoIGxldmVyYWdlIHBvdGVudGlhbGx5IHdvcmtzLiBFYWNoIHZhbGlkYXRpb24gcXVlcnkg Y2FuIHN0b3JlIGEgVVJJLCBhbmQgdGhhdCBVUkkgbWF5IGdldCBhc3NvY2lhdGVkIHdpdGggYSBs YXJnZSBudW1iZXIgb2YgbG9jYXRpb25zLiBNYXliZSB0aGVyZSdzIGEgc3RyZWV0IG5hbWUgY2hh bmdlIG9yIGFuIGFubmV4YXRpb24uIFNvIG1heWJlIHRob3VzYW5kcyBvciB0ZW5zIG9yIGh1bmRy ZWRzDQogb2YgdGhvdXNhbmRzIG9mIGxvY2F0aW9ucyBhcmUgcG90ZW50aWFsbHkgaW52YWxpZGF0 ZWQuIFRoZXkgYWxsIGhhdmUgdGhlIHNhbWUgVVJJIGFzc29jaWF0ZWQgd2l0aCB0aGVtLCBzbyB0 aGUgTG9TVCBzZXJ2ZXIgY29ubmVjdHMgdG8gdGhlIFVSSSBvbmNlIGFuZCBQT1NUcyBvbmUgbm90 aWZpY2F0aW9uLCBubz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+LS1SYW5kYWxsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIDMxIEF1ZyAyMDIxLCBhdCAxMDo1MywgQnJpYW4g Um9zZW4gd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgIzc3Nzc3NyAxLjVwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDQuMHB0O21hcmdpbi1sZWZ0OjBjbTttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowY207bWFyZ2luLWJvdHRvbTozLjc1cHQiPg0KPGRpdiBpZD0iMkY0Mjc0MkMtNEY1 NS00RTI5LThCQjctMDA4Mjk2ODY2QTUxIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+T2YgY291cnNlIGFuIGF0dGFja2VyIHdvdWxkIGNvbmNl YWwgaXRzZWxmIGFuZCByZWdpc3RlciBtdWx0aXBsZSBVUklzIHVuZGVyIGRpZmZlcmVudCBpZGVu dGl0aWVzLiAmbmJzcDtCdXQgdGhlIGJpZ2dlciAmbmJzcDtwcm9ibGVtIGlzIHRoYXQgaWYgYSBs YXJnZSBwbGFubmVkIGNoYW5nZSBvY2N1cnJlZCwNCiB0aGUgdmljdGltIGNvdWxkIHJlY2VpdmUg YSBsYXJnZSBudW1iZXIgb2Ygbm90aWZpY2F0aW9ucyBpdCBkaWRu4oCZdCBleHBlY3QuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojNzc3Nzc3Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+V2l0aCBhIHRl c3QgdHJhbnNpdGlvbiwgd2Uga25vdyB0aGF0IHRoZSBjbGllbnQgZXhwZWN0cyB0byBzZWUgbm90 aWZpY2F0aW9ucywgd2Ugb25seSBuZWVkIG9uZSBwZXIgVVJJICh3ZSBjb3VsZCBzcGVjaWZ5IG9u ZSBwZXIgZG9tYWluIOKAlCBhZnRlciB0aGUgc2NoZW1lIGFuZCBiZWZvcmUNCiB0aGUgZmlyc3Qg c2xhc2gpLiAmbmJzcDtJZiB3ZSBkb27igJl0IGdldCB0aGUgSUQsIHdlIGtub3cgbm90IHRvIGFs bG93IHRoYXQgVVJJIHRvIGJlIHByb3Zpc2lvbmVkLiAmbmJzcDtTbyBpdOKAmXMgb25lIHRlc3Qg dHJhbnNhY3Rpb24gdnMgYSBsYXJnZSBudW1iZXIgb2YgcGxhbm5lZCBjaGFuZ2UgdHJhbnNhY3Rp b25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 Izc3Nzc3NyI+QnJpYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNzc3Nzc3Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+T24gQXVnIDMxLCAy MDIxLCBhdCAxOjM1IFBNLCBSYW5kYWxsIEdlbGxlbnMgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWls dG86cmcmIzQzO2lldGZAcmFuZHkucGVuc2l2ZS5vcmciPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+cmcmIzQzO2lldGZA cmFuZHkucGVuc2l2ZS5vcmc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij4mZ3Q7 DQogd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiM3Nzc3NzciPklmIGEgbWFsaWNpb3VzIGNsaWVudCByZWdpc3RlcnMgYSBV UkkgdGhhdCBpcyBkZXNpZ25lZCB0byBhdHRhY2sgYSB0aGlyZCBzaXRlLCB0aGUgdGVzdCB0cmFu c2FjdGlvbiBjYXVzZXMNCiB0aGUgTG9TVCBzZXJ2ZXIgdG8gY29ubmVjdCB0byBpdCBhbmQgUE9T VCBhIGNvbW1hbmQuIFdpdGhvdXQgYSB0ZXN0IHRyYW5zYWN0aW9uLCB0aGUgTG9TVCBzZXJ2ZXIg c3RvcmVzIHRoZSBVUkkgYW5kIGF0IGEgZnV0dXJlIHRpbWUgY29ubmVjdHMgdG8gaXQgYW5kIHNl bmRzIGEgY29tbWFuZC4gRWl0aGVyIHdheSwgYSBMb1NUIGNsaWVudCBjYW4gcmVnaXN0ZXIgcG90 ZW50aWFsbHkgb25lIFVSSSBwZXIgcXVlcmllZCBsb2NhdGlvbiwgYW5kIGENCiBMb1NUIHNlcnZl ciB3aWxsIGNvbm5lY3QgdG8gdGhhdCBVUkkgYW5kIFBPU1QgYSBtZXNzYWdlLiBBIHF1ZXJpZWQg bG9jYXRpb24gY291bGQgYmUgdGllZCB0byBtYW55IG90aGVyIGxvY2F0aW9ucywgc28gdGhlcmUg Y291bGQgYmUgbWFueSBsb2NhdGlvbnMgZm9yIHdoaWNoIGEgY2hhbmdlIHdvdWxkIHRyaWdnZXIg dGhlIExvU1Qgc2VydmVyIHRvIHVzZSB0aGUgVVJJLCBidXQgaXMgdGhhdCB3b3JzZT88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj Nzc3Nzc3Ij4tLVJhbmRhbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij5PbiAzMSBBdWcgMjAyMSwgYXQgMTA6Mjcs IEJyaWFuIFJvc2VuIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICM3Nzc3NzcgMS41cHQ7 cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdDttYXJnaW4tbGVmdDowY207bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206My43NXB0Ij4NCjxkaXYgaWQ9Ijg1MTY3 ODgyLTQ3MDctNERBNy1BRjA0LUQ3NkVERkEzRUMxRiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPklmIHRoZSB3b3JrIGdyb3VwIHdhbnRzIHRv IGhhdmUgdGhlIExvU1Qgc2VydmVyIGtlZXAgdGhlIFVSSSB1bnRpbCBleHByZXNzbHkgZGVsZXRl ZCwgdGhhdOKAmXMgb2theSB3aXRoIG1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiM3Nzc3NzciPkF1dGhlbnRpY2F0aW5nIHRoZSBjbGllbnQgdG8gdGhlIHNl cnZlciBkb2VzbuKAmXQgbWVhbiB0aGUgVVJJIGlzIGF1dGhlbnRpY2F0ZWQuICZuYnNwO1dlIGNh buKAmXQgcmVzdHJpY3QgdGhlIFVSSSB0byBiZSB0aGUgc2FtZSBlbnRpdHkgYXMgdGhlIGNsaWVu dCBydW5uaW5nIHRoZSBMb1NUIHRyYW5zYWN0aW9uLg0KICZuYnNwO0FuZCB0aGUgY2xpZW50cyBh cmUgd2lkZSByYW5naW5nLiAmbmJzcDtDb3VsZCBiZSBhbiBlbnRlcnByaXNlIHJ1bm5pbmcgaXRz IG93biBMSVMgZm9yIGV4YW1wbGUuICZuYnNwO1dlIGNhbuKAmXQgYXNzdW1lIHRoZSBOb3J0aCBB bWVyaWNhbiBQS0kgaXMgd29ya2FibGUgZXZlcnl3aGVyZSwgYW5kIGV2ZW4gdGhhdCBkb2VzbuKA mXQgZXh0ZW5kIHRvIGFuIGVudGVycHJpc2UgTElTLiAmbmJzcDtJU1RNIHdlIGhhdmUgdG8gcnVu IGEgdGVzdCB0cmFuc2FjdGlvbiB3aXRoIHRoZQ0KIG5vdGlmaWNhdGlvbiBzZXJ2aWNlIHRvIG1h a2Ugc3VyZSBpdOKAmXMgd2hhdCB3ZSB0aGluayBpdCBpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3 Nzc3NyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPkJyaWFuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM3Nzc3NzciPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNzc3Nzc3Ij5PbiBBdWcgMzEsIDIwMjEsIGF0IDk6MDEgQU0sIENhcm9uLCBHdXkgJmx0Ozwv c3Bhbj48YSBocmVmPSJtYWlsdG86Zy5jYXJvbkBiZWxsLmNhIj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPmcuY2Fyb25A YmVsbC5jYTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPiZndDsNCiB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNzc3Nzc3Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 Izc3Nzc3NyI+SW5saW5lLjxicj4NCjxicj4NCkd1eTxicj4NCjxicj4NCi0tLS0tTWVzc2FnZSBk J29yaWdpbmUtLS0tLTxicj4NCkRlJm5ic3A7OiBCcmlhbiBSb3NlbiAmbHQ7PC9zcGFuPjxhIGhy ZWY9Im1haWx0bzpickBicmlhbnJvc2VuLm5ldCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPmJyQGJyaWFucm9zZW4ubmV0PC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNzc3Nzc3Ij4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxicj4NCkVudm95w6kmbmJzcDs6IDMxIGFvw7t0IDIwMjEgMDg6MTE8 YnI+DQrDgCZuYnNwOzogQ2Fyb24sIEd1eSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpnLmNh cm9uQGJlbGwuY2EiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5nLmNhcm9uQGJlbGwu Y2E8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3Nzci PiZndDs8YnI+DQpDYyZuYnNwOzogUmFuZGFsbCBHZWxsZW5zICZsdDs8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOnJnJiM0MztpZXRmQHJhbmR5LnBlbnNpdmUub3JnIj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+cmcmIzQzO2lldGZAcmFuZHkucGVuc2l2ZS5vcmc8L3NwYW4+PC9hPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPiZndDs7DQogRUNSSVQgJmx0 Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZWNyaXRAaWV0Zi5vcmciPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5lY3JpdEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+Jmd0Ozxicj4NCk9iamV0Jm5ic3A7OiBbRVhUXVJl OiBbRWNyaXRdIHBsYW5uZWQtY2hhbmdlczogdHdvIHF1ZXN0aW9uczxicj4NCjxicj4NCllvdSBk ZWxldGUgdGhlIFVSSSB3aGVuIHlvdSBkZWxldGUgdGhlIHJlY29yZCBpbiB0aGUgTElTLjxicj4N CltHQ10gVGhhdCdzIGZpbmUgYnV0IHRoYXQgd2FzIG5vdCB0aGUgcXVlc3Rpb24gUmFuZGFsbCBw b3NlZC4gSGUgYXNrZWQgd2hldGhlciB0aGUgVVJJIGlzIGRlbGV0ZWQgYWZ0ZXIgYSBub3RpZmlj YXRpb24uIEkgYWdyZWUgdGhhdCBpZiB0aGUgQ2xpZW50IGRvZXMgbm90IGhvc3QgdGhlIGxvY2F0 aW9uIGFueW1vcmUgdGhhdCB0aGUgVVJJIGFzc29jaWF0ZWQgd2l0aCB0aGF0IGxvY2F0aW9uIGlu IHRoZSBTZXJ2ZXIgc2hvdWxkIGJlIGRlbGV0ZWQuDQogVGhpcyBjb3VsZCBiZSBhY2hpZXZlZCB3 aXRoIGFuIGVtcHR5ICZsdDtwbGFubmVkQ2hhbmdlJmd0Oy48YnI+DQo8YnI+DQpJIGRvbuKAmXQg dGhpbmsgdGhpcyBpcyBjb3ZlcmVkIGluIDUyMjIuICZuYnNwO1RoZSBtZWNoYW5pc20gY2F1c2Vz IHRoZSBMb1NUIHNlcnZlciB0byBzZW5kIG5vdGlmaWNhdGlvbnMgdG8gdGhlIGNsaWVudCwgYnV0 IHRoZSBjbGllbnQgaXMgYWxsb3dlZCB0byBwdXQgYW55IFVSSSBpbiB0aGUgcmVjb3JkLCBhbmQg aXQgY2FuIGFkZCBpdCB0byBhcyBtYW55IHJlY29yZHMgYXMgaXQgd2FudHMuPGJyPg0KW0dDXSBJ IHRob3VnaHQgd2UgYWdyZWVkIG9uIHVzaW5nIG9uZSBnZW5lcmljIFVSSSBwZXIgQ2xpZW50LiBD bGllbnRzIHNob3VsZCBiZSBhdXRoZW50aWNhdGVkIGJ5IHRoZSBTZXJ2ZXJzLjxicj4NCiZuYnNw O0FuIGV2aWwgaW1wbGVtZW50YXRpb24gY291bGQgcmVjb3JkIFVSSXMgYWdhaW5zdCBtdWx0aXBs ZSB0YXJnZXRzIHRoYXQgd2VyZSB1bmF3YXJlIHRoYXQgdGhlIGV2aWwgaW1wbGVtZW50YXRpb24g ZGlkIGl0LCB1bnRpbCB0aGV5IGdvdCBhIGxhcmdlIG51bWJlciBvZiBQVVNIIHRyYW5zYWN0aW9u cyB0aGV5IGRpZG7igJl0IGV4cGVjdCBvciB1bmRlcnN0YW5kIGFzIGEgcmVzdWx0IG9mIGEgbGFy Z2UgcGxhbm5lZCBjaGFuZ2UuPGJyPg0KW0dDXSBPbmx5IGF1dGhlbnRpY2F0ZWQgQ2xpZW50cyBz aG91bGQgYmUgYWxsb3dlZCB0byBwcm92aWRlIFVSSXMgdG8gYmUgc3RvcmVkIGJ5IHRoZSBTZXJ2 ZXJzLjxicj4NCjxicj4NClRoZSBwcm9wb3NlZCBtZWNoYW5pc20gcXVhbGlmaWVzIHRoZSBjbGll bnQgVVJJIGJlZm9yZSBpdHMgdXNlZCBpbiBhIHBsYW5uZWQgY2hhbmdlLjxicj4NCjxicj4NCkJy aWFuPGJyPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3 Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+T24gQXVnIDMxLCAyMDIx LCBhdCA3OjM3IEFNLCBDYXJvbiwgR3V5ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmcuY2Fy b25AYmVsbC5jYSI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmcuY2Fyb25AYmVsbC5j YTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+ Jmd0Ow0KIHdyb3RlOjxicj4NCjxicj4NCldlbGwsIHRoaXMgaXMgbm90IGdvaW5nIGluIHRoZSBk aXJlY3Rpb24gSSB0aG91Z2h0Ljxicj4NCjxicj4NCldoYXQgaXMgdGhlIHB1cnBvc2Ugb2YgZGVs ZXRpbmcgdGhlIFVSSXMgYXQgdGhlIFNlcnZlciBwb3N0LXZhbGlkYXRpb24/PGJyPg0KPGJyPg0K UmVnYXJkaW5nIG9wZW5pbmcgYSBuZXcgRG9TLCBJIGd1ZXNzIEknbSBub3QgZm9sbG93aW5nLiBX b3VsZG4ndCB0aGlzIGNhc2UgYmUgY292ZXJlZCBieSB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlv bnMgaW4gUkZDIDUyMjI/PGJyPg0KPGJyPg0KV2hhdCB5b3UncmUgcHJvcG9zaW5nIHB1dHMgYmFj ayBzaWduaWZpY2FudCBsb2FkIG9uIHRoZSBTZXJ2ZXJzIChhIGtleSBjb25zaWRlcmF0aW9uIGZv ciBjcmVhdGluZyBwbGFubmVkLWNoYW5nZXMgaW4gdGhlIGZpcnN0IHBsYWNlKSBhbmQgY29tcGxp Y2F0ZXMgdGhlIG1lY2hhbmlzbS48YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojNzc3Nzc3Ij5HdXk8YnI+DQo8YnI+DQo8YnI+DQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5l LS0tLS08YnI+DQpEZSA6IEVjcml0ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmVjcml0LWJv dW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmVjcml0LWJvdW5jZXNAaWV0Zi5vcmc8 L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+Jmd0OyBEZSBsYSBwYXJ0 IGRlIEJyaWFuDQogUm9zZW4gRW52b3nDqSA6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjMwIGFvw7t0IDIwMjEgMTE6MjIgw4AgOiBSYW5kYWxs IEdlbGxlbnMgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cmcmIzQzO2lldGZAcmFuZHkucGVu c2l2ZS5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPnJnJiM0MztpZXRmQHJhbmR5LnBlbnNpdmUub3Jn PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPiZndDsNCiBDYzxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo6IEVDUklU ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmVjcml0QGlldGYub3JnIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5lY3JpdEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3 Nzc3Ij4mZ3Q7IE9iamV0IDogW0VYVF1SZTogW0Vjcml0XSBwbGFubmVkLWNoYW5nZXM6DQogdHdv PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCnF1 ZXN0aW9uczxicj4NCjxicj4NCkFuc3dlciAxOiB5ZXMuICZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij5TaW5jZSB0aGVyZSBpcyBnb2luZyB0 byBiZSBhIHJldmFsaWRhdGlvbiwganVzdCBkZWxldGluZyB0aGUgc2V0dGluZyBzZWVtcyByaWdo dCB0byBtZS48YnI+DQpBbnN3ZXIgMjogVXAgdG8gc2VydmVyLiAmbmJzcDtJZiBJIHdlcmUgaW1w bGVtZW50aW5nLCBJIHdvdWxkIGhhc2ggdGhlIHJlYWwgSUQgd2l0aCB0aGUgVVJJIGFuZCBzb21l IGtpbmQgb2YgcHJlZGljdGFibGUgbm9uY2UuICZuYnNwOzxicj4NCjxicj4NCldlIHByb2JhYmx5 IGhhdmUgdG8gc2F5IG1vcmUgYWJvdXQgaG93IHRoZSBzZXJ2ZXIgaWRlbnRpZmllcyB0aGUgY2xp ZW50LCBzbyB0aGF0IHJlcGxhY2VtZW50IG9mIHRoZSBVUkkgd29ya3MuICZuYnNwO0NvdWxkIHdl IHNheSB3ZSB1c2UgdGhlIGRvbWFpbiBvZiB0aGUgVVJJICh0aGUgZW50aXJlIGRvbWFpbiB3aXRo IGFsbCB0aGUgZG90cykgdG8gaWRlbnRpZnkgdGhlIGNsaWVudCwgYW5kIGFueXRoaW5nIGNhbiBv Y2N1ciBhZnRlciBpdCAobWVhbmluZw0KIGEgc2xhc2ggYW5kIHdoYXRldmVyKT8gJm5ic3A7SWYg d2UgZG8gdGhhdCwgdGhlbiBob3cgd291bGQgZGVsZXRlIHRoZSBub3RpZmljYXRpb24/ICZuYnNw O0ZvcmNlIHRoZXJlIHRvIGJlIHNvbWV0aGluZyBvdGhlciB0aGFuIHRoZSBkb21haW4gKHVnbHkp LiAmbmJzcDtFeHBsaWNpdCBkZWxldGUgcmVxdWVzdD88YnI+DQo8YnI+DQpIbW1tLCB3ZeKAmXZl IG9wZW5lZCBhIERvUyBhdHRhY2s6IGEgcm9ndWUgY2xpZW50IHN0b3JlcyBhIGJ1bmNoIG9mIFVS SXMgZm9yIHNlcnZlcnMgaXQgd2FudHMgdG8gdmljdGltaXplLiAmbmJzcDtJbiBOb3J0aCBBbWVy aWNhIHdlIGhhdmUgYSByZWFsIHNpbXBsZSBzb2x1dGlvbiBmb3IgdGhhdCwgYmVjYXVzZSB3ZSBo YXZlIGEgUEtJLCBzbyB3ZSBrbm93LCBmb3Igc3VyZSwgd2hvIHRoZSBjbGllbnQgaXMsIGFuZCBj b3VsZCByZXN0cmljdCB3aG8gd2UgYWxsb3cNCiB0byBzdG9yZSBVUklzLCBidXQgdGhhdCB3b3Vs ZG7igJl0IGJlIHRydWUgaW4gZ2VuZXJhbC4gJm5ic3A7QWxzbywgaXQgd291bGQgYmUgbmljZSBm b3IgdGhlIGNsaWVudCB0byBoYXZlIGNvbmZpZGVuY2UgdGhlIG1lY2hhbmlzbSB3b3JrZWQgYmVm b3JlIGl0IG5lZWRlZCBpdC48YnI+DQo8YnI+DQpTbzxicj4NCkxldOKAmXMgYWRkIGEg4oCcY29t bWFuZOKAnSB0byBwbGFubmVkQ2hhbmdlIGluIHRoZSBmaW5kU2VydmljZSByZXF1ZXN0LiAmbmJz cDs8YnI+DQpBbmQsIGhhdmUgdGhlIGNsaWVudCBoYXZlIGEgcmVzcG9uc2UgdG8gdGhlIG5vdGlm aWNhdGlvbiB3aGljaCBpcyB0aGU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGJyPg0KSUQgKGpzb24gd2l0aCB0aGUgMjAwKTxicj4NCjxicj4NCjxicj4N ClRoZSBjbGllbnQgc3RhcnRzIGJ5IHNlbmRpbmcgYSBjb21tYW5kIG9mIOKAnGluaXRpYWxpemXi gJ0uICZuYnNwO1RoZSBkb21haW4gaXMgdGhlIGlkZW50aXR5IG9mIHRoZSBjbGllbnQuICZuYnNw O1RoZSByZXNwb25zZSBpcyBhbiBpbW1lZGlhdGUgbm90aWZpY2F0aW9uIHRvIHRoZSB3aXRoIHdo YXRldmVyIExJIHdhcyBpbiB0aGUgcmVxdWVzdCBhbmQgYW4gSUQuICZuYnNwO1RoZSAmbmJzcDty ZXNwb25zZSBieSB0aGUgY2xpZW50ICh3aGljaCBpcyB0aGUgbm90aWZpY2F0aW9uIHdlYiBzZXJ2 ZXIpDQogaXMgYSBwaWVjZSBvZiBqc29uIGNvbnRhaW5pbmcgdGhlIElELiAmbmJzcDtXZSBjYW4g c2F5IHRoYXQgdGhlIExJIGluIHRoaXMgaW5pdGlhbGl6ZSBjb21tYW5kIGNvdWxkIGJlIHNvbWV0 aGluZyBzaW1wbGUgbGlrZSB0aGUgQ291bnRyeSBDb2RlIHRoYXQgd291bGRu4oCZdCBnZXQgYSBw bGFubmVkIGNoYW5nZS48YnI+DQo8YnI+DQpUaGVyZWFmdGVyLCB0aGUgTG9TVCBzZXJ2ZXIgKG5v dGlmaWNhdGlvbiBjbGllbnQpIHBlcmlvZGljYWxseSByZXBlYXRzIHRoaXMga2VlcGFsaXZlIG5v dGlmaWNhdGlvbiBldmVyeSBkYXkgb3Igd2VlayB3aXRoIHRoZSBpbml0aWFsaXplIExJLiAmbmJz cDtUaGUgY2xpZW50IGhhcyB0byByZXNwb25kIHdpdGggdGhlIElELjxicj4NCjxicj4NClRoZSBy ZWd1bGFyIG5vdGlmaWNhdGlvbiByZXF1ZXN0IGlzIGEgY29tbWFuZCBvZiDigJxub3RpZnnigJ0u ICZuYnNwO1RoZSBzZXJ2ZXIgaWdub3JlcyBhIHJlcXVlc3QgZm9yIG5vdGlmaWNhdGlvbiBmcm9t IGFuIHVuaW5pdGlhbGl6ZWQgY2xpZW50Ljxicj4NClRoZSBub3RpZmljYXRpb24gY2FuIGJlIGRl bGV0ZWQgd2l0aCBhIGNvbW1hbmQgb2Yg4oCcZGVsZXRl4oCdLiAmbmJzcDtJZiB5b3UgZGVsZXRl IHRoZSBpbml0aWFsaXplIExJLCB0aGVuIHRoZSBzZXJ2ZXIgd29u4oCZdCBzZW5kIGFueSBtb3Jl IG5vdGlmaWNhdGlvbnMgdG8gdGhhdCBjbGllbnQgYW5kIGRlbGV0ZXMgYWxsIFVSSXMgaXQgd2Fz IHNhdmluZyBmb3IgdGhhdCBjbGllbnQuICZuYnNwO1RoZSBjbGllbnQgd291bGQgaGF2ZSB0byBy ZS1pbml0aWFsaXplIHRvIHJlc2V0Ljxicj4NCjxicj4NCkJyaWFuPGJyPg0KPGJyPg0KPGJyPg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij5PbiBBdWcgMjcsIDIwMjEsIGF0IDU6 NDEgUE0sIFJhbmRhbGwgR2VsbGVucyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpyZyYjNDM7 aWV0ZkByYW5keS5wZW5zaXZlLm9yZyI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPnJn JiM0MztpZXRmQHJhbmR5LnBlbnNpdmUub3JnPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij4mZ3Q7DQogd3JvdGU6PGJyPg0KPGJyPg0KSSB0aGlu ayB3ZSdyZSBtb3ZpbmcgdG8gYSBtb2RlbCB3aGVyZTo8YnI+DQotIEluIGEgcXVlcnksIGEgY2xp ZW50IGNhbiByZXF1ZXN0IHRvIGJlIG5vdGlmaWVkIHdoZW4gdGhlIGxvY2F0aW9uPHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCnNob3VsZCBiZSBy ZXZhbGlkYXRlZDs8YnI+DQotIEluIHRoZSByZXNwb25zZSwgdGhlIHNlcnZlciBwcm92aWRlcyBh biBJRCB3aGljaCB0aGUgY2xpZW50PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxicj4NCmFzc29jaWF0ZXMgd2l0aCB0aGUgbG9jYXRpb24gaXQganVzdCB2 YWxpZGF0ZWQ7PGJyPg0KLSBUaGUgc2VydmVyIHNlbmRzIGEgbm90aWZpY2F0aW9uIHRvIHRoZSBV UkksIGNvbnRhaW5pbmcgdGhlIElEOzxicj4NCi0gVGhlIGNsaWVudCByZXZhbGlkYXRlcyBlYWNo IGxvY2F0aW9uIHdpdGggd2hpY2ggdGhhdCBJRCBpcyBhc3NvY2lhdGVkLjxicj4NCjxicj4NClF1 ZXN0aW9uIDE6IERvZXMgdGhlIHNlcnZlciBkZWxldGUvaW5hY3RpdmF0ZSB0aGUgVVJJIG9uY2Ug aXQgaGFzIHNlbnQgdGhlIG5vdGlmaWNhdGlvbj88YnI+DQo8YnI+DQpRdWVzdGlvbiAyOiBQcmVz dW1hYmx5LCB3aGVuIHRoZSBjbGllbnQgcmV2YWxpZGF0ZXMgdGhlIGxvY2F0aW9uKHMpLCBpdCB3 aWxsIGFnYWluIHJlcXVlc3Qgbm90aWZpY2F0aW9uLiAmbmJzcDtEb2VzIHRoZSBzZXJ2ZXIgcmV0 dXJuIHRoZSBzYW1lIElEIGFzIGJlZm9yZSwgb3IgYSBkaWZmZXJlbnQgSUQ/ICZuYnNwO0EgZGlm ZmVyZW50IElEIGNvdWxkIHBlcmhhcHMgYmUgdXNlZnVsIGluIGVkZ2UgY2FzZXMgd2hlcmUgdGhl IHNlcnZlciBkaWRuJ3Qgc2VuZCBvcg0KIHRoZSBjbGllbnQgZGlkbid0IGdldCB0aGUgbm90aWZp Y2F0aW9uLCBidXQgYW55IHV0aWxpdHkgc2VlbXMgc21hbGwuICZuYnNwO0lmIGl0J3MgdGhlIHNh bWUgSUQsIHRoZW4gdGhlIGFuc3dlciB0byBxdWVzdGlvbiAxIGNhbiBiZSB0aGF0IHRoZSBVUkkg cmVtYWlucyBhY3RpdmUgdW50aWwgdGhlIGNsaWVudCBhc2tzIHRvIG5vIGxvbmdlciBiZSBub3Rp ZmllZCAoYnkgc2VuZGluZyBhbiBlbXB0eSBVUkk/KS48YnI+DQo8YnI+DQotLVJhbmRhbGw8YnI+ DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCkVjcml0IG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86RWNyaXRA aWV0Zi5vcmciPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5FY3JpdEBpZXRmLm9yZzwv c3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+PGJy Pg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZWNyaXQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0PC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojNzc3Nzc3Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCkVjcml0IG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJt YWlsdG86RWNyaXRAaWV0Zi5vcmciPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5FY3Jp dEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 Izc3Nzc3NyI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZWNyaXQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0PC9zcGFuPjwvYT48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij48YnI+DQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJy Pg0KLS0tLS0tLS0gRXh0ZXJuYWwgRW1haWw6IFBsZWFzZSB1c2UgY2F1dGlvbiB3aGVuIG9wZW5p bmcgbGlua3MgYW5kPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxicj4NCmF0dGFjaG1lbnRzIC8gQ291cnJpZWwgZXh0ZXJuZTogU295ZXogcHJ1ZGVudCBh dmVjIGxlcyBsaWVucyBldDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YnI+DQpkb2N1bWVudHMgam9pbnRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6Izc3Nzc3NyI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 Izc3Nzc3NyI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KRXh0ZXJuYWwgRW1haWw6IFBsZWFz ZSB1c2UgY2F1dGlvbiB3aGVuIG9wZW5pbmcgbGlua3MgYW5kIGF0dGFjaG1lbnRzIC8gQ291cnJp ZWwgZXh0ZXJuZTogU295ZXogcHJ1ZGVudCBhdmVjIGxlcyBsaWVucyBldCBkb2N1bWVudHMgam9p bnRzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiM3Nzc3NzciPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0i MTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzdHJv bmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj5FeHRlcm5hbCBF bWFpbDo8L3NwYW4+PC9pPjwvc3Ryb25nPjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2NvbG9yOmJsdWUiPiBQbGVhc2UgdXNlIGNhdXRpb24gd2hlbiBvcGVuaW5nIGxpbmtzIGFuZCBh dHRhY2htZW50cyAvDQo8L3NwYW4+PC9lbT48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Y29sb3I6Ymx1ZSI+Q291cnJpZWwgZXh0ZXJuZTo8L3NwYW4+PC9pPjwvc3Ryb25n PjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPiBTb3lleiBwcnVk ZW50IGF2ZWMgbGVzIGxpZW5zIGV0IGRvY3VtZW50cyBqb2ludHMNCjwvc3Bhbj48L2VtPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_851c82ef56714b8a917761d98234093abellca_-- From nobody Tue Aug 31 13:54:55 2021 Return-Path: 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 22CC03A0CE8 for ; Tue, 31 Aug 2021 13:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, 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 q5f9dCoWzwmM for ; Tue, 31 Aug 2021 13:54:47 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id B94033A0CEC for ; Tue, 31 Aug 2021 13:54:46 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 31 Aug 2021 13:54:45 -0700 From: "Randall Gellens" To: "Caron, Guy" Cc: ECRIT Date: Tue, 31 Aug 2021 13:54:45 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <1F917507-F9BE-4003-8058-B19E5A288AF6@randy.pensive.org> In-Reply-To: References: <6fdb8f42317d4dfc99783a4d834b6c85@bell.ca> <07be5a05ac8b4146adc2f0ba56f0e106@bell.ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_CBF0B652-9C1A-4598-97A2-CA2D64E9AD89_=" Embedded-HTML: [{"HTML":[457, 24570], "plain":[126, 3292], "uuid":"31D7250F-C3FD-4F48-93B9-FFAB261421B9"}] Archived-At: Subject: Re: [Ecrit] similar-location-09: GCaron Review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 20:54:53 -0000 --=_MailMate_CBF0B652-9C1A-4598-97A2-CA2D64E9AD89_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable It looked to me to be almost entirely minor editorial suggestions. --Randall On 31 Aug 2021, at 13:30, Caron, Guy wrote: > Thanks all that confirmed the reception of the attachment on the list. > > I was wondering since the posting did not spark any reaction. > > Guy > > De : Randall Gellens > Envoy=C3=A9 : 31 ao=C3=BBt 2021 15:00 > =C3=80 : Caron, Guy > Cc : ECRIT > Objet : [EXT]Re: [Ecrit] similar-location-09: GCaron Review > > > I received an email from you via the list on 8/27 that contains an = > attachment. > > --Randall > > On 31 Aug 2021, at 6:04, Caron, Guy wrote: > > Can someone confirm that the attachment was delivered through the = > ECRIT list? > > > > I got it myself but want to be sure everyone got it. > > > > Thanks, > > > > Guy > > > > De : Ecrit > De = > la part de Caron, Guy > Envoy=C3=A9 : 27 ao=C3=BBt 2021 16:09 > =C3=80 : ECRIT > > Objet : [EXT][Ecrit] TR: similar-location-09: GCaron Review > > > > Resending to the ECRIT list. > > > > Guy > > > > De : Caron, Guy > Envoy=C3=A9 : 27 ao=C3=BBt 2021 16:01 > =C3=80 : 'draft-ietf-ecrit-similar-location@ietf.org' = > > > Objet : similar-location-09: GCaron Review > > > > Hi, > > > > I reviewed this document and think it is mostly in good shape. I have = > a few comments to offer: > > > > 1. The document does not use a convention to express XML types = > such as for elements, =E2=80=98boobooboo=E2=80=99 for attri= butes, = > =E2=80=9Cheyheyhey=E2=80=9D for values, etc. in the text. Should it? > > 2. The document defines terms in section 2, which are spelled = > with capital first letters however, when used in the text after = > section 2, a number of instances do no use the same style and should. > > 3. Section 2, in the Invalid Location definition, the term = > locationInvalid is used however, there is no defined element in here = > or anywhere else. Was that suppose to refer to lost-planned-changes = > ? > > 4. Section 2, the Similar Location definition says =E2=80=9CA = > suggested civic location that is comparatively close to the civic = > location which was input=E2=80=9D. Comparing what? Geographic proximity= , = > semantically close, else? > > 5. For completeness, it would be nice to include the = > =E2=80=98similarLocationsLimited=E2=80=99 attribute in the example = > in section 5.2. > > 6. There are two errors in the XML schema in section 6: > > a. xmlns=3D"urn:ietf:params:xml:ns:lost-rli1=C3=A2 should be = > xmlns=3D"urn:ietf:params:xml:ns:lost-rli1" > > b. should be value=3D"1"/> > > 7. The reference to planned-changes in section 9.1 should be = > updated > > > > I=E2=80=99m trying to attach a MSWord version with track-change here th= at = > includes resolutions to 2 and 5, with additional proposed editorial = > and non-subtative changes. If it does not pass the mail server, I will = > send directly to the authors. > > > > Thanks, > > > > Guy > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > ________________________________ > External Email: Please use caution when opening links and attachments = > / Courriel externe: Soyez prudent avec les liens et documents joints --=_MailMate_CBF0B652-9C1A-4598-97A2-CA2D64E9AD89_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">It looked to me to be almost entirely minor editorial sugg= estions.

--Randall

On 31 Aug 2021, at 13:30, Caron, Guy wrote:

Thanks all that confirmed the recepti= on of the attachment on the list.

=C2=A0

I was wondering since the posting did= not spark any reaction.

=C2=A0

Guy

=C2=A0

De=C2= =A0: Randall Gellens <rg+ietf@randy.pensive.org>
Envoy=C3=A9=C2=A0: 31 ao=C3=BBt 2021 15:00
=C3=80=C2=A0: Caron, Guy <g.caron@bell.ca>
Cc=C2=A0: ECRIT <ecrit@ietf.org>
Objet=C2=A0: [EXT]Re: [Ecrit] similar-location-09: GCaron Review

=C2=A0

I received an email from you via the list on 8/27 that co= ntains an attachment.

--Randall

On 31 Aug 2021, at 6:04, Caron, Guy wrote:

Can someone confirm that the attachme= nt was delivered through the ECRIT list?

=C2=A0

I got it myself but want to be sure e= veryone got it.

=C2=A0

Thanks,

=C2=A0

Guy

=C2=A0

=C2=A0

Resending to the ECRIT list.

=C2=A0

Guy

=C2=A0

De=C2=A0: Caron, Guy
Envoy=C3=A9=C2=A0: 27 ao=C3=BBt 2021 16:01
=C3=80=C2=A0: 'draft-ietf-ecrit-similar-location@ietf.org' <dr= aft-ietf-ecrit-similar-location@ietf.org>= ;
Objet=C2=A0: similar-location-09: GCaron Review

=C2=A0

Hi,

=C2=A0

I reviewed this document and think it= is mostly in good shape. I have a few comments to offer:

=C2=A0

1.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The document does= not use a convention to express XML types such as <blablabla> for = elements, =E2=80=98boobooboo=E2=80=99 for attributes, =E2=80=9Cheyheyhey=E2= =80=9D for values, etc. in the text. Should it?

2.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The document defi= nes terms in section 2, which are spelled with capital first letters howe= ver, when used in the text after section 2, a number of instances do no use the same style and should.

3.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 2, in the= Invalid Location definition, the term locationInvalid is used however, t= here is no defined element in here or anywhere else. Was that suppose to refer to lost-planned-changes <locationInva= lidated>?

4.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 2, the Si= milar Location definition says =E2=80=9CA suggested civic location that i= s comparatively close to the civic location which was input=E2=80=9D. Comparing what? Geographic proximity, semantically c= lose, else?

5.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For completeness,= it would be nice to include the =E2=80=98similarLocationsLimited=E2=80=99= attribute in the example <findServiceResponse> in section 5.2.

6.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 There are two err= ors in the XML schema in section 6:

a.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 xmlns=3D"urn:ietf= :params:xml:ns:lost-rli1=C3=A2 should be xmlns=3D"urn:ietf:params:xml:ns:= lost-rli1"

b.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <xs:minInclusi= ve value=3D"1"> should be <xs:minInclusive value=3D"1"/><= /p>

7.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The reference to = planned-changes in section 9.1 should be updated

=C2=A0

I=E2=80=99m trying to attach a MSWord= version with track-change here that includes resolutions to 2 and 5, with additional proposed editorial and non-subtative changes. If it d= oes not pass the mail server, I will send directly to the authors.=

=C2=A0

Thanks,

=C2=A0

Guy

___________________________________________= ____
Ecrit mailing list
Ecrit@ietf.org
https:/= /www.ietf.org/mailman/listinfo/ecrit

<= span style=3D"font-size:9.0pt;color:blue">External Email: Please use caution wh= en opening links and attachments / Courrie= l externe: Soyez prudent avec les liens et documents joints

--=_MailMate_CBF0B652-9C1A-4598-97A2-CA2D64E9AD89_=-- From nobody Tue Aug 31 13:55:21 2021 Return-Path: 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 CB87B3A0CEF for ; Tue, 31 Aug 2021 13:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, 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.20150623.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 cs4WX_o7MUIK for ; Tue, 31 Aug 2021 13:55:07 -0700 (PDT) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 4D8973A0CEE for ; Tue, 31 Aug 2021 13:55:07 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id z2so824051iln.0 for ; Tue, 31 Aug 2021 13:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2BgrGzj1/Re5a1PzPpu3KtXOjdEmQJoDzy/Nd03VNLg=; b=ahpsE5CjZAgmiros/eo6S1wKGXzvtJLUZbi78hKkQtY2c6NyOJXqBiFhetjW2yH+X2 IJ3KFIGNF75DOyNW3HnCShAg+SIuPpQxgSOdG5R58sG+FoNzfDqHGj7Tgj8GZsio797v hh0Fp7pgCxozMIhYyIHYrQJYYYPjIc9hlWwLYBZplFxaaWDcLr4ZXaZYJYtPankNf5WD OTOx/FRZ2C062+Qptrg9W2/QlTEHRvyr40zCdaEeGuqa6Xcd/1tIJsVAjCXLvZBZAx4+ TMfbXClAU2pipmD2YCEpNVdcN4ewKIg04oB0CmzfpWFUxvnEhbiM3F+b5trg7yl/m7rE BKPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2BgrGzj1/Re5a1PzPpu3KtXOjdEmQJoDzy/Nd03VNLg=; b=VzXewQZihkSYOT87jghetq0CwIxyZmdcphV4Ukd4r59jupaNCqrVDsARLtk8oI6/pX OeypPaicmpxKRsNetQw9fyMokT3kZq0WP4g1l0KVsWLwapaZFS5i9i6bRvwCifM242iF RY0ZxueYlx2QOkJwQRtm/2UXgCUonimtYE75bVVD/rszKx1KHqF74V6T2kuRJKLtJb4L 0lCCCuzk53nMR3Fhz6CwszH9t9MOyegKHd7nVe49xz9VRZ6ZbOn0FWd1l6MTFlkp9YWX n7U2+wNxUzC43o8OrTquhqbMFufrGW8NhFfTINfEI29bqZFohmuYQ+yajhY8Vl7+6lZf NEGw== X-Gm-Message-State: AOAM533QwPUlr92POhTrnOZX2iAwYfFbvCTSz6SoBTb4bgsyVTz521f/ rnlRCW+/qIGLXbKdKB3KJasYug== X-Google-Smtp-Source: ABdhPJwqeI11tbtyICsG80EcaMNO/RrmoKeB9uC5vrkg0A7FtPAf+tYDTGOHOcphPnuBcFMfip5yBw== X-Received: by 2002:a05:6e02:d0f:: with SMTP id g15mr20909925ilj.71.1630443305021; Tue, 31 Aug 2021 13:55:05 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id x13sm11258028ilq.18.2021.08.31.13.55.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Aug 2021 13:55:04 -0700 (PDT) From: Brian Rosen Message-Id: <0F5C2109-77E1-495E-9768-94E28DC6A76A@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_3995F505-7E3C-4431-91A5-3DF932A429DE" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 31 Aug 2021 16:55:03 -0400 In-Reply-To: <851c82ef56714b8a917761d98234093a@bell.ca> Cc: Randall Gellens , ECRIT To: "Caron, Guy" References: <5577e2e6daa4405bbe12ef61675e1f55@bell.ca> <3AD58DEC-1DC9-4BC0-B55C-4E782E4AAA74@brianrosen.net> <9433989A-85D7-41B9-96EA-313ADC0F02CD@brianrosen.net> <851c82ef56714b8a917761d98234093a@bell.ca> X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Ecrit] planned-changes: two questions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 20:55:16 -0000 --Apple-Mail=_3995F505-7E3C-4431-91A5-3DF932A429DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 If we did that, we would have to implement limit and start to handle a = large list. =20 Brian > On Aug 31, 2021, at 4:38 PM, Caron, Guy wrote: >=20 > If we make a list of IDs, one notification per = URI per planned change would be sufficient. > =20 > Guy > =20 > De : Brian Rosen =20 > Envoy=C3=A9 : 31 ao=C3=BBt 2021 15:35 > =C3=80 : Randall Gellens > Cc : Caron, Guy ; ECRIT > Objet : [EXT]Re: [Ecrit] planned-changes: two questions > =20 > No. =20 > =20 > There is one URI, but many IDs, one per unique record at the LoST = server that is involved in a planned change. The one URI will receive = one notification per ID it has registered for. > =20 > =20 >=20 >=20 > On Aug 31, 2021, at 2:56 PM, Randall Gellens = > wrote: > =20 > i understand that the concern is allowing a client to leverage the = LoST server to attack a large number of targets, I'm just not clear = mechanically how such leverage potentially works. Each validation query = can store a URI, and that URI may get associated with a large number of = locations. Maybe there's a street name change or an annexation. So maybe = thousands or tens or hundreds of thousands of locations are potentially = invalidated. They all have the same URI associated with them, so the = LoST server connects to the URI once and POSTs one notification, no? > --Randall > On 31 Aug 2021, at 10:53, Brian Rosen wrote: > Of course an attacker would conceal itself and register multiple URIs = under different identities. But the bigger problem is that if a large = planned change occurred, the victim could receive a large number of = notifications it didn=E2=80=99t expect. > =20 > With a test transition, we know that the client expects to see = notifications, we only need one per URI (we could specify one per domain = =E2=80=94 after the scheme and before the first slash). If we don=E2=80=99= t get the ID, we know not to allow that URI to be provisioned. So = it=E2=80=99s one test transaction vs a large number of planned change = transactions. > =20 > Brian > =20 >=20 >=20 > On Aug 31, 2021, at 1:35 PM, Randall Gellens = > wrote: > =20 > If a malicious client registers a URI that is designed to attack a = third site, the test transaction causes the LoST server to connect to it = and POST a command. Without a test transaction, the LoST server stores = the URI and at a future time connects to it and sends a command. Either = way, a LoST client can register potentially one URI per queried = location, and a LoST server will connect to that URI and POST a message. = A queried location could be tied to many other locations, so there could = be many locations for which a change would trigger the LoST server to = use the URI, but is that worse? > --Randall > On 31 Aug 2021, at 10:27, Brian Rosen wrote: > If the work group wants to have the LoST server keep the URI until = expressly deleted, that=E2=80=99s okay with me. > =20 > Authenticating the client to the server doesn=E2=80=99t mean the URI = is authenticated. We can=E2=80=99t restrict the URI to be the same = entity as the client running the LoST transaction. And the clients are = wide ranging. Could be an enterprise running its own LIS for example. = We can=E2=80=99t assume the North American PKI is workable everywhere, = and even that doesn=E2=80=99t extend to an enterprise LIS. ISTM we have = to run a test transaction with the notification service to make sure = it=E2=80=99s what we think it is. > =20 > Brian > =20 > =20 >=20 >=20 > On Aug 31, 2021, at 9:01 AM, Caron, Guy > wrote: > =20 > Inline. >=20 > Guy >=20 > -----Message d'origine----- > De : Brian Rosen >=20 > Envoy=C3=A9 : 31 ao=C3=BBt 2021 08:11 > =C3=80 : Caron, Guy > > Cc : Randall Gellens >; ECRIT > > Objet : [EXT]Re: [Ecrit] planned-changes: two questions >=20 > You delete the URI when you delete the record in the LIS. > [GC] That's fine but that was not the question Randall posed. He asked = whether the URI is deleted after a notification. I agree that if the = Client does not host the location anymore that the URI associated with = that location in the Server should be deleted. This could be achieved = with an empty . >=20 > I don=E2=80=99t think this is covered in 5222. The mechanism causes = the LoST server to send notifications to the client, but the client is = allowed to put any URI in the record, and it can add it to as many = records as it wants. > [GC] I thought we agreed on using one generic URI per Client. Clients = should be authenticated by the Servers. > An evil implementation could record URIs against multiple targets = that were unaware that the evil implementation did it, until they got a = large number of PUSH transactions they didn=E2=80=99t expect or = understand as a result of a large planned change. > [GC] Only authenticated Clients should be allowed to provide URIs to = be stored by the Servers. >=20 > The proposed mechanism qualifies the client URI before its used in a = planned change. >=20 > Brian >=20 >=20 > On Aug 31, 2021, at 7:37 AM, Caron, Guy > wrote: >=20 > Well, this is not going in the direction I thought. >=20 > What is the purpose of deleting the URIs at the Server = post-validation? >=20 > Regarding opening a new DoS, I guess I'm not following. Wouldn't this = case be covered by the security considerations in RFC 5222? >=20 > What you're proposing puts back significant load on the Servers (a key = consideration for creating planned-changes in the first place) and = complicates the mechanism. >=20 > Guy >=20 >=20 > -----Message d'origine----- > De : Ecrit > De = la part de Brian Rosen Envoy=C3=A9 :=20 > 30 ao=C3=BBt 2021 11:22 =C3=80 : Randall Gellens = > Cc=20 > : ECRIT > Objet : [EXT]Re: = [Ecrit] planned-changes: two=20 > questions >=20 > Answer 1: yes. Since there is going to be a revalidation, just = deleting the setting seems right to me. > Answer 2: Up to server. If I were implementing, I would hash the real = ID with the URI and some kind of predictable nonce. =20 >=20 > We probably have to say more about how the server identifies the = client, so that replacement of the URI works. Could we say we use the = domain of the URI (the entire domain with all the dots) to identify the = client, and anything can occur after it (meaning a slash and whatever)? = If we do that, then how would delete the notification? Force there to = be something other than the domain (ugly). Explicit delete request? >=20 > Hmmm, we=E2=80=99ve opened a DoS attack: a rogue client stores a bunch = of URIs for servers it wants to victimize. In North America we have a = real simple solution for that, because we have a PKI, so we know, for = sure, who the client is, and could restrict who we allow to store URIs, = but that wouldn=E2=80=99t be true in general. Also, it would be nice = for the client to have confidence the mechanism worked before it needed = it. >=20 > So > Let=E2=80=99s add a =E2=80=9Ccommand=E2=80=9D to plannedChange in the = findService request. =20 > And, have the client have a response to the notification which is the=20= > ID (json with the 200) >=20 >=20 > The client starts by sending a command of =E2=80=9Cinitialize=E2=80=9D. = The domain is the identity of the client. The response is an immediate = notification to the with whatever LI was in the request and an ID. The = response by the client (which is the notification web server) is a piece = of json containing the ID. We can say that the LI in this initialize = command could be something simple like the Country Code that wouldn=E2=80=99= t get a planned change. >=20 > Thereafter, the LoST server (notification client) periodically repeats = this keepalive notification every day or week with the initialize LI. = The client has to respond with the ID. >=20 > The regular notification request is a command of =E2=80=9Cnotify=E2=80=9D= . The server ignores a request for notification from an uninitialized = client. > The notification can be deleted with a command of =E2=80=9Cdelete=E2=80=9D= . If you delete the initialize LI, then the server won=E2=80=99t send = any more notifications to that client and deletes all URIs it was saving = for that client. The client would have to re-initialize to reset. >=20 > Brian >=20 >=20 > On Aug 27, 2021, at 5:41 PM, Randall Gellens = > wrote: >=20 > I think we're moving to a model where: > - In a query, a client can request to be notified when the location=20 > should be revalidated; > - In the response, the server provides an ID which the client=20 > associates with the location it just validated; > - The server sends a notification to the URI, containing the ID; > - The client revalidates each location with which that ID is = associated. >=20 > Question 1: Does the server delete/inactivate the URI once it has sent = the notification? >=20 > Question 2: Presumably, when the client revalidates the location(s), = it will again request notification. Does the server return the same ID = as before, or a different ID? A different ID could perhaps be useful in = edge cases where the server didn't send or the client didn't get the = notification, but any utility seems small. If it's the same ID, then = the answer to question 1 can be that the URI remains active until the = client asks to no longer be notified (by sending an empty URI?). >=20 > --Randall >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit = >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit = > ---------------------------------------------------------------------- > -------- External Email: Please use caution when opening links and=20 > attachments / Courriel externe: Soyez prudent avec les liens et=20 > documents joints >=20 > = --------------------------------------------------------------------------= ---- > External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints > =20 > =20 > =20 > External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints --Apple-Mail=_3995F505-7E3C-4431-91A5-3DF932A429DE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 If = we did that, we would have to implement limit and start to handle a = large list.  

Brian


On Aug = 31, 2021, at 4:38 PM, Caron, Guy <g.caron@bell.ca> wrote:

If we make = <revalidateLocation> a list of IDs, one notification per URI per = planned change would be sufficient.
 
Guy
 
De : Brian = Rosen <br@brianrosen.net> 
Envoy=C3=A9 : 31 ao=C3=BBt 2021 15:35
=C3=80 : Randall Gellens <rg+ietf@randy.pensive.org>
Cc : Caron, Guy <g.caron@bell.ca>; = ECRIT <ecrit@ietf.org>
Objet : [EXT]Re: [Ecrit] = planned-changes: two questions
 
No.  
 
There is one URI, but many IDs, one per unique record at the = LoST server that is involved in a planned change.  The one URI will = receive one notification per ID it has registered for.
 
 


On Aug = 31, 2021, at 2:56 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:
 
i understand that the concern is allowing a = client to leverage the LoST server to attack a large number of targets, = I'm just not clear mechanically how such leverage potentially works. = Each validation query can store a URI, and that URI may get associated = with a large number of locations. Maybe there's a street name change or = an annexation. So maybe thousands or tens or hundreds of thousands of = locations are potentially invalidated. They all have the same URI = associated with them, so the LoST server connects to the URI once and = POSTs one notification, no?
--Randall
On 31 Aug 2021, at 10:53, Brian Rosen wrote:
Of course an attacker would = conceal itself and register multiple URIs under different identities. =  But the bigger  problem is that if a large planned change = occurred, the victim could receive a large number of notifications it = didn=E2=80=99t expect.
 
With a test transition, we know that the client = expects to see notifications, we only need one per URI (we could specify = one per domain =E2=80=94 after the scheme and before the first slash). =  If we don=E2=80=99t get the ID, we know not to allow that URI to = be provisioned.  So it=E2=80=99s one test transaction vs a large = number of planned change transactions.
 
Brian
 


On Aug 31, = 2021, at 1:35 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:
 
If a malicious client = registers a URI that is designed to attack a third site, the test = transaction causes the LoST server to connect to it and POST a command. = Without a test transaction, the LoST server stores the URI and at a = future time connects to it and sends a command. Either way, a LoST = client can register potentially one URI per queried location, and a LoST = server will connect to that URI and POST a message. A queried location = could be tied to many other locations, so there could be many locations = for which a change would trigger the LoST server to use the URI, but is = that worse?
--Randall
On 31 Aug 2021, at 10:27, Brian = Rosen wrote:
If the work group wants to have the LoST server = keep the URI until expressly deleted, that=E2=80=99s okay with me.
 
Authenticating the client to the server doesn=E2=80=99t mean = the URI is authenticated.  We can=E2=80=99t restrict the URI to be = the same entity as the client running the LoST transaction.  And = the clients are wide ranging.  Could be an enterprise running its = own LIS for example.  We can=E2=80=99t assume the North American = PKI is workable everywhere, and even that doesn=E2=80=99t extend to an = enterprise LIS.  ISTM we have to run a test transaction with the = notification service to make sure it=E2=80=99s what we think it is.
 
Brian
 
 


On Aug 31, = 2021, at 9:01 AM, Caron, Guy <g.caron@bell.ca> wrote:
 
Inline.

Guy

-----Message = d'origine-----
De : Brian Rosen <br@brianrosen.net> 
Envoy=C3=A9&nb= sp;: 31 ao=C3=BBt 2021 08:11
=C3=80 : Caron, Guy = <g.caron@bell.ca>
Cc : Randall = Gellens <rg+ietf@randy.pensive.org>; ECRIT = <ecrit@ietf.org>
Objet : [EXT]Re: = [Ecrit] planned-changes: two questions

You = delete the URI when you delete the record in the LIS.
[GC] = That's fine but that was not the question Randall posed. He asked = whether the URI is deleted after a notification. I agree that if the = Client does not host the location anymore that the URI associated with = that location in the Server should be deleted. This could be achieved = with an empty <plannedChange>.

I = don=E2=80=99t think this is covered in 5222.  The mechanism causes = the LoST server to send notifications to the client, but the client is = allowed to put any URI in the record, and it can add it to as many = records as it wants.
[GC] I thought we agreed on using one = generic URI per Client. Clients should be authenticated by the = Servers.
 An evil implementation could record URIs = against multiple targets that were unaware that the evil implementation = did it, until they got a large number of PUSH transactions they didn=E2=80= =99t expect or understand as a result of a large planned change.
[GC] Only authenticated Clients should be allowed to provide = URIs to be stored by the Servers.

The = proposed mechanism qualifies the client URI before its used in a planned = change.

Brian


On Aug 31, 2021, at 7:37 AM, Caron, Guy = <g.caron@bell.ca> wrote:

Well, this is not going in the direction I thought.

What is the purpose of deleting the URIs at = the Server post-validation?

Regarding = opening a new DoS, I guess I'm not following. Wouldn't this case be = covered by the security considerations in RFC 5222?

What you're proposing puts back significant load on the = Servers (a key consideration for creating planned-changes in the first = place) and complicates the mechanism.

Guy


-----Message d'origine-----
De : = Ecrit <ecrit-bounces@ietf.org> De la part de Brian Rosen Envoy=C3=A9 : 
30 ao=C3=BBt = 2021 11:22 =C3=80 : Randall Gellens <rg+ietf@randy.pensive.org> Cc 
: ECRIT <ecrit@ietf.org> Objet : [EXT]Re: [Ecrit] planned-changes: two 
questions

Answer 1: yes.  Since there is going to be a = revalidation, just deleting the setting seems right to me.
Answer 2: Up to server.  If I were implementing, I would = hash the real ID with the URI and some kind of predictable nonce. =  

We probably have to say more about = how the server identifies the client, so that replacement of the URI = works.  Could we say we use the domain of the URI (the entire = domain with all the dots) to identify the client, and anything can occur = after it (meaning a slash and whatever)?  If we do that, then how = would delete the notification?  Force there to be something other = than the domain (ugly).  Explicit delete request?

Hmmm, we=E2=80=99ve opened a DoS attack: a rogue client = stores a bunch of URIs for servers it wants to victimize.  In North = America we have a real simple solution for that, because we have a PKI, = so we know, for sure, who the client is, and could restrict who we allow = to store URIs, but that wouldn=E2=80=99t be true in general.  Also, = it would be nice for the client to have confidence the mechanism worked = before it needed it.

So
Let=E2=80= =99s add a =E2=80=9Ccommand=E2=80=9D to plannedChange in the findService = request.  
And, have the client have a response to = the notification which is the 
ID (json = with the 200)


The client = starts by sending a command of =E2=80=9Cinitialize=E2=80=9D.  The = domain is the identity of the client.  The response is an immediate = notification to the with whatever LI was in the request and an ID. =  The  response by the client (which is the notification web = server) is a piece of json containing the ID.  We can say that the = LI in this initialize command could be something simple like the Country = Code that wouldn=E2=80=99t get a planned change.

Thereafter, the LoST server (notification client) = periodically repeats this keepalive notification every day or week with = the initialize LI.  The client has to respond with the ID.

The regular notification request is a command = of =E2=80=9Cnotify=E2=80=9D.  The server ignores a request for = notification from an uninitialized client.
The = notification can be deleted with a command of =E2=80=9Cdelete=E2=80=9D. =  If you delete the initialize LI, then the server won=E2=80=99t = send any more notifications to that client and deletes all URIs it was = saving for that client.  The client would have to re-initialize to = reset.

Brian

On Aug 27, 2021, at 5:41 PM, Randall = Gellens <rg+ietf@randy.pensive.org> wrote:

I think we're moving to a model where:
- In a query, a client can request to be notified when the = location 
should be revalidated;
- In the response, the = server provides an ID which the client 
associates = with the location it just validated;
- The server sends a = notification to the URI, containing the ID;
- The client = revalidates each location with which that ID is associated.

Question 1: Does the server delete/inactivate = the URI once it has sent the notification?

Question 2: Presumably, when the client revalidates the = location(s), it will again request notification.  Does the server = return the same ID as before, or a different ID?  A different ID = could perhaps be useful in edge cases where the server didn't send or = the client didn't get the notification, but any utility seems small. =  If it's the same ID, then the answer to question 1 can be that the = URI remains active until the client asks to no longer be notified (by = sending an empty URI?).

--Randall

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
---------------------------------------------------------------= -------
-------- External Email: Please use caution when = opening links and 
attachments / Courriel externe: Soyez prudent avec les liens = et 
documents joints

---------------------------------------------------------------= ---------------
External Email: Please use caution when = opening links and attachments / Courriel externe: Soyez prudent avec les = liens et documents joints
 
<= /div>
 
<= /div>
 
External Email: Please use caution when = opening links and attachments / Courriel externe: Soyez prudent avec les = liens et documents = joints

= --Apple-Mail=_3995F505-7E3C-4431-91A5-3DF932A429DE-- From nobody Tue Aug 31 13:57:28 2021 Return-Path: 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 99F313A0D27 for ; Tue, 31 Aug 2021 13:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=bell.ca 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 XqbCSarPJapq for ; Tue, 31 Aug 2021 13:57:20 -0700 (PDT) Received: from ESA2-Wyn.bell.ca (esa2-wyn.bell.ca [67.69.243.180]) (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 01EC53A0D18 for ; Tue, 31 Aug 2021 13:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1630443440; x=1661979440; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=+kVvmSxHRv3hUvdPDCO74hoicApSbOSxIg9gz1QaXyg=; b=gzOPiV7H8+CeyqnxomX12R8Su7MhW5tsqXNxvCxIUwsjEt7/4mK30kE2 751JPH9Wloaln0WlPI5VQjyE8AUwsxaIU5NP1bSJ/MWkGVhAD9AtS3MV5 zHPPUv39NNPK7OzFXLWJd45wpIwPpikG9rdTJCjcuzYtw6ZRNmuWgbwux dpz3tlJUoYfpwb0QPRvf7bPJOiCbaVLticVWeDVmp84E+e7cQu1nzltvd I1jBFYTr7exvISkyZQeKoDAi68FWtR3nhLdICT7fjJOcgcCiG6HqUOSXW aWNfvEa+aDlWzA2TRYwHCAjJkvvJGX/x9aAWhZi1pL9mMOgVsyS5DxWE/ w==; IronPort-SDR: 2I2WzE0WS0O6D9oWfNmDqvgUjseViOZILaw1xHUeVTX+k3ZGXxlJe79DmN5J7BZhGj0Iu5rTyg r2zp0KErDXtA== Received: from dm5cch-d01.bellca.int.bell.ca (HELO DG1MBX04-WYN.bell.corp.bce.ca) ([198.235.102.31]) by esa02corp-wyn.bell.corp.bce.ca with ESMTP; 31 Aug 2021 16:57:18 -0400 Received: from DG12MBX02-WYN.bell.corp.bce.ca (142.182.18.47) by DG1MBX04-WYN.bell.corp.bce.ca (142.182.18.14) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Tue, 31 Aug 2021 16:57:18 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX02-WYN.bell.corp.bce.ca (142.182.18.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Tue, 31 Aug 2021 16:57:17 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Tue, 31 Aug 2021 16:57:17 -0400 From: "Caron, Guy" To: Brian Rosen CC: Randall Gellens , ECRIT Thread-Topic: [EXT]Re: [Ecrit] planned-changes: two questions Thread-Index: AQHXnbLZ8xDlKKXTXU23cWH8anqQbauNeTZQgABQ14D//8deMIAAkTMAgAACPYCAAAUMgIAAEX0AgAAK0gD//83iAIAASICA//+9V/A= Date: Tue, 31 Aug 2021 20:57:17 +0000 Message-ID: <0619e49202b146298d1bf7e01ec16fe2@bell.ca> References: <5577e2e6daa4405bbe12ef61675e1f55@bell.ca> <3AD58DEC-1DC9-4BC0-B55C-4E782E4AAA74@brianrosen.net> <9433989A-85D7-41B9-96EA-313ADC0F02CD@brianrosen.net> <851c82ef56714b8a917761d98234093a@bell.ca> <0F5C2109-77E1-495E-9768-94E28DC6A76A@brianrosen.net> In-Reply-To: <0F5C2109-77E1-495E-9768-94E28DC6A76A@brianrosen.net> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.112.70] Content-Type: multipart/alternative; boundary="_000_0619e49202b146298d1bf7e01ec16fe2bellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] planned-changes: two questions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 20:57:27 -0000 --_000_0619e49202b146298d1bf7e01ec16fe2bellca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHNpemUgb2YgdGhlIGxpc3QgY291bGQgYmUgYSBwb2xpY3kgYXQgdGhlIFNlcnZlci4NCg0K R3V5DQoNCkRlIDogQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0Pg0KRW52b3nDqSA6IDMx IGFvw7t0IDIwMjEgMTY6NTUNCsOAIDogQ2Fyb24sIEd1eSA8Zy5jYXJvbkBiZWxsLmNhPg0KQ2Mg OiBSYW5kYWxsIEdlbGxlbnMgPHJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmc+OyBFQ1JJVCA8ZWNy aXRAaWV0Zi5vcmc+DQpPYmpldCA6IFtFWFRdUmU6IFtFY3JpdF0gcGxhbm5lZC1jaGFuZ2VzOiB0 d28gcXVlc3Rpb25zDQoNCklmIHdlIGRpZCB0aGF0LCB3ZSB3b3VsZCBoYXZlIHRvIGltcGxlbWVu dCBsaW1pdCBhbmQgc3RhcnQgdG8gaGFuZGxlIGEgbGFyZ2UgbGlzdC4NCg0KQnJpYW4NCg0KDQoN Ck9uIEF1ZyAzMSwgMjAyMSwgYXQgNDozOCBQTSwgQ2Fyb24sIEd1eSA8Zy5jYXJvbkBiZWxsLmNh PG1haWx0bzpnLmNhcm9uQGJlbGwuY2E+PiB3cm90ZToNCg0KSWYgd2UgbWFrZSA8cmV2YWxpZGF0 ZUxvY2F0aW9uPiBhIGxpc3Qgb2YgSURzLCBvbmUgbm90aWZpY2F0aW9uIHBlciBVUkkgcGVyIHBs YW5uZWQgY2hhbmdlIHdvdWxkIGJlIHN1ZmZpY2llbnQuDQoNCkd1eQ0KDQpEZSA6IEJyaWFuIFJv c2VuIDxickBicmlhbnJvc2VuLm5ldDxtYWlsdG86YnJAYnJpYW5yb3Nlbi5uZXQ+Pg0KRW52b3nD qSA6IDMxIGFvw7t0IDIwMjEgMTU6MzUNCsOAIDogUmFuZGFsbCBHZWxsZW5zIDxyZytpZXRmQHJh bmR5LnBlbnNpdmUub3JnPG1haWx0bzpyZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnPj4NCkNjIDog Q2Fyb24sIEd1eSA8Zy5jYXJvbkBiZWxsLmNhPG1haWx0bzpnLmNhcm9uQGJlbGwuY2E+PjsgRUNS SVQgPGVjcml0QGlldGYub3JnPG1haWx0bzplY3JpdEBpZXRmLm9yZz4+DQpPYmpldCA6IFtFWFRd UmU6IFtFY3JpdF0gcGxhbm5lZC1jaGFuZ2VzOiB0d28gcXVlc3Rpb25zDQoNCk5vLg0KDQpUaGVy ZSBpcyBvbmUgVVJJLCBidXQgbWFueSBJRHMsIG9uZSBwZXIgdW5pcXVlIHJlY29yZCBhdCB0aGUg TG9TVCBzZXJ2ZXIgdGhhdCBpcyBpbnZvbHZlZCBpbiBhIHBsYW5uZWQgY2hhbmdlLiAgVGhlIG9u ZSBVUkkgd2lsbCByZWNlaXZlIG9uZSBub3RpZmljYXRpb24gcGVyIElEIGl0IGhhcyByZWdpc3Rl cmVkIGZvci4NCg0KDQoNCg0KDQpPbiBBdWcgMzEsIDIwMjEsIGF0IDI6NTYgUE0sIFJhbmRhbGwg R2VsbGVucyA8cmcraWV0ZkByYW5keS5wZW5zaXZlLm9yZzxtYWlsdG86cmcraWV0ZkByYW5keS5w ZW5zaXZlLm9yZz4+IHdyb3RlOg0KDQppIHVuZGVyc3RhbmQgdGhhdCB0aGUgY29uY2VybiBpcyBh bGxvd2luZyBhIGNsaWVudCB0byBsZXZlcmFnZSB0aGUgTG9TVCBzZXJ2ZXIgdG8gYXR0YWNrIGEg bGFyZ2UgbnVtYmVyIG9mIHRhcmdldHMsIEknbSBqdXN0IG5vdCBjbGVhciBtZWNoYW5pY2FsbHkg aG93IHN1Y2ggbGV2ZXJhZ2UgcG90ZW50aWFsbHkgd29ya3MuIEVhY2ggdmFsaWRhdGlvbiBxdWVy eSBjYW4gc3RvcmUgYSBVUkksIGFuZCB0aGF0IFVSSSBtYXkgZ2V0IGFzc29jaWF0ZWQgd2l0aCBh IGxhcmdlIG51bWJlciBvZiBsb2NhdGlvbnMuIE1heWJlIHRoZXJlJ3MgYSBzdHJlZXQgbmFtZSBj aGFuZ2Ugb3IgYW4gYW5uZXhhdGlvbi4gU28gbWF5YmUgdGhvdXNhbmRzIG9yIHRlbnMgb3IgaHVu ZHJlZHMgb2YgdGhvdXNhbmRzIG9mIGxvY2F0aW9ucyBhcmUgcG90ZW50aWFsbHkgaW52YWxpZGF0 ZWQuIFRoZXkgYWxsIGhhdmUgdGhlIHNhbWUgVVJJIGFzc29jaWF0ZWQgd2l0aCB0aGVtLCBzbyB0 aGUgTG9TVCBzZXJ2ZXIgY29ubmVjdHMgdG8gdGhlIFVSSSBvbmNlIGFuZCBQT1NUcyBvbmUgbm90 aWZpY2F0aW9uLCBubz8NCi0tUmFuZGFsbA0KT24gMzEgQXVnIDIwMjEsIGF0IDEwOjUzLCBCcmlh biBSb3NlbiB3cm90ZToNCk9mIGNvdXJzZSBhbiBhdHRhY2tlciB3b3VsZCBjb25jZWFsIGl0c2Vs ZiBhbmQgcmVnaXN0ZXIgbXVsdGlwbGUgVVJJcyB1bmRlciBkaWZmZXJlbnQgaWRlbnRpdGllcy4g IEJ1dCB0aGUgYmlnZ2VyICBwcm9ibGVtIGlzIHRoYXQgaWYgYSBsYXJnZSBwbGFubmVkIGNoYW5n ZSBvY2N1cnJlZCwgdGhlIHZpY3RpbSBjb3VsZCByZWNlaXZlIGEgbGFyZ2UgbnVtYmVyIG9mIG5v dGlmaWNhdGlvbnMgaXQgZGlkbuKAmXQgZXhwZWN0Lg0KDQpXaXRoIGEgdGVzdCB0cmFuc2l0aW9u LCB3ZSBrbm93IHRoYXQgdGhlIGNsaWVudCBleHBlY3RzIHRvIHNlZSBub3RpZmljYXRpb25zLCB3 ZSBvbmx5IG5lZWQgb25lIHBlciBVUkkgKHdlIGNvdWxkIHNwZWNpZnkgb25lIHBlciBkb21haW4g 4oCUIGFmdGVyIHRoZSBzY2hlbWUgYW5kIGJlZm9yZSB0aGUgZmlyc3Qgc2xhc2gpLiAgSWYgd2Ug ZG9u4oCZdCBnZXQgdGhlIElELCB3ZSBrbm93IG5vdCB0byBhbGxvdyB0aGF0IFVSSSB0byBiZSBw cm92aXNpb25lZC4gIFNvIGl04oCZcyBvbmUgdGVzdCB0cmFuc2FjdGlvbiB2cyBhIGxhcmdlIG51 bWJlciBvZiBwbGFubmVkIGNoYW5nZSB0cmFuc2FjdGlvbnMuDQoNCkJyaWFuDQoNCg0KDQoNCk9u IEF1ZyAzMSwgMjAyMSwgYXQgMTozNSBQTSwgUmFuZGFsbCBHZWxsZW5zIDxyZytpZXRmQHJhbmR5 LnBlbnNpdmUub3JnPG1haWx0bzpyZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnPj4gd3JvdGU6DQoN CklmIGEgbWFsaWNpb3VzIGNsaWVudCByZWdpc3RlcnMgYSBVUkkgdGhhdCBpcyBkZXNpZ25lZCB0 byBhdHRhY2sgYSB0aGlyZCBzaXRlLCB0aGUgdGVzdCB0cmFuc2FjdGlvbiBjYXVzZXMgdGhlIExv U1Qgc2VydmVyIHRvIGNvbm5lY3QgdG8gaXQgYW5kIFBPU1QgYSBjb21tYW5kLiBXaXRob3V0IGEg dGVzdCB0cmFuc2FjdGlvbiwgdGhlIExvU1Qgc2VydmVyIHN0b3JlcyB0aGUgVVJJIGFuZCBhdCBh IGZ1dHVyZSB0aW1lIGNvbm5lY3RzIHRvIGl0IGFuZCBzZW5kcyBhIGNvbW1hbmQuIEVpdGhlciB3 YXksIGEgTG9TVCBjbGllbnQgY2FuIHJlZ2lzdGVyIHBvdGVudGlhbGx5IG9uZSBVUkkgcGVyIHF1 ZXJpZWQgbG9jYXRpb24sIGFuZCBhIExvU1Qgc2VydmVyIHdpbGwgY29ubmVjdCB0byB0aGF0IFVS SSBhbmQgUE9TVCBhIG1lc3NhZ2UuIEEgcXVlcmllZCBsb2NhdGlvbiBjb3VsZCBiZSB0aWVkIHRv IG1hbnkgb3RoZXIgbG9jYXRpb25zLCBzbyB0aGVyZSBjb3VsZCBiZSBtYW55IGxvY2F0aW9ucyBm b3Igd2hpY2ggYSBjaGFuZ2Ugd291bGQgdHJpZ2dlciB0aGUgTG9TVCBzZXJ2ZXIgdG8gdXNlIHRo ZSBVUkksIGJ1dCBpcyB0aGF0IHdvcnNlPw0KLS1SYW5kYWxsDQpPbiAzMSBBdWcgMjAyMSwgYXQg MTA6MjcsIEJyaWFuIFJvc2VuIHdyb3RlOg0KSWYgdGhlIHdvcmsgZ3JvdXAgd2FudHMgdG8gaGF2 ZSB0aGUgTG9TVCBzZXJ2ZXIga2VlcCB0aGUgVVJJIHVudGlsIGV4cHJlc3NseSBkZWxldGVkLCB0 aGF04oCZcyBva2F5IHdpdGggbWUuDQoNCkF1dGhlbnRpY2F0aW5nIHRoZSBjbGllbnQgdG8gdGhl IHNlcnZlciBkb2VzbuKAmXQgbWVhbiB0aGUgVVJJIGlzIGF1dGhlbnRpY2F0ZWQuICBXZSBjYW7i gJl0IHJlc3RyaWN0IHRoZSBVUkkgdG8gYmUgdGhlIHNhbWUgZW50aXR5IGFzIHRoZSBjbGllbnQg cnVubmluZyB0aGUgTG9TVCB0cmFuc2FjdGlvbi4gIEFuZCB0aGUgY2xpZW50cyBhcmUgd2lkZSBy YW5naW5nLiAgQ291bGQgYmUgYW4gZW50ZXJwcmlzZSBydW5uaW5nIGl0cyBvd24gTElTIGZvciBl eGFtcGxlLiAgV2UgY2Fu4oCZdCBhc3N1bWUgdGhlIE5vcnRoIEFtZXJpY2FuIFBLSSBpcyB3b3Jr YWJsZSBldmVyeXdoZXJlLCBhbmQgZXZlbiB0aGF0IGRvZXNu4oCZdCBleHRlbmQgdG8gYW4gZW50 ZXJwcmlzZSBMSVMuICBJU1RNIHdlIGhhdmUgdG8gcnVuIGEgdGVzdCB0cmFuc2FjdGlvbiB3aXRo IHRoZSBub3RpZmljYXRpb24gc2VydmljZSB0byBtYWtlIHN1cmUgaXTigJlzIHdoYXQgd2UgdGhp bmsgaXQgaXMuDQoNCkJyaWFuDQoNCg0KDQoNCg0KT24gQXVnIDMxLCAyMDIxLCBhdCA5OjAxIEFN LCBDYXJvbiwgR3V5IDxnLmNhcm9uQGJlbGwuY2E8bWFpbHRvOmcuY2Fyb25AYmVsbC5jYT4+IHdy b3RlOg0KDQpJbmxpbmUuDQoNCkd1eQ0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRl IDogQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0PG1haWx0bzpickBicmlhbnJvc2VuLm5l dD4+DQpFbnZvecOpIDogMzEgYW/Du3QgMjAyMSAwODoxMQ0Kw4AgOiBDYXJvbiwgR3V5IDxnLmNh cm9uQGJlbGwuY2E8bWFpbHRvOmcuY2Fyb25AYmVsbC5jYT4+DQpDYyA6IFJhbmRhbGwgR2VsbGVu cyA8cmcraWV0ZkByYW5keS5wZW5zaXZlLm9yZzxtYWlsdG86cmcraWV0ZkByYW5keS5wZW5zaXZl Lm9yZz4+OyBFQ1JJVCA8ZWNyaXRAaWV0Zi5vcmc8bWFpbHRvOmVjcml0QGlldGYub3JnPj4NCk9i amV0IDogW0VYVF1SZTogW0Vjcml0XSBwbGFubmVkLWNoYW5nZXM6IHR3byBxdWVzdGlvbnMNCg0K WW91IGRlbGV0ZSB0aGUgVVJJIHdoZW4geW91IGRlbGV0ZSB0aGUgcmVjb3JkIGluIHRoZSBMSVMu DQpbR0NdIFRoYXQncyBmaW5lIGJ1dCB0aGF0IHdhcyBub3QgdGhlIHF1ZXN0aW9uIFJhbmRhbGwg cG9zZWQuIEhlIGFza2VkIHdoZXRoZXIgdGhlIFVSSSBpcyBkZWxldGVkIGFmdGVyIGEgbm90aWZp Y2F0aW9uLiBJIGFncmVlIHRoYXQgaWYgdGhlIENsaWVudCBkb2VzIG5vdCBob3N0IHRoZSBsb2Nh dGlvbiBhbnltb3JlIHRoYXQgdGhlIFVSSSBhc3NvY2lhdGVkIHdpdGggdGhhdCBsb2NhdGlvbiBp biB0aGUgU2VydmVyIHNob3VsZCBiZSBkZWxldGVkLiBUaGlzIGNvdWxkIGJlIGFjaGlldmVkIHdp dGggYW4gZW1wdHkgPHBsYW5uZWRDaGFuZ2U+Lg0KDQpJIGRvbuKAmXQgdGhpbmsgdGhpcyBpcyBj b3ZlcmVkIGluIDUyMjIuICBUaGUgbWVjaGFuaXNtIGNhdXNlcyB0aGUgTG9TVCBzZXJ2ZXIgdG8g c2VuZCBub3RpZmljYXRpb25zIHRvIHRoZSBjbGllbnQsIGJ1dCB0aGUgY2xpZW50IGlzIGFsbG93 ZWQgdG8gcHV0IGFueSBVUkkgaW4gdGhlIHJlY29yZCwgYW5kIGl0IGNhbiBhZGQgaXQgdG8gYXMg bWFueSByZWNvcmRzIGFzIGl0IHdhbnRzLg0KW0dDXSBJIHRob3VnaHQgd2UgYWdyZWVkIG9uIHVz aW5nIG9uZSBnZW5lcmljIFVSSSBwZXIgQ2xpZW50LiBDbGllbnRzIHNob3VsZCBiZSBhdXRoZW50 aWNhdGVkIGJ5IHRoZSBTZXJ2ZXJzLg0KIEFuIGV2aWwgaW1wbGVtZW50YXRpb24gY291bGQgcmVj b3JkIFVSSXMgYWdhaW5zdCBtdWx0aXBsZSB0YXJnZXRzIHRoYXQgd2VyZSB1bmF3YXJlIHRoYXQg dGhlIGV2aWwgaW1wbGVtZW50YXRpb24gZGlkIGl0LCB1bnRpbCB0aGV5IGdvdCBhIGxhcmdlIG51 bWJlciBvZiBQVVNIIHRyYW5zYWN0aW9ucyB0aGV5IGRpZG7igJl0IGV4cGVjdCBvciB1bmRlcnN0 YW5kIGFzIGEgcmVzdWx0IG9mIGEgbGFyZ2UgcGxhbm5lZCBjaGFuZ2UuDQpbR0NdIE9ubHkgYXV0 aGVudGljYXRlZCBDbGllbnRzIHNob3VsZCBiZSBhbGxvd2VkIHRvIHByb3ZpZGUgVVJJcyB0byBi ZSBzdG9yZWQgYnkgdGhlIFNlcnZlcnMuDQoNClRoZSBwcm9wb3NlZCBtZWNoYW5pc20gcXVhbGlm aWVzIHRoZSBjbGllbnQgVVJJIGJlZm9yZSBpdHMgdXNlZCBpbiBhIHBsYW5uZWQgY2hhbmdlLg0K DQpCcmlhbg0KDQoNCg0KT24gQXVnIDMxLCAyMDIxLCBhdCA3OjM3IEFNLCBDYXJvbiwgR3V5IDxn LmNhcm9uQGJlbGwuY2E8bWFpbHRvOmcuY2Fyb25AYmVsbC5jYT4+IHdyb3RlOg0KDQpXZWxsLCB0 aGlzIGlzIG5vdCBnb2luZyBpbiB0aGUgZGlyZWN0aW9uIEkgdGhvdWdodC4NCg0KV2hhdCBpcyB0 aGUgcHVycG9zZSBvZiBkZWxldGluZyB0aGUgVVJJcyBhdCB0aGUgU2VydmVyIHBvc3QtdmFsaWRh dGlvbj8NCg0KUmVnYXJkaW5nIG9wZW5pbmcgYSBuZXcgRG9TLCBJIGd1ZXNzIEknbSBub3QgZm9s bG93aW5nLiBXb3VsZG4ndCB0aGlzIGNhc2UgYmUgY292ZXJlZCBieSB0aGUgc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMgaW4gUkZDIDUyMjI/DQoNCldoYXQgeW91J3JlIHByb3Bvc2luZyBwdXRzIGJh Y2sgc2lnbmlmaWNhbnQgbG9hZCBvbiB0aGUgU2VydmVycyAoYSBrZXkgY29uc2lkZXJhdGlvbiBm b3IgY3JlYXRpbmcgcGxhbm5lZC1jaGFuZ2VzIGluIHRoZSBmaXJzdCBwbGFjZSkgYW5kIGNvbXBs aWNhdGVzIHRoZSBtZWNoYW5pc20uDQoNCkd1eQ0KDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUt LS0tLQ0KRGUgOiBFY3JpdCA8ZWNyaXQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZWNyaXQtYm91 bmNlc0BpZXRmLm9yZz4+IERlIGxhIHBhcnQgZGUgQnJpYW4gUm9zZW4gRW52b3nDqSA6DQozMCBh b8O7dCAyMDIxIDExOjIyIMOAIDogUmFuZGFsbCBHZWxsZW5zIDxyZytpZXRmQHJhbmR5LnBlbnNp dmUub3JnPG1haWx0bzpyZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnPj4gQ2MNCjogRUNSSVQgPGVj cml0QGlldGYub3JnPG1haWx0bzplY3JpdEBpZXRmLm9yZz4+IE9iamV0IDogW0VYVF1SZTogW0Vj cml0XSBwbGFubmVkLWNoYW5nZXM6IHR3bw0KcXVlc3Rpb25zDQoNCkFuc3dlciAxOiB5ZXMuICBT aW5jZSB0aGVyZSBpcyBnb2luZyB0byBiZSBhIHJldmFsaWRhdGlvbiwganVzdCBkZWxldGluZyB0 aGUgc2V0dGluZyBzZWVtcyByaWdodCB0byBtZS4NCkFuc3dlciAyOiBVcCB0byBzZXJ2ZXIuICBJ ZiBJIHdlcmUgaW1wbGVtZW50aW5nLCBJIHdvdWxkIGhhc2ggdGhlIHJlYWwgSUQgd2l0aCB0aGUg VVJJIGFuZCBzb21lIGtpbmQgb2YgcHJlZGljdGFibGUgbm9uY2UuDQoNCldlIHByb2JhYmx5IGhh dmUgdG8gc2F5IG1vcmUgYWJvdXQgaG93IHRoZSBzZXJ2ZXIgaWRlbnRpZmllcyB0aGUgY2xpZW50 LCBzbyB0aGF0IHJlcGxhY2VtZW50IG9mIHRoZSBVUkkgd29ya3MuICBDb3VsZCB3ZSBzYXkgd2Ug dXNlIHRoZSBkb21haW4gb2YgdGhlIFVSSSAodGhlIGVudGlyZSBkb21haW4gd2l0aCBhbGwgdGhl IGRvdHMpIHRvIGlkZW50aWZ5IHRoZSBjbGllbnQsIGFuZCBhbnl0aGluZyBjYW4gb2NjdXIgYWZ0 ZXIgaXQgKG1lYW5pbmcgYSBzbGFzaCBhbmQgd2hhdGV2ZXIpPyAgSWYgd2UgZG8gdGhhdCwgdGhl biBob3cgd291bGQgZGVsZXRlIHRoZSBub3RpZmljYXRpb24/ICBGb3JjZSB0aGVyZSB0byBiZSBz b21ldGhpbmcgb3RoZXIgdGhhbiB0aGUgZG9tYWluICh1Z2x5KS4gIEV4cGxpY2l0IGRlbGV0ZSBy ZXF1ZXN0Pw0KDQpIbW1tLCB3ZeKAmXZlIG9wZW5lZCBhIERvUyBhdHRhY2s6IGEgcm9ndWUgY2xp ZW50IHN0b3JlcyBhIGJ1bmNoIG9mIFVSSXMgZm9yIHNlcnZlcnMgaXQgd2FudHMgdG8gdmljdGlt aXplLiAgSW4gTm9ydGggQW1lcmljYSB3ZSBoYXZlIGEgcmVhbCBzaW1wbGUgc29sdXRpb24gZm9y IHRoYXQsIGJlY2F1c2Ugd2UgaGF2ZSBhIFBLSSwgc28gd2Uga25vdywgZm9yIHN1cmUsIHdobyB0 aGUgY2xpZW50IGlzLCBhbmQgY291bGQgcmVzdHJpY3Qgd2hvIHdlIGFsbG93IHRvIHN0b3JlIFVS SXMsIGJ1dCB0aGF0IHdvdWxkbuKAmXQgYmUgdHJ1ZSBpbiBnZW5lcmFsLiAgQWxzbywgaXQgd291 bGQgYmUgbmljZSBmb3IgdGhlIGNsaWVudCB0byBoYXZlIGNvbmZpZGVuY2UgdGhlIG1lY2hhbmlz bSB3b3JrZWQgYmVmb3JlIGl0IG5lZWRlZCBpdC4NCg0KU28NCkxldOKAmXMgYWRkIGEg4oCcY29t bWFuZOKAnSB0byBwbGFubmVkQ2hhbmdlIGluIHRoZSBmaW5kU2VydmljZSByZXF1ZXN0Lg0KQW5k LCBoYXZlIHRoZSBjbGllbnQgaGF2ZSBhIHJlc3BvbnNlIHRvIHRoZSBub3RpZmljYXRpb24gd2hp Y2ggaXMgdGhlDQpJRCAoanNvbiB3aXRoIHRoZSAyMDApDQoNCg0KVGhlIGNsaWVudCBzdGFydHMg Ynkgc2VuZGluZyBhIGNvbW1hbmQgb2Yg4oCcaW5pdGlhbGl6ZeKAnS4gIFRoZSBkb21haW4gaXMg dGhlIGlkZW50aXR5IG9mIHRoZSBjbGllbnQuICBUaGUgcmVzcG9uc2UgaXMgYW4gaW1tZWRpYXRl IG5vdGlmaWNhdGlvbiB0byB0aGUgd2l0aCB3aGF0ZXZlciBMSSB3YXMgaW4gdGhlIHJlcXVlc3Qg YW5kIGFuIElELiAgVGhlICByZXNwb25zZSBieSB0aGUgY2xpZW50ICh3aGljaCBpcyB0aGUgbm90 aWZpY2F0aW9uIHdlYiBzZXJ2ZXIpIGlzIGEgcGllY2Ugb2YganNvbiBjb250YWluaW5nIHRoZSBJ RC4gIFdlIGNhbiBzYXkgdGhhdCB0aGUgTEkgaW4gdGhpcyBpbml0aWFsaXplIGNvbW1hbmQgY291 bGQgYmUgc29tZXRoaW5nIHNpbXBsZSBsaWtlIHRoZSBDb3VudHJ5IENvZGUgdGhhdCB3b3VsZG7i gJl0IGdldCBhIHBsYW5uZWQgY2hhbmdlLg0KDQpUaGVyZWFmdGVyLCB0aGUgTG9TVCBzZXJ2ZXIg KG5vdGlmaWNhdGlvbiBjbGllbnQpIHBlcmlvZGljYWxseSByZXBlYXRzIHRoaXMga2VlcGFsaXZl IG5vdGlmaWNhdGlvbiBldmVyeSBkYXkgb3Igd2VlayB3aXRoIHRoZSBpbml0aWFsaXplIExJLiAg VGhlIGNsaWVudCBoYXMgdG8gcmVzcG9uZCB3aXRoIHRoZSBJRC4NCg0KVGhlIHJlZ3VsYXIgbm90 aWZpY2F0aW9uIHJlcXVlc3QgaXMgYSBjb21tYW5kIG9mIOKAnG5vdGlmeeKAnS4gIFRoZSBzZXJ2 ZXIgaWdub3JlcyBhIHJlcXVlc3QgZm9yIG5vdGlmaWNhdGlvbiBmcm9tIGFuIHVuaW5pdGlhbGl6 ZWQgY2xpZW50Lg0KVGhlIG5vdGlmaWNhdGlvbiBjYW4gYmUgZGVsZXRlZCB3aXRoIGEgY29tbWFu ZCBvZiDigJxkZWxldGXigJ0uICBJZiB5b3UgZGVsZXRlIHRoZSBpbml0aWFsaXplIExJLCB0aGVu IHRoZSBzZXJ2ZXIgd29u4oCZdCBzZW5kIGFueSBtb3JlIG5vdGlmaWNhdGlvbnMgdG8gdGhhdCBj bGllbnQgYW5kIGRlbGV0ZXMgYWxsIFVSSXMgaXQgd2FzIHNhdmluZyBmb3IgdGhhdCBjbGllbnQu ICBUaGUgY2xpZW50IHdvdWxkIGhhdmUgdG8gcmUtaW5pdGlhbGl6ZSB0byByZXNldC4NCg0KQnJp YW4NCg0KDQoNCk9uIEF1ZyAyNywgMjAyMSwgYXQgNTo0MSBQTSwgUmFuZGFsbCBHZWxsZW5zIDxy ZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnPG1haWx0bzpyZytpZXRmQHJhbmR5LnBlbnNpdmUub3Jn Pj4gd3JvdGU6DQoNCkkgdGhpbmsgd2UncmUgbW92aW5nIHRvIGEgbW9kZWwgd2hlcmU6DQotIElu IGEgcXVlcnksIGEgY2xpZW50IGNhbiByZXF1ZXN0IHRvIGJlIG5vdGlmaWVkIHdoZW4gdGhlIGxv Y2F0aW9uDQpzaG91bGQgYmUgcmV2YWxpZGF0ZWQ7DQotIEluIHRoZSByZXNwb25zZSwgdGhlIHNl cnZlciBwcm92aWRlcyBhbiBJRCB3aGljaCB0aGUgY2xpZW50DQphc3NvY2lhdGVzIHdpdGggdGhl IGxvY2F0aW9uIGl0IGp1c3QgdmFsaWRhdGVkOw0KLSBUaGUgc2VydmVyIHNlbmRzIGEgbm90aWZp Y2F0aW9uIHRvIHRoZSBVUkksIGNvbnRhaW5pbmcgdGhlIElEOw0KLSBUaGUgY2xpZW50IHJldmFs aWRhdGVzIGVhY2ggbG9jYXRpb24gd2l0aCB3aGljaCB0aGF0IElEIGlzIGFzc29jaWF0ZWQuDQoN ClF1ZXN0aW9uIDE6IERvZXMgdGhlIHNlcnZlciBkZWxldGUvaW5hY3RpdmF0ZSB0aGUgVVJJIG9u Y2UgaXQgaGFzIHNlbnQgdGhlIG5vdGlmaWNhdGlvbj8NCg0KUXVlc3Rpb24gMjogUHJlc3VtYWJs eSwgd2hlbiB0aGUgY2xpZW50IHJldmFsaWRhdGVzIHRoZSBsb2NhdGlvbihzKSwgaXQgd2lsbCBh Z2FpbiByZXF1ZXN0IG5vdGlmaWNhdGlvbi4gIERvZXMgdGhlIHNlcnZlciByZXR1cm4gdGhlIHNh bWUgSUQgYXMgYmVmb3JlLCBvciBhIGRpZmZlcmVudCBJRD8gIEEgZGlmZmVyZW50IElEIGNvdWxk IHBlcmhhcHMgYmUgdXNlZnVsIGluIGVkZ2UgY2FzZXMgd2hlcmUgdGhlIHNlcnZlciBkaWRuJ3Qg c2VuZCBvciB0aGUgY2xpZW50IGRpZG4ndCBnZXQgdGhlIG5vdGlmaWNhdGlvbiwgYnV0IGFueSB1 dGlsaXR5IHNlZW1zIHNtYWxsLiAgSWYgaXQncyB0aGUgc2FtZSBJRCwgdGhlbiB0aGUgYW5zd2Vy IHRvIHF1ZXN0aW9uIDEgY2FuIGJlIHRoYXQgdGhlIFVSSSByZW1haW5zIGFjdGl2ZSB1bnRpbCB0 aGUgY2xpZW50IGFza3MgdG8gbm8gbG9uZ2VyIGJlIG5vdGlmaWVkIChieSBzZW5kaW5nIGFuIGVt cHR5IFVSST8pLg0KDQotLVJhbmRhbGwNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkVjcml0IG1haWxpbmcgbGlzdA0KRWNyaXRAaWV0Zi5vcmc8bWFp bHRvOkVjcml0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9lY3JpdA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KRWNyaXQgbWFpbGluZyBsaXN0DQpFY3JpdEBpZXRmLm9yZzxtYWlsdG86RWNyaXRAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQotLS0tLS0tLSBFeHRlcm5hbCBFbWFpbDogUGxlYXNlIHVzZSBjYXV0aW9uIHdoZW4g b3BlbmluZyBsaW5rcyBhbmQNCmF0dGFjaG1lbnRzIC8gQ291cnJpZWwgZXh0ZXJuZTogU295ZXog cHJ1ZGVudCBhdmVjIGxlcyBsaWVucyBldA0KZG9jdW1lbnRzIGpvaW50cw0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCkV4dGVybmFsIEVtYWlsOiBQbGVhc2UgdXNlIGNhdXRpb24gd2hlbiBvcGVu aW5nIGxpbmtzIGFuZCBhdHRhY2htZW50cyAvIENvdXJyaWVsIGV4dGVybmU6IFNveWV6IHBydWRl bnQgYXZlYyBsZXMgbGllbnMgZXQgZG9jdW1lbnRzIGpvaW50cw0KDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkV4dGVybmFsIEVtYWlsOiBQbGVhc2UgdXNlIGNhdXRpb24g d2hlbiBvcGVuaW5nIGxpbmtzIGFuZCBhdHRhY2htZW50cyAvIENvdXJyaWVsIGV4dGVybmU6IFNv eWV6IHBydWRlbnQgYXZlYyBsZXMgbGllbnMgZXQgZG9jdW1lbnRzIGpvaW50cw0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KRXh0ZXJuYWwgRW1haWw6IFBsZWFzZSB1c2UgY2F1 dGlvbiB3aGVuIG9wZW5pbmcgbGlua3MgYW5kIGF0dGFjaG1lbnRzIC8gQ291cnJpZWwgZXh0ZXJu ZTogU295ZXogcHJ1ZGVudCBhdmVjIGxlcyBsaWVucyBldCBkb2N1bWVudHMgam9pbnRzDQo= --_000_0619e49202b146298d1bf7e01ec16fe2bellca_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0K CXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFt ZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRlItQ0EiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhlIHNp emUgb2YgdGhlIGxpc3QgY291bGQgYmUgYSBwb2xpY3kgYXQgdGhlIFNlcnZlci48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ R3V5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkRlJm5ic3A7Ojwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEJyaWFuIFJvc2VuICZsdDtickBi cmlhbnJvc2VuLm5ldCZndDsNCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiAzMSBhb8O7dCAy MDIxIDE2OjU1PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBDYXJvbiwgR3V5ICZsdDtnLmNhcm9uQGJl bGwuY2EmZ3Q7PGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBSYW5kYWxsIEdlbGxlbnMgJmx0O3JnJiM0 MztpZXRmQHJhbmR5LnBlbnNpdmUub3JnJmd0OzsgRUNSSVQgJmx0O2Vjcml0QGlldGYub3JnJmd0 Ozxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gW0VYVF1SZTogW0Vjcml0XSBwbGFubmVkLWNoYW5n ZXM6IHR3byBxdWVzdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JZiB3ZSBkaWQgdGhhdCwgd2Ugd291bGQgaGF2ZSB0byBpbXBsZW1lbnQgbGltaXQg YW5kIHN0YXJ0IHRvIGhhbmRsZSBhIGxhcmdlIGxpc3QuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnJpYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gQXVnIDMxLCAyMDIxLCBhdCA0OjM4IFBNLCBD YXJvbiwgR3V5ICZsdDs8YSBocmVmPSJtYWlsdG86Zy5jYXJvbkBiZWxsLmNhIj5nLmNhcm9uQGJl bGwuY2E8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SWYg d2UgbWFrZSAmbHQ7cmV2YWxpZGF0ZUxvY2F0aW9uJmd0OyBhIGxpc3Qgb2YgSURzLCBvbmUgbm90 aWZpY2F0aW9uIHBlciBVUkkgcGVyIHBsYW5uZWQgY2hhbmdlIHdvdWxkIGJlIHN1ZmZpY2llbnQu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkd1eTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUNBIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkJyaWFu DQogUm9zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpickBicmlhbnJvc2VuLm5ldCI+YnJAYnJpYW5y b3Nlbi5uZXQ8L2E+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+MzEgYW/Du3QgMjAyMSAxNTozNTxicj4NCjxiPsOA Jm5ic3A7OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+UmFuZGFsbCBHZWxsZW5zICZsdDs8YSBocmVmPSJtYWlsdG86cmcmIzQzO2lldGZAcmFuZHku cGVuc2l2ZS5vcmciPnJnJiM0MztpZXRmQHJhbmR5LnBlbnNpdmUub3JnPC9hPiZndDs8YnI+DQo8 Yj5DYyZuYnNwOzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPkNhcm9uLCBHdXkgJmx0OzxhIGhyZWY9Im1haWx0bzpnLmNhcm9uQGJlbGwuY2EiPmcu Y2Fyb25AYmVsbC5jYTwvYT4mZ3Q7OyBFQ1JJVCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVjcml0QGll dGYub3JnIj5lY3JpdEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5bRVhUXVJlOiBb RWNyaXRdIHBsYW5uZWQtY2hhbmdlczogdHdvIHF1ZXN0aW9uczwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPk5vLiAmbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIj5UaGVyZSBpcyBvbmUgVVJJLCBidXQgbWFueSBJRHMsIG9uZSBwZXIgdW5p cXVlIHJlY29yZCBhdCB0aGUgTG9TVCBzZXJ2ZXIgdGhhdCBpcyBpbnZvbHZlZCBpbiBhIHBsYW5u ZWQgY2hhbmdlLiAmbmJzcDtUaGUgb25lIFVSSSB3aWxsIHJlY2VpdmUgb25lIG5vdGlmaWNhdGlv biBwZXIgSUQgaXQgaGFzIHJlZ2lzdGVyZWQgZm9yLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUNBIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj48YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+T24gQXVnIDMxLCAyMDIxLCBhdCAyOjU2IFBNLCBSYW5k YWxsIEdlbGxlbnMgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cmcmIzQzO2lldGZAcmFuZHku cGVuc2l2ZS5vcmciPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6cHVycGxlIj5yZyYj NDM7aWV0ZkByYW5keS5wZW5zaXZlLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tQ0EiPiZn dDsgd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+aSB1bmRlcnN0YW5kIHRoYXQgdGhlIGNvbmNl cm4gaXMgYWxsb3dpbmcgYSBjbGllbnQgdG8gbGV2ZXJhZ2UgdGhlIExvU1Qgc2VydmVyIHRvIGF0 dGFjayBhIGxhcmdlIG51bWJlciBvZiB0YXJnZXRzLCBJJ20ganVzdCBub3QgY2xlYXIgbWVjaGFu aWNhbGx5IGhvdyBzdWNoIGxldmVyYWdlIHBvdGVudGlhbGx5DQogd29ya3MuIEVhY2ggdmFsaWRh dGlvbiBxdWVyeSBjYW4gc3RvcmUgYSBVUkksIGFuZCB0aGF0IFVSSSBtYXkgZ2V0IGFzc29jaWF0 ZWQgd2l0aCBhIGxhcmdlIG51bWJlciBvZiBsb2NhdGlvbnMuIE1heWJlIHRoZXJlJ3MgYSBzdHJl ZXQgbmFtZSBjaGFuZ2Ugb3IgYW4gYW5uZXhhdGlvbi4gU28gbWF5YmUgdGhvdXNhbmRzIG9yIHRl bnMgb3IgaHVuZHJlZHMgb2YgdGhvdXNhbmRzIG9mIGxvY2F0aW9ucyBhcmUgcG90ZW50aWFsbHkg aW52YWxpZGF0ZWQuDQogVGhleSBhbGwgaGF2ZSB0aGUgc2FtZSBVUkkgYXNzb2NpYXRlZCB3aXRo IHRoZW0sIHNvIHRoZSBMb1NUIHNlcnZlciBjb25uZWN0cyB0byB0aGUgVVJJIG9uY2UgYW5kIFBP U1RzIG9uZSBub3RpZmljYXRpb24sIG5vPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+LS1SYW5kYWxsPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj5PbiAzMSBBdWcgMjAyMSwgYXQgMTA6NTMsIEJyaWFuIFJvc2VuIHdyb3RlOjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgIzc3Nzc3NyAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDQuMHB0O21hcmdpbi1sZWZ0OjBjbTttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207 bWFyZ2luLWJvdHRvbTozLjc1cHQiPg0KPGRpdiBpZD0iMkY0Mjc0MkMtNEY1NS00RTI5LThCQjct MDA4Mjk2ODY2QTUxIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM3Nzc3NzciPk9mIGNvdXJzZSBhbiBhdHRhY2tlciB3b3VsZCBjb25jZWFsIGl0 c2VsZiBhbmQgcmVnaXN0ZXIgbXVsdGlwbGUgVVJJcyB1bmRlciBkaWZmZXJlbnQgaWRlbnRpdGll cy4gJm5ic3A7QnV0IHRoZSBiaWdnZXIgJm5ic3A7cHJvYmxlbSBpcyB0aGF0IGlmIGEgbGFyZ2Ug cGxhbm5lZCBjaGFuZ2Ugb2NjdXJyZWQsDQogdGhlIHZpY3RpbSBjb3VsZCByZWNlaXZlIGEgbGFy Z2UgbnVtYmVyIG9mIG5vdGlmaWNhdGlvbnMgaXQgZGlkbuKAmXQgZXhwZWN0Ljwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM3Nzc3NzciPldpdGggYSB0ZXN0IHRyYW5zaXRpb24sIHdlIGtub3cgdGhhdCB0aGUg Y2xpZW50IGV4cGVjdHMgdG8gc2VlIG5vdGlmaWNhdGlvbnMsIHdlIG9ubHkgbmVlZCBvbmUgcGVy IFVSSSAod2UgY291bGQgc3BlY2lmeSBvbmUgcGVyIGRvbWFpbiDigJQgYWZ0ZXIgdGhlIHNjaGVt ZSBhbmQgYmVmb3JlDQogdGhlIGZpcnN0IHNsYXNoKS4gJm5ic3A7SWYgd2UgZG9u4oCZdCBnZXQg dGhlIElELCB3ZSBrbm93IG5vdCB0byBhbGxvdyB0aGF0IFVSSSB0byBiZSBwcm92aXNpb25lZC4g Jm5ic3A7U28gaXTigJlzIG9uZSB0ZXN0IHRyYW5zYWN0aW9uIHZzIGEgbGFyZ2UgbnVtYmVyIG9m IHBsYW5uZWQgY2hhbmdlIHRyYW5zYWN0aW9ucy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6Izc3Nzc3NyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3 Nzc3NzciPkJyaWFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+PGJyPg0KPGJyPg0KPGJyPg0K PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPk9uIEF1ZyAzMSwgMjAyMSwgYXQg MTozNSBQTSwgUmFuZGFsbCBHZWxsZW5zICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnJnJiM0 MztpZXRmQHJhbmR5LnBlbnNpdmUub3JnIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj5yZyYjNDM7 aWV0ZkByYW5keS5wZW5zaXZlLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3Nzci PiZndDsNCiB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPklm IGEgbWFsaWNpb3VzIGNsaWVudCByZWdpc3RlcnMgYSBVUkkgdGhhdCBpcyBkZXNpZ25lZCB0byBh dHRhY2sgYSB0aGlyZCBzaXRlLCB0aGUgdGVzdCB0cmFuc2FjdGlvbiBjYXVzZXMgdGhlIExvU1Qg c2VydmVyIHRvIGNvbm5lY3QgdG8gaXQgYW5kIFBPU1QgYSBjb21tYW5kLiBXaXRob3V0DQogYSB0 ZXN0IHRyYW5zYWN0aW9uLCB0aGUgTG9TVCBzZXJ2ZXIgc3RvcmVzIHRoZSBVUkkgYW5kIGF0IGEg ZnV0dXJlIHRpbWUgY29ubmVjdHMgdG8gaXQgYW5kIHNlbmRzIGEgY29tbWFuZC4gRWl0aGVyIHdh eSwgYSBMb1NUIGNsaWVudCBjYW4gcmVnaXN0ZXIgcG90ZW50aWFsbHkgb25lIFVSSSBwZXIgcXVl cmllZCBsb2NhdGlvbiwgYW5kIGEgTG9TVCBzZXJ2ZXIgd2lsbCBjb25uZWN0IHRvIHRoYXQgVVJJ IGFuZCBQT1NUIGEgbWVzc2FnZS4gQSBxdWVyaWVkDQogbG9jYXRpb24gY291bGQgYmUgdGllZCB0 byBtYW55IG90aGVyIGxvY2F0aW9ucywgc28gdGhlcmUgY291bGQgYmUgbWFueSBsb2NhdGlvbnMg Zm9yIHdoaWNoIGEgY2hhbmdlIHdvdWxkIHRyaWdnZXIgdGhlIExvU1Qgc2VydmVyIHRvIHVzZSB0 aGUgVVJJLCBidXQgaXMgdGhhdCB3b3JzZT88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+LS1S YW5kYWxsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPk9uIDMxIEF1ZyAyMDIxLCBhdCAxMDoy NywgQnJpYW4gUm9zZW4gd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjNzc3 Nzc3IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQ7bWFyZ2luLWxlZnQ6MGNtO21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjMuNzVwdCI+DQo8ZGl2 IGlkPSI4NTE2Nzg4Mi00NzA3LTREQTctQUYwNC1ENzZFREZBM0VDMUYiPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+SWYgdGhlIHdv cmsgZ3JvdXAgd2FudHMgdG8gaGF2ZSB0aGUgTG9TVCBzZXJ2ZXIga2VlcCB0aGUgVVJJIHVudGls IGV4cHJlc3NseSBkZWxldGVkLCB0aGF04oCZcyBva2F5IHdpdGggbWUuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6Izc3Nzc3NyI+QXV0aGVudGljYXRpbmcgdGhlIGNsaWVudCB0byB0aGUgc2VydmVyIGRvZXNu 4oCZdCBtZWFuIHRoZSBVUkkgaXMgYXV0aGVudGljYXRlZC4gJm5ic3A7V2UgY2Fu4oCZdCByZXN0 cmljdCB0aGUgVVJJIHRvIGJlIHRoZSBzYW1lIGVudGl0eSBhcyB0aGUgY2xpZW50IHJ1bm5pbmcg dGhlIExvU1QgdHJhbnNhY3Rpb24uDQogJm5ic3A7QW5kIHRoZSBjbGllbnRzIGFyZSB3aWRlIHJh bmdpbmcuICZuYnNwO0NvdWxkIGJlIGFuIGVudGVycHJpc2UgcnVubmluZyBpdHMgb3duIExJUyBm b3IgZXhhbXBsZS4gJm5ic3A7V2UgY2Fu4oCZdCBhc3N1bWUgdGhlIE5vcnRoIEFtZXJpY2FuIFBL SSBpcyB3b3JrYWJsZSBldmVyeXdoZXJlLCBhbmQgZXZlbiB0aGF0IGRvZXNu4oCZdCBleHRlbmQg dG8gYW4gZW50ZXJwcmlzZSBMSVMuICZuYnNwO0lTVE0gd2UgaGF2ZSB0byBydW4gYSB0ZXN0IHRy YW5zYWN0aW9uIHdpdGggdGhlDQogbm90aWZpY2F0aW9uIHNlcnZpY2UgdG8gbWFrZSBzdXJlIGl0 4oCZcyB3aGF0IHdlIHRoaW5rIGl0IGlzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNzc3Nzc3Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3 NyI+QnJpYW48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+PGJyPg0KPGJyPg0KPGJy Pg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPk9uIEF1ZyAzMSwgMjAyMSwg YXQgOTowMSBBTSwgQ2Fyb24sIEd1eSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpnLmNhcm9u QGJlbGwuY2EiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGUiPmcuY2Fyb25AYmVsbC5jYTwvc3Bhbj48 L2E+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPiZndDsNCiB3cm90ZTo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+SW5saW5lLjxicj4NCjxicj4NCkd1eTxicj4NCjxicj4N Ci0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxicj4NCkRlJm5ic3A7OiBCcmlhbiBSb3NlbiAm bHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpickBicmlhbnJvc2VuLm5ldCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj5ickBicmlhbnJvc2VuLm5ldDwvc3Bhbj48 L2E+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+Jmd0OzxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQpFbnZvecOp Jm5ic3A7OiAzMSBhb8O7dCAyMDIxIDA4OjExPGJyPg0Kw4AmbmJzcDs6IENhcm9uLCBHdXkgJmx0 Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86Zy5jYXJvbkBiZWxsLmNhIj48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGUiPmcuY2Fyb25AYmVsbC5jYTwvc3Bhbj48L2E+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+Jmd0Ozxicj4NCkNjJm5i c3A7OiBSYW5kYWxsIEdlbGxlbnMgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cmcmIzQzO2ll dGZAcmFuZHkucGVuc2l2ZS5vcmciPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OnB1cnBsZSI+cmcmIzQzO2lldGZAcmFuZHkucGVuc2l2ZS5vcmc8L3NwYW4+PC9hPjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPiZndDs7DQogRUNSSVQgJmx0Ozwv c3Bhbj48YSBocmVmPSJtYWlsdG86ZWNyaXRAaWV0Zi5vcmciPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOnB1cnBsZSI+ZWNyaXRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPiZndDs8YnI+DQpPYmpldCZuYnNw OzogW0VYVF1SZTogW0Vjcml0XSBwbGFubmVkLWNoYW5nZXM6IHR3byBxdWVzdGlvbnM8YnI+DQo8 YnI+DQpZb3UgZGVsZXRlIHRoZSBVUkkgd2hlbiB5b3UgZGVsZXRlIHRoZSByZWNvcmQgaW4gdGhl IExJUy48YnI+DQpbR0NdIFRoYXQncyBmaW5lIGJ1dCB0aGF0IHdhcyBub3QgdGhlIHF1ZXN0aW9u IFJhbmRhbGwgcG9zZWQuIEhlIGFza2VkIHdoZXRoZXIgdGhlIFVSSSBpcyBkZWxldGVkIGFmdGVy IGEgbm90aWZpY2F0aW9uLiBJIGFncmVlIHRoYXQgaWYgdGhlIENsaWVudCBkb2VzIG5vdCBob3N0 IHRoZSBsb2NhdGlvbiBhbnltb3JlIHRoYXQgdGhlIFVSSSBhc3NvY2lhdGVkIHdpdGggdGhhdCBs b2NhdGlvbiBpbiB0aGUgU2VydmVyIHNob3VsZCBiZSBkZWxldGVkLg0KIFRoaXMgY291bGQgYmUg YWNoaWV2ZWQgd2l0aCBhbiBlbXB0eSAmbHQ7cGxhbm5lZENoYW5nZSZndDsuPGJyPg0KPGJyPg0K SSBkb27igJl0IHRoaW5rIHRoaXMgaXMgY292ZXJlZCBpbiA1MjIyLiAmbmJzcDtUaGUgbWVjaGFu aXNtIGNhdXNlcyB0aGUgTG9TVCBzZXJ2ZXIgdG8gc2VuZCBub3RpZmljYXRpb25zIHRvIHRoZSBj bGllbnQsIGJ1dCB0aGUgY2xpZW50IGlzIGFsbG93ZWQgdG8gcHV0IGFueSBVUkkgaW4gdGhlIHJl Y29yZCwgYW5kIGl0IGNhbiBhZGQgaXQgdG8gYXMgbWFueSByZWNvcmRzIGFzIGl0IHdhbnRzLjxi cj4NCltHQ10gSSB0aG91Z2h0IHdlIGFncmVlZCBvbiB1c2luZyBvbmUgZ2VuZXJpYyBVUkkgcGVy IENsaWVudC4gQ2xpZW50cyBzaG91bGQgYmUgYXV0aGVudGljYXRlZCBieSB0aGUgU2VydmVycy48 YnI+DQombmJzcDtBbiBldmlsIGltcGxlbWVudGF0aW9uIGNvdWxkIHJlY29yZCBVUklzIGFnYWlu c3QgbXVsdGlwbGUgdGFyZ2V0cyB0aGF0IHdlcmUgdW5hd2FyZSB0aGF0IHRoZSBldmlsIGltcGxl bWVudGF0aW9uIGRpZCBpdCwgdW50aWwgdGhleSBnb3QgYSBsYXJnZSBudW1iZXIgb2YgUFVTSCB0 cmFuc2FjdGlvbnMgdGhleSBkaWRu4oCZdCBleHBlY3Qgb3IgdW5kZXJzdGFuZCBhcyBhIHJlc3Vs dCBvZiBhIGxhcmdlIHBsYW5uZWQgY2hhbmdlLjxicj4NCltHQ10gT25seSBhdXRoZW50aWNhdGVk IENsaWVudHMgc2hvdWxkIGJlIGFsbG93ZWQgdG8gcHJvdmlkZSBVUklzIHRvIGJlIHN0b3JlZCBi eSB0aGUgU2VydmVycy48YnI+DQo8YnI+DQpUaGUgcHJvcG9zZWQgbWVjaGFuaXNtIHF1YWxpZmll cyB0aGUgY2xpZW50IFVSSSBiZWZvcmUgaXRzIHVzZWQgaW4gYSBwbGFubmVkIGNoYW5nZS48YnI+ DQo8YnI+DQpCcmlhbjxicj4NCjxicj4NCjxicj4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+T24gQXVnIDMxLCAyMDIxLCBhdCA3OjM3IEFN LCBDYXJvbiwgR3V5ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmcuY2Fyb25AYmVsbC5jYSI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj5nLmNhcm9uQGJlbGwu Y2E8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3Nzci PiZndDsNCiB3cm90ZTo8YnI+DQo8YnI+DQpXZWxsLCB0aGlzIGlzIG5vdCBnb2luZyBpbiB0aGUg ZGlyZWN0aW9uIEkgdGhvdWdodC48YnI+DQo8YnI+DQpXaGF0IGlzIHRoZSBwdXJwb3NlIG9mIGRl bGV0aW5nIHRoZSBVUklzIGF0IHRoZSBTZXJ2ZXIgcG9zdC12YWxpZGF0aW9uPzxicj4NCjxicj4N ClJlZ2FyZGluZyBvcGVuaW5nIGEgbmV3IERvUywgSSBndWVzcyBJJ20gbm90IGZvbGxvd2luZy4g V291bGRuJ3QgdGhpcyBjYXNlIGJlIGNvdmVyZWQgYnkgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIGluIFJGQyA1MjIyPzxicj4NCjxicj4NCldoYXQgeW91J3JlIHByb3Bvc2luZyBwdXRzIGJh Y2sgc2lnbmlmaWNhbnQgbG9hZCBvbiB0aGUgU2VydmVycyAoYSBrZXkgY29uc2lkZXJhdGlvbiBm b3IgY3JlYXRpbmcgcGxhbm5lZC1jaGFuZ2VzIGluIHRoZSBmaXJzdCBwbGFjZSkgYW5kIGNvbXBs aWNhdGVzIHRoZSBtZWNoYW5pc20uPGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6Izc3Nzc3NyI+R3V5PGJyPg0KPGJyPg0KPGJyPg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2lu ZS0tLS0tPGJyPg0KRGUgOiBFY3JpdCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzplY3JpdC1i b3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZSI+ZWNyaXQtYm91 bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij4m Z3Q7IERlIGxhDQogcGFydCBkZSBCcmlhbiBSb3NlbiBFbnZvecOpIDo8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KMzAgYW/Du3QgMjAyMSAxMToy MiDDgCA6IFJhbmRhbGwgR2VsbGVucyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpyZyYjNDM7 aWV0ZkByYW5keS5wZW5zaXZlLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGUiPnJn JiM0MztpZXRmQHJhbmR5LnBlbnNpdmUub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiM3Nzc3NzciPiZndDsNCiBDYzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48YnI+DQo6IEVDUklUICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmVj cml0QGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZSI+ZWNyaXRAaWV0Zi5v cmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+Jmd0OyBPYmpldCA6 IFtFWFRdUmU6IFtFY3JpdF0NCiBwbGFubmVkLWNoYW5nZXM6IHR3bzxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQpxdWVzdGlvbnM8YnI+DQo8YnI+ DQpBbnN3ZXIgMTogeWVzLiAmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6Izc3Nzc3NyI+U2luY2UgdGhlcmUgaXMgZ29pbmcgdG8gYmUgYSByZXZhbGlkYXRp b24sIGp1c3QgZGVsZXRpbmcgdGhlIHNldHRpbmcgc2VlbXMgcmlnaHQgdG8gbWUuPGJyPg0KQW5z d2VyIDI6IFVwIHRvIHNlcnZlci4gJm5ic3A7SWYgSSB3ZXJlIGltcGxlbWVudGluZywgSSB3b3Vs ZCBoYXNoIHRoZSByZWFsIElEIHdpdGggdGhlIFVSSSBhbmQgc29tZSBraW5kIG9mIHByZWRpY3Rh YmxlIG5vbmNlLiAmbmJzcDs8YnI+DQo8YnI+DQpXZSBwcm9iYWJseSBoYXZlIHRvIHNheSBtb3Jl IGFib3V0IGhvdyB0aGUgc2VydmVyIGlkZW50aWZpZXMgdGhlIGNsaWVudCwgc28gdGhhdCByZXBs YWNlbWVudCBvZiB0aGUgVVJJIHdvcmtzLiAmbmJzcDtDb3VsZCB3ZSBzYXkgd2UgdXNlIHRoZSBk b21haW4gb2YgdGhlIFVSSSAodGhlIGVudGlyZSBkb21haW4gd2l0aCBhbGwgdGhlIGRvdHMpIHRv IGlkZW50aWZ5IHRoZSBjbGllbnQsIGFuZCBhbnl0aGluZyBjYW4gb2NjdXIgYWZ0ZXIgaXQgKG1l YW5pbmcNCiBhIHNsYXNoIGFuZCB3aGF0ZXZlcik/ICZuYnNwO0lmIHdlIGRvIHRoYXQsIHRoZW4g aG93IHdvdWxkIGRlbGV0ZSB0aGUgbm90aWZpY2F0aW9uPyAmbmJzcDtGb3JjZSB0aGVyZSB0byBi ZSBzb21ldGhpbmcgb3RoZXIgdGhhbiB0aGUgZG9tYWluICh1Z2x5KS4gJm5ic3A7RXhwbGljaXQg ZGVsZXRlIHJlcXVlc3Q/PGJyPg0KPGJyPg0KSG1tbSwgd2XigJl2ZSBvcGVuZWQgYSBEb1MgYXR0 YWNrOiBhIHJvZ3VlIGNsaWVudCBzdG9yZXMgYSBidW5jaCBvZiBVUklzIGZvciBzZXJ2ZXJzIGl0 IHdhbnRzIHRvIHZpY3RpbWl6ZS4gJm5ic3A7SW4gTm9ydGggQW1lcmljYSB3ZSBoYXZlIGEgcmVh bCBzaW1wbGUgc29sdXRpb24gZm9yIHRoYXQsIGJlY2F1c2Ugd2UgaGF2ZSBhIFBLSSwgc28gd2Ug a25vdywgZm9yIHN1cmUsIHdobyB0aGUgY2xpZW50IGlzLCBhbmQgY291bGQgcmVzdHJpY3Qgd2hv IHdlIGFsbG93DQogdG8gc3RvcmUgVVJJcywgYnV0IHRoYXQgd291bGRu4oCZdCBiZSB0cnVlIGlu IGdlbmVyYWwuICZuYnNwO0Fsc28sIGl0IHdvdWxkIGJlIG5pY2UgZm9yIHRoZSBjbGllbnQgdG8g aGF2ZSBjb25maWRlbmNlIHRoZSBtZWNoYW5pc20gd29ya2VkIGJlZm9yZSBpdCBuZWVkZWQgaXQu PGJyPg0KPGJyPg0KU288YnI+DQpMZXTigJlzIGFkZCBhIOKAnGNvbW1hbmTigJ0gdG8gcGxhbm5l ZENoYW5nZSBpbiB0aGUgZmluZFNlcnZpY2UgcmVxdWVzdC4gJm5ic3A7PGJyPg0KQW5kLCBoYXZl IHRoZSBjbGllbnQgaGF2ZSBhIHJlc3BvbnNlIHRvIHRoZSBub3RpZmljYXRpb24gd2hpY2ggaXMg dGhlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4N CklEIChqc29uIHdpdGggdGhlIDIwMCk8YnI+DQo8YnI+DQo8YnI+DQpUaGUgY2xpZW50IHN0YXJ0 cyBieSBzZW5kaW5nIGEgY29tbWFuZCBvZiDigJxpbml0aWFsaXpl4oCdLiAmbmJzcDtUaGUgZG9t YWluIGlzIHRoZSBpZGVudGl0eSBvZiB0aGUgY2xpZW50LiAmbmJzcDtUaGUgcmVzcG9uc2UgaXMg YW4gaW1tZWRpYXRlIG5vdGlmaWNhdGlvbiB0byB0aGUgd2l0aCB3aGF0ZXZlciBMSSB3YXMgaW4g dGhlIHJlcXVlc3QgYW5kIGFuIElELiAmbmJzcDtUaGUgJm5ic3A7cmVzcG9uc2UgYnkgdGhlIGNs aWVudCAod2hpY2ggaXMgdGhlIG5vdGlmaWNhdGlvbiB3ZWIgc2VydmVyKQ0KIGlzIGEgcGllY2Ug b2YganNvbiBjb250YWluaW5nIHRoZSBJRC4gJm5ic3A7V2UgY2FuIHNheSB0aGF0IHRoZSBMSSBp biB0aGlzIGluaXRpYWxpemUgY29tbWFuZCBjb3VsZCBiZSBzb21ldGhpbmcgc2ltcGxlIGxpa2Ug dGhlIENvdW50cnkgQ29kZSB0aGF0IHdvdWxkbuKAmXQgZ2V0IGEgcGxhbm5lZCBjaGFuZ2UuPGJy Pg0KPGJyPg0KVGhlcmVhZnRlciwgdGhlIExvU1Qgc2VydmVyIChub3RpZmljYXRpb24gY2xpZW50 KSBwZXJpb2RpY2FsbHkgcmVwZWF0cyB0aGlzIGtlZXBhbGl2ZSBub3RpZmljYXRpb24gZXZlcnkg ZGF5IG9yIHdlZWsgd2l0aCB0aGUgaW5pdGlhbGl6ZSBMSS4gJm5ic3A7VGhlIGNsaWVudCBoYXMg dG8gcmVzcG9uZCB3aXRoIHRoZSBJRC48YnI+DQo8YnI+DQpUaGUgcmVndWxhciBub3RpZmljYXRp b24gcmVxdWVzdCBpcyBhIGNvbW1hbmQgb2Yg4oCcbm90aWZ54oCdLiAmbmJzcDtUaGUgc2VydmVy IGlnbm9yZXMgYSByZXF1ZXN0IGZvciBub3RpZmljYXRpb24gZnJvbSBhbiB1bmluaXRpYWxpemVk IGNsaWVudC48YnI+DQpUaGUgbm90aWZpY2F0aW9uIGNhbiBiZSBkZWxldGVkIHdpdGggYSBjb21t YW5kIG9mIOKAnGRlbGV0ZeKAnS4gJm5ic3A7SWYgeW91IGRlbGV0ZSB0aGUgaW5pdGlhbGl6ZSBM SSwgdGhlbiB0aGUgc2VydmVyIHdvbuKAmXQgc2VuZCBhbnkgbW9yZSBub3RpZmljYXRpb25zIHRv IHRoYXQgY2xpZW50IGFuZCBkZWxldGVzIGFsbCBVUklzIGl0IHdhcyBzYXZpbmcgZm9yIHRoYXQg Y2xpZW50LiAmbmJzcDtUaGUgY2xpZW50IHdvdWxkIGhhdmUgdG8gcmUtaW5pdGlhbGl6ZSB0byBy ZXNldC48YnI+DQo8YnI+DQpCcmlhbjxicj4NCjxicj4NCjxicj4NCjxicj4NCjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+T24gQXVnIDI3LCAyMDIxLCBh dCA1OjQxIFBNLCBSYW5kYWxsIEdlbGxlbnMgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cmcm IzQzO2lldGZAcmFuZHkucGVuc2l2ZS5vcmciPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOnB1cnBsZSI+cmcmIzQzO2lldGZAcmFuZHkucGVuc2l2ZS5vcmc8L3NwYW4+PC9hPjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPiZndDsNCiB3cm90ZTo8 YnI+DQo8YnI+DQpJIHRoaW5rIHdlJ3JlIG1vdmluZyB0byBhIG1vZGVsIHdoZXJlOjxicj4NCi0g SW4gYSBxdWVyeSwgYSBjbGllbnQgY2FuIHJlcXVlc3QgdG8gYmUgbm90aWZpZWQgd2hlbiB0aGUg bG9jYXRpb248c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGJyPg0Kc2hvdWxkIGJlIHJldmFsaWRhdGVkOzxicj4NCi0gSW4gdGhlIHJlc3BvbnNlLCB0aGUg c2VydmVyIHByb3ZpZGVzIGFuIElEIHdoaWNoIHRoZSBjbGllbnQ8c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KYXNzb2NpYXRlcyB3aXRoIHRoZSBs b2NhdGlvbiBpdCBqdXN0IHZhbGlkYXRlZDs8YnI+DQotIFRoZSBzZXJ2ZXIgc2VuZHMgYSBub3Rp ZmljYXRpb24gdG8gdGhlIFVSSSwgY29udGFpbmluZyB0aGUgSUQ7PGJyPg0KLSBUaGUgY2xpZW50 IHJldmFsaWRhdGVzIGVhY2ggbG9jYXRpb24gd2l0aCB3aGljaCB0aGF0IElEIGlzIGFzc29jaWF0 ZWQuPGJyPg0KPGJyPg0KUXVlc3Rpb24gMTogRG9lcyB0aGUgc2VydmVyIGRlbGV0ZS9pbmFjdGl2 YXRlIHRoZSBVUkkgb25jZSBpdCBoYXMgc2VudCB0aGUgbm90aWZpY2F0aW9uPzxicj4NCjxicj4N ClF1ZXN0aW9uIDI6IFByZXN1bWFibHksIHdoZW4gdGhlIGNsaWVudCByZXZhbGlkYXRlcyB0aGUg bG9jYXRpb24ocyksIGl0IHdpbGwgYWdhaW4gcmVxdWVzdCBub3RpZmljYXRpb24uICZuYnNwO0Rv ZXMgdGhlIHNlcnZlciByZXR1cm4gdGhlIHNhbWUgSUQgYXMgYmVmb3JlLCBvciBhIGRpZmZlcmVu dCBJRD8gJm5ic3A7QSBkaWZmZXJlbnQgSUQgY291bGQgcGVyaGFwcyBiZSB1c2VmdWwgaW4gZWRn ZSBjYXNlcyB3aGVyZSB0aGUgc2VydmVyIGRpZG4ndCBzZW5kIG9yDQogdGhlIGNsaWVudCBkaWRu J3QgZ2V0IHRoZSBub3RpZmljYXRpb24sIGJ1dCBhbnkgdXRpbGl0eSBzZWVtcyBzbWFsbC4gJm5i c3A7SWYgaXQncyB0aGUgc2FtZSBJRCwgdGhlbiB0aGUgYW5zd2VyIHRvIHF1ZXN0aW9uIDEgY2Fu IGJlIHRoYXQgdGhlIFVSSSByZW1haW5zIGFjdGl2ZSB1bnRpbCB0aGUgY2xpZW50IGFza3MgdG8g bm8gbG9uZ2VyIGJlIG5vdGlmaWVkIChieSBzZW5kaW5nIGFuIGVtcHR5IFVSST8pLjxicj4NCjxi cj4NCi0tUmFuZGFsbDxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KRWNyaXQgbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhy ZWY9Im1haWx0bzpFY3JpdEBpZXRmLm9yZyI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6cHVycGxlIj5FY3JpdEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9lY3JpdDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNzc3Nzc3Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCkVjcml0IG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBo cmVmPSJtYWlsdG86RWNyaXRAaWV0Zi5vcmciPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOnB1cnBsZSI+RWNyaXRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0Ij48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZWNyaXQ8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM3Nzc3NzciPjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQotLS0tLS0tLSBFeHRlcm5hbCBFbWFp bDogUGxlYXNlIHVzZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQ8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KYXR0YWNobWVudHMgLyBD b3VycmllbCBleHRlcm5lOiBTb3lleiBwcnVkZW50IGF2ZWMgbGVzIGxpZW5zIGV0PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCmRvY3VtZW50cyBq b2ludHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNzc3Nzc3Ij48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij4t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpFeHRlcm5hbCBFbWFpbDogUGxlYXNlIHVzZSBjYXV0 aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQgYXR0YWNobWVudHMgLyBDb3VycmllbCBleHRlcm5l OiBTb3lleiBwcnVkZW50IGF2ZWMgbGVzIGxpZW5zIGV0IGRvY3VtZW50cyBqb2ludHM8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVy Ij4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Y29sb3I6Ymx1ZSI+RXh0ZXJuYWwgRW1haWw6PC9zcGFuPjwvaT48L3N0cm9uZz48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48aT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48L2k+PC9zcGFuPjxlbT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPlBsZWFzZQ0KIHVzZSBjYXV0aW9uIHdo ZW4gb3BlbmluZyBsaW5rcyBhbmQgYXR0YWNobWVudHMgLzwvc3Bhbj48L2VtPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjwvaT48L3NwYW4+PHN0cm9uZz48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPkNvdXJyaWVsIGV4dGVybmU6PC9zcGFuPjwv aT48L3N0cm9uZz48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48L2k+PC9zcGFu PjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPlNveWV6DQogcHJ1 ZGVudCBhdmVjIGxlcyBsaWVucyBldCBkb2N1bWVudHMgam9pbnRzPC9zcGFuPjwvZW0+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhy IHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9y OmJsdWUiPkV4dGVybmFsIEVtYWlsOjwvc3Bhbj48L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+IFBsZWFzZSB1c2UgY2F1dGlvbiB3aGVuIG9w ZW5pbmcgbGlua3MgYW5kIGF0dGFjaG1lbnRzIC8NCjwvc3Bhbj48L2VtPjxzdHJvbmc+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj5Db3VycmllbCBleHRlcm5lOjwv c3Bhbj48L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6 Ymx1ZSI+IFNveWV6IHBydWRlbnQgYXZlYyBsZXMgbGllbnMgZXQgZG9jdW1lbnRzIGpvaW50cw0K PC9zcGFuPjwvZW0+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_0619e49202b146298d1bf7e01ec16fe2bellca_-- From nobody Tue Aug 31 13:57:46 2021 Return-Path: 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 897B63A0D27 for ; Tue, 31 Aug 2021 13:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, 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 L5pyvQUmeWi6 for ; Tue, 31 Aug 2021 13:57:37 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3D38B3A0D6E for ; Tue, 31 Aug 2021 13:57:37 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 31 Aug 2021 13:57:36 -0700 From: "Randall Gellens" To: "Caron, Guy" Cc: ECRIT Date: Tue, 31 Aug 2021 13:57:36 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <1F7E1149-1B92-4AD9-8D14-AB5CFDD533CD@randy.pensive.org> In-Reply-To: <1F917507-F9BE-4003-8058-B19E5A288AF6@randy.pensive.org> References: <6fdb8f42317d4dfc99783a4d834b6c85@bell.ca> <07be5a05ac8b4146adc2f0ba56f0e106@bell.ca> <1F917507-F9BE-4003-8058-B19E5A288AF6@randy.pensive.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_0BE88146-AEF9-4E62-B653-8272D100621E_=" Embedded-HTML: [{"HTML":[605, 25134], "plain":[274, 3527], "uuid":"C42CB07E-5150-4963-98B1-74FBA57AFC1B"}] Archived-At: Subject: Re: [Ecrit] similar-location-09: GCaron Review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 20:57:44 -0000 --=_MailMate_0BE88146-AEF9-4E62-B653-8272D100621E_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable By the way, I sent a detailed review of similar-location to the list on = august 24th but haven't seen any response. Subject "Review of = draft-ietf-ecrit-similar-location-09". Maybe the list didn't send it = out? --Randall On 31 Aug 2021, at 13:54, Randall Gellens wrote: > It looked to me to be almost entirely minor editorial suggestions. > > --Randall > > On 31 Aug 2021, at 13:30, Caron, Guy wrote: > >> Thanks all that confirmed the reception of the attachment on the = >> list. >> >> I was wondering since the posting did not spark any reaction. >> >> Guy >> >> De : Randall Gellens >> Envoy=C3=A9 : 31 ao=C3=BBt 2021 15:00 >> =C3=80 : Caron, Guy >> Cc : ECRIT >> Objet : [EXT]Re: [Ecrit] similar-location-09: GCaron Review >> >> >> I received an email from you via the list on 8/27 that contains an = >> attachment. >> >> --Randall >> >> On 31 Aug 2021, at 6:04, Caron, Guy wrote: >> >> Can someone confirm that the attachment was delivered through the = >> ECRIT list? >> >> >> >> I got it myself but want to be sure everyone got it. >> >> >> >> Thanks, >> >> >> >> Guy >> >> >> >> De : Ecrit > De = >> la part de Caron, Guy >> Envoy=C3=A9 : 27 ao=C3=BBt 2021 16:09 >> =C3=80 : ECRIT > >> Objet : [EXT][Ecrit] TR: similar-location-09: GCaron Review >> >> >> >> Resending to the ECRIT list. >> >> >> >> Guy >> >> >> >> De : Caron, Guy >> Envoy=C3=A9 : 27 ao=C3=BBt 2021 16:01 >> =C3=80 : 'draft-ietf-ecrit-similar-location@ietf.org' = >> > >> Objet : similar-location-09: GCaron Review >> >> >> >> Hi, >> >> >> >> I reviewed this document and think it is mostly in good shape. I have = >> a few comments to offer: >> >> >> >> 1. The document does not use a convention to express XML types = >> such as for elements, =E2=80=98boobooboo=E2=80=99 for attr= ibutes, = >> =E2=80=9Cheyheyhey=E2=80=9D for values, etc. in the text. Should it? >> >> 2. The document defines terms in section 2, which are spelled = >> with capital first letters however, when used in the text after = >> section 2, a number of instances do no use the same style and should. >> >> 3. Section 2, in the Invalid Location definition, the term = >> locationInvalid is used however, there is no defined element in here = >> or anywhere else. Was that suppose to refer to lost-planned-changes = >> ? >> >> 4. Section 2, the Similar Location definition says =E2=80=9CA = >> suggested civic location that is comparatively close to the civic = >> location which was input=E2=80=9D. Comparing what? Geographic proximit= y, = >> semantically close, else? >> >> 5. For completeness, it would be nice to include the = >> =E2=80=98similarLocationsLimited=E2=80=99 attribute in the example = >> in section 5.2. >> >> 6. There are two errors in the XML schema in section 6: >> >> a. xmlns=3D"urn:ietf:params:xml:ns:lost-rli1=C3=A2 should be = >> xmlns=3D"urn:ietf:params:xml:ns:lost-rli1" >> >> b. should be > value=3D"1"/> >> >> 7. The reference to planned-changes in section 9.1 should be = >> updated >> >> >> >> I=E2=80=99m trying to attach a MSWord version with track-change here t= hat = >> includes resolutions to 2 and 5, with additional proposed editorial = >> and non-subtative changes. If it does not pass the mail server, I = >> will send directly to the authors. >> >> >> >> Thanks, >> >> >> >> Guy >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >> ________________________________ >> External Email: Please use caution when opening links and attachments = >> / Courriel externe: Soyez prudent avec les liens et documents joints > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --=_MailMate_0BE88146-AEF9-4E62-B653-8272D100621E_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">By the way, I sent a detailed review of similar-location t= o the list on august 24th but haven't seen any response. Subject "Review= of draft-ietf-ecrit-similar-location-09". Maybe the list didn't send it= out?

--Randall

On 31 Aug 2021, at 13:54, Randall Gellens wrote:

<= p dir=3D"auto">It looked to me to be almost entirely minor editorial sugg= estions.

--Randall

On 31 Aug 2021, at 13:30, Caron, Guy wrote:

Thanks all that confirmed the recepti= on of the attachment on the list.

=C2=A0

I was wondering since the posting did= not spark any reaction.

=C2=A0

Guy

=C2=A0

De=C2= =A0: Randall Gellens <rg+ietf@randy.pensive.org>
Envoy=C3=A9=C2=A0: 31 ao=C3=BBt 2021 15:00
=C3=80=C2=A0: Caron, Guy <g.caron@bell.ca>
Cc=C2=A0: ECRIT <ecrit@ietf.org>
Objet=C2=A0: [EXT]Re: [Ecrit] similar-location-09: GCaron Review

=C2=A0

I received an email from you via the list on 8/27 that co= ntains an attachment.

--Randall

On 31 Aug 2021, at 6:04, Caron, Guy wrote:

Can someone confirm that the attachme= nt was delivered through the ECRIT list?

=C2=A0

I got it myself but want to be sure e= veryone got it.

=C2=A0

Thanks,

=C2=A0

Guy

=C2=A0

=C2=A0

Resending to the ECRIT list.

=C2=A0

Guy

=C2=A0

De=C2=A0: Caron, Guy
Envoy=C3=A9=C2=A0: 27 ao=C3=BBt 2021 16:01
=C3=80=C2=A0: 'draft-ietf-ecrit-similar-location@ietf.org' <dr= aft-ietf-ecrit-similar-location@ietf.org>= ;
Objet=C2=A0: similar-location-09: GCaron Review

=C2=A0

Hi,

=C2=A0

I reviewed this document and think it= is mostly in good shape. I have a few comments to offer:

=C2=A0

1.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The document does= not use a convention to express XML types such as <blablabla> for = elements, =E2=80=98boobooboo=E2=80=99 for attributes, =E2=80=9Cheyheyhey=E2= =80=9D for values, etc. in the text. Should it?

2.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The document defi= nes terms in section 2, which are spelled with capital first letters howe= ver, when used in the text after section 2, a number of instances do no use the same style and should.

3.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 2, in the= Invalid Location definition, the term locationInvalid is used however, t= here is no defined element in here or anywhere else. Was that suppose to refer to lost-planned-changes <locationInva= lidated>?

4.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 2, the Si= milar Location definition says =E2=80=9CA suggested civic location that i= s comparatively close to the civic location which was input=E2=80=9D. Comparing what? Geographic proximity, semantically c= lose, else?

5.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For completeness,= it would be nice to include the =E2=80=98similarLocationsLimited=E2=80=99= attribute in the example <findServiceResponse> in section 5.2.

6.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 There are two err= ors in the XML schema in section 6:

a.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 xmlns=3D"urn:ietf= :params:xml:ns:lost-rli1=C3=A2 should be xmlns=3D"urn:ietf:params:xml:ns:= lost-rli1"

b.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <xs:minInclusi= ve value=3D"1"> should be <xs:minInclusive value=3D"1"/><= /p>

7.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The reference to = planned-changes in section 9.1 should be updated

=C2=A0

I=E2=80=99m trying to attach a MSWord= version with track-change here that includes resolutions to 2 and 5, with additional proposed editorial and non-subtative changes. If it d= oes not pass the mail server, I will send directly to the authors.=

=C2=A0

Thanks,

=C2=A0

Guy

___________________________________________= ____
Ecrit mailing list
Ecrit@ietf.org
https:/= /www.ietf.org/mailman/listinfo/ecrit

<= span style=3D"font-size:9.0pt;color:blue">External Email: Please use caution wh= en opening links and attachments / Courrie= l externe: Soyez prudent avec les liens et documents joints

______________________= _________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

--=_MailMate_0BE88146-AEF9-4E62-B653-8272D100621E_=-- From nobody Tue Aug 31 14:01:47 2021 Return-Path: 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 259E23A0D6E for ; Tue, 31 Aug 2021 14:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01] 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 GSsLOfc2UV64 for ; Tue, 31 Aug 2021 14:01:40 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id AE60B3A0D6B for ; Tue, 31 Aug 2021 14:01:40 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 31 Aug 2021 14:01:40 -0700 From: "Randall Gellens" To: ecrit@ietf.org, "Brian Rosen" Date: Tue, 31 Aug 2021 14:01:39 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: <2B7FD550-34D6-4A80-956C-7CCDA7D34847@randy.pensive.org> References: <2B7FD550-34D6-4A80-956C-7CCDA7D34847@randy.pensive.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: Re: [Ecrit] Review of draft-ietf-ecrit-lost-planned-changes-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 21:01:46 -0000 I haven't seen responses to the numbered items from my review: > (1) Should the Time to Live information in a validation response be an > attribute rather than an element? Logically, it seems more an > attribute of the response, and also it mirrors the 'expires' attribute > on which it is modeled. > > (2) In the extension schema, are 'invalidAsOf' and 'asOf' swapped? > ('AsOf' should be part of the element but looks like > maybe it is part of the response, while 'invalidAsOf' is part of > ). > > (3) I'm not sure that "The server MUST have policy that limits use of > this mechanism by a given client" is warranted; I think using "SHOULD" > is more easily justified. --Randall On 23 Aug 2021, at 14:12, Randall Gellens wrote: > (1) Should the Time to Live information in a validation response be an > attribute rather than an element? Logically, it seems more an > attribute of the response, and also it mirrors the 'expires' attribute > on which it is modeled. > > (2) In the extension schema, are 'invalidAsOf' and 'asOf' swapped? > ('AsOf' should be part of the element but looks like > maybe it is part of the response, while 'invalidAsOf' is part of > ). > > (3) I'm not sure that "The server MUST have policy that limits use of > this mechanism by a given client" is warranted; I think using "SHOULD" > is more easily justified. > > I have a number of suggested edits for clarification or language. > Attached are four files: > > draft-ietf-ecrit-lost-planned-changes-04-rg.xml > > The XML uploaded by Brian, with my edits. > > draft-ietf-ecrit-lost-planned-changes-04-rg.txt > > The TXT generated from the XML with my edits. > > Diff-txt.html > > An IETF tools diff showing my edits to the TXT, side by side. > > Diff-xml.html > > An IETF tools diff showing my edits to the XML, side by side. > > > --Randall From nobody Tue Aug 31 14:06:08 2021 Return-Path: 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 6E0653A0DD2 for ; Tue, 31 Aug 2021 14:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, 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.20150623.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 2lWgjAl4uwQO for ; Tue, 31 Aug 2021 14:05:59 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 EC8DE3A0DC6 for ; Tue, 31 Aug 2021 14:05:58 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id z1so853845ioh.7 for ; Tue, 31 Aug 2021 14:05:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=pMI4Avl8MhJoGgHztc3dM44BaK/qyPDIAc6YF6VJVqk=; b=xf5YdT/wzyiKVlu0tyy1qZCdNKhZJ2ZkUnGMdYlJOJCm4WGEcbK0f2PQ8tj4y/r1fT 32YyLiuZhCDLqXsp2snMzC08u4zvzxoFh1NPC/EVlcYkQlTnX/YWexcVizrsBBM++rP3 jWX/0+vYgAS+umwzyxpCin7p/s6Hr7ZTgbK3aT+sEy1Wgf9hIexEJ3j15neKDfm0SPcv drUBlvgoNwZoDGlIPe8S6qQ5JeBNFlxbzXwU5hc987qsbvTXwzW9+Jx8VQE99mMLG/gA 46+tZ4gIkaL5zEuevOu+3eJnfLHigWXBLn71uYqnFZ0oTFXlDqHfjrFSa7+n3FnTZ3cr mpPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=pMI4Avl8MhJoGgHztc3dM44BaK/qyPDIAc6YF6VJVqk=; b=QLpGhu1dl6edoS0E1BUSGbkUSFuDimuJcAqbdAFu+JCq+5OYcfFqUXtkG7vyP/wohm PhTg+QeXEGZWkNTHvA310JQa7t7IedcsUnCcPLpLV+VhXKjxo0y/bEj8x0tW+T3p7GX1 E71xC7QkV/cbbBJCK3Mz4QlCvDFW7hUG63tUMeDc5L6lI7JcTKumUfRG5BDa41nJiGqd Vsw/R+1F5/kzSZp/Wp7URtr4j/x7qZE2gCC2rw7d3uK/H3kqk4yZwGT1IwnRGBsG8B1A R0MD4feMpJ2FPSOpQfKDe2KNcJITPiUPbPxLuea+5mQhEA03E4mvIEMG6yvS/tXM/2Fw x1Kw== X-Gm-Message-State: AOAM532Hq89MEhRHr1i1x8MbASFOLCOMF6iHkBz3Ow4YWMQohuuICuV/ hJYzLyd1cFYVq7wsu+JGkGTtDw== X-Google-Smtp-Source: ABdhPJxovPZBDFpqM530cwwWTvl6Kir8fg8W6ale1W6zW5Jt/aZsHvBDF32I7HyQm2KXZlcHun82tA== X-Received: by 2002:a05:6638:38aa:: with SMTP id b42mr4703483jav.6.1630443957612; Tue, 31 Aug 2021 14:05:57 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id c8sm10708928ilk.64.2021.08.31.14.05.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Aug 2021 14:05:57 -0700 (PDT) From: Brian Rosen Message-Id: <7F2CBE4B-BDD2-4EF9-80B2-F577244A3998@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_2BEE5F67-D4DD-46A0-91CA-0D092AC35BA0" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 31 Aug 2021 17:05:56 -0400 In-Reply-To: <1F7E1149-1B92-4AD9-8D14-AB5CFDD533CD@randy.pensive.org> Cc: "Caron, Guy" , ECRIT To: Randall Gellens References: <6fdb8f42317d4dfc99783a4d834b6c85@bell.ca> <07be5a05ac8b4146adc2f0ba56f0e106@bell.ca> <1F917507-F9BE-4003-8058-B19E5A288AF6@randy.pensive.org> <1F7E1149-1B92-4AD9-8D14-AB5CFDD533CD@randy.pensive.org> X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Ecrit] similar-location-09: GCaron Review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 21:06:06 -0000 --Apple-Mail=_2BEE5F67-D4DD-46A0-91CA-0D092AC35BA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I got it. Update coming. Will reply if I have any issues with it. Brian > On Aug 31, 2021, at 4:57 PM, Randall Gellens = wrote: >=20 > By the way, I sent a detailed review of similar-location to the list = on august 24th but haven't seen any response. Subject "Review of = draft-ietf-ecrit-similar-location-09". Maybe the list didn't send it = out? >=20 > --Randall >=20 > On 31 Aug 2021, at 13:54, Randall Gellens wrote: >=20 > It looked to me to be almost entirely minor editorial suggestions. >=20 > --Randall >=20 > On 31 Aug 2021, at 13:30, Caron, Guy wrote: >=20 > Thanks all that confirmed the reception of the attachment on the list. > =20 > I was wondering since the posting did not spark any reaction. > =20 > Guy > =20 > De : Randall Gellens =20 > Envoy=C3=A9 : 31 ao=C3=BBt 2021 15:00 > =C3=80 : Caron, Guy > Cc : ECRIT > Objet : [EXT]Re: [Ecrit] similar-location-09: GCaron Review > =20 > I received an email from you via the list on 8/27 that contains an = attachment. >=20 > --Randall >=20 > On 31 Aug 2021, at 6:04, Caron, Guy wrote: >=20 > Can someone confirm that the attachment was delivered through the = ECRIT list? > =20 > I got it myself but want to be sure everyone got it. > =20 > Thanks, > =20 > Guy > =20 > De : Ecrit > De = la part de Caron, Guy > Envoy=C3=A9 : 27 ao=C3=BBt 2021 16:09 > =C3=80 : ECRIT > > Objet : [EXT][Ecrit] TR: similar-location-09: GCaron Review > =20 > Resending to the ECRIT list. > =20 > Guy > =20 > De : Caron, Guy=20 > Envoy=C3=A9 : 27 ao=C3=BBt 2021 16:01 > =C3=80 : 'draft-ietf-ecrit-similar-location@ietf.org' = > > Objet : similar-location-09: GCaron Review > =20 > Hi, > =20 > I reviewed this document and think it is mostly in good shape. I have = a few comments to offer: > =20 > 1. The document does not use a convention to express XML types = such as for elements, =E2=80=98boobooboo=E2=80=99 for = attributes, =E2=80=9Cheyheyhey=E2=80=9D for values, etc. in the text. = Should it? > 2. The document defines terms in section 2, which are spelled = with capital first letters however, when used in the text after section = 2, a number of instances do no use the same style and should. > 3. Section 2, in the Invalid Location definition, the term = locationInvalid is used however, there is no defined element in here or = anywhere else. Was that suppose to refer to lost-planned-changes = ? > 4. Section 2, the Similar Location definition says =E2=80=9CA = suggested civic location that is comparatively close to the civic = location which was input=E2=80=9D. Comparing what? Geographic proximity, = semantically close, else? > 5. For completeness, it would be nice to include the = =E2=80=98similarLocationsLimited=E2=80=99 attribute in the example = in section 5.2. > 6. There are two errors in the XML schema in section 6: > a. xmlns=3D"urn:ietf:params:xml:ns:lost-rli1=C3=A2 should be = xmlns=3D"urn:ietf:params:xml:ns:lost-rli1" > b. should be > 7. The reference to planned-changes in section 9.1 should be = updated > =20 > I=E2=80=99m trying to attach a MSWord version with track-change here = that includes resolutions to 2 and 5, with additional proposed editorial = and non-subtative changes. If it does not pass the mail server, I will = send directly to the authors. > =20 > Thanks, > =20 > Guy > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit = > External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit = _____________________________= __________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --Apple-Mail=_2BEE5F67-D4DD-46A0-91CA-0D092AC35BA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = got it.  Update coming.  Will reply if I have any issues with = it.

Brian

On Aug 31, 2021, at 4:57 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

By = the way, I sent a detailed review of similar-location to the list on = august 24th but haven't seen any response. Subject "Review of = draft-ietf-ecrit-similar-location-09". Maybe the list didn't send it = out?

--Randall

On 31 Aug 2021, at 13:54, Randall Gellens wrote:

It = looked to me to be almost entirely minor editorial suggestions.

--Randall

On 31 = Aug 2021, at 13:30, Caron, Guy wrote:

Thanks all that = confirmed the reception of the attachment on the list.

 

I was wondering since = the posting did not spark any reaction.

 

Guy

 

De : Randall Gellens <rg+ietf@randy.pensive.org>
Envoy=C3=A9 : 31 ao=C3=BBt 2021 15:00
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : ECRIT <ecrit@ietf.org>
Objet : [EXT]Re: [Ecrit] similar-location-09: = GCaron Review

 

I received = an email from you via the list on 8/27 that contains an = attachment.

--Randall

On 31 Aug = 2021, at 6:04, Caron, Guy wrote:

Can someone confirm that = the attachment was delivered through the ECRIT list?

 

I got it myself but want = to be sure everyone got it.

 

Thanks,

 

Guy

 

De : Ecrit <ecrit-bounces@ietf.org> De la part de Caron, Guy
Envoy=C3=A9 : 27 ao=C3=BBt 2021 16:09
=C3=80 : ECRIT <ecrit@ietf.org>
Objet : [EXT][Ecrit] TR: similar-location-09: = GCaron Review

 

Resending to the ECRIT = list.

 

Guy

 

De : Caron, Guy
Envoy=C3=A9 : 27 ao=C3=BBt 2021 16:01
=C3=80 : 'draft-ietf-ecrit-similar-location@ietf.org' <draft-ietf-ecrit-similar-location@ietf.org>
Objet : similar-location-09: GCaron = Review

 

Hi,

 

I reviewed this document = and think it is mostly in good shape. I have a few comments to = offer:

 

1.       The document does not = use a convention to express XML types such as <blablabla> for = elements, =E2=80=98boobooboo=E2=80=99 for attributes, =E2=80=9Cheyheyhey=E2= =80=9D for values, etc. in the text. Should it?

2.       The document defines = terms in section 2, which are spelled with capital first letters = however, when used in the text after section 2, a number of instances do no use the same style and should.

3.       Section 2, in the = Invalid Location definition, the term locationInvalid is used however, = there is no defined element in here or anywhere else. Was that suppose to refer to lost-planned-changes = <locationInvalidated>?

4.       Section 2, the Similar = Location definition says =E2=80=9CA suggested civic location that is = comparatively close to the civic location which was input=E2=80=9D. Comparing what? Geographic proximity, semantically = close, else?

5.       For completeness, it = would be nice to include the =E2=80=98similarLocationsLimited=E2=80=99 = attribute in the example <findServiceResponse> in section 5.2.

6.       There are two errors in = the XML schema in section 6:

a.       xmlns=3D"urn:ietf:params:xml:ns:lost-rli1=C3=A2 should be = xmlns=3D"urn:ietf:params:xml:ns:lost-rli1"

b.       <xs:minInclusive = value=3D"1"> should be <xs:minInclusive = value=3D"1"/>

7.       The reference to = planned-changes in section 9.1 should be updated

 

I=E2=80=99m trying to = attach a MSWord version with track-change here that includes resolutions = to 2 and 5, with additional proposed editorial and non-subtative changes. If it = does not pass the mail server, I will send directly to the = authors.

 

Thanks,

 

Guy

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

External Email: Please use caution when = opening links and attachments / Courriel = externe: Soyez prudent avec les = liens et documents joints

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit = mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

= --Apple-Mail=_2BEE5F67-D4DD-46A0-91CA-0D092AC35BA0-- From nobody Tue Aug 31 14:13:32 2021 Return-Path: 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 8CDF33A11AB for ; Tue, 31 Aug 2021 14:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, 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.20150623.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 9X8S_u7LslWV for ; Tue, 31 Aug 2021 14:13:24 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 47C8F3A11A0 for ; Tue, 31 Aug 2021 14:13:24 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id b7so921493iob.4 for ; Tue, 31 Aug 2021 14:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rqju/XEbDkcriedoUY9tW3ZClOSnDE5VOORiz37YVSs=; b=WfcDf9ts52yKcR8LD3gQ64LeoH38v9IPim739vV0/Xu9cOng0z/uhyWUQkyry608ll zzYXBu1WXYoa88zJA0DeCZtcZFkmJJ+XOV1+0RYXdhH38MozPGZwvpsW8JNyq3lKkFcl uJSusTJLk+Q6hUzCDPK+83m+TxS/N2kpZt9t8YfA800Ljc1cRffvBN5opVJyyWaCbnEg yBbwgERXHjOT5z9ycszK4XBVm4zQzHaP7/ngbpW8h4WLo8baT2ahQaUUpFvdgJWE9zJf u75x2txKNFjAFcxKZO1ceBDmfmN/oEbp8LpGcPaJHm/VMoRAtjE8K6/iXanG4WOEZg03 nDeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=rqju/XEbDkcriedoUY9tW3ZClOSnDE5VOORiz37YVSs=; b=Uj7ZNvzVtZVtE3f4QGRWpDBf5uaMiRM3AB91ZQCY4WwXfk4gQnJMzvcXv1CQtJ+aSW gyUj6kWKCQ7qzfyE2T2MF8jC0g5ePFyAiXYXnKxZ1Jtr8M3RMcZadSvQGpLI7ZkoyrgN 0zncWi6Gw4T/6kHFcAoKYvE6nxhNGxYuB6Fk0tYy+WpL5aPT4/oPhyx5WfvuxyHB0Jy/ SA1I6nNQ2bRup1rHOCPboSyPSkHwAV2LN/gE5SFDSsrSj7WnLD1ycx/iCIfFEd2l6SlW Kwhyd3T4WouZC/OQntmzD6N5UftXURewrdRuWx5OW0maDueU96RaEHIcghvl7qB79ENi lzOA== X-Gm-Message-State: AOAM530pf50rkBMYmsPpu6l4JORO/5HhdLBsFU/AGADwIgvI4yxNkXrS 1zvz05rnzP6FlH3c0Iffx7IIo8Bz5JNu+rPz X-Google-Smtp-Source: ABdhPJw7rRxPSAZ2knqacP6Ri3HFd7ezXbEjJPUNl3EjPNZAiot+lV4efApbIv8Xl3FSsCjvICedbw== X-Received: by 2002:a05:6602:2001:: with SMTP id y1mr24439801iod.97.1630444402861; Tue, 31 Aug 2021 14:13:22 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id s16sm10802168iln.5.2021.08.31.14.11.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Aug 2021 14:12:32 -0700 (PDT) From: Brian Rosen Message-Id: <8247DFD7-D3B3-44BC-9EE7-A2EF4B994A01@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_84932FDA-B7F5-4A6E-B7B1-013A61CF1F21" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 31 Aug 2021 17:11:51 -0400 In-Reply-To: <0619e49202b146298d1bf7e01ec16fe2@bell.ca> Cc: Randall Gellens , ECRIT To: "Caron, Guy" References: <5577e2e6daa4405bbe12ef61675e1f55@bell.ca> <3AD58DEC-1DC9-4BC0-B55C-4E782E4AAA74@brianrosen.net> <9433989A-85D7-41B9-96EA-313ADC0F02CD@brianrosen.net> <851c82ef56714b8a917761d98234093a@bell.ca> <0F5C2109-77E1-495E-9768-94E28DC6A76A@brianrosen.net> <0619e49202b146298d1bf7e01ec16fe2@bell.ca> X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Ecrit] planned-changes: two questions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 21:13:31 -0000 --Apple-Mail=_84932FDA-B7F5-4A6E-B7B1-013A61CF1F21 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It could limit it, but that would be a problem if it limited it such = that a large planned change properly registered couldn=E2=80=99t work. = In some areas, they change hundreds of thousands of address points in a = large annexation. It=E2=80=99s not typically millions, but you could = imagine something like a county that dumps a new Site/Structure list = where there wasn=E2=80=99t one before that triggers this kind of = notification. That doesn=E2=80=99t change the need for start and limit if the list can = be big. Lots of systems I know have pretty severe limits on the size of = an upload response for interfaces like this. Hmmm, start and limit go the wrong way. The notification is the POST. = Start and Limit are for a GET. We would have to implement an equivalent = on the registration. Brian > On Aug 31, 2021, at 4:57 PM, Caron, Guy wrote: >=20 > The size of the list could be a policy at the Server. > =20 > Guy > =20 > De : Brian Rosen =20 > Envoy=C3=A9 : 31 ao=C3=BBt 2021 16:55 > =C3=80 : Caron, Guy > Cc : Randall Gellens ; ECRIT = > Objet : [EXT]Re: [Ecrit] planned-changes: two questions > =20 > If we did that, we would have to implement limit and start to handle a = large list. =20 > =20 > Brian > =20 >=20 >=20 > On Aug 31, 2021, at 4:38 PM, Caron, Guy > wrote: > =20 > If we make a list of IDs, one notification per = URI per planned change would be sufficient. > =20 > Guy > =20 > De : Brian Rosen >=20 > Envoy=C3=A9 : 31 ao=C3=BBt 2021 15:35 > =C3=80 : Randall Gellens > > Cc : Caron, Guy >; ECRIT = > > Objet : [EXT]Re: [Ecrit] planned-changes: two questions > =20 > No. =20 > =20 > There is one URI, but many IDs, one per unique record at the LoST = server that is involved in a planned change. The one URI will receive = one notification per ID it has registered for. > =20 > =20 >=20 >=20 >=20 > On Aug 31, 2021, at 2:56 PM, Randall Gellens = > wrote: > =20 > i understand that the concern is allowing a client to leverage the = LoST server to attack a large number of targets, I'm just not clear = mechanically how such leverage potentially works. Each validation query = can store a URI, and that URI may get associated with a large number of = locations. Maybe there's a street name change or an annexation. So maybe = thousands or tens or hundreds of thousands of locations are potentially = invalidated. They all have the same URI associated with them, so the = LoST server connects to the URI once and POSTs one notification, no? > --Randall > On 31 Aug 2021, at 10:53, Brian Rosen wrote: > Of course an attacker would conceal itself and register multiple URIs = under different identities. But the bigger problem is that if a large = planned change occurred, the victim could receive a large number of = notifications it didn=E2=80=99t expect. > =20 > With a test transition, we know that the client expects to see = notifications, we only need one per URI (we could specify one per domain = =E2=80=94 after the scheme and before the first slash). If we don=E2=80=99= t get the ID, we know not to allow that URI to be provisioned. So = it=E2=80=99s one test transaction vs a large number of planned change = transactions. > =20 > Brian > =20 >=20 >=20 >=20 > On Aug 31, 2021, at 1:35 PM, Randall Gellens = > wrote: > =20 > If a malicious client registers a URI that is designed to attack a = third site, the test transaction causes the LoST server to connect to it = and POST a command. Without a test transaction, the LoST server stores = the URI and at a future time connects to it and sends a command. Either = way, a LoST client can register potentially one URI per queried = location, and a LoST server will connect to that URI and POST a message. = A queried location could be tied to many other locations, so there could = be many locations for which a change would trigger the LoST server to = use the URI, but is that worse? > --Randall > On 31 Aug 2021, at 10:27, Brian Rosen wrote: > If the work group wants to have the LoST server keep the URI until = expressly deleted, that=E2=80=99s okay with me. > =20 > Authenticating the client to the server doesn=E2=80=99t mean the URI = is authenticated. We can=E2=80=99t restrict the URI to be the same = entity as the client running the LoST transaction. And the clients are = wide ranging. Could be an enterprise running its own LIS for example. = We can=E2=80=99t assume the North American PKI is workable everywhere, = and even that doesn=E2=80=99t extend to an enterprise LIS. ISTM we have = to run a test transaction with the notification service to make sure = it=E2=80=99s what we think it is. > =20 > Brian > =20 > =20 >=20 >=20 >=20 > On Aug 31, 2021, at 9:01 AM, Caron, Guy > wrote: > =20 > Inline. >=20 > Guy >=20 > -----Message d'origine----- > De : Brian Rosen >=20 > Envoy=C3=A9 : 31 ao=C3=BBt 2021 08:11 > =C3=80 : Caron, Guy > > Cc : Randall Gellens >; ECRIT > > Objet : [EXT]Re: [Ecrit] planned-changes: two questions >=20 > You delete the URI when you delete the record in the LIS. > [GC] That's fine but that was not the question Randall posed. He asked = whether the URI is deleted after a notification. I agree that if the = Client does not host the location anymore that the URI associated with = that location in the Server should be deleted. This could be achieved = with an empty . >=20 > I don=E2=80=99t think this is covered in 5222. The mechanism causes = the LoST server to send notifications to the client, but the client is = allowed to put any URI in the record, and it can add it to as many = records as it wants. > [GC] I thought we agreed on using one generic URI per Client. Clients = should be authenticated by the Servers. > An evil implementation could record URIs against multiple targets = that were unaware that the evil implementation did it, until they got a = large number of PUSH transactions they didn=E2=80=99t expect or = understand as a result of a large planned change. > [GC] Only authenticated Clients should be allowed to provide URIs to = be stored by the Servers. >=20 > The proposed mechanism qualifies the client URI before its used in a = planned change. >=20 > Brian >=20 >=20 >=20 > On Aug 31, 2021, at 7:37 AM, Caron, Guy > wrote: >=20 > Well, this is not going in the direction I thought. >=20 > What is the purpose of deleting the URIs at the Server = post-validation? >=20 > Regarding opening a new DoS, I guess I'm not following. Wouldn't this = case be covered by the security considerations in RFC 5222? >=20 > What you're proposing puts back significant load on the Servers (a key = consideration for creating planned-changes in the first place) and = complicates the mechanism. >=20 > Guy >=20 >=20 > -----Message d'origine----- > De : Ecrit > De = la part de Brian Rosen Envoy=C3=A9 :=20 > 30 ao=C3=BBt 2021 11:22 =C3=80 : Randall Gellens = > Cc=20 > : ECRIT > Objet : [EXT]Re: = [Ecrit] planned-changes: two=20 > questions >=20 > Answer 1: yes. Since there is going to be a revalidation, just = deleting the setting seems right to me. > Answer 2: Up to server. If I were implementing, I would hash the real = ID with the URI and some kind of predictable nonce. =20 >=20 > We probably have to say more about how the server identifies the = client, so that replacement of the URI works. Could we say we use the = domain of the URI (the entire domain with all the dots) to identify the = client, and anything can occur after it (meaning a slash and whatever)? = If we do that, then how would delete the notification? Force there to = be something other than the domain (ugly). Explicit delete request? >=20 > Hmmm, we=E2=80=99ve opened a DoS attack: a rogue client stores a bunch = of URIs for servers it wants to victimize. In North America we have a = real simple solution for that, because we have a PKI, so we know, for = sure, who the client is, and could restrict who we allow to store URIs, = but that wouldn=E2=80=99t be true in general. Also, it would be nice = for the client to have confidence the mechanism worked before it needed = it. >=20 > So > Let=E2=80=99s add a =E2=80=9Ccommand=E2=80=9D to plannedChange in the = findService request. =20 > And, have the client have a response to the notification which is the=20= > ID (json with the 200) >=20 >=20 > The client starts by sending a command of =E2=80=9Cinitialize=E2=80=9D. = The domain is the identity of the client. The response is an immediate = notification to the with whatever LI was in the request and an ID. The = response by the client (which is the notification web server) is a piece = of json containing the ID. We can say that the LI in this initialize = command could be something simple like the Country Code that wouldn=E2=80=99= t get a planned change. >=20 > Thereafter, the LoST server (notification client) periodically repeats = this keepalive notification every day or week with the initialize LI. = The client has to respond with the ID. >=20 > The regular notification request is a command of =E2=80=9Cnotify=E2=80=9D= . The server ignores a request for notification from an uninitialized = client. > The notification can be deleted with a command of =E2=80=9Cdelete=E2=80=9D= . If you delete the initialize LI, then the server won=E2=80=99t send = any more notifications to that client and deletes all URIs it was saving = for that client. The client would have to re-initialize to reset. >=20 > Brian >=20 >=20 >=20 > On Aug 27, 2021, at 5:41 PM, Randall Gellens = > wrote: >=20 > I think we're moving to a model where: > - In a query, a client can request to be notified when the location=20 > should be revalidated; > - In the response, the server provides an ID which the client=20 > associates with the location it just validated; > - The server sends a notification to the URI, containing the ID; > - The client revalidates each location with which that ID is = associated. >=20 > Question 1: Does the server delete/inactivate the URI once it has sent = the notification? >=20 > Question 2: Presumably, when the client revalidates the location(s), = it will again request notification. Does the server return the same ID = as before, or a different ID? A different ID could perhaps be useful in = edge cases where the server didn't send or the client didn't get the = notification, but any utility seems small. If it's the same ID, then = the answer to question 1 can be that the URI remains active until the = client asks to no longer be notified (by sending an empty URI?). >=20 > --Randall >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit = >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit = > ---------------------------------------------------------------------- > -------- External Email: Please use caution when opening links and=20 > attachments / Courriel externe: Soyez prudent avec les liens et=20 > documents joints >=20 > = --------------------------------------------------------------------------= ---- > External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints > =20 > =20 > =20 > External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints > =20 > External Email: Please use caution when opening links and attachments = / Courriel externe: Soyez prudent avec les liens et documents joints --Apple-Mail=_84932FDA-B7F5-4A6E-B7B1-013A61CF1F21 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 It = could limit it, but that would be a problem if it limited it such that a = large planned change properly registered couldn=E2=80=99t work.  In = some areas, they change hundreds of thousands of address points in a = large annexation.  It=E2=80=99s not typically millions, but you = could imagine something like a county that dumps a new Site/Structure = list where there wasn=E2=80=99t one before that triggers this kind of = notification.

That = doesn=E2=80=99t change the need for start and limit if the list can be = big.  Lots of systems I know have pretty severe limits on the size = of an upload response for interfaces like this.

Hmmm, start and limit go the wrong way. =  The notification is the POST.  Start and Limit are for a GET. =  We would have to implement an equivalent on the = registration.

Brian

On Aug = 31, 2021, at 4:57 PM, Caron, Guy <g.caron@bell.ca> wrote:

The size of the list = could be a policy at the Server.
 
Guy
 
De : Brian = Rosen <br@brianrosen.net> 
Envoy=C3=A9 : 31 ao=C3=BBt 2021 16:55
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : Randall Gellens <rg+ietf@randy.pensive.org>; ECRIT <ecrit@ietf.org>
Objet : [EXT]Re: [Ecrit] = planned-changes: two questions
 
If we did that, we would have to = implement limit and start to handle a large list.  
 
Brian
 


On Aug 31, 2021, at 4:38 PM, Caron, Guy = <g.caron@bell.ca> = wrote:
 
If we make = <revalidateLocation> a list of IDs, one notification per URI per = planned change would be sufficient.
 
Guy
 
De : Brian Rosen <br@brianrosen.net> 
Envoy=C3=A9 : 31 ao=C3=BBt 2021 15:35
=C3=80 : Randall Gellens <rg+ietf@randy.pensive.org>
Cc : Caron, Guy <g.caron@bell.ca>; ECRIT <ecrit@ietf.org>
Objet : [EXT]Re: [Ecrit] = planned-changes: two questions
 
No.  
 
There is one URI, but many = IDs, one per unique record at the LoST server that is involved in a = planned change.  The one URI will receive one notification per ID = it has registered for.
 
 



On Aug 31, 2021, at 2:56 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:
 
i understand that the concern is allowing a = client to leverage the LoST server to attack a large number of targets, = I'm just not clear mechanically how such leverage potentially works. = Each validation query can store a URI, and that URI may get associated = with a large number of locations. Maybe there's a street name change or = an annexation. So maybe thousands or tens or hundreds of thousands of = locations are potentially invalidated. They all have the same URI = associated with them, so the LoST server connects to the URI once and = POSTs one notification, no?
--Randall
On = 31 Aug 2021, at 10:53, Brian Rosen wrote:
Of course an attacker = would conceal itself and register multiple URIs under different = identities.  But the bigger  problem is that if a large = planned change occurred, the victim could receive a large number of = notifications it didn=E2=80=99t expect.
 
With a test transition, we know = that the client expects to see notifications, we only need one per URI = (we could specify one per domain =E2=80=94 after the scheme and before = the first slash).  If we don=E2=80=99t get the ID, we know not to = allow that URI to be provisioned.  So it=E2=80=99s one test = transaction vs a large number of planned change transactions.
 
Brian
 



On Aug 31, 2021, at 1:35 PM, = Randall Gellens <rg+ietf@randy.pensive.org> wrote:
 
If a malicious client registers a URI that is = designed to attack a third site, the test transaction causes the LoST = server to connect to it and POST a command. Without a test transaction, = the LoST server stores the URI and at a future time connects to it and = sends a command. Either way, a LoST client can register potentially one = URI per queried location, and a LoST server will connect to that URI and = POST a message. A queried location could be tied to many other = locations, so there could be many locations for which a change would = trigger the LoST server to use the URI, but is that worse?
--Randall
On 31 Aug 2021, at = 10:27, Brian Rosen wrote:
If the work group = wants to have the LoST server keep the URI until expressly deleted, = that=E2=80=99s okay with me.
 
Authenticating the client to the server doesn=E2=80=99t mean = the URI is authenticated.  We can=E2=80=99t restrict the URI to be = the same entity as the client running the LoST transaction.  And = the clients are wide ranging.  Could be an enterprise running its = own LIS for example.  We can=E2=80=99t assume the North American = PKI is workable everywhere, and even that doesn=E2=80=99t extend to an = enterprise LIS.  ISTM we have to run a test transaction with the = notification service to make sure it=E2=80=99s what we think it = is.
 
Brian
 
 



On Aug 31, 2021, at 9:01 AM, Caron, Guy <g.caron@bell.ca> wrote:
 
Inline.

Guy

-----Message = d'origine-----
De : Brian Rosen <br@brianrosen.net> 
Envoy=C3=A9&nb= sp;: 31 ao=C3=BBt 2021 08:11
=C3=80 : Caron, Guy = <g.caron@bell.ca>
Cc : Randall = Gellens <rg+ietf@randy.pensive.org>; ECRIT <ecrit@ietf.org>
Objet : [EXT]Re: = [Ecrit] planned-changes: two questions

You = delete the URI when you delete the record in the LIS.
[GC] = That's fine but that was not the question Randall posed. He asked = whether the URI is deleted after a notification. I agree that if the = Client does not host the location anymore that the URI associated with = that location in the Server should be deleted. This could be achieved = with an empty <plannedChange>.

I = don=E2=80=99t think this is covered in 5222.  The mechanism causes = the LoST server to send notifications to the client, but the client is = allowed to put any URI in the record, and it can add it to as many = records as it wants.
[GC] I thought we agreed on using one = generic URI per Client. Clients should be authenticated by the = Servers.
 An evil implementation could record URIs = against multiple targets that were unaware that the evil implementation = did it, until they got a large number of PUSH transactions they didn=E2=80= =99t expect or understand as a result of a large planned change.
[GC] Only authenticated Clients should be allowed to provide = URIs to be stored by the Servers.

The = proposed mechanism qualifies the client URI before its used in a planned = change.

Brian



On Aug 31, 2021, at 7:37 AM, Caron, Guy <g.caron@bell.ca> wrote:

Well, this is not going in the direction I thought.

What is the purpose of deleting the URIs at = the Server post-validation?

Regarding = opening a new DoS, I guess I'm not following. Wouldn't this case be = covered by the security considerations in RFC 5222?

What you're proposing puts back significant load on the = Servers (a key consideration for creating planned-changes in the first = place) and complicates the mechanism.

Guy


-----Message d'origine-----
De : = Ecrit <ecrit-bounces@ietf.org> De la part de Brian Rosen Envoy=C3=A9 : 
30 ao=C3=BBt = 2021 11:22 =C3=80 : Randall Gellens <rg+ietf@randy.pensive.org> Cc 
: ECRIT <ecrit@ietf.org> Objet : [EXT]Re: [Ecrit] planned-changes: two 
questions

Answer 1: yes.  Since there is going to be a = revalidation, just deleting the setting seems right to me.
Answer 2: Up to server.  If I were implementing, I would = hash the real ID with the URI and some kind of predictable nonce. =  

We probably have to say more about = how the server identifies the client, so that replacement of the URI = works.  Could we say we use the domain of the URI (the entire = domain with all the dots) to identify the client, and anything can occur = after it (meaning a slash and whatever)?  If we do that, then how = would delete the notification?  Force there to be something other = than the domain (ugly).  Explicit delete request?

Hmmm, we=E2=80=99ve opened a DoS attack: a rogue client = stores a bunch of URIs for servers it wants to victimize.  In North = America we have a real simple solution for that, because we have a PKI, = so we know, for sure, who the client is, and could restrict who we allow = to store URIs, but that wouldn=E2=80=99t be true in general.  Also, = it would be nice for the client to have confidence the mechanism worked = before it needed it.

So
Let=E2=80= =99s add a =E2=80=9Ccommand=E2=80=9D to plannedChange in the findService = request.  
And, have the client have a response to = the notification which is the 
ID (json = with the 200)


The client = starts by sending a command of =E2=80=9Cinitialize=E2=80=9D.  The = domain is the identity of the client.  The response is an immediate = notification to the with whatever LI was in the request and an ID. =  The  response by the client (which is the notification web = server) is a piece of json containing the ID.  We can say that the = LI in this initialize command could be something simple like the Country = Code that wouldn=E2=80=99t get a planned change.

Thereafter, the LoST server (notification client) = periodically repeats this keepalive notification every day or week with = the initialize LI.  The client has to respond with the ID.

The regular notification request is a command = of =E2=80=9Cnotify=E2=80=9D.  The server ignores a request for = notification from an uninitialized client.
The = notification can be deleted with a command of =E2=80=9Cdelete=E2=80=9D. =  If you delete the initialize LI, then the server won=E2=80=99t = send any more notifications to that client and deletes all URIs it was = saving for that client.  The client would have to re-initialize to = reset.

Brian


On Aug 27, 2021, at 5:41 PM, Randall Gellens <rg+ietf@randy.pensive.org> wrote:

I think we're moving to a model where:
- In a query, a client can request to be notified when the = location 
should be revalidated;
- In the response, the = server provides an ID which the client 
associates = with the location it just validated;
- The server sends a = notification to the URI, containing the ID;
- The client = revalidates each location with which that ID is associated.

Question 1: Does the server delete/inactivate = the URI once it has sent the notification?

Question 2: Presumably, when the client revalidates the = location(s), it will again request notification.  Does the server = return the same ID as before, or a different ID?  A different ID = could perhaps be useful in edge cases where the server didn't send or = the client didn't get the notification, but any utility seems small. =  If it's the same ID, then the answer to question 1 can be that the = URI remains active until the client asks to no longer be notified (by = sending an empty URI?).

--Randall

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
---------------------------------------------------------------= -------
-------- External Email: Please use caution when = opening links and 
attachments / Courriel externe: Soyez prudent avec les liens = et 
documents joints

---------------------------------------------------------------= ---------------
External Email: Please use caution when = opening links and attachments / Courriel externe: Soyez prudent avec les = liens et documents joints
 
 
 
External Email: Please use caution = when opening links and attachments / Courriel externe: Soyez prudent avec = les liens et documents joints
 
External Email: Please use caution when = opening links and attachments / Courriel externe: Soyez prudent avec les = liens et documents = joints

= --Apple-Mail=_84932FDA-B7F5-4A6E-B7B1-013A61CF1F21-- From nobody Tue Aug 31 14:14:40 2021 Return-Path: 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 F219E3A11A1 for ; Tue, 31 Aug 2021 14:14:37 -0700 (PDT) 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.20150623.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 KBapLPKwgACn for ; Tue, 31 Aug 2021 14:14:32 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 5372D3A1235 for ; Tue, 31 Aug 2021 14:14:12 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id b200so843796iof.13 for ; Tue, 31 Aug 2021 14:14:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4CkoCsShoCnJHVMLwNuQNeR/Giu3Ycb0QCs+RJDxKII=; b=EWlx561qpVUsjEW/YgZn47pQF1H/ceVDMEW8JI4ztuEcxs0jjLprXqBiDu7nrjmXtk yZ4wSyddLz/gadb+4zBkpVXgPeJBwMSK86Uwi4pdu+4TWgf5EWX2fxJomo1Y+i8UZ8lX YWSwuhhdlFA125dMCfNfgxjdOpxJQJU140UMGfp70nIVNkafRF2t+led/vnBMbZ03agV FXB8vDLaDub9vT6rwSL4H4RLRk1klTMaaqTnpOYkkEd0+SIQFjo0bUVpHbiKeyxfOQuc GneQ38F0exzyrB8WRrfI8nxlSjU59xmXKuvtb9IoMM38lt1Wb+6LuF6g3GVFUeX/OsyX 3nOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4CkoCsShoCnJHVMLwNuQNeR/Giu3Ycb0QCs+RJDxKII=; b=bzSTrUSu7QL2Crw37KQBn8JxAWBItunUOzZuFQ/N857XJxoJYMtoDJBiV9D+SNbjVO 5z2UXKGJIBlyJHhq0kCw6BTh7lgrh0jvDfvpdqu9te+gW+YxsMD2KkAVWIJG7u64ZvOL JHbVxKAyYUGFkjPP5tEcorCjcU5qggzLeSATtOyMnWJ8Rckn7sJDlBFaPwuR6eLDbWZx HyVGyYhEazTTnRos9OT8fRDaQTUQftYBdsP4B6cErQ40LdYDi4VcpeQW99ce3rYlZuoH kCbyHKcTfwIXYRBhuPhanTnbBc3X6lCb9eDY+lbOv4aL1pxmJb7FPyQzGdzM6g3pcscY eRMA== X-Gm-Message-State: AOAM531816Ng1UNZQOu950ZfFLgGktmsSHVHvGowjUpSoagvvADByqio k5KYyKb8/FXLTBBNcP3C/BH4hT4IMHQ8yGBU X-Google-Smtp-Source: ABdhPJx8n1hDM3AznJVvgu0fUmT0cl1wX2vbzmp39f/6UnftcrhBr/y67IZafQ+6qe37i2s2HGGcqw== X-Received: by 2002:a05:6602:1503:: with SMTP id g3mr24503884iow.25.1630444450560; Tue, 31 Aug 2021 14:14:10 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id s16sm10802168iln.5.2021.08.31.14.14.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Aug 2021 14:14:07 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Brian Rosen In-Reply-To: Date: Tue, 31 Aug 2021 17:14:07 -0400 Cc: ecrit@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6274F332-0928-404E-B1AA-218DF1E88DF0@brianrosen.net> References: <2B7FD550-34D6-4A80-956C-7CCDA7D34847@randy.pensive.org> To: Randall Gellens X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Ecrit] Review of draft-ietf-ecrit-lost-planned-changes-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 21:14:38 -0000 I=E2=80=99ll make TTL an attribute. I=E2=80=99ll look at the AsOf and InvalidAsOf. Might be a problem as = you suggest. I really think that there should be limits but I can soften the = requirement to SHOULD. Brian > On Aug 31, 2021, at 5:01 PM, Randall Gellens = wrote: >=20 > I haven't seen responses to the numbered items from my review: >=20 >> (1) Should the Time to Live information in a validation response be = an attribute rather than an element? Logically, it seems more an = attribute of the response, and also it mirrors the 'expires' attribute = on which it is modeled. >>=20 >> (2) In the extension schema, are 'invalidAsOf' and 'asOf' swapped? = ('AsOf' should be part of the element but looks like = maybe it is part of the response, while 'invalidAsOf' is part of = ). >>=20 >> (3) I'm not sure that "The server MUST have policy that limits use of = this mechanism by a given client" is warranted; I think using "SHOULD" = is more easily justified. >=20 > --Randall >=20 > On 23 Aug 2021, at 14:12, Randall Gellens wrote: >=20 >> (1) Should the Time to Live information in a validation response be = an attribute rather than an element? Logically, it seems more an = attribute of the response, and also it mirrors the 'expires' attribute = on which it is modeled. >>=20 >> (2) In the extension schema, are 'invalidAsOf' and 'asOf' swapped? = ('AsOf' should be part of the element but looks like = maybe it is part of the response, while 'invalidAsOf' is part of = ). >>=20 >> (3) I'm not sure that "The server MUST have policy that limits use of = this mechanism by a given client" is warranted; I think using "SHOULD" = is more easily justified. >>=20 >> I have a number of suggested edits for clarification or language. = Attached are four files: >>=20 >> draft-ietf-ecrit-lost-planned-changes-04-rg.xml >>=20 >> The XML uploaded by Brian, with my edits. >>=20 >> draft-ietf-ecrit-lost-planned-changes-04-rg.txt >>=20 >> The TXT generated from the XML with my edits. >>=20 >> Diff-txt.html >>=20 >> An IETF tools diff showing my edits to the TXT, side by side. >>=20 >> Diff-xml.html >>=20 >> An IETF tools diff showing my edits to the XML, side by side. >>=20 >>=20 >> --Randall From nobody Tue Aug 31 14:50:11 2021 Return-Path: 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 792B53A0848 for ; Tue, 31 Aug 2021 14:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FORGED_RELAY_MUA_TO_MX=0.01, 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 RIz_nWnlpQ2n for ; Tue, 31 Aug 2021 14:50:01 -0700 (PDT) Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id A10B83A0843 for ; Tue, 31 Aug 2021 14:50:00 -0700 (PDT) Received: from [99.111.97.181] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 31 Aug 2021 14:49:59 -0700 From: "Randall Gellens" To: "Brian Rosen" Cc: "Caron, Guy" , ECRIT Date: Tue, 31 Aug 2021 14:49:59 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: In-Reply-To: <8247DFD7-D3B3-44BC-9EE7-A2EF4B994A01@brianrosen.net> References: <5577e2e6daa4405bbe12ef61675e1f55@bell.ca> <3AD58DEC-1DC9-4BC0-B55C-4E782E4AAA74@brianrosen.net> <9433989A-85D7-41B9-96EA-313ADC0F02CD@brianrosen.net> <851c82ef56714b8a917761d98234093a@bell.ca> <0F5C2109-77E1-495E-9768-94E28DC6A76A@brianrosen.net> <0619e49202b146298d1bf7e01ec16fe2@bell.ca> <8247DFD7-D3B3-44BC-9EE7-A2EF4B994A01@brianrosen.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_80281531-E502-4074-BC9C-0B1225774697_=" Embedded-HTML: [{"HTML":[462, 39373], "plain":[131, 12112], "uuid":"78B73CEE-847B-497F-B835-18D753B1319F"}] Archived-At: Subject: Re: [Ecrit] planned-changes: two questions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 21:50:08 -0000 --=_MailMate_80281531-E502-4074-BC9C-0B1225774697_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable The IDs are entirely up to the server. The server can aggregate them. --Randall On 31 Aug 2021, at 14:11, Brian Rosen wrote: > It could limit it, but that would be a problem if it limited it such = > that a large planned change properly registered couldn=E2=80=99t work. = In = > some areas, they change hundreds of thousands of address points in a = > large annexation. It=E2=80=99s not typically millions, but you could = > imagine something like a county that dumps a new Site/Structure list = > where there wasn=E2=80=99t one before that triggers this kind of = > notification. > > That doesn=E2=80=99t change the need for start and limit if the list ca= n be = > big. Lots of systems I know have pretty severe limits on the size of = > an upload response for interfaces like this. > > Hmmm, start and limit go the wrong way. The notification is the POST. = > Start and Limit are for a GET. We would have to implement an = > equivalent on the registration. > > Brian > >> On Aug 31, 2021, at 4:57 PM, Caron, Guy wrote: >> >> The size of the list could be a policy at the Server. >> >> Guy >> >> De : Brian Rosen >> Envoy=C3=A9 : 31 ao=C3=BBt 2021 16:55 >> =C3=80 : Caron, Guy >> Cc : Randall Gellens ; ECRIT = >> >> Objet : [EXT]Re: [Ecrit] planned-changes: two questions >> >> If we did that, we would have to implement limit and start to handle = >> a large list. >> >> Brian >> >> >> >> On Aug 31, 2021, at 4:38 PM, Caron, Guy > > wrote: >> >> If we make a list of IDs, one notification per = >> URI per planned change would be sufficient. >> >> Guy >> >> De : Brian Rosen > >> Envoy=C3=A9 : 31 ao=C3=BBt 2021 15:35 >> =C3=80 : Randall Gellens > > >> Cc : Caron, Guy >; ECRIT = >> > >> Objet : [EXT]Re: [Ecrit] planned-changes: two questions >> >> No. >> >> There is one URI, but many IDs, one per unique record at the LoST = >> server that is involved in a planned change. The one URI will = >> receive one notification per ID it has registered for. >> >> >> >> >> >> On Aug 31, 2021, at 2:56 PM, Randall Gellens = >> > wrote: >> >> i understand that the concern is allowing a client to leverage the = >> LoST server to attack a large number of targets, I'm just not clear = >> mechanically how such leverage potentially works. Each validation = >> query can store a URI, and that URI may get associated with a large = >> number of locations. Maybe there's a street name change or an = >> annexation. So maybe thousands or tens or hundreds of thousands of = >> locations are potentially invalidated. They all have the same URI = >> associated with them, so the LoST server connects to the URI once and = >> POSTs one notification, no? >> --Randall >> On 31 Aug 2021, at 10:53, Brian Rosen wrote: >> Of course an attacker would conceal itself and register multiple URIs = >> under different identities. But the bigger problem is that if a = >> large planned change occurred, the victim could receive a large = >> number of notifications it didn=E2=80=99t expect. >> >> With a test transition, we know that the client expects to see = >> notifications, we only need one per URI (we could specify one per = >> domain =E2=80=94 after the scheme and before the first slash). If we = >> don=E2=80=99t get the ID, we know not to allow that URI to be provisio= ned. = >> So it=E2=80=99s one test transaction vs a large number of planned chan= ge = >> transactions. >> >> Brian >> >> >> >> >> On Aug 31, 2021, at 1:35 PM, Randall Gellens = >> > wrote: >> >> If a malicious client registers a URI that is designed to attack a = >> third site, the test transaction causes the LoST server to connect to = >> it and POST a command. Without a test transaction, the LoST server = >> stores the URI and at a future time connects to it and sends a = >> command. Either way, a LoST client can register potentially one URI = >> per queried location, and a LoST server will connect to that URI and = >> POST a message. A queried location could be tied to many other = >> locations, so there could be many locations for which a change would = >> trigger the LoST server to use the URI, but is that worse? >> --Randall >> On 31 Aug 2021, at 10:27, Brian Rosen wrote: >> If the work group wants to have the LoST server keep the URI until = >> expressly deleted, that=E2=80=99s okay with me. >> >> Authenticating the client to the server doesn=E2=80=99t mean the URI i= s = >> authenticated. We can=E2=80=99t restrict the URI to be the same entit= y as = >> the client running the LoST transaction. And the clients are wide = >> ranging. Could be an enterprise running its own LIS for example. We = >> can=E2=80=99t assume the North American PKI is workable everywhere, an= d = >> even that doesn=E2=80=99t extend to an enterprise LIS. ISTM we have t= o run = >> a test transaction with the notification service to make sure it=E2=80= =99s = >> what we think it is. >> >> Brian >> >> >> >> >> >> On Aug 31, 2021, at 9:01 AM, Caron, Guy > > wrote: >> >> Inline. >> >> Guy >> >> -----Message d'origine----- >> De : Brian Rosen > >> Envoy=C3=A9 : 31 ao=C3=BBt 2021 08:11 >> =C3=80 : Caron, Guy > >> Cc : Randall Gellens > >; ECRIT > > >> Objet : [EXT]Re: [Ecrit] planned-changes: two questions >> >> You delete the URI when you delete the record in the LIS. >> [GC] That's fine but that was not the question Randall posed. He = >> asked whether the URI is deleted after a notification. I agree that = >> if the Client does not host the location anymore that the URI = >> associated with that location in the Server should be deleted. This = >> could be achieved with an empty . >> >> I don=E2=80=99t think this is covered in 5222. The mechanism causes t= he = >> LoST server to send notifications to the client, but the client is = >> allowed to put any URI in the record, and it can add it to as many = >> records as it wants. >> [GC] I thought we agreed on using one generic URI per Client. Clients = >> should be authenticated by the Servers. >> An evil implementation could record URIs against multiple targets = >> that were unaware that the evil implementation did it, until they got = >> a large number of PUSH transactions they didn=E2=80=99t expect or = >> understand as a result of a large planned change. >> [GC] Only authenticated Clients should be allowed to provide URIs to = >> be stored by the Servers. >> >> The proposed mechanism qualifies the client URI before its used in a = >> planned change. >> >> Brian >> >> >> >> On Aug 31, 2021, at 7:37 AM, Caron, Guy > > wrote: >> >> Well, this is not going in the direction I thought. >> >> What is the purpose of deleting the URIs at the Server = >> post-validation? >> >> Regarding opening a new DoS, I guess I'm not following. Wouldn't this = >> case be covered by the security considerations in RFC 5222? >> >> What you're proposing puts back significant load on the Servers (a = >> key consideration for creating planned-changes in the first place) = >> and complicates the mechanism. >> >> Guy >> >> >> -----Message d'origine----- >> De : Ecrit > = >> De la part de Brian Rosen Envoy=C3=A9 : >> 30 ao=C3=BBt 2021 11:22 =C3=80 : Randall Gellens > > Cc >> : ECRIT > Objet : [EXT]Re: = >> [Ecrit] planned-changes: two >> questions >> >> Answer 1: yes. Since there is going to be a revalidation, just = >> deleting the setting seems right to me. >> Answer 2: Up to server. If I were implementing, I would hash the = >> real ID with the URI and some kind of predictable nonce. >> >> We probably have to say more about how the server identifies the = >> client, so that replacement of the URI works. Could we say we use = >> the domain of the URI (the entire domain with all the dots) to = >> identify the client, and anything can occur after it (meaning a slash = >> and whatever)? If we do that, then how would delete the = >> notification? Force there to be something other than the domain = >> (ugly). Explicit delete request? >> >> Hmmm, we=E2=80=99ve opened a DoS attack: a rogue client stores a bunch= of = >> URIs for servers it wants to victimize. In North America we have a = >> real simple solution for that, because we have a PKI, so we know, for = >> sure, who the client is, and could restrict who we allow to store = >> URIs, but that wouldn=E2=80=99t be true in general. Also, it would be= nice = >> for the client to have confidence the mechanism worked before it = >> needed it. >> >> So >> Let=E2=80=99s add a =E2=80=9Ccommand=E2=80=9D to plannedChange in the = findService = >> request. >> And, have the client have a response to the notification which is the >> ID (json with the 200) >> >> >> The client starts by sending a command of =E2=80=9Cinitialize=E2=80=9D= =2E The = >> domain is the identity of the client. The response is an immediate = >> notification to the with whatever LI was in the request and an ID. = >> The response by the client (which is the notification web server) is = >> a piece of json containing the ID. We can say that the LI in this = >> initialize command could be something simple like the Country Code = >> that wouldn=E2=80=99t get a planned change. >> >> Thereafter, the LoST server (notification client) periodically = >> repeats this keepalive notification every day or week with the = >> initialize LI. The client has to respond with the ID. >> >> The regular notification request is a command of =E2=80=9Cnotify=E2=80= =9D. The = >> server ignores a request for notification from an uninitialized = >> client. >> The notification can be deleted with a command of =E2=80=9Cdelete=E2=80= =9D. If = >> you delete the initialize LI, then the server won=E2=80=99t send any m= ore = >> notifications to that client and deletes all URIs it was saving for = >> that client. The client would have to re-initialize to reset. >> >> Brian >> >> >> >> On Aug 27, 2021, at 5:41 PM, Randall Gellens = >> > wrote: >> >> I think we're moving to a model where: >> - In a query, a client can request to be notified when the location >> should be revalidated; >> - In the response, the server provides an ID which the client >> associates with the location it just validated; >> - The server sends a notification to the URI, containing the ID; >> - The client revalidates each location with which that ID is = >> associated. >> >> Question 1: Does the server delete/inactivate the URI once it has = >> sent the notification? >> >> Question 2: Presumably, when the client revalidates the location(s), = >> it will again request notification. Does the server return the same = >> ID as before, or a different ID? A different ID could perhaps be = >> useful in edge cases where the server didn't send or the client = >> didn't get the notification, but any utility seems small. If it's = >> the same ID, then the answer to question 1 can be that the URI = >> remains active until the client asks to no longer be notified (by = >> sending an empty URI?). >> >> --Randall >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit = >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit = >> >> ----------------------------------------------------------------------= >> -------- External Email: Please use caution when opening links and >> attachments / Courriel externe: Soyez prudent avec les liens et >> documents joints >> >> ----------------------------------------------------------------------= -------- >> External Email: Please use caution when opening links and attachments = >> / Courriel externe: Soyez prudent avec les liens et documents joints >> >> >> >> External Email: Please use caution when opening links and attachments = >> / Courriel externe: Soyez prudent avec les liens et documents joints >> >> External Email: Please use caution when opening links and attachments = >> / Courriel externe: Soyez prudent avec les liens et documents joints --=_MailMate_80281531-E502-4074-BC9C-0B1225774697_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">The IDs are entirely up to the server. The server can agg= regate them.

--Randall

On 31 Aug 2021, at 14:11, Brian Rosen wrote:

It could limit it, but that would be a pro= blem if it limited it such that a large planned change properly registere= d couldn=E2=80=99t work.  In some areas, they change hundreds of tho= usands of address points in a large annexation.  It=E2=80=99s not ty= pically millions, but you could imagine something like a county that dump= s a new Site/Structure list where there wasn=E2=80=99t one before that tr= iggers this kind of notification.

That doesn=E2=80=99t change the need for start and limit if = the list can be big.  Lots of systems I know have pretty severe limi= ts on the size of an upload response for interfaces like this.

Hmmm, start and limit go = the wrong way.  The notification is the POST.  Start and Limit = are for a GET.  We would have to implement an equivalent on the regi= stration.

Brian=

On Aug 31, 2021, at 4:57 PM, Caron, Guy &l= t;g.caron@bell.ca> w= rote:

The size of the list= could be a policy at the Server.
 
Guy=
 
De : Brian Rosen <br@brianrosen.net> 
Envoy=C3=A9&nbs= p;: 31 ao=C3=BBt 20= 21 16:55
=C3=80 : Caron, Guy <g.caron@bell.ca>
C= c : Randall Ge= llens <rg+ietf= @randy.pensive.org>; ECRIT <ecrit@ietf.org>
Objet :=  [EXT]Re: [Ecrit] p= lanned-changes: two questions
 
If we did that, we = would have to implement limit and start to handle a large list.  
 
Brian
 


<= div class=3D"">
On Aug 31, 20= 21, at 4:38 PM, Caron, Guy <g.caron@bell.ca> wrote:
 
If we make <revalidateLocation> a list= of IDs, one notification per URI per planned change would be sufficient.=
 
Guy
&= nbsp;
De : Brian Rosen <br@brianrosen.net> 
Envoy=C3=A9 :<= span class=3D"apple-converted-space"> 31 ao=C3=BBt 2021 15:35=
=C3=80 : Randall Gellens <rg+ietf@randy.pensive.org>
Cc&n= bsp;: Caron, Guy &l= t;g.caron@bell.ca>; ECRIT <ecrit@ietf.org>
Objet&n= bsp;: [EXT]Re: [Ecr= it] planned-changes: two questions
 
No.  
=
 
There is one UR= I, but many IDs, one per unique record at the LoST server that is involve= d in a planned change.  The one URI will receive one notification pe= r ID it has registered for.
 
 



On Aug 31, 2021, at 2:56 PM, Randall Ge= llens <rg+ietf@randy.pensive.org= > wrote:<= /div>
 
=
i understand= that the concern is allowing a client to leverage the LoST server to att= ack a large number of targets, I'm just not clear mechanically how such l= everage potentially works. Each validation query can store a URI, and tha= t URI may get associated with a large number of locations. Maybe there's = a street name change or an annexation. So maybe thousands or tens or hund= reds of thousands of locations are potentially invalidated. They all have= the same URI associated with them, so the LoST server connects to the UR= I once and POSTs one notification, no?
=
--Ran= dall
On 31 Aug 2021, at 10:53, Brian Rosen wr= ote:
Of course an attacker would conceal it= self and register multiple URIs under different identities.  But the= bigger  problem is that if a large planned change occurred, the vic= tim could receive a large number of notifications it didn=E2=80=99t expec= t.
 
With a test transition, we know that the client expects to = see notifications, we only need one per URI (we could specify one per dom= ain =E2=80=94 after the scheme and before the first slash).  If we d= on=E2=80=99t get the ID, we know not to allow that URI to be provisioned.=  So it=E2=80=99s one test transaction vs a large number of planned = change transactions.
 
=
Brian<= /div>
 



On Aug 31, 2021, at 1:35 PM, Randall Gellens <rg+ietf@randy.pe= nsive.org> wrote:
 
= If a malicious client registers a URI that is= designed to attack a third site, the test transaction causes the LoST se= rver to connect to it and POST a command. Without a test transaction, the= LoST server stores the URI and at a future time connects to it and sends= a command. Either way, a LoST client can register potentially one URI pe= r queried location, and a LoST server will connect to that URI and POST a= message. A queried location could be tied to many other locations, so th= ere could be many locations for which a change would trigger the LoST ser= ver to use the URI, but is that worse?
=
--Randall
<= div class=3D"">
On 31 Aug 2021, at 10:27, Brian Rosen wrote:
If the work group wants to have the LoST server keep the U= RI until expressly deleted, that=E2=80=99s okay with me.
 
Authe= nticating the client to the server doesn=E2=80=99t mean the URI is authen= ticated.  We can=E2=80=99t restrict the URI to be the same entity as= the client running the LoST transaction.  And the clients are wide = ranging.  Could be an enterprise running its own LIS for example. &n= bsp;We can=E2=80=99t assume the North American PKI is workable everywhere= , and even that doesn=E2=80=99t extend to an enterprise LIS.  ISTM w= e have to run a test transaction with the notification service to make su= re it=E2=80=99s what we think it is.
 =
Brian
 =
 



On Aug 31, 2021, at 9:01 AM, Caron, Guy <g.caron@bell.ca> wrote:
 
Inline.

Guy=

-----Message d'origine-----
D= e : Brian Rosen <br@brianrosen.net> = ;
Envoy=C3=A9 : 31 ao=C3=BBt 2021 08:11
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : Randall G= ellens <rg+ietf@randy.pensive.org>; ECRIT <ecrit@ietf.org>
Objet : [E= XT]Re: [Ecrit] planned-changes: two questions

You delete the URI when you delete the record in the LIS.
[GC] That's fine but that was not the question Randall posed. He asked w= hether the URI is deleted after a notification. I agree that if the Clien= t does not host the location anymore that the URI associated with that lo= cation in the Server should be deleted. This could be achieved with an em= pty <plannedChange>.

I don=E2=80=99t t= hink this is covered in 5222.  The mechanism causes the LoST server = to send notifications to the client, but the client is allowed to put any= URI in the record, and it can add it to as many records as it wants.
[GC] I thought we agreed on using one generic URI per Client. = Clients should be authenticated by the Servers.
 An ev= il implementation could record URIs against multiple targets that were un= aware that the evil implementation did it, until they got a large number = of PUSH transactions they didn=E2=80=99t expect or understand as a result= of a large planned change.
[GC] Only authenticated Clients= should be allowed to provide URIs to be stored by the Servers.

The proposed mechanism qualifies the client URI before = its used in a planned change.

Brian



On Aug 31, 2021, at 7:= 37 AM, Caron, Guy <g.caron@bell.ca> wrote:

Well, this is= not going in the direction I thought.

What = is the purpose of deleting the URIs at the Server post-validation?

Regarding opening a new DoS, I guess I'm not follo= wing. Wouldn't this case be covered by the security considerations in RFC= 5222?

What you're proposing puts back signi= ficant load on the Servers (a key consideration for creating planned-chan= ges in the first place) and complicates the mechanism.

Guy


-----Message d'origine-----
De : = Ecrit <ec= rit-bounces@ietf.org> De l= a part de Brian Rosen Envoy=C3=A9 :=  
30 ao=C3=BBt 2021 11:22 =C3=80 : Randall Gell= ens <r= g+ietf@randy.pensive.org> = Cc 
: ECR= IT <ecrit@ietf.or= g> Objet : [EXT]Re: [Ecrit= ] planned-changes: two =
questions

Answer 1: yes. &nbs= p;Since there is g= oing to be a revalidation, just deleting the setting seems right to me.Answer 2: Up to server.  If I were implementing, I woul= d hash the real ID with the URI and some kind of predictable nonce.  = ;

We probably have to say more about how the= server identifies the client, so that replacement of the URI works. &nbs= p;Could we say we use the domain of the URI (the entire domain with all t= he dots) to identify the client, and anything can occur after it (meaning= a slash and whatever)?  If we do that, then how would delete the no= tification?  Force there to be something other than the domain (ugly= ).  Explicit delete request?

Hmmm, we=E2= =80=99ve opened a DoS attack: a rogue client stores a bunch of URIs for s= ervers it wants to victimize.  In North America we have a real simpl= e solution for that, because we have a PKI, so we know, for sure, who the= client is, and could restrict who we allow to store URIs, but that would= n=E2=80=99t be true in general.  Also, it would be nice for the clie= nt to have confidence the mechanism worked before it needed it.

So
Let=E2=80=99s add a =E2=80=9Ccommand=E2= =80=9D to plannedChange in the findService request.  
= And, have the client have a response to the notification which is the 
ID (json wi= th the 200)


The client starts= by sending a command of =E2=80=9Cinitialize=E2=80=9D.  The domain i= s the identity of the client.  The response is an immediate notifica= tion to the with whatever LI was in the request and an ID.  The &nbs= p;response by the client (which is the notification web server) is a piec= e of json containing the ID.  We can say that the LI in this initial= ize command could be something simple like the Country Code that wouldn=E2= =80=99t get a planned change.

Thereafter, th= e LoST server (notification client) periodically repeats this keepalive n= otification every day or week with the initialize LI.  The client ha= s to respond with the ID.

The regular notifi= cation request is a command of =E2=80=9Cnotify=E2=80=9D.  The server= ignores a request for notification from an uninitialized client.
The notification can be deleted with a command of =E2=80=9Cdelete=E2= =80=9D.  If you delete the initialize LI, then the server won=E2=80=99= t send any more notifications to that client and deletes all URIs it was = saving for that client.  The client would have to re-initialize to r= eset.

Brian


On Aug 27, 2021, at 5:41 PM, Randall Gellens = <rg+ietf@randy.pensive.org> wrote:

I think we're= moving to a model where:
- In a query, a client can reques= t to be notified when the location&= nbsp;
should be revalidated;
- In the = response, the server provides an ID which the client 
associates with the location= it just validated;
- The server sends a notification to th= e URI, containing the ID;
- The client revalidates each loc= ation with which that ID is associated.

Ques= tion 1: Does the server delete/inactivate the URI once it has sent the no= tification?

Question 2: Presumably, when the= client revalidates the location(s), it will again request notification. =  Does the server return the same ID as before, or a different ID? &n= bsp;A different ID could perhaps be useful in edge cases where the server= didn't send or the client didn't get the notification, but any utility s= eems small.  If it's the same ID, then the answer to question 1 can = be that the URI remains active until the client asks to no longer be noti= fied (by sending an empty URI?).

--Randall
_____________________________________________= __
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit=

_______________________________________________
Ec= rit mailing list
Ecrit@ietf.org
https://www.iet= f.org/mailman/listinfo/ecrit
--------------------------------------------= --------------------------
-------- External Email: Please = use caution when opening links and&= nbsp;
attachments / Courriel externe: Soyez prudent = avec les liens et 
documents joints

------------------------------------------------= ------------------------------
External Email: Please use c= aution when opening links and attachments / Courriel externe: Soyez prude= nt avec les liens et documents joints
<= /div>
 
<= /div>
=
&= nbsp;
 
External Email: Please use caution when opening links and= attachments / <= /i>Courriel externe: Soyez prudent avec les lie= ns et documents joints
 
External Email: Please use caution when opening l= inks and attachments / = Courriel externe: Soyez prudent avec les liens et = documents joints

--=_MailMate_80281531-E502-4074-BC9C-0B1225774697_=-- From nobody Tue Aug 31 14:50:21 2021 Return-Path: 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 1D8793A0843 for ; Tue, 31 Aug 2021 14:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=bell.ca 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 7BXJq93FaYdJ for ; Tue, 31 Aug 2021 14:50:01 -0700 (PDT) Received: from ESA2-Wyn.bell.ca (esa2-wyn.bell.ca [67.69.243.180]) (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 CFBE83A0844 for ; Tue, 31 Aug 2021 14:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1630446600; x=1661982600; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=IY2jJKmLwqZMBvFqxqJ9rK5RoYO4JxdQtz7l141lYYA=; b=V0c0rtgh47lq6bNsM2foqOBIzkJx6+zrq8gq6uLV/NTj9RZEarOqae8T 9LDgMbh62wXsPJt5uYNwVj/xkMSGVB6ViUJVZuBBErlHcwZcp58HlXqKi HoKD4gnRbFQg7qhazsox9bUYtP51i/9Obs6YFl8NtwG9CdqaUp2+2z24e K2bUz1WR6KyTfJ+zf/4lX37hpb7yYqAxinDY3pHF1pqxTWJkBiYTKE8IJ WOZtwVmT6RO5X4IAgDHvp4KSDGBnccksAjDiydyPke8OKbp0GAFb3SJ/n jBqdU+4EQGneZZLe4KP7eLrtq25rnBsowbZRZfeiJ75NCtnzOvamvqH+I A==; IronPort-SDR: EvNYnUz/Jwky0mIfTgbYMMBCl9DvvNl1Qbts61+3vdK4ZPmJmslitw/RksfalBzRjZUoGaF2c7 aXTEpfshNtrg== Received: from dm5czo-d01.bellca.int.bell.ca (HELO DG7MBX01-WYN.bell.corp.bce.ca) ([198.235.102.33]) by esa02corp-wyn.bell.corp.bce.ca with ESMTP; 31 Aug 2021 17:49:58 -0400 Received: from DG12MBX02-WYN.bell.corp.bce.ca (142.182.18.47) by DG7MBX01-WYN.bell.corp.bce.ca (142.182.18.40) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Tue, 31 Aug 2021 17:49:58 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca (142.182.18.46) by DG12MBX02-WYN.bell.corp.bce.ca (142.182.18.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Tue, 31 Aug 2021 17:49:58 -0400 Received: from DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7]) by DG12MBX01-WYN.bell.corp.bce.ca ([fe80::e0dd:6ba7:3471:98e7%4]) with mapi id 15.01.2242.010; Tue, 31 Aug 2021 17:49:58 -0400 From: "Caron, Guy" To: Brian Rosen CC: Randall Gellens , ECRIT Thread-Topic: [EXT]Re: [Ecrit] planned-changes: two questions Thread-Index: AQHXnbLZ8xDlKKXTXU23cWH8anqQbauNeTZQgABQ14D//8deMIAAkTMAgAACPYCAAAUMgIAAEX0AgAAK0gD//83iAIAASICA//+9V/AACOtzgAAHKwRg Date: Tue, 31 Aug 2021 21:49:58 +0000 Message-ID: <95cfe4eb9e8447ed8ba0185333a79c52@bell.ca> References: <5577e2e6daa4405bbe12ef61675e1f55@bell.ca> <3AD58DEC-1DC9-4BC0-B55C-4E782E4AAA74@brianrosen.net> <9433989A-85D7-41B9-96EA-313ADC0F02CD@brianrosen.net> <851c82ef56714b8a917761d98234093a@bell.ca> <0F5C2109-77E1-495E-9768-94E28DC6A76A@brianrosen.net> <0619e49202b146298d1bf7e01ec16fe2@bell.ca> <8247DFD7-D3B3-44BC-9EE7-A2EF4B994A01@brianrosen.net> In-Reply-To: <8247DFD7-D3B3-44BC-9EE7-A2EF4B994A01@brianrosen.net> Accept-Language: fr-CA, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.112.70] Content-Type: multipart/alternative; boundary="_000_95cfe4eb9e8447ed8ba0185333a79c52bellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ecrit] planned-changes: two questions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emergency Context Resolution with Internet Technologies List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 21:50:08 -0000 --_000_95cfe4eb9e8447ed8ba0185333a79c52bellca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2VsbCwgdGhpcyBub3RpZmljYXRpb24gcHJvY2VzcyBpcyBmb3IgcGxhbm5lZCBjaGFuZ2VzIGFu ZCBpbiB0aGUgbWFqb3JpdHkgb2YgY2FzZXMsIHBsYW5uZWQgY2hhbmdlcyB3aWxsIHRyaWdnZXIg bm90aWZpY2F0aW9uIGluIGFkdmFuY2Ugb2YgdGhlIGNoYW5nZS4gSXQgYWN0dWFsbHkgbWF5IGJl IGEgYmVuZWZpdCB0byB0aGUgU2VydmVyIHRvIHNlbmQgbm90aWZpY2F0aW9ucyBpbiBidW5kbGVz LCBlc3BlY2lhbGx5IGlmIHRoZSBwbGFubmVkIGNoYW5nZSBpcyBsYXJnZS4gVGhhdCB3YXkgaXQg Y291bGQgc29tZXdoYXQgY29udHJvbCB0aGUgc3VyZ2Ugb2YgcmV2YWxpZGF0aW9ucyBjb21pbmcg dG8gaXQuDQoNCkd1eQ0KDQpEZSA6IEJyaWFuIFJvc2VuIDxickBicmlhbnJvc2VuLm5ldD4NCkVu dm95w6kgOiAzMSBhb8O7dCAyMDIxIDE3OjEyDQrDgCA6IENhcm9uLCBHdXkgPGcuY2Fyb25AYmVs bC5jYT4NCkNjIDogUmFuZGFsbCBHZWxsZW5zIDxyZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnPjsg RUNSSVQgPGVjcml0QGlldGYub3JnPg0KT2JqZXQgOiBbRVhUXVJlOiBbRWNyaXRdIHBsYW5uZWQt Y2hhbmdlczogdHdvIHF1ZXN0aW9ucw0KDQpJdCBjb3VsZCBsaW1pdCBpdCwgYnV0IHRoYXQgd291 bGQgYmUgYSBwcm9ibGVtIGlmIGl0IGxpbWl0ZWQgaXQgc3VjaCB0aGF0IGEgbGFyZ2UgcGxhbm5l ZCBjaGFuZ2UgcHJvcGVybHkgcmVnaXN0ZXJlZCBjb3VsZG7igJl0IHdvcmsuICBJbiBzb21lIGFy ZWFzLCB0aGV5IGNoYW5nZSBodW5kcmVkcyBvZiB0aG91c2FuZHMgb2YgYWRkcmVzcyBwb2ludHMg aW4gYSBsYXJnZSBhbm5leGF0aW9uLiAgSXTigJlzIG5vdCB0eXBpY2FsbHkgbWlsbGlvbnMsIGJ1 dCB5b3UgY291bGQgaW1hZ2luZSBzb21ldGhpbmcgbGlrZSBhIGNvdW50eSB0aGF0IGR1bXBzIGEg bmV3IFNpdGUvU3RydWN0dXJlIGxpc3Qgd2hlcmUgdGhlcmUgd2FzbuKAmXQgb25lIGJlZm9yZSB0 aGF0IHRyaWdnZXJzIHRoaXMga2luZCBvZiBub3RpZmljYXRpb24uDQoNClRoYXQgZG9lc27igJl0 IGNoYW5nZSB0aGUgbmVlZCBmb3Igc3RhcnQgYW5kIGxpbWl0IGlmIHRoZSBsaXN0IGNhbiBiZSBi aWcuICBMb3RzIG9mIHN5c3RlbXMgSSBrbm93IGhhdmUgcHJldHR5IHNldmVyZSBsaW1pdHMgb24g dGhlIHNpemUgb2YgYW4gdXBsb2FkIHJlc3BvbnNlIGZvciBpbnRlcmZhY2VzIGxpa2UgdGhpcy4N Cg0KSG1tbSwgc3RhcnQgYW5kIGxpbWl0IGdvIHRoZSB3cm9uZyB3YXkuICBUaGUgbm90aWZpY2F0 aW9uIGlzIHRoZSBQT1NULiAgU3RhcnQgYW5kIExpbWl0IGFyZSBmb3IgYSBHRVQuICBXZSB3b3Vs ZCBoYXZlIHRvIGltcGxlbWVudCBhbiBlcXVpdmFsZW50IG9uIHRoZSByZWdpc3RyYXRpb24uDQoN CkJyaWFuDQoNCg0KT24gQXVnIDMxLCAyMDIxLCBhdCA0OjU3IFBNLCBDYXJvbiwgR3V5IDxnLmNh cm9uQGJlbGwuY2E8bWFpbHRvOmcuY2Fyb25AYmVsbC5jYT4+IHdyb3RlOg0KDQpUaGUgc2l6ZSBv ZiB0aGUgbGlzdCBjb3VsZCBiZSBhIHBvbGljeSBhdCB0aGUgU2VydmVyLg0KDQpHdXkNCg0KRGUg OiBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ8bWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0 Pj4NCkVudm95w6kgOiAzMSBhb8O7dCAyMDIxIDE2OjU1DQrDgCA6IENhcm9uLCBHdXkgPGcuY2Fy b25AYmVsbC5jYTxtYWlsdG86Zy5jYXJvbkBiZWxsLmNhPj4NCkNjIDogUmFuZGFsbCBHZWxsZW5z IDxyZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnPG1haWx0bzpyZytpZXRmQHJhbmR5LnBlbnNpdmUu b3JnPj47IEVDUklUIDxlY3JpdEBpZXRmLm9yZzxtYWlsdG86ZWNyaXRAaWV0Zi5vcmc+Pg0KT2Jq ZXQgOiBbRVhUXVJlOiBbRWNyaXRdIHBsYW5uZWQtY2hhbmdlczogdHdvIHF1ZXN0aW9ucw0KDQpJ ZiB3ZSBkaWQgdGhhdCwgd2Ugd291bGQgaGF2ZSB0byBpbXBsZW1lbnQgbGltaXQgYW5kIHN0YXJ0 IHRvIGhhbmRsZSBhIGxhcmdlIGxpc3QuDQoNCkJyaWFuDQoNCg0KDQoNCk9uIEF1ZyAzMSwgMjAy MSwgYXQgNDozOCBQTSwgQ2Fyb24sIEd1eSA8Zy5jYXJvbkBiZWxsLmNhPG1haWx0bzpnLmNhcm9u QGJlbGwuY2E+PiB3cm90ZToNCg0KSWYgd2UgbWFrZSA8cmV2YWxpZGF0ZUxvY2F0aW9uPiBhIGxp c3Qgb2YgSURzLCBvbmUgbm90aWZpY2F0aW9uIHBlciBVUkkgcGVyIHBsYW5uZWQgY2hhbmdlIHdv dWxkIGJlIHN1ZmZpY2llbnQuDQoNCkd1eQ0KDQpEZSA6IEJyaWFuIFJvc2VuIDxickBicmlhbnJv c2VuLm5ldDxtYWlsdG86YnJAYnJpYW5yb3Nlbi5uZXQ+Pg0KRW52b3nDqSA6IDMxIGFvw7t0IDIw MjEgMTU6MzUNCsOAIDogUmFuZGFsbCBHZWxsZW5zIDxyZytpZXRmQHJhbmR5LnBlbnNpdmUub3Jn PG1haWx0bzpyZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnPj4NCkNjIDogQ2Fyb24sIEd1eSA8Zy5j YXJvbkBiZWxsLmNhPG1haWx0bzpnLmNhcm9uQGJlbGwuY2E+PjsgRUNSSVQgPGVjcml0QGlldGYu b3JnPG1haWx0bzplY3JpdEBpZXRmLm9yZz4+DQpPYmpldCA6IFtFWFRdUmU6IFtFY3JpdF0gcGxh bm5lZC1jaGFuZ2VzOiB0d28gcXVlc3Rpb25zDQoNCk5vLg0KDQpUaGVyZSBpcyBvbmUgVVJJLCBi dXQgbWFueSBJRHMsIG9uZSBwZXIgdW5pcXVlIHJlY29yZCBhdCB0aGUgTG9TVCBzZXJ2ZXIgdGhh dCBpcyBpbnZvbHZlZCBpbiBhIHBsYW5uZWQgY2hhbmdlLiAgVGhlIG9uZSBVUkkgd2lsbCByZWNl aXZlIG9uZSBub3RpZmljYXRpb24gcGVyIElEIGl0IGhhcyByZWdpc3RlcmVkIGZvci4NCg0KDQoN Cg0KDQoNCk9uIEF1ZyAzMSwgMjAyMSwgYXQgMjo1NiBQTSwgUmFuZGFsbCBHZWxsZW5zIDxyZytp ZXRmQHJhbmR5LnBlbnNpdmUub3JnPG1haWx0bzpyZytpZXRmQHJhbmR5LnBlbnNpdmUub3JnPj4g d3JvdGU6DQoNCmkgdW5kZXJzdGFuZCB0aGF0IHRoZSBjb25jZXJuIGlzIGFsbG93aW5nIGEgY2xp ZW50IHRvIGxldmVyYWdlIHRoZSBMb1NUIHNlcnZlciB0byBhdHRhY2sgYSBsYXJnZSBudW1iZXIg b2YgdGFyZ2V0cywgSSdtIGp1c3Qgbm90IGNsZWFyIG1lY2hhbmljYWxseSBob3cgc3VjaCBsZXZl cmFnZSBwb3RlbnRpYWxseSB3b3Jrcy4gRWFjaCB2YWxpZGF0aW9uIHF1ZXJ5IGNhbiBzdG9yZSBh IFVSSSwgYW5kIHRoYXQgVVJJIG1heSBnZXQgYXNzb2NpYXRlZCB3aXRoIGEgbGFyZ2UgbnVtYmVy IG9mIGxvY2F0aW9ucy4gTWF5YmUgdGhlcmUncyBhIHN0cmVldCBuYW1lIGNoYW5nZSBvciBhbiBh bm5leGF0aW9uLiBTbyBtYXliZSB0aG91c2FuZHMgb3IgdGVucyBvciBodW5kcmVkcyBvZiB0aG91 c2FuZHMgb2YgbG9jYXRpb25zIGFyZSBwb3RlbnRpYWxseSBpbnZhbGlkYXRlZC4gVGhleSBhbGwg aGF2ZSB0aGUgc2FtZSBVUkkgYXNzb2NpYXRlZCB3aXRoIHRoZW0sIHNvIHRoZSBMb1NUIHNlcnZl ciBjb25uZWN0cyB0byB0aGUgVVJJIG9uY2UgYW5kIFBPU1RzIG9uZSBub3RpZmljYXRpb24sIG5v Pw0KLS1SYW5kYWxsDQpPbiAzMSBBdWcgMjAyMSwgYXQgMTA6NTMsIEJyaWFuIFJvc2VuIHdyb3Rl Og0KT2YgY291cnNlIGFuIGF0dGFja2VyIHdvdWxkIGNvbmNlYWwgaXRzZWxmIGFuZCByZWdpc3Rl ciBtdWx0aXBsZSBVUklzIHVuZGVyIGRpZmZlcmVudCBpZGVudGl0aWVzLiAgQnV0IHRoZSBiaWdn ZXIgIHByb2JsZW0gaXMgdGhhdCBpZiBhIGxhcmdlIHBsYW5uZWQgY2hhbmdlIG9jY3VycmVkLCB0 aGUgdmljdGltIGNvdWxkIHJlY2VpdmUgYSBsYXJnZSBudW1iZXIgb2Ygbm90aWZpY2F0aW9ucyBp dCBkaWRu4oCZdCBleHBlY3QuDQoNCldpdGggYSB0ZXN0IHRyYW5zaXRpb24sIHdlIGtub3cgdGhh dCB0aGUgY2xpZW50IGV4cGVjdHMgdG8gc2VlIG5vdGlmaWNhdGlvbnMsIHdlIG9ubHkgbmVlZCBv bmUgcGVyIFVSSSAod2UgY291bGQgc3BlY2lmeSBvbmUgcGVyIGRvbWFpbiDigJQgYWZ0ZXIgdGhl IHNjaGVtZSBhbmQgYmVmb3JlIHRoZSBmaXJzdCBzbGFzaCkuICBJZiB3ZSBkb27igJl0IGdldCB0 aGUgSUQsIHdlIGtub3cgbm90IHRvIGFsbG93IHRoYXQgVVJJIHRvIGJlIHByb3Zpc2lvbmVkLiAg U28gaXTigJlzIG9uZSB0ZXN0IHRyYW5zYWN0aW9uIHZzIGEgbGFyZ2UgbnVtYmVyIG9mIHBsYW5u ZWQgY2hhbmdlIHRyYW5zYWN0aW9ucy4NCg0KQnJpYW4NCg0KDQoNCg0KDQpPbiBBdWcgMzEsIDIw MjEsIGF0IDE6MzUgUE0sIFJhbmRhbGwgR2VsbGVucyA8cmcraWV0ZkByYW5keS5wZW5zaXZlLm9y ZzxtYWlsdG86cmcraWV0ZkByYW5keS5wZW5zaXZlLm9yZz4+IHdyb3RlOg0KDQpJZiBhIG1hbGlj aW91cyBjbGllbnQgcmVnaXN0ZXJzIGEgVVJJIHRoYXQgaXMgZGVzaWduZWQgdG8gYXR0YWNrIGEg dGhpcmQgc2l0ZSwgdGhlIHRlc3QgdHJhbnNhY3Rpb24gY2F1c2VzIHRoZSBMb1NUIHNlcnZlciB0 byBjb25uZWN0IHRvIGl0IGFuZCBQT1NUIGEgY29tbWFuZC4gV2l0aG91dCBhIHRlc3QgdHJhbnNh Y3Rpb24sIHRoZSBMb1NUIHNlcnZlciBzdG9yZXMgdGhlIFVSSSBhbmQgYXQgYSBmdXR1cmUgdGlt ZSBjb25uZWN0cyB0byBpdCBhbmQgc2VuZHMgYSBjb21tYW5kLiBFaXRoZXIgd2F5LCBhIExvU1Qg Y2xpZW50IGNhbiByZWdpc3RlciBwb3RlbnRpYWxseSBvbmUgVVJJIHBlciBxdWVyaWVkIGxvY2F0 aW9uLCBhbmQgYSBMb1NUIHNlcnZlciB3aWxsIGNvbm5lY3QgdG8gdGhhdCBVUkkgYW5kIFBPU1Qg YSBtZXNzYWdlLiBBIHF1ZXJpZWQgbG9jYXRpb24gY291bGQgYmUgdGllZCB0byBtYW55IG90aGVy IGxvY2F0aW9ucywgc28gdGhlcmUgY291bGQgYmUgbWFueSBsb2NhdGlvbnMgZm9yIHdoaWNoIGEg Y2hhbmdlIHdvdWxkIHRyaWdnZXIgdGhlIExvU1Qgc2VydmVyIHRvIHVzZSB0aGUgVVJJLCBidXQg aXMgdGhhdCB3b3JzZT8NCi0tUmFuZGFsbA0KT24gMzEgQXVnIDIwMjEsIGF0IDEwOjI3LCBCcmlh biBSb3NlbiB3cm90ZToNCklmIHRoZSB3b3JrIGdyb3VwIHdhbnRzIHRvIGhhdmUgdGhlIExvU1Qg c2VydmVyIGtlZXAgdGhlIFVSSSB1bnRpbCBleHByZXNzbHkgZGVsZXRlZCwgdGhhdOKAmXMgb2th eSB3aXRoIG1lLg0KDQpBdXRoZW50aWNhdGluZyB0aGUgY2xpZW50IHRvIHRoZSBzZXJ2ZXIgZG9l c27igJl0IG1lYW4gdGhlIFVSSSBpcyBhdXRoZW50aWNhdGVkLiAgV2UgY2Fu4oCZdCByZXN0cmlj dCB0aGUgVVJJIHRvIGJlIHRoZSBzYW1lIGVudGl0eSBhcyB0aGUgY2xpZW50IHJ1bm5pbmcgdGhl IExvU1QgdHJhbnNhY3Rpb24uICBBbmQgdGhlIGNsaWVudHMgYXJlIHdpZGUgcmFuZ2luZy4gIENv dWxkIGJlIGFuIGVudGVycHJpc2UgcnVubmluZyBpdHMgb3duIExJUyBmb3IgZXhhbXBsZS4gIFdl IGNhbuKAmXQgYXNzdW1lIHRoZSBOb3J0aCBBbWVyaWNhbiBQS0kgaXMgd29ya2FibGUgZXZlcnl3 aGVyZSwgYW5kIGV2ZW4gdGhhdCBkb2VzbuKAmXQgZXh0ZW5kIHRvIGFuIGVudGVycHJpc2UgTElT LiAgSVNUTSB3ZSBoYXZlIHRvIHJ1biBhIHRlc3QgdHJhbnNhY3Rpb24gd2l0aCB0aGUgbm90aWZp Y2F0aW9uIHNlcnZpY2UgdG8gbWFrZSBzdXJlIGl04oCZcyB3aGF0IHdlIHRoaW5rIGl0IGlzLg0K DQpCcmlhbg0KDQoNCg0KDQoNCg0KT24gQXVnIDMxLCAyMDIxLCBhdCA5OjAxIEFNLCBDYXJvbiwg R3V5IDxnLmNhcm9uQGJlbGwuY2E8bWFpbHRvOmcuY2Fyb25AYmVsbC5jYT4+IHdyb3RlOg0KDQpJ bmxpbmUuDQoNCkd1eQ0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlIDogQnJpYW4g Um9zZW4gPGJyQGJyaWFucm9zZW4ubmV0PG1haWx0bzpickBicmlhbnJvc2VuLm5ldD4+DQpFbnZv ecOpIDogMzEgYW/Du3QgMjAyMSAwODoxMQ0Kw4AgOiBDYXJvbiwgR3V5IDxnLmNhcm9uQGJlbGwu Y2E8bWFpbHRvOmcuY2Fyb25AYmVsbC5jYT4+DQpDYyA6IFJhbmRhbGwgR2VsbGVucyA8cmcraWV0 ZkByYW5keS5wZW5zaXZlLm9yZzxtYWlsdG86cmcraWV0ZkByYW5keS5wZW5zaXZlLm9yZz4+OyBF Q1JJVCA8ZWNyaXRAaWV0Zi5vcmc8bWFpbHRvOmVjcml0QGlldGYub3JnPj4NCk9iamV0IDogW0VY VF1SZTogW0Vjcml0XSBwbGFubmVkLWNoYW5nZXM6IHR3byBxdWVzdGlvbnMNCg0KWW91IGRlbGV0 ZSB0aGUgVVJJIHdoZW4geW91IGRlbGV0ZSB0aGUgcmVjb3JkIGluIHRoZSBMSVMuDQpbR0NdIFRo YXQncyBmaW5lIGJ1dCB0aGF0IHdhcyBub3QgdGhlIHF1ZXN0aW9uIFJhbmRhbGwgcG9zZWQuIEhl IGFza2VkIHdoZXRoZXIgdGhlIFVSSSBpcyBkZWxldGVkIGFmdGVyIGEgbm90aWZpY2F0aW9uLiBJ IGFncmVlIHRoYXQgaWYgdGhlIENsaWVudCBkb2VzIG5vdCBob3N0IHRoZSBsb2NhdGlvbiBhbnlt b3JlIHRoYXQgdGhlIFVSSSBhc3NvY2lhdGVkIHdpdGggdGhhdCBsb2NhdGlvbiBpbiB0aGUgU2Vy dmVyIHNob3VsZCBiZSBkZWxldGVkLiBUaGlzIGNvdWxkIGJlIGFjaGlldmVkIHdpdGggYW4gZW1w dHkgPHBsYW5uZWRDaGFuZ2U+Lg0KDQpJIGRvbuKAmXQgdGhpbmsgdGhpcyBpcyBjb3ZlcmVkIGlu IDUyMjIuICBUaGUgbWVjaGFuaXNtIGNhdXNlcyB0aGUgTG9TVCBzZXJ2ZXIgdG8gc2VuZCBub3Rp ZmljYXRpb25zIHRvIHRoZSBjbGllbnQsIGJ1dCB0aGUgY2xpZW50IGlzIGFsbG93ZWQgdG8gcHV0 IGFueSBVUkkgaW4gdGhlIHJlY29yZCwgYW5kIGl0IGNhbiBhZGQgaXQgdG8gYXMgbWFueSByZWNv cmRzIGFzIGl0IHdhbnRzLg0KW0dDXSBJIHRob3VnaHQgd2UgYWdyZWVkIG9uIHVzaW5nIG9uZSBn ZW5lcmljIFVSSSBwZXIgQ2xpZW50LiBDbGllbnRzIHNob3VsZCBiZSBhdXRoZW50aWNhdGVkIGJ5 IHRoZSBTZXJ2ZXJzLg0KIEFuIGV2aWwgaW1wbGVtZW50YXRpb24gY291bGQgcmVjb3JkIFVSSXMg YWdhaW5zdCBtdWx0aXBsZSB0YXJnZXRzIHRoYXQgd2VyZSB1bmF3YXJlIHRoYXQgdGhlIGV2aWwg aW1wbGVtZW50YXRpb24gZGlkIGl0LCB1bnRpbCB0aGV5IGdvdCBhIGxhcmdlIG51bWJlciBvZiBQ VVNIIHRyYW5zYWN0aW9ucyB0aGV5IGRpZG7igJl0IGV4cGVjdCBvciB1bmRlcnN0YW5kIGFzIGEg cmVzdWx0IG9mIGEgbGFyZ2UgcGxhbm5lZCBjaGFuZ2UuDQpbR0NdIE9ubHkgYXV0aGVudGljYXRl ZCBDbGllbnRzIHNob3VsZCBiZSBhbGxvd2VkIHRvIHByb3ZpZGUgVVJJcyB0byBiZSBzdG9yZWQg YnkgdGhlIFNlcnZlcnMuDQoNClRoZSBwcm9wb3NlZCBtZWNoYW5pc20gcXVhbGlmaWVzIHRoZSBj bGllbnQgVVJJIGJlZm9yZSBpdHMgdXNlZCBpbiBhIHBsYW5uZWQgY2hhbmdlLg0KDQpCcmlhbg0K DQoNCg0KDQpPbiBBdWcgMzEsIDIwMjEsIGF0IDc6MzcgQU0sIENhcm9uLCBHdXkgPGcuY2Fyb25A YmVsbC5jYTxtYWlsdG86Zy5jYXJvbkBiZWxsLmNhPj4gd3JvdGU6DQoNCldlbGwsIHRoaXMgaXMg bm90IGdvaW5nIGluIHRoZSBkaXJlY3Rpb24gSSB0aG91Z2h0Lg0KDQpXaGF0IGlzIHRoZSBwdXJw b3NlIG9mIGRlbGV0aW5nIHRoZSBVUklzIGF0IHRoZSBTZXJ2ZXIgcG9zdC12YWxpZGF0aW9uPw0K DQpSZWdhcmRpbmcgb3BlbmluZyBhIG5ldyBEb1MsIEkgZ3Vlc3MgSSdtIG5vdCBmb2xsb3dpbmcu IFdvdWxkbid0IHRoaXMgY2FzZSBiZSBjb3ZlcmVkIGJ5IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucyBpbiBSRkMgNTIyMj8NCg0KV2hhdCB5b3UncmUgcHJvcG9zaW5nIHB1dHMgYmFjayBzaWdu aWZpY2FudCBsb2FkIG9uIHRoZSBTZXJ2ZXJzIChhIGtleSBjb25zaWRlcmF0aW9uIGZvciBjcmVh dGluZyBwbGFubmVkLWNoYW5nZXMgaW4gdGhlIGZpcnN0IHBsYWNlKSBhbmQgY29tcGxpY2F0ZXMg dGhlIG1lY2hhbmlzbS4NCg0KR3V5DQoNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpE ZSA6IEVjcml0IDxlY3JpdC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzplY3JpdC1ib3VuY2VzQGll dGYub3JnPj4gRGUgbGEgcGFydCBkZSBCcmlhbiBSb3NlbiBFbnZvecOpIDoNCjMwIGFvw7t0IDIw MjEgMTE6MjIgw4AgOiBSYW5kYWxsIEdlbGxlbnMgPHJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmc8 bWFpbHRvOnJnK2lldGZAcmFuZHkucGVuc2l2ZS5vcmc+PiBDYw0KOiBFQ1JJVCA8ZWNyaXRAaWV0 Zi5vcmc8bWFpbHRvOmVjcml0QGlldGYub3JnPj4gT2JqZXQgOiBbRVhUXVJlOiBbRWNyaXRdIHBs YW5uZWQtY2hhbmdlczogdHdvDQpxdWVzdGlvbnMNCg0KQW5zd2VyIDE6IHllcy4gIFNpbmNlIHRo ZXJlIGlzIGdvaW5nIHRvIGJlIGEgcmV2YWxpZGF0aW9uLCBqdXN0IGRlbGV0aW5nIHRoZSBzZXR0 aW5nIHNlZW1zIHJpZ2h0IHRvIG1lLg0KQW5zd2VyIDI6IFVwIHRvIHNlcnZlci4gIElmIEkgd2Vy ZSBpbXBsZW1lbnRpbmcsIEkgd291bGQgaGFzaCB0aGUgcmVhbCBJRCB3aXRoIHRoZSBVUkkgYW5k IHNvbWUga2luZCBvZiBwcmVkaWN0YWJsZSBub25jZS4NCg0KV2UgcHJvYmFibHkgaGF2ZSB0byBz YXkgbW9yZSBhYm91dCBob3cgdGhlIHNlcnZlciBpZGVudGlmaWVzIHRoZSBjbGllbnQsIHNvIHRo YXQgcmVwbGFjZW1lbnQgb2YgdGhlIFVSSSB3b3Jrcy4gIENvdWxkIHdlIHNheSB3ZSB1c2UgdGhl IGRvbWFpbiBvZiB0aGUgVVJJICh0aGUgZW50aXJlIGRvbWFpbiB3aXRoIGFsbCB0aGUgZG90cykg dG8gaWRlbnRpZnkgdGhlIGNsaWVudCwgYW5kIGFueXRoaW5nIGNhbiBvY2N1ciBhZnRlciBpdCAo bWVhbmluZyBhIHNsYXNoIGFuZCB3aGF0ZXZlcik/ICBJZiB3ZSBkbyB0aGF0LCB0aGVuIGhvdyB3 b3VsZCBkZWxldGUgdGhlIG5vdGlmaWNhdGlvbj8gIEZvcmNlIHRoZXJlIHRvIGJlIHNvbWV0aGlu ZyBvdGhlciB0aGFuIHRoZSBkb21haW4gKHVnbHkpLiAgRXhwbGljaXQgZGVsZXRlIHJlcXVlc3Q/ DQoNCkhtbW0sIHdl4oCZdmUgb3BlbmVkIGEgRG9TIGF0dGFjazogYSByb2d1ZSBjbGllbnQgc3Rv cmVzIGEgYnVuY2ggb2YgVVJJcyBmb3Igc2VydmVycyBpdCB3YW50cyB0byB2aWN0aW1pemUuICBJ biBOb3J0aCBBbWVyaWNhIHdlIGhhdmUgYSByZWFsIHNpbXBsZSBzb2x1dGlvbiBmb3IgdGhhdCwg YmVjYXVzZSB3ZSBoYXZlIGEgUEtJLCBzbyB3ZSBrbm93LCBmb3Igc3VyZSwgd2hvIHRoZSBjbGll bnQgaXMsIGFuZCBjb3VsZCByZXN0cmljdCB3aG8gd2UgYWxsb3cgdG8gc3RvcmUgVVJJcywgYnV0 IHRoYXQgd291bGRu4oCZdCBiZSB0cnVlIGluIGdlbmVyYWwuICBBbHNvLCBpdCB3b3VsZCBiZSBu aWNlIGZvciB0aGUgY2xpZW50IHRvIGhhdmUgY29uZmlkZW5jZSB0aGUgbWVjaGFuaXNtIHdvcmtl ZCBiZWZvcmUgaXQgbmVlZGVkIGl0Lg0KDQpTbw0KTGV04oCZcyBhZGQgYSDigJxjb21tYW5k4oCd IHRvIHBsYW5uZWRDaGFuZ2UgaW4gdGhlIGZpbmRTZXJ2aWNlIHJlcXVlc3QuDQpBbmQsIGhhdmUg dGhlIGNsaWVudCBoYXZlIGEgcmVzcG9uc2UgdG8gdGhlIG5vdGlmaWNhdGlvbiB3aGljaCBpcyB0 aGUNCklEIChqc29uIHdpdGggdGhlIDIwMCkNCg0KDQpUaGUgY2xpZW50IHN0YXJ0cyBieSBzZW5k aW5nIGEgY29tbWFuZCBvZiDigJxpbml0aWFsaXpl4oCdLiAgVGhlIGRvbWFpbiBpcyB0aGUgaWRl bnRpdHkgb2YgdGhlIGNsaWVudC4gIFRoZSByZXNwb25zZSBpcyBhbiBpbW1lZGlhdGUgbm90aWZp Y2F0aW9uIHRvIHRoZSB3aXRoIHdoYXRldmVyIExJIHdhcyBpbiB0aGUgcmVxdWVzdCBhbmQgYW4g SUQuICBUaGUgIHJlc3BvbnNlIGJ5IHRoZSBjbGllbnQgKHdoaWNoIGlzIHRoZSBub3RpZmljYXRp b24gd2ViIHNlcnZlcikgaXMgYSBwaWVjZSBvZiBqc29uIGNvbnRhaW5pbmcgdGhlIElELiAgV2Ug Y2FuIHNheSB0aGF0IHRoZSBMSSBpbiB0aGlzIGluaXRpYWxpemUgY29tbWFuZCBjb3VsZCBiZSBz b21ldGhpbmcgc2ltcGxlIGxpa2UgdGhlIENvdW50cnkgQ29kZSB0aGF0IHdvdWxkbuKAmXQgZ2V0 IGEgcGxhbm5lZCBjaGFuZ2UuDQoNClRoZXJlYWZ0ZXIsIHRoZSBMb1NUIHNlcnZlciAobm90aWZp Y2F0aW9uIGNsaWVudCkgcGVyaW9kaWNhbGx5IHJlcGVhdHMgdGhpcyBrZWVwYWxpdmUgbm90aWZp Y2F0aW9uIGV2ZXJ5IGRheSBvciB3ZWVrIHdpdGggdGhlIGluaXRpYWxpemUgTEkuICBUaGUgY2xp ZW50IGhhcyB0byByZXNwb25kIHdpdGggdGhlIElELg0KDQpUaGUgcmVndWxhciBub3RpZmljYXRp b24gcmVxdWVzdCBpcyBhIGNvbW1hbmQgb2Yg4oCcbm90aWZ54oCdLiAgVGhlIHNlcnZlciBpZ25v cmVzIGEgcmVxdWVzdCBmb3Igbm90aWZpY2F0aW9uIGZyb20gYW4gdW5pbml0aWFsaXplZCBjbGll bnQuDQpUaGUgbm90aWZpY2F0aW9uIGNhbiBiZSBkZWxldGVkIHdpdGggYSBjb21tYW5kIG9mIOKA nGRlbGV0ZeKAnS4gIElmIHlvdSBkZWxldGUgdGhlIGluaXRpYWxpemUgTEksIHRoZW4gdGhlIHNl cnZlciB3b27igJl0IHNlbmQgYW55IG1vcmUgbm90aWZpY2F0aW9ucyB0byB0aGF0IGNsaWVudCBh bmQgZGVsZXRlcyBhbGwgVVJJcyBpdCB3YXMgc2F2aW5nIGZvciB0aGF0IGNsaWVudC4gIFRoZSBj bGllbnQgd291bGQgaGF2ZSB0byByZS1pbml0aWFsaXplIHRvIHJlc2V0Lg0KDQpCcmlhbg0KDQoN Cg0KDQpPbiBBdWcgMjcsIDIwMjEsIGF0IDU6NDEgUE0sIFJhbmRhbGwgR2VsbGVucyA8cmcraWV0 ZkByYW5keS5wZW5zaXZlLm9yZzxtYWlsdG86cmcraWV0ZkByYW5keS5wZW5zaXZlLm9yZz4+IHdy b3RlOg0KDQpJIHRoaW5rIHdlJ3JlIG1vdmluZyB0byBhIG1vZGVsIHdoZXJlOg0KLSBJbiBhIHF1 ZXJ5LCBhIGNsaWVudCBjYW4gcmVxdWVzdCB0byBiZSBub3RpZmllZCB3aGVuIHRoZSBsb2NhdGlv bg0Kc2hvdWxkIGJlIHJldmFsaWRhdGVkOw0KLSBJbiB0aGUgcmVzcG9uc2UsIHRoZSBzZXJ2ZXIg cHJvdmlkZXMgYW4gSUQgd2hpY2ggdGhlIGNsaWVudA0KYXNzb2NpYXRlcyB3aXRoIHRoZSBsb2Nh dGlvbiBpdCBqdXN0IHZhbGlkYXRlZDsNCi0gVGhlIHNlcnZlciBzZW5kcyBhIG5vdGlmaWNhdGlv biB0byB0aGUgVVJJLCBjb250YWluaW5nIHRoZSBJRDsNCi0gVGhlIGNsaWVudCByZXZhbGlkYXRl cyBlYWNoIGxvY2F0aW9uIHdpdGggd2hpY2ggdGhhdCBJRCBpcyBhc3NvY2lhdGVkLg0KDQpRdWVz dGlvbiAxOiBEb2VzIHRoZSBzZXJ2ZXIgZGVsZXRlL2luYWN0aXZhdGUgdGhlIFVSSSBvbmNlIGl0 IGhhcyBzZW50IHRoZSBub3RpZmljYXRpb24/DQoNClF1ZXN0aW9uIDI6IFByZXN1bWFibHksIHdo ZW4gdGhlIGNsaWVudCByZXZhbGlkYXRlcyB0aGUgbG9jYXRpb24ocyksIGl0IHdpbGwgYWdhaW4g cmVxdWVzdCBub3RpZmljYXRpb24uICBEb2VzIHRoZSBzZXJ2ZXIgcmV0dXJuIHRoZSBzYW1lIElE IGFzIGJlZm9yZSwgb3IgYSBkaWZmZXJlbnQgSUQ/ICBBIGRpZmZlcmVudCBJRCBjb3VsZCBwZXJo YXBzIGJlIHVzZWZ1bCBpbiBlZGdlIGNhc2VzIHdoZXJlIHRoZSBzZXJ2ZXIgZGlkbid0IHNlbmQg b3IgdGhlIGNsaWVudCBkaWRuJ3QgZ2V0IHRoZSBub3RpZmljYXRpb24sIGJ1dCBhbnkgdXRpbGl0 eSBzZWVtcyBzbWFsbC4gIElmIGl0J3MgdGhlIHNhbWUgSUQsIHRoZW4gdGhlIGFuc3dlciB0byBx dWVzdGlvbiAxIGNhbiBiZSB0aGF0IHRoZSBVUkkgcmVtYWlucyBhY3RpdmUgdW50aWwgdGhlIGNs aWVudCBhc2tzIHRvIG5vIGxvbmdlciBiZSBub3RpZmllZCAoYnkgc2VuZGluZyBhbiBlbXB0eSBV Ukk/KS4NCg0KLS1SYW5kYWxsDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpFY3JpdCBtYWlsaW5nIGxpc3QNCkVjcml0QGlldGYub3JnPG1haWx0bzpF Y3JpdEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNy aXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkVj cml0IG1haWxpbmcgbGlzdA0KRWNyaXRAaWV0Zi5vcmc8bWFpbHRvOkVjcml0QGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KLS0tLS0tLS0gRXh0ZXJuYWwgRW1haWw6IFBsZWFzZSB1c2UgY2F1dGlvbiB3aGVuIG9wZW5p bmcgbGlua3MgYW5kDQphdHRhY2htZW50cyAvIENvdXJyaWVsIGV4dGVybmU6IFNveWV6IHBydWRl bnQgYXZlYyBsZXMgbGllbnMgZXQNCmRvY3VtZW50cyBqb2ludHMNCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpFeHRlcm5hbCBFbWFpbDogUGxlYXNlIHVzZSBjYXV0aW9uIHdoZW4gb3BlbmluZyBs aW5rcyBhbmQgYXR0YWNobWVudHMgLyBDb3VycmllbCBleHRlcm5lOiBTb3lleiBwcnVkZW50IGF2 ZWMgbGVzIGxpZW5zIGV0IGRvY3VtZW50cyBqb2ludHMNCg0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpFeHRlcm5hbCBFbWFpbDogUGxlYXNlIHVzZSBjYXV0aW9uIHdoZW4g b3BlbmluZyBsaW5rcyBhbmQgYXR0YWNobWVudHMgLyBDb3VycmllbCBleHRlcm5lOiBTb3lleiBw cnVkZW50IGF2ZWMgbGVzIGxpZW5zIGV0IGRvY3VtZW50cyBqb2ludHMNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkV4dGVybmFsIEVtYWlsOiBQbGVhc2UgdXNlIGNhdXRpb24g d2hlbiBvcGVuaW5nIGxpbmtzIGFuZCBhdHRhY2htZW50cyAvIENvdXJyaWVsIGV4dGVybmU6IFNv eWV6IHBydWRlbnQgYXZlYyBsZXMgbGllbnMgZXQgZG9jdW1lbnRzIGpvaW50cw0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KRXh0ZXJuYWwgRW1haWw6IFBsZWFzZSB1c2UgY2F1 dGlvbiB3aGVuIG9wZW5pbmcgbGlua3MgYW5kIGF0dGFjaG1lbnRzIC8gQ291cnJpZWwgZXh0ZXJu ZTogU295ZXogcHJ1ZGVudCBhdmVjIGxlcyBsaWVucyBldCBkb2N1bWVudHMgam9pbnRzDQo= --_000_95cfe4eb9e8447ed8ba0185333a79c52bellca_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0K CXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFt ZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRlItQ0EiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+V2VsbCwg dGhpcyBub3RpZmljYXRpb24gcHJvY2VzcyBpcyBmb3IgcGxhbm5lZCBjaGFuZ2VzIGFuZCBpbiB0 aGUgbWFqb3JpdHkgb2YgY2FzZXMsIHBsYW5uZWQgY2hhbmdlcyB3aWxsIHRyaWdnZXIgbm90aWZp Y2F0aW9uDQogaW4gYWR2YW5jZSBvZiB0aGUgY2hhbmdlLiBJdCBhY3R1YWxseSBtYXkgYmUgYSBi ZW5lZml0IHRvIHRoZSBTZXJ2ZXIgdG8gc2VuZCBub3RpZmljYXRpb25zIGluIGJ1bmRsZXMsIGVz cGVjaWFsbHkgaWYgdGhlIHBsYW5uZWQgY2hhbmdlIGlzIGxhcmdlLiBUaGF0IHdheSBpdCBjb3Vs ZCBzb21ld2hhdCBjb250cm9sIHRoZSBzdXJnZSBvZiByZXZhbGlkYXRpb25zIGNvbWluZyB0byBp dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+R3V5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEJyaWFuIFJv c2VuICZsdDtickBicmlhbnJvc2VuLm5ldCZndDsNCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9i PiAzMSBhb8O7dCAyMDIxIDE3OjEyPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBDYXJvbiwgR3V5ICZs dDtnLmNhcm9uQGJlbGwuY2EmZ3Q7PGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBSYW5kYWxsIEdlbGxl bnMgJmx0O3JnJiM0MztpZXRmQHJhbmR5LnBlbnNpdmUub3JnJmd0OzsgRUNSSVQgJmx0O2Vjcml0 QGlldGYub3JnJmd0Ozxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gW0VYVF1SZTogW0Vjcml0XSBw bGFubmVkLWNoYW5nZXM6IHR3byBxdWVzdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBjb3VsZCBsaW1pdCBpdCwgYnV0IHRoYXQgd291bGQgYmUg YSBwcm9ibGVtIGlmIGl0IGxpbWl0ZWQgaXQgc3VjaCB0aGF0IGEgbGFyZ2UgcGxhbm5lZCBjaGFu Z2UgcHJvcGVybHkgcmVnaXN0ZXJlZCBjb3VsZG7igJl0IHdvcmsuICZuYnNwO0luIHNvbWUgYXJl YXMsIHRoZXkgY2hhbmdlIGh1bmRyZWRzIG9mIHRob3VzYW5kcyBvZiBhZGRyZXNzIHBvaW50cyBp biBhIGxhcmdlIGFubmV4YXRpb24uICZuYnNwO0l04oCZcyBub3QgdHlwaWNhbGx5DQogbWlsbGlv bnMsIGJ1dCB5b3UgY291bGQgaW1hZ2luZSBzb21ldGhpbmcgbGlrZSBhIGNvdW50eSB0aGF0IGR1 bXBzIGEgbmV3IFNpdGUvU3RydWN0dXJlIGxpc3Qgd2hlcmUgdGhlcmUgd2FzbuKAmXQgb25lIGJl Zm9yZSB0aGF0IHRyaWdnZXJzIHRoaXMga2luZCBvZiBub3RpZmljYXRpb24uPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IGRvZXNu4oCZdCBjaGFuZ2Ug dGhlIG5lZWQgZm9yIHN0YXJ0IGFuZCBsaW1pdCBpZiB0aGUgbGlzdCBjYW4gYmUgYmlnLiAmbmJz cDtMb3RzIG9mIHN5c3RlbXMgSSBrbm93IGhhdmUgcHJldHR5IHNldmVyZSBsaW1pdHMgb24gdGhl IHNpemUgb2YgYW4gdXBsb2FkIHJlc3BvbnNlIGZvciBpbnRlcmZhY2VzIGxpa2UgdGhpcy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG1tbSwg c3RhcnQgYW5kIGxpbWl0IGdvIHRoZSB3cm9uZyB3YXkuICZuYnNwO1RoZSBub3RpZmljYXRpb24g aXMgdGhlIFBPU1QuICZuYnNwO1N0YXJ0IGFuZCBMaW1pdCBhcmUgZm9yIGEgR0VULiAmbmJzcDtX ZSB3b3VsZCBoYXZlIHRvIGltcGxlbWVudCBhbiBlcXVpdmFsZW50IG9uIHRoZSByZWdpc3RyYXRp b24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkJyaWFuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gQXVnIDMxLCAyMDIxLCBhdCA0OjU3IFBNLCBDYXJvbiwgR3V5ICZsdDs8YSBocmVmPSJt YWlsdG86Zy5jYXJvbkBiZWxsLmNhIj5nLmNhcm9uQGJlbGwuY2E8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIHNpemUgb2YgdGhlIGxpc3QgY291bGQg YmUgYSBwb2xpY3kgYXQgdGhlIFNlcnZlci48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+R3V5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5EZSZu YnNwOzo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFu IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRlIi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+QnJpYW4NCiBSb3NlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJyQGJyaWFucm9z ZW4ubmV0Ij5ickBicmlhbnJvc2VuLm5ldDwvYT4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4zMSBhb8O7dCAyMDIx IDE2OjU1PGJyPg0KPGI+w4AmbmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj5DYXJvbiwgR3V5ICZsdDs8YSBocmVmPSJtYWlsdG86Zy5jYXJv bkBiZWxsLmNhIj5nLmNhcm9uQGJlbGwuY2E8L2E+Jmd0Ozxicj4NCjxiPkNjJm5ic3A7OjwvYj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmFuZGFsbCBH ZWxsZW5zICZsdDs8YSBocmVmPSJtYWlsdG86cmcmIzQzO2lldGZAcmFuZHkucGVuc2l2ZS5vcmci PnJnJiM0MztpZXRmQHJhbmR5LnBlbnNpdmUub3JnPC9hPiZndDs7IEVDUklUICZsdDs8YSBocmVm PSJtYWlsdG86ZWNyaXRAaWV0Zi5vcmciPmVjcml0QGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5P YmpldCZuYnNwOzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPltFWFRdUmU6IFtFY3JpdF0gcGxhbm5lZC1jaGFuZ2VzOiB0d28gcXVlc3Rpb25zPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SWYgd2UgZGlkIHRoYXQsIHdlIHdvdWxkIGhhdmUgdG8gaW1wbGVt ZW50IGxpbWl0IGFuZCBzdGFydCB0byBoYW5kbGUgYSBsYXJnZSBsaXN0LiAmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkJyaWFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIEF1ZyAzMSwgMjAyMSwgYXQgNDozOCBQTSwgQ2Fyb24sIEd1eSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmcuY2Fyb25AYmVsbC5jYSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+Zy5jYXJv bkBiZWxsLmNhPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JZiB3ZSBtYWtlICZsdDtyZXZh bGlkYXRlTG9jYXRpb24mZ3Q7IGEgbGlzdCBvZiBJRHMsIG9uZSBub3RpZmljYXRpb24gcGVyIFVS SSBwZXIgcGxhbm5lZCBjaGFuZ2Ugd291bGQgYmUgc3VmZmljaWVudC48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ R3V5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bh bj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QnJpYW4NCiBSb3NlbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5ickBicmlhbnJvc2VuLm5ldDwvc3Bhbj48L2E+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+MzEgYW/Du3Qg MjAyMSAxNTozNTxicj4NCjxiPsOAJm5ic3A7OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmFuZGFsbCBHZWxsZW5zICZsdDs8YSBocmVmPSJtYWls dG86cmcmIzQzO2lldGZAcmFuZHkucGVuc2l2ZS5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPnJnJiM0MztpZXRmQHJhbmR5LnBlbnNpdmUub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+ Q2MmbmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj5DYXJvbiwgR3V5ICZsdDs8YSBocmVmPSJtYWlsdG86Zy5jYXJvbkBiZWxsLmNhIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5nLmNhcm9uQGJlbGwuY2E8L3NwYW4+PC9hPiZndDs7IEVD UklUICZsdDs8YSBocmVmPSJtYWlsdG86ZWNyaXRAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPmVjcml0QGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+T2JqZXQmbmJz cDs6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5b RVhUXVJlOiBbRWNyaXRdIHBsYW5uZWQtY2hhbmdlczogdHdvIHF1ZXN0aW9uczwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPk5vLiAmbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5UaGVyZSBpcyBvbmUgVVJJLCBidXQgbWFueSBJRHMs IG9uZSBwZXIgdW5pcXVlIHJlY29yZCBhdCB0aGUgTG9TVCBzZXJ2ZXIgdGhhdCBpcyBpbnZvbHZl ZCBpbiBhIHBsYW5uZWQgY2hhbmdlLiAmbmJzcDtUaGUgb25lIFVSSSB3aWxsIHJlY2VpdmUgb25l IG5vdGlmaWNhdGlvbiBwZXIgSUQgaXQgaGFzIHJlZ2lzdGVyZWQgZm9yLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+T24gQXVnIDMxLCAy MDIxLCBhdCAyOjU2IFBNLCBSYW5kYWxsIEdlbGxlbnMgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWls dG86cmcmIzQzO2lldGZAcmFuZHkucGVuc2l2ZS5vcmciPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iY29sb3I6cHVycGxlIj5yZyYjNDM7aWV0ZkByYW5keS5wZW5zaXZlLm9yZzwvc3Bhbj48L2E+ PHNwYW4gbGFuZz0iRU4tQ0EiPiZndDsgd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+aSB1bmRlcnN0YW5kIHRoYXQgdGhlIGNvbmNlcm4gaXMg YWxsb3dpbmcgYSBjbGllbnQgdG8gbGV2ZXJhZ2UgdGhlIExvU1Qgc2VydmVyIHRvIGF0dGFjayBh IGxhcmdlIG51bWJlciBvZiB0YXJnZXRzLCBJJ20ganVzdCBub3QgY2xlYXIgbWVjaGFuaWNhbGx5 IGhvdyBzdWNoIGxldmVyYWdlIHBvdGVudGlhbGx5DQogd29ya3MuIEVhY2ggdmFsaWRhdGlvbiBx dWVyeSBjYW4gc3RvcmUgYSBVUkksIGFuZCB0aGF0IFVSSSBtYXkgZ2V0IGFzc29jaWF0ZWQgd2l0 aCBhIGxhcmdlIG51bWJlciBvZiBsb2NhdGlvbnMuIE1heWJlIHRoZXJlJ3MgYSBzdHJlZXQgbmFt ZSBjaGFuZ2Ugb3IgYW4gYW5uZXhhdGlvbi4gU28gbWF5YmUgdGhvdXNhbmRzIG9yIHRlbnMgb3Ig aHVuZHJlZHMgb2YgdGhvdXNhbmRzIG9mIGxvY2F0aW9ucyBhcmUgcG90ZW50aWFsbHkgaW52YWxp ZGF0ZWQuDQogVGhleSBhbGwgaGF2ZSB0aGUgc2FtZSBVUkkgYXNzb2NpYXRlZCB3aXRoIHRoZW0s IHNvIHRoZSBMb1NUIHNlcnZlciBjb25uZWN0cyB0byB0aGUgVVJJIG9uY2UgYW5kIFBPU1RzIG9u ZSBub3RpZmljYXRpb24sIG5vPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+LS1SYW5kYWxs PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5PbiAzMSBBdWcgMjAyMSwgYXQgMTA6NTMsIEJy aWFuIFJvc2VuIHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Nzc3Nzc3IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQ7bWFyZ2luLWxlZnQ6MGNtO21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjMuNzVwdCI+DQo8 ZGl2IGlkPSIyRjQyNzQyQy00RjU1LTRFMjktOEJCNy0wMDgyOTY4NjZBNTEiPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3Nzci Pk9mIGNvdXJzZSBhbiBhdHRhY2tlciB3b3VsZCBjb25jZWFsIGl0c2VsZiBhbmQgcmVnaXN0ZXIg bXVsdGlwbGUgVVJJcyB1bmRlciBkaWZmZXJlbnQgaWRlbnRpdGllcy4gJm5ic3A7QnV0IHRoZSBi aWdnZXIgJm5ic3A7cHJvYmxlbSBpcyB0aGF0IGlmIGEgbGFyZ2UgcGxhbm5lZCBjaGFuZ2Ugb2Nj dXJyZWQsDQogdGhlIHZpY3RpbSBjb3VsZCByZWNlaXZlIGEgbGFyZ2UgbnVtYmVyIG9mIG5vdGlm aWNhdGlvbnMgaXQgZGlkbuKAmXQgZXhwZWN0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6Izc3Nzc3NyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPldpdGggYSB0ZXN0IHRyYW5zaXRpb24sIHdlIGtu b3cgdGhhdCB0aGUgY2xpZW50IGV4cGVjdHMgdG8gc2VlIG5vdGlmaWNhdGlvbnMsIHdlIG9ubHkg bmVlZCBvbmUgcGVyIFVSSSAod2UgY291bGQgc3BlY2lmeSBvbmUgcGVyIGRvbWFpbiDigJQgYWZ0 ZXIgdGhlIHNjaGVtZSBhbmQgYmVmb3JlDQogdGhlIGZpcnN0IHNsYXNoKS4gJm5ic3A7SWYgd2Ug ZG9u4oCZdCBnZXQgdGhlIElELCB3ZSBrbm93IG5vdCB0byBhbGxvdyB0aGF0IFVSSSB0byBiZSBw cm92aXNpb25lZC4gJm5ic3A7U28gaXTigJlzIG9uZSB0ZXN0IHRyYW5zYWN0aW9uIHZzIGEgbGFy Z2UgbnVtYmVyIG9mIHBsYW5uZWQgY2hhbmdlIHRyYW5zYWN0aW9ucy48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPkJyaWFuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+PGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM3Nzc3NzciPk9uIEF1ZyAzMSwgMjAyMSwgYXQgMTozNSBQTSwgUmFuZGFsbCBHZWxs ZW5zICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnJnJiM0MztpZXRmQHJhbmR5LnBlbnNpdmUu b3JnIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj5yZyYjNDM7aWV0ZkByYW5keS5wZW5zaXZlLm9y Zzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPiZndDsNCiB3cm90ZTo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3 Nzc3NzciPklmIGEgbWFsaWNpb3VzIGNsaWVudCByZWdpc3RlcnMgYSBVUkkgdGhhdCBpcyBkZXNp Z25lZCB0byBhdHRhY2sgYSB0aGlyZCBzaXRlLCB0aGUgdGVzdCB0cmFuc2FjdGlvbiBjYXVzZXMg dGhlIExvU1Qgc2VydmVyIHRvIGNvbm5lY3QgdG8gaXQgYW5kIFBPU1QgYSBjb21tYW5kLiBXaXRo b3V0DQogYSB0ZXN0IHRyYW5zYWN0aW9uLCB0aGUgTG9TVCBzZXJ2ZXIgc3RvcmVzIHRoZSBVUkkg YW5kIGF0IGEgZnV0dXJlIHRpbWUgY29ubmVjdHMgdG8gaXQgYW5kIHNlbmRzIGEgY29tbWFuZC4g RWl0aGVyIHdheSwgYSBMb1NUIGNsaWVudCBjYW4gcmVnaXN0ZXIgcG90ZW50aWFsbHkgb25lIFVS SSBwZXIgcXVlcmllZCBsb2NhdGlvbiwgYW5kIGEgTG9TVCBzZXJ2ZXIgd2lsbCBjb25uZWN0IHRv IHRoYXQgVVJJIGFuZCBQT1NUIGEgbWVzc2FnZS4gQSBxdWVyaWVkDQogbG9jYXRpb24gY291bGQg YmUgdGllZCB0byBtYW55IG90aGVyIGxvY2F0aW9ucywgc28gdGhlcmUgY291bGQgYmUgbWFueSBs b2NhdGlvbnMgZm9yIHdoaWNoIGEgY2hhbmdlIHdvdWxkIHRyaWdnZXIgdGhlIExvU1Qgc2VydmVy IHRvIHVzZSB0aGUgVVJJLCBidXQgaXMgdGhhdCB3b3JzZT88L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6Izc3Nzc3NyI+LS1SYW5kYWxsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM3Nzc3NzciPk9uIDMxIEF1ZyAyMDIxLCBhdCAxMDoyNywgQnJpYW4gUm9zZW4gd3Jv dGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICM3Nzc3NzcgMS41cHQ7 cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdDttYXJnaW4tbGVmdDowY207bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206My43NXB0Ij4NCjxkaXYgaWQ9Ijg1MTY3 ODgyLTQ3MDctNERBNy1BRjA0LUQ3NkVERkEzRUMxRiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+SWYgdGhlIHdvcmsg Z3JvdXAgd2FudHMgdG8gaGF2ZSB0aGUgTG9TVCBzZXJ2ZXIga2VlcCB0aGUgVVJJIHVudGlsIGV4 cHJlc3NseSBkZWxldGVkLCB0aGF04oCZcyBva2F5IHdpdGggbWUuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+QXV0aGVudGljYXRpbmcgdGhl IGNsaWVudCB0byB0aGUgc2VydmVyIGRvZXNu4oCZdCBtZWFuIHRoZSBVUkkgaXMgYXV0aGVudGlj YXRlZC4gJm5ic3A7V2UgY2Fu4oCZdCByZXN0cmljdCB0aGUgVVJJIHRvIGJlIHRoZSBzYW1lIGVu dGl0eSBhcyB0aGUgY2xpZW50IHJ1bm5pbmcgdGhlIExvU1QgdHJhbnNhY3Rpb24uDQogJm5ic3A7 QW5kIHRoZSBjbGllbnRzIGFyZSB3aWRlIHJhbmdpbmcuICZuYnNwO0NvdWxkIGJlIGFuIGVudGVy cHJpc2UgcnVubmluZyBpdHMgb3duIExJUyBmb3IgZXhhbXBsZS4gJm5ic3A7V2UgY2Fu4oCZdCBh c3N1bWUgdGhlIE5vcnRoIEFtZXJpY2FuIFBLSSBpcyB3b3JrYWJsZSBldmVyeXdoZXJlLCBhbmQg ZXZlbiB0aGF0IGRvZXNu4oCZdCBleHRlbmQgdG8gYW4gZW50ZXJwcmlzZSBMSVMuICZuYnNwO0lT VE0gd2UgaGF2ZSB0byBydW4gYSB0ZXN0IHRyYW5zYWN0aW9uIHdpdGggdGhlDQogbm90aWZpY2F0 aW9uIHNlcnZpY2UgdG8gbWFrZSBzdXJlIGl04oCZcyB3aGF0IHdlIHRoaW5rIGl0IGlzLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3 NyI+QnJpYW48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 Izc3Nzc3NyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM3Nzc3NzciPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPk9uIEF1ZyAz MSwgMjAyMSwgYXQgOTowMSBBTSwgQ2Fyb24sIEd1eSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzpnLmNhcm9uQGJlbGwuY2EiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGUiPmcuY2Fyb25AYmVsbC5j YTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPiZndDsNCiB3cm90ZTo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3 Nzc3NyI+SW5saW5lLjxicj4NCjxicj4NCkd1eTxicj4NCjxicj4NCi0tLS0tTWVzc2FnZSBkJ29y aWdpbmUtLS0tLTxicj4NCkRlJm5ic3A7OiBCcmlhbiBSb3NlbiAmbHQ7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpickBicmlhbnJvc2VuLm5ldCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6cHVycGxlIj5ickBicmlhbnJvc2VuLm5ldDwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQpFbnZvecOpJm5ic3A7OiAzMSBhb8O7dCAy MDIxIDA4OjExPGJyPg0Kw4AmbmJzcDs6IENhcm9uLCBHdXkgJmx0Ozwvc3Bhbj48YSBocmVmPSJt YWlsdG86Zy5jYXJvbkBiZWxsLmNhIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpwdXJwbGUiPmcuY2Fyb25AYmVsbC5jYTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+Jmd0Ozxicj4NCkNjJm5ic3A7OiBSYW5kYWxsIEdlbGxl bnMgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cmcmIzQzO2lldGZAcmFuZHkucGVuc2l2ZS5v cmciPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZSI+cmcmIzQzO2ll dGZAcmFuZHkucGVuc2l2ZS5vcmc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM3Nzc3NzciPiZndDs7DQogRUNSSVQgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWls dG86ZWNyaXRAaWV0Zi5vcmciPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1 cnBsZSI+ZWNyaXRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM3Nzc3NzciPiZndDs8YnI+DQpPYmpldCZuYnNwOzogW0VYVF1SZTogW0Vjcml0 XSBwbGFubmVkLWNoYW5nZXM6IHR3byBxdWVzdGlvbnM8YnI+DQo8YnI+DQpZb3UgZGVsZXRlIHRo ZSBVUkkgd2hlbiB5b3UgZGVsZXRlIHRoZSByZWNvcmQgaW4gdGhlIExJUy48YnI+DQpbR0NdIFRo YXQncyBmaW5lIGJ1dCB0aGF0IHdhcyBub3QgdGhlIHF1ZXN0aW9uIFJhbmRhbGwgcG9zZWQuIEhl IGFza2VkIHdoZXRoZXIgdGhlIFVSSSBpcyBkZWxldGVkIGFmdGVyIGEgbm90aWZpY2F0aW9uLiBJ IGFncmVlIHRoYXQgaWYgdGhlIENsaWVudCBkb2VzIG5vdCBob3N0IHRoZSBsb2NhdGlvbiBhbnlt b3JlIHRoYXQgdGhlIFVSSSBhc3NvY2lhdGVkIHdpdGggdGhhdCBsb2NhdGlvbiBpbiB0aGUgU2Vy dmVyIHNob3VsZCBiZSBkZWxldGVkLg0KIFRoaXMgY291bGQgYmUgYWNoaWV2ZWQgd2l0aCBhbiBl bXB0eSAmbHQ7cGxhbm5lZENoYW5nZSZndDsuPGJyPg0KPGJyPg0KSSBkb27igJl0IHRoaW5rIHRo aXMgaXMgY292ZXJlZCBpbiA1MjIyLiAmbmJzcDtUaGUgbWVjaGFuaXNtIGNhdXNlcyB0aGUgTG9T VCBzZXJ2ZXIgdG8gc2VuZCBub3RpZmljYXRpb25zIHRvIHRoZSBjbGllbnQsIGJ1dCB0aGUgY2xp ZW50IGlzIGFsbG93ZWQgdG8gcHV0IGFueSBVUkkgaW4gdGhlIHJlY29yZCwgYW5kIGl0IGNhbiBh ZGQgaXQgdG8gYXMgbWFueSByZWNvcmRzIGFzIGl0IHdhbnRzLjxicj4NCltHQ10gSSB0aG91Z2h0 IHdlIGFncmVlZCBvbiB1c2luZyBvbmUgZ2VuZXJpYyBVUkkgcGVyIENsaWVudC4gQ2xpZW50cyBz aG91bGQgYmUgYXV0aGVudGljYXRlZCBieSB0aGUgU2VydmVycy48YnI+DQombmJzcDtBbiBldmls IGltcGxlbWVudGF0aW9uIGNvdWxkIHJlY29yZCBVUklzIGFnYWluc3QgbXVsdGlwbGUgdGFyZ2V0 cyB0aGF0IHdlcmUgdW5hd2FyZSB0aGF0IHRoZSBldmlsIGltcGxlbWVudGF0aW9uIGRpZCBpdCwg dW50aWwgdGhleSBnb3QgYSBsYXJnZSBudW1iZXIgb2YgUFVTSCB0cmFuc2FjdGlvbnMgdGhleSBk aWRu4oCZdCBleHBlY3Qgb3IgdW5kZXJzdGFuZCBhcyBhIHJlc3VsdCBvZiBhIGxhcmdlIHBsYW5u ZWQgY2hhbmdlLjxicj4NCltHQ10gT25seSBhdXRoZW50aWNhdGVkIENsaWVudHMgc2hvdWxkIGJl IGFsbG93ZWQgdG8gcHJvdmlkZSBVUklzIHRvIGJlIHN0b3JlZCBieSB0aGUgU2VydmVycy48YnI+ DQo8YnI+DQpUaGUgcHJvcG9zZWQgbWVjaGFuaXNtIHF1YWxpZmllcyB0aGUgY2xpZW50IFVSSSBi ZWZvcmUgaXRzIHVzZWQgaW4gYSBwbGFubmVkIGNoYW5nZS48YnI+DQo8YnI+DQpCcmlhbjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+T24gQXVnIDMxLCAyMDIxLCBhdCA3OjM3 IEFNLCBDYXJvbiwgR3V5ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmcuY2Fyb25AYmVsbC5j YSI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj5nLmNhcm9uQGJl bGwuY2E8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3 NzciPiZndDsNCiB3cm90ZTo8YnI+DQo8YnI+DQpXZWxsLCB0aGlzIGlzIG5vdCBnb2luZyBpbiB0 aGUgZGlyZWN0aW9uIEkgdGhvdWdodC48YnI+DQo8YnI+DQpXaGF0IGlzIHRoZSBwdXJwb3NlIG9m IGRlbGV0aW5nIHRoZSBVUklzIGF0IHRoZSBTZXJ2ZXIgcG9zdC12YWxpZGF0aW9uPzxicj4NCjxi cj4NClJlZ2FyZGluZyBvcGVuaW5nIGEgbmV3IERvUywgSSBndWVzcyBJJ20gbm90IGZvbGxvd2lu Zy4gV291bGRuJ3QgdGhpcyBjYXNlIGJlIGNvdmVyZWQgYnkgdGhlIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zIGluIFJGQyA1MjIyPzxicj4NCjxicj4NCldoYXQgeW91J3JlIHByb3Bvc2luZyBwdXRz IGJhY2sgc2lnbmlmaWNhbnQgbG9hZCBvbiB0aGUgU2VydmVycyAoYSBrZXkgY29uc2lkZXJhdGlv biBmb3IgY3JlYXRpbmcgcGxhbm5lZC1jaGFuZ2VzIGluIHRoZSBmaXJzdCBwbGFjZSkgYW5kIGNv bXBsaWNhdGVzIHRoZSBtZWNoYW5pc20uPGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6Izc3Nzc3NyI+R3V5PGJyPg0KPGJyPg0KPGJyPg0KLS0tLS1NZXNzYWdlIGQnb3Jp Z2luZS0tLS0tPGJyPg0KRGUgOiBFY3JpdCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzplY3Jp dC1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZSI+ZWNyaXQt Ym91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3 Ij4mZ3Q7IERlIGxhDQogcGFydCBkZSBCcmlhbiBSb3NlbiBFbnZvecOpIDo8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KMzAgYW/Du3QgMjAyMSAx MToyMiDDgCA6IFJhbmRhbGwgR2VsbGVucyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpyZyYj NDM7aWV0ZkByYW5keS5wZW5zaXZlLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGUi PnJnJiM0MztpZXRmQHJhbmR5LnBlbnNpdmUub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM3Nzc3NzciPiZndDsNCiBDYzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo6IEVDUklUICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRv OmVjcml0QGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZSI+ZWNyaXRAaWV0 Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+Jmd0OyBPYmpl dCA6IFtFWFRdUmU6IFtFY3JpdF0NCiBwbGFubmVkLWNoYW5nZXM6IHR3bzxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQpxdWVzdGlvbnM8YnI+DQo8 YnI+DQpBbnN3ZXIgMTogeWVzLiAmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6Izc3Nzc3NyI+U2luY2UgdGhlcmUgaXMgZ29pbmcgdG8gYmUgYSByZXZhbGlk YXRpb24sIGp1c3QgZGVsZXRpbmcgdGhlIHNldHRpbmcgc2VlbXMgcmlnaHQgdG8gbWUuPGJyPg0K QW5zd2VyIDI6IFVwIHRvIHNlcnZlci4gJm5ic3A7SWYgSSB3ZXJlIGltcGxlbWVudGluZywgSSB3 b3VsZCBoYXNoIHRoZSByZWFsIElEIHdpdGggdGhlIFVSSSBhbmQgc29tZSBraW5kIG9mIHByZWRp Y3RhYmxlIG5vbmNlLiAmbmJzcDs8YnI+DQo8YnI+DQpXZSBwcm9iYWJseSBoYXZlIHRvIHNheSBt b3JlIGFib3V0IGhvdyB0aGUgc2VydmVyIGlkZW50aWZpZXMgdGhlIGNsaWVudCwgc28gdGhhdCBy ZXBsYWNlbWVudCBvZiB0aGUgVVJJIHdvcmtzLiAmbmJzcDtDb3VsZCB3ZSBzYXkgd2UgdXNlIHRo ZSBkb21haW4gb2YgdGhlIFVSSSAodGhlIGVudGlyZSBkb21haW4gd2l0aCBhbGwgdGhlIGRvdHMp IHRvIGlkZW50aWZ5IHRoZSBjbGllbnQsIGFuZCBhbnl0aGluZyBjYW4gb2NjdXIgYWZ0ZXIgaXQg KG1lYW5pbmcNCiBhIHNsYXNoIGFuZCB3aGF0ZXZlcik/ICZuYnNwO0lmIHdlIGRvIHRoYXQsIHRo ZW4gaG93IHdvdWxkIGRlbGV0ZSB0aGUgbm90aWZpY2F0aW9uPyAmbmJzcDtGb3JjZSB0aGVyZSB0 byBiZSBzb21ldGhpbmcgb3RoZXIgdGhhbiB0aGUgZG9tYWluICh1Z2x5KS4gJm5ic3A7RXhwbGlj aXQgZGVsZXRlIHJlcXVlc3Q/PGJyPg0KPGJyPg0KSG1tbSwgd2XigJl2ZSBvcGVuZWQgYSBEb1Mg YXR0YWNrOiBhIHJvZ3VlIGNsaWVudCBzdG9yZXMgYSBidW5jaCBvZiBVUklzIGZvciBzZXJ2ZXJz IGl0IHdhbnRzIHRvIHZpY3RpbWl6ZS4gJm5ic3A7SW4gTm9ydGggQW1lcmljYSB3ZSBoYXZlIGEg cmVhbCBzaW1wbGUgc29sdXRpb24gZm9yIHRoYXQsIGJlY2F1c2Ugd2UgaGF2ZSBhIFBLSSwgc28g d2Uga25vdywgZm9yIHN1cmUsIHdobyB0aGUgY2xpZW50IGlzLCBhbmQgY291bGQgcmVzdHJpY3Qg d2hvIHdlIGFsbG93DQogdG8gc3RvcmUgVVJJcywgYnV0IHRoYXQgd291bGRu4oCZdCBiZSB0cnVl IGluIGdlbmVyYWwuICZuYnNwO0Fsc28sIGl0IHdvdWxkIGJlIG5pY2UgZm9yIHRoZSBjbGllbnQg dG8gaGF2ZSBjb25maWRlbmNlIHRoZSBtZWNoYW5pc20gd29ya2VkIGJlZm9yZSBpdCBuZWVkZWQg aXQuPGJyPg0KPGJyPg0KU288YnI+DQpMZXTigJlzIGFkZCBhIOKAnGNvbW1hbmTigJ0gdG8gcGxh bm5lZENoYW5nZSBpbiB0aGUgZmluZFNlcnZpY2UgcmVxdWVzdC4gJm5ic3A7PGJyPg0KQW5kLCBo YXZlIHRoZSBjbGllbnQgaGF2ZSBhIHJlc3BvbnNlIHRvIHRoZSBub3RpZmljYXRpb24gd2hpY2gg aXMgdGhlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxi cj4NCklEIChqc29uIHdpdGggdGhlIDIwMCk8YnI+DQo8YnI+DQo8YnI+DQpUaGUgY2xpZW50IHN0 YXJ0cyBieSBzZW5kaW5nIGEgY29tbWFuZCBvZiDigJxpbml0aWFsaXpl4oCdLiAmbmJzcDtUaGUg ZG9tYWluIGlzIHRoZSBpZGVudGl0eSBvZiB0aGUgY2xpZW50LiAmbmJzcDtUaGUgcmVzcG9uc2Ug aXMgYW4gaW1tZWRpYXRlIG5vdGlmaWNhdGlvbiB0byB0aGUgd2l0aCB3aGF0ZXZlciBMSSB3YXMg aW4gdGhlIHJlcXVlc3QgYW5kIGFuIElELiAmbmJzcDtUaGUgJm5ic3A7cmVzcG9uc2UgYnkgdGhl IGNsaWVudCAod2hpY2ggaXMgdGhlIG5vdGlmaWNhdGlvbiB3ZWIgc2VydmVyKQ0KIGlzIGEgcGll Y2Ugb2YganNvbiBjb250YWluaW5nIHRoZSBJRC4gJm5ic3A7V2UgY2FuIHNheSB0aGF0IHRoZSBM SSBpbiB0aGlzIGluaXRpYWxpemUgY29tbWFuZCBjb3VsZCBiZSBzb21ldGhpbmcgc2ltcGxlIGxp a2UgdGhlIENvdW50cnkgQ29kZSB0aGF0IHdvdWxkbuKAmXQgZ2V0IGEgcGxhbm5lZCBjaGFuZ2Uu PGJyPg0KPGJyPg0KVGhlcmVhZnRlciwgdGhlIExvU1Qgc2VydmVyIChub3RpZmljYXRpb24gY2xp ZW50KSBwZXJpb2RpY2FsbHkgcmVwZWF0cyB0aGlzIGtlZXBhbGl2ZSBub3RpZmljYXRpb24gZXZl cnkgZGF5IG9yIHdlZWsgd2l0aCB0aGUgaW5pdGlhbGl6ZSBMSS4gJm5ic3A7VGhlIGNsaWVudCBo YXMgdG8gcmVzcG9uZCB3aXRoIHRoZSBJRC48YnI+DQo8YnI+DQpUaGUgcmVndWxhciBub3RpZmlj YXRpb24gcmVxdWVzdCBpcyBhIGNvbW1hbmQgb2Yg4oCcbm90aWZ54oCdLiAmbmJzcDtUaGUgc2Vy dmVyIGlnbm9yZXMgYSByZXF1ZXN0IGZvciBub3RpZmljYXRpb24gZnJvbSBhbiB1bmluaXRpYWxp emVkIGNsaWVudC48YnI+DQpUaGUgbm90aWZpY2F0aW9uIGNhbiBiZSBkZWxldGVkIHdpdGggYSBj b21tYW5kIG9mIOKAnGRlbGV0ZeKAnS4gJm5ic3A7SWYgeW91IGRlbGV0ZSB0aGUgaW5pdGlhbGl6 ZSBMSSwgdGhlbiB0aGUgc2VydmVyIHdvbuKAmXQgc2VuZCBhbnkgbW9yZSBub3RpZmljYXRpb25z IHRvIHRoYXQgY2xpZW50IGFuZCBkZWxldGVzIGFsbCBVUklzIGl0IHdhcyBzYXZpbmcgZm9yIHRo YXQgY2xpZW50LiAmbmJzcDtUaGUgY2xpZW50IHdvdWxkIGhhdmUgdG8gcmUtaW5pdGlhbGl6ZSB0 byByZXNldC48YnI+DQo8YnI+DQpCcmlhbjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3 Nzc3NyI+T24gQXVnIDI3LCAyMDIxLCBhdCA1OjQxIFBNLCBSYW5kYWxsIEdlbGxlbnMgJmx0Ozwv c3Bhbj48YSBocmVmPSJtYWlsdG86cmcmIzQzO2lldGZAcmFuZHkucGVuc2l2ZS5vcmciPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZSI+cmcmIzQzO2lldGZAcmFuZHku cGVuc2l2ZS5vcmc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM3Nzc3NzciPiZndDsNCiB3cm90ZTo8YnI+DQo8YnI+DQpJIHRoaW5rIHdlJ3JlIG1vdmluZyB0 byBhIG1vZGVsIHdoZXJlOjxicj4NCi0gSW4gYSBxdWVyeSwgYSBjbGllbnQgY2FuIHJlcXVlc3Qg dG8gYmUgbm90aWZpZWQgd2hlbiB0aGUgbG9jYXRpb248c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0Kc2hvdWxkIGJlIHJldmFsaWRhdGVkOzxicj4N Ci0gSW4gdGhlIHJlc3BvbnNlLCB0aGUgc2VydmVyIHByb3ZpZGVzIGFuIElEIHdoaWNoIHRoZSBj bGllbnQ8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJy Pg0KYXNzb2NpYXRlcyB3aXRoIHRoZSBsb2NhdGlvbiBpdCBqdXN0IHZhbGlkYXRlZDs8YnI+DQot IFRoZSBzZXJ2ZXIgc2VuZHMgYSBub3RpZmljYXRpb24gdG8gdGhlIFVSSSwgY29udGFpbmluZyB0 aGUgSUQ7PGJyPg0KLSBUaGUgY2xpZW50IHJldmFsaWRhdGVzIGVhY2ggbG9jYXRpb24gd2l0aCB3 aGljaCB0aGF0IElEIGlzIGFzc29jaWF0ZWQuPGJyPg0KPGJyPg0KUXVlc3Rpb24gMTogRG9lcyB0 aGUgc2VydmVyIGRlbGV0ZS9pbmFjdGl2YXRlIHRoZSBVUkkgb25jZSBpdCBoYXMgc2VudCB0aGUg bm90aWZpY2F0aW9uPzxicj4NCjxicj4NClF1ZXN0aW9uIDI6IFByZXN1bWFibHksIHdoZW4gdGhl IGNsaWVudCByZXZhbGlkYXRlcyB0aGUgbG9jYXRpb24ocyksIGl0IHdpbGwgYWdhaW4gcmVxdWVz dCBub3RpZmljYXRpb24uICZuYnNwO0RvZXMgdGhlIHNlcnZlciByZXR1cm4gdGhlIHNhbWUgSUQg YXMgYmVmb3JlLCBvciBhIGRpZmZlcmVudCBJRD8gJm5ic3A7QSBkaWZmZXJlbnQgSUQgY291bGQg cGVyaGFwcyBiZSB1c2VmdWwgaW4gZWRnZSBjYXNlcyB3aGVyZSB0aGUgc2VydmVyIGRpZG4ndCBz ZW5kIG9yDQogdGhlIGNsaWVudCBkaWRuJ3QgZ2V0IHRoZSBub3RpZmljYXRpb24sIGJ1dCBhbnkg dXRpbGl0eSBzZWVtcyBzbWFsbC4gJm5ic3A7SWYgaXQncyB0aGUgc2FtZSBJRCwgdGhlbiB0aGUg YW5zd2VyIHRvIHF1ZXN0aW9uIDEgY2FuIGJlIHRoYXQgdGhlIFVSSSByZW1haW5zIGFjdGl2ZSB1 bnRpbCB0aGUgY2xpZW50IGFza3MgdG8gbm8gbG9uZ2VyIGJlIG5vdGlmaWVkIChieSBzZW5kaW5n IGFuIGVtcHR5IFVSST8pLjxicj4NCjxicj4NCi0tUmFuZGFsbDxicj4NCjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KRWNyaXQgbWFpbGlu ZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpFY3JpdEBpZXRmLm9yZyI+PHNwYW4g bGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cHVycGxlIj5FY3JpdEBpZXRmLm9yZzwvc3Bh bj48L2E+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+PGJyPg0K PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNy aXQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZSI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdDwvc3Bhbj48L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3 Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCkVjcml0IG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86RWNyaXRA aWV0Zi5vcmciPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZSI+RWNy aXRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM3Nzc3NzciPjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2Vjcml0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpw dXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQ8L3NwYW4+ PC9hPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPjxicj4NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08YnI+DQotLS0tLS0tLSBFeHRlcm5hbCBFbWFpbDogUGxlYXNlIHVzZSBjYXV0 aW9uIHdoZW4gb3BlbmluZyBsaW5rcyBhbmQ8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KYXR0YWNobWVudHMgLyBDb3VycmllbCBleHRlcm5lOiBT b3lleiBwcnVkZW50IGF2ZWMgbGVzIGxpZW5zIGV0PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCmRvY3VtZW50cyBqb2ludHM8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj Nzc3Nzc3Ij48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3Ij4tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08YnI+DQpFeHRlcm5hbCBFbWFpbDogUGxlYXNlIHVzZSBjYXV0aW9u IHdoZW4gb3BlbmluZyBsaW5rcyBhbmQgYXR0YWNobWVudHMgLyBDb3VycmllbCBleHRlcm5lOiBT b3lleiBwcnVkZW50IGF2ZWMgbGVzIGxpZW5zIGV0IGRvY3VtZW50cyBqb2ludHM8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izc3Nzc3NyI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzc3Nzc3 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhy IHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Ryb25nPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Y29sb3I6Ymx1ZSI+RXh0ZXJuYWwgRW1haWw6PC9zcGFuPjwvaT48L3N0cm9uZz48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48aT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48L2k+PC9zcGFuPjxlbT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPlBsZWFzZQ0KIHVzZSBjYXV0aW9uIHdo ZW4gb3BlbmluZyBsaW5rcyBhbmQgYXR0YWNobWVudHMgLzwvc3Bhbj48L2VtPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjwvaT48L3NwYW4+PHN0cm9uZz48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPkNvdXJyaWVsIGV4dGVybmU6PC9zcGFuPjwv aT48L3N0cm9uZz48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48L2k+PC9zcGFu PjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPlNveWV6DQogcHJ1 ZGVudCBhdmVjIGxlcyBsaWVucyBldCBkb2N1bWVudHMgam9pbnRzPC9zcGFuPjwvZW0+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0 ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50 ZXIiPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHN0cm9uZz48aT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPkV4dGVybmFsIEVtYWlsOjwvc3Bh bj48L2k+PC9zdHJvbmc+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PC9pPjwv c3Bhbj48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj5QbGVhc2UN CiB1c2UgY2F1dGlvbiB3aGVuIG9wZW5pbmcgbGlua3MgYW5kIGF0dGFjaG1lbnRzIC88L3NwYW4+ PC9lbT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48aT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48L2k+PC9zcGFuPjxzdHJv bmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj5Db3VycmllbCBl eHRlcm5lOjwvc3Bhbj48L2k+PC9zdHJvbmc+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibHVlIj4mbmJzcDs8 L3NwYW4+PC9pPjwvc3Bhbj48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpi bHVlIj5Tb3lleg0KIHBydWRlbnQgYXZlYyBsZXMgbGllbnMgZXQgZG9jdW1lbnRzIGpvaW50czwv c3Bhbj48L2VtPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0i dGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2Vu dGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHN0cm9uZz48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOmJsdWUiPkV4dGVybmFsIEVtYWlsOjwvc3Bhbj48L2k+ PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+IFBs ZWFzZSB1c2UgY2F1dGlvbiB3aGVuIG9wZW5pbmcgbGlua3MgYW5kIGF0dGFjaG1lbnRzIC8NCjwv c3Bhbj48L2VtPjxzdHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpi bHVlIj5Db3VycmllbCBleHRlcm5lOjwvc3Bhbj48L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Y29sb3I6Ymx1ZSI+IFNveWV6IHBydWRlbnQgYXZlYyBsZXMgbGll bnMgZXQgZG9jdW1lbnRzIGpvaW50cw0KPC9zcGFuPjwvZW0+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_95cfe4eb9e8447ed8ba0185333a79c52bellca_--
<= p dir=3D"auto">If we go with your option:

So maybe we should normatively upda= te 5222 to say that the RelaxNG is =E2=80=9Creplaced by=E2=80=9D the xml = schema for the purposes of defining new extensions, but the existing exte= nsion definitions in RelaxNG form are still valid.

We should probably try to also at least crea= te an XML schema for LoST-Sync, since that's going to be increasingly nee= ded for emergency services, at least in North America. How much would th= at delay the draft, or would we want to try and do it in its own document= ?

I'd like to hear from other group members. Especially fr= om anyone who supports this approach and is willing to review the XML sch= emas.


--Randall

On 24 Aug 2021, at 11:12, Brian Rosen wrote:

In general, I=E2=80=99d like to deprecate = it, but I=E2=80=99m having second thoughts on the difficulty in doing so.=

If we= were to deprecate it, we would have to deal with existing extensions. &n= bsp;I see RFCs 6197, 6451 and 6739 have RelaxNG schemas that extend LoST.=  I note that all 3 of these are Experimental.   So one argumen= t is that if we deprecate the RelaxNG schema in 5222, we have to do that = to these extensions, and provide xml schemas to replace them.  I wil= l note that LoST Sync (6739) is going to be heavily deployed soon.  =

So maybe we sh= ould normatively update 5222 to say that the RelaxNG is =E2=80=9Creplaced= by=E2=80=9D the xml schema for the purposes of defining new extensions, = but the existing extension definitions in RelaxNG form are still valid. &= nbsp;If someone wanted to help make xml schema replacements for at least = 6739, that would be useful.  If we did all 3, then we probably could= deprecate the RelaxNG everywhere.  This draft would have to update = those 3 RFCs as well as 5222.

<= div class=3D"">If we don=E2=80=99t deprecate the RelaxNG, then there is a= lways the standards issue of what if there is a discrepancy between the x= ml schema and the RelaxNG.  I think we would have to say that it=E2=80= =99s the RelaxNG, and we would use the errata process to fix the xml sche= ma.

Th= e thing to keep in mind is that every implementor I know is using xml sch= emas, however they get them, to build their code. The practical answer is= that everyone needs xml schemas and no one needs RelaxNG.

Brian

On Aug 24, 2021, at 1:48 PM, Caron, Guy <g.caron@bell.ca> wrote:

Thanks for pointing me to this email. = My search somehow did not find this one.
 
Reading the comments, it seems to me that the commenter is not totally= adverse to the idea of making a normative change towards the XML schema.=
 = ;
I=E2=80=99m not familiar enough with= the process to determine if or how the RelaxNG version of the LoST schem= a can be deprecated. I can live with a normative XML version to which any= further extensions (or updates) attach to and leave the initial RelaxNG = schema becoming organically outdated and useless.
 
Thanks,
<= o:p class=3D""> 
Guy
 
De : Brian Rosen <br@brianrosen.net>&= nbsp;
Envoy=C3=A9 : 23 ao=C3=BBt 2021 17:12
=C3=80 : Caron, Guy <g.caron@bell.ca>
Cc : ecrit@ietf.org
Objet&nb= sp;: [EXT]Re: lost-= planned-changes-04: XML vs RelaxNG
&nbs= p;
https://mai= larchive.ietf.org/arch/msg/ecrit/oTPSzxsLp3YNy8J6HOwYjxdx1bI/
 
If we don=E2=80=99t deprecate the Rel= axNG schema, shouldn=E2=80=99t extensions have to provide Relax NG?  = ; That=E2=80=99s my setf serving reason to deprecate it.   I guess w= e could not actually deprecate it, but normatively update 5222 to say tha= t extensions should reference the xml schema.
=
 
Brian
 
 


On Au= g 23, 2021, at 4:59 PM, Caron, Guy <g.caron@= bell.ca> wrote:
 
If you refer to general comments made= in the early days of LoST, some 15 years ago, I guess time tells that Re= laxNG did not ramp up as expected.
 
I can=E2=80=99t find comments o= n the ECRIT list specific to planned-changes asking for XML schemas to be= informative while updating RFC5222.
 <= /div>
<= span lang=3D"EN-CA" style=3D"font-size: 11pt; font-family: Calibri, sans-= serif; color: rgb(31, 73, 125);" class=3D"">I agree with your sentiment t= hat XML schemas should be a normative alternative (i.e., does not depreca= tes) to RelaxNG.
=
 
Besides, by not providing RelaxNG equivalents for = the extensions, isn=E2=80=99t that what you are doing anyway?
 
Than= ks,
 
Guy
 
De&nbs= p;:&nbs= p;Brian Rosen <br@brianrosen.net> <= /span>
Envoy=C3=A9 : 23 ao=C3=BBt 2021 16:37
= =C3=80 :&nbs= p;Caron, Guy <g.caron@bell.ca>=
Cc : ecrit@ietf.org
Objet :&n= bsp;[EXT]Re: lost-planned-changes-04: XML vs RelaxNG
 
We have had co= mments suggesting it be non normative, which is why it says what it does = now. 
 
My personal view is that it should replace= the Relax NG schema, and any subsequent changes and extensions should on= ly reference this one. No one that I know uses the Relax NG schema one wa= y or another they get an xml schema and use that. 
 
<= div class=3D"">
But I will go with whatever the consensus is  
 
Brian
 =
On Mon, Aug 23, 2021 at 4:32 PM Car= on, Guy <g.caron@bell.ca> wrote:
<= /div>
In section 7, the replacement XML schema is = qualified as an =E2=80=9Cinformative alternative=E2=80=9D however, the te= xt in the Intro states =E2=80=9CAlternative schemas have been circulated,= which is undesirable, as they may not be in conformance to the RelaxNG s= chema in [RFC5222]. This document provides an XML schema that replaces th= e RelaxNG schema. It can be used by any implementation interchangeably wi= th the RelaxNG schema.=E2=80=9D
<= div class=3D"">
 
The latter seems to indicate that the XML schema in section = 7 is a normative alternative rather than an informative one.
 
I think this is what we want but= the text must be adjusted accordingly.
 
Thanks,
=
 
Guy
Ex= ternal Email: = ;Please use caution when opening links and attachments /<= /span> Courriel externe: Soyez prudent avec les liens et documen= ts joints
 = ;
External Email: Please use caution when opening links and attach= ments / Courriel externe: Soyez prudent avec les liens et documents joint= s