From nobody Mon Mar 2 06:38:24 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C061A8799 for ; Mon, 2 Mar 2015 06:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 LaQ6M3xYARNk for ; Mon, 2 Mar 2015 06:38:20 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FCE91A8793 for ; Mon, 2 Mar 2015 06:38:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3128; q=dns/txt; s=iport; t=1425307100; x=1426516700; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=49hWAXfd3GX+ITARmBzUVLcT+eAki55Aud5qx3Pkqco=; b=RndasPhqPrQlp1cNkMse7epT4UvfPKbHQaO1qp1Dri6uFjeYsTcuUGIE swBd6j25rnrVy6PvmRpvCbvkOs1FxVOzElbnT49JqVOe8H9cnNrs3bCVs 1cdYpM6ymESFjk6tNW+knV+QVNqfl/MFRXFoksWRhcl7jGg0jzKV8G3+/ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AiBQDxdPRU/49dJa1agwJSXsFBhW4CgSFNAQEBAQEBfIQPAQEBAwE6LRAHCwIBGQMBAh8QMhsCCAIEEwkSiAwIDdYCAQEBAQEBBAEBAQEBAQEBARmLEoR7gxGBFAWPeINghWeBGjmCZ48gI4NubwGBQ38BAQE X-IronPort-AV: E=Sophos;i="5.09,675,1418083200"; d="scan'208";a="111083431" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by mtv-iport-1.cisco.com with ESMTP; 02 Mar 2015 14:38:20 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t22EcImk027149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 2 Mar 2015 14:38:19 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.20]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Mon, 2 Mar 2015 08:38:18 -0600 From: "Marc Linsner (mlinsner)" To: "ecrit@ietf.org" Thread-Topic: New Version Notification for draft-marshall-ecrit-indoor-location-00.txt Thread-Index: AQHQVHpJHdrpwniKDESOf+es7qoxHw== Date: Mon, 2 Mar 2015 14:38:17 +0000 Message-ID: References: <20150301234854.13335.84450.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.148.98] Content-Type: text/plain; charset="us-ascii" Content-ID: <8AEAC21591346B498C0E0F59290C7C8E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Ecrit] Fwd: New Version Notification for draft-marshall-ecrit-indoor-location-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 14:38:22 -0000 All, A new draft to discuss the new methods for cellular device location, prompt= ed by the US cellular carriers adding to their device location repertoire. We hope to present and discuss at the Dallas ECRIT meeting. Marc, Roger, Dorothy =20 Begin forwarded message: > From: > Subject: New Version Notification for draft-marshall-ecrit-indoor-locatio= n-00.txt > Date: March 1, 2015 at 6:48:54 PM EST > To: Marc Linsner , Marc Linsner , Dorothy Stanley , "Roger Marshall" , Dorothy Stanley , Roge= r Marshall >=20 >=20 > A new version of I-D, draft-marshall-ecrit-indoor-location-00.txt > has been successfully submitted by Roger Marshall and posted to the > IETF repository. >=20 > Name: draft-marshall-ecrit-indoor-location > Revision: 00 > Title: Indoor Location Mechanisms for Emergency Services > Document date: 2015-03-01 > Group: Individual Submission > Pages: 18 > URL: http://www.ietf.org/internet-drafts/draft-marshall-ecrit-= indoor-location-00.txt > Status: https://datatracker.ietf.org/doc/draft-marshall-ecrit-ind= oor-location/ > Htmlized: http://tools.ietf.org/html/draft-marshall-ecrit-indoor-lo= cation-00 >=20 >=20 > Abstract: > The application of summoning emergency assistance by using a phone to > call 9-1-1 in North America has been ingrained in society for 40+ > years. A successful emergency response to a caller in need, is > dependent upon the responders receiving accurate location information > to effect timely action. Traditional wireline telephony is able to > utilize the location of the physical wires as a source of information > for caller location, whereas wireless technologies require more > exotic mechanisms to locate a 9-1-1 caller. >=20 > Mechanisms for locating a cellular caller dialing 9-1-1 is based on > 20 year old technology, which was designed for outdoor environments, > and does not perform sufficiently when used to locate an emergency > caller from within a home or office building environment. >=20 > With growing trends in mobile cellular usage, large portions of > subscribers are relying solely on their mobile phones to make > emergency calls. Emergency response time suffers when that caller is > located indoors. >=20 > This document defines the problem statement and solutions for > expanding the current set of methods used to locate a cellular caller > to 9-1-1. The expansion of the methods includes connections to > services that are outside the normal administrative domain of the > cellular provider, hence both the privacy and security aspects of > connecting these systems are taken into consideration. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From DBanks@ddti.net Mon Mar 2 08:42:34 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62BCB1A1B73 for ; Mon, 2 Mar 2015 08:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 XHawUDNwZHi2 for ; Mon, 2 Mar 2015 08:42:31 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0693.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::693]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB05B1A1B6D for ; Mon, 2 Mar 2015 08:42:30 -0800 (PST) Received: from CY1PR0701MB1305.namprd07.prod.outlook.com (25.160.149.24) by CY1PR0701MB1308.namprd07.prod.outlook.com (25.160.150.11) with Microsoft SMTP Server (TLS) id 15.1.99.14; Mon, 2 Mar 2015 16:42:10 +0000 Received: from CY1PR0701MB1305.namprd07.prod.outlook.com ([25.160.149.24]) by CY1PR0701MB1305.namprd07.prod.outlook.com ([25.160.149.24]) with mapi id 15.01.0099.004; Mon, 2 Mar 2015 16:42:10 +0000 From: Dan Banks To: "ecrit@ietf.org" Thread-Topic: Comments re: draft-ietf-additional-data-28 Thread-Index: AdBVAgOel91qtnpkTouCc8kTpj7cnw== Date: Mon, 2 Mar 2015 16:42:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [4.53.197.18] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1308; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006); SRVR:CY1PR0701MB1308; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1308; x-forefront-prvs: 0503FF9A3E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(124975003)(19300405004)(66066001)(19625215002)(77156002)(62966003)(450100001)(229853001)(2351001)(122556002)(40100003)(19617315012)(110136001)(107886001)(76576001)(33656002)(46102003)(16236675004)(92566002)(2501003)(230783001)(15975445007)(102836002)(86362001)(2900100001)(87936001)(2656002)(74316001)(99286002)(50986999)(19580395003)(54356999)(80792004); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0701MB1308; H:CY1PR0701MB1305.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_CY1PR0701MB130508CADDB58E4521FE5716A7100CY1PR0701MB1305_" MIME-Version: 1.0 X-OriginatorOrg: ddti.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2015 16:42:10.0548 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4c0f48ba-5f29-44b1-b29c-1aff8251101b X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1308 Archived-At: Subject: [Ecrit] Comments re: draft-ietf-additional-data-28 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 16:46:07 -0000 --_000_CY1PR0701MB130508CADDB58E4521FE5716A7100CY1PR0701MB1305_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable While working through draft-ietf-additional-data-28, I noted a few issues: 1) The text states in section 4.1.6 that the element in ProviderInf= o uses ISO 639-1:2002 codes, which seems appropriate. However, the schema = (section 7.1) uses the name "iso3166a2" as the type name. It would be bett= er if the type name in the schema reflected the actual standard uses for th= e element. Additionally, the type definition indicates uppercase letters (= which is typical for ISO 3166 codes), but it is recommended that language c= odes be expressed in lower case (see http://www.loc.gov/standards/iso639-2/= faq.html#21). I suggest that the schema be updated by renaming the "iso3166a2" type and c= hanging the pattern to lowercase, and that all examples be updated accordin= gly. 2) Section 4.2.1 states that the element is "Optional whe= n a 'ServiceType' value is 'wireless'; required otherwise." However, the s= chema in section 7.2 shows the ServiceEnvironment element as minOccurrs=3D"= 1". 3) In section 7.6, the "provided-by" element is defined, but I'm not sure if i= t is correct the way it is written since the "provided-by" element itself i= s defined elsewhere for PIDF-LO, and I don't believe that there is a use de= scribed for a "provided-by" element with the urn:ietf:params:xml:ns:Emergen= cyCallData namespace. 4) For the XML fragments given as examples in sections 5.2 and 5.3, I think it= would be more clear if the applicable namespaces were spelled out instead = of using prefixes that aren't declared in that particular fragment (but are= used for examples elsewhere). 5) In the example on page 39 (section 6) and other places, the DataProviderCon= tact element is written in the xCard namespace, which appears to be incorre= ct. That element is in the EmergencyCallData:ProviderInfo namespace in the= schema. 6) Looking at the ProviderInfoType definition (section 7.1), it appears that t= he DataProviderContact element is required, but can be empty. Section 4.1.= 7, however, states that the use of the element is optional. Am I interpret= ing the schema correctly, and is that the intended definition? Dan Banks --_000_CY1PR0701MB130508CADDB58E4521FE5716A7100CY1PR0701MB1305_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

While working through draft-ietf-additional-data-28,= I noted a few issues:

 

1)

The text states in section 4.1.6 that the <langua= ge> element in ProviderInfo uses ISO 639-1:2002 codes, which seems appro= priate.  However, the schema (section 7.1) uses the name “iso316= 6a2” as the type name.  It would be better if the type name in the schema reflected the actual standard uses for the element.&nbs= p; Additionally, the type definition indicates uppercase letters (which is = typical for ISO 3166 codes), but it is recommended that language codes be e= xpressed in lower case (see http://www.lo= c.gov/standards/iso639-2/faq.html#21).

 

I suggest that the schema be updated by renaming the= “iso3166a2” type and changing the pattern to lowercase, and th= at all examples be updated accordingly.

 

2)

Section 4.2.1 states that the <ServiceEnvironment= > element is “Optional when a 'ServiceType' value is 'wireless'; r= equired otherwise.”  However, the schema in section 7.2 shows th= e ServiceEnvironment element as minOccurrs=3D”1”.

 

3)

In section 7.6, the “provided-by” elemen= t is defined, but I’m not sure if it is correct the way it is written= since the “provided-by” element itself is defined elsewhere fo= r PIDF-LO, and I don’t believe that there is a use described for a “provided-by” element with the urn:ietf:params:xml:ns:Emerge= ncyCallData namespace.

 

4)

For the XML fragments given as examples in sections = 5.2 and 5.3, I think it would be more clear if the applicable namespaces we= re spelled out instead of using prefixes that aren’t declared in that= particular fragment (but are used for examples elsewhere).

 

5)

In the example on page 3= 9 (section 6) and other places, the DataProviderContact element is written = in the xCard namespace, which appears to be incorrect.  That element i= s in the EmergencyCallData:ProviderInfo namespace in the schema.

 =

6)

Looking at the ProviderI= nfoType definition (section 7.1), it appears that the DataProviderContact e= lement is required, but can be empty.  Section 4.1.7, however, states = that the use of the element is optional.  Am I interpreting the schema correctly, and is that the intended definitio= n?

 =

Dan Banks

--_000_CY1PR0701MB130508CADDB58E4521FE5716A7100CY1PR0701MB1305_-- From nobody Mon Mar 2 11:34:42 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54D61A8930 for ; Mon, 2 Mar 2015 11:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 GHqjLJMk1PUN for ; Mon, 2 Mar 2015 11:34:39 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB6741A8932 for ; Mon, 2 Mar 2015 11:34:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=281; q=dns/txt; s=iport; t=1425324879; x=1426534479; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=d34OaDxQHqU6Dw9sf3DfBOrTvxS39CNwrRyajaE8DPI=; b=lB3K9RvEaunS+0DdRwJBW1F6s9D4Evf3hUgnjPnHvaSWoPs8ak5029gt edndjeMIHqVAUCPCTnxtKm42oaPP9+cL+jA+uVRwKlBQwkdlrDUcF6Bzy Cgrn9HHd8e+HtmoulOIrs8IjoHxU6gb82KXwhaCPn947XQqWbX1q4gQ2i 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AUBgBLuvRU/xbLJq1ag1QaQQO7R4V4h2QBAQEBAQF8hBYdHVEBPkInBIhCDa1GqQUBCwEfjy8BAYNtgRQFj3iDYIVngRo5gmePICODboF6OX8BAQE X-IronPort-AV: E=Sophos;i="5.09,677,1418083200"; d="scan'208";a="367026418" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 02 Mar 2015 19:34:37 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t22JYZE8026957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 2 Mar 2015 19:34:36 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.20]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Mon, 2 Mar 2015 13:34:35 -0600 From: "Marc Linsner (mlinsner)" To: "ecrit@ietf.org" Thread-Topic: WGLC draft-ietf-ecrit-data-only-ea-09 Thread-Index: AQHQVR/q6VIDY6LyCUWbUkqDQNXjdA== Date: Mon, 2 Mar 2015 19:34:35 +0000 Message-ID: <46CF01EC-C5AD-46B0-AB95-397C3C3A9EA8@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.148.98] Content-Type: text/plain; charset="us-ascii" Content-ID: <09EE70101DCB3F428FB26F990EAEC12E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Ecrit] WGLC draft-ietf-ecrit-data-only-ea-09 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 19:34:41 -0000 All, This is notification of a Working Group Last Call for this draft. Please r= eview and submit comments to the mail list by COB March 16, 2015. The draft can be found at: http://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ Thanks, Roger and Marc= From nobody Tue Mar 3 00:00:43 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 455BF1A1A33 for ; Tue, 3 Mar 2015 00:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 v1lrwtq_7ClS for ; Tue, 3 Mar 2015 00:00:38 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F17AD1A1A27 for ; Tue, 3 Mar 2015 00:00:37 -0800 (PST) Received: from [192.168.131.140] ([80.92.121.102]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M2Glc-1XaskP2xzY-00s96F; Tue, 03 Mar 2015 09:00:33 +0100 Message-ID: <54F56A20.2020607@gmx.net> Date: Tue, 03 Mar 2015 09:00:32 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" , "ecrit@ietf.org" References: <54E36FCD.6060301@gmx.net> <949EF20990823C4C85C18D59AA11AD8B4A0F2A5E@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B4A0F2A5E@FR712WXCHMBA11.zeu.alcatel-lucent.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9wSvKFEPXlTX0p9fdOpxNfXQP4HTvnu78" X-Provags-ID: V03:K0:mmvzFyjo+nx4xS359WPjciyJPpCvWUXnaTwc5BljKD8XgE8ytIs sniN4266n0e0cm+fX24mfjDa8toWF2Dzm2UdHHSHBJss1gpGJCuviXQ9Xm/m1gE1rJ7rVP9 /Te2XKGnCJk6WAUHV6wf6Qwu5j+jR+tvOTjaMY/kThXq3g1QrUqfv+JwMH8a6wDW7G4mu/6 k1F1BicKMFsLTa5bnyZVg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [Ecrit] car-crash & ecrit-ecall drafts X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 08:00:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9wSvKFEPXlTX0p9fdOpxNfXQP4HTvnu78 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Keith, if 3GPP wants to use the work then that's great. If they don't then that's OK as well. The documents illustrate how you can re-use existing functionality for placing an emergency call from a car. We have developed lots of building blocks in ECRIT, GEOPRIV and other IETF groups that can be re-used (as you can see from the references in the documents). Given there is always a lot of excitement in re-building everything from scratch I believe that's a pretty solid story we have created here. Ciao Hannes On 02/19/2015 03:21 PM, DRAGE, Keith (Keith) wrote: > I believe the only realistic use case is where it is used through a > 3GPP access. >=20 > Unless you are saying you have an over the top use case where the > 3GPP aspect is not an emergency call, then you have an underlying > dependency on 3GPP, and in particular the successful use of the new > URN values. >=20 > Of particular criticality is what happens when the underlying system > does not understand the new URN, and therefore ignores the subtypes. > 3GPP needs to tell you whether it is appropriate that that is always > delivered to an ordinary PSAP. Also an issue is whether service > continuity is meant to operate on such a call, and if so, how. >=20 > Unfortunately, you do not seem to have created sufficient interest in > the 3GPP community for anyone to start a related work item. That > implies to me that there is not yet consensus behind getting this > right as a capability. >=20 > Keith >=20 >> -----Original Message----- From: Ecrit >> [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig=20 >> Sent: 17 February 2015 16:44 To: ecrit@ietf.org Subject: [Ecrit] >> car-crash & ecrit-ecall drafts >>=20 >> FWIW, I would like to see these two documents to advance:=20 >> https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/=20 >> https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ >>=20 >> I see no need to create a dependency on 3GPP work since there are >> other customers for these documents. >>=20 >> Ciao Hannes >>=20 --9wSvKFEPXlTX0p9fdOpxNfXQP4HTvnu78 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU9WogAAoJEGhJURNOOiAtS0kIAKPCVtvNYBcCOo1pApgkOfTx Iiktnx8fyM3iI2iMZvng1/hev96JSA2+BSKwswPSLJGROyd/evvSb39DEw3bGorj qRmWL3vJ9lzuTqPixyiyvJbM2rF0GaTcAvT+CUfKhW+qVPL/cpL12J4jB5Oxf6Kt 4Lfw6xzawTKatH6PYWJKeLD7L14zDoEQtMXZzi3lLorMmCZV4SmOpO0Dl61AwmhO Vsk/SE6g6F24fD3vTrIUG2p0DLVwjR8vDbwfzQcT8qT9pngdi8k9Gt7F2Tesoemd hf8dTxSYV+DHVF8k3c8YLsuoZS3lQK9NkqjmkPllj09QHSGFNfea3SsACSZ70FM= =Jhad -----END PGP SIGNATURE----- --9wSvKFEPXlTX0p9fdOpxNfXQP4HTvnu78-- From nobody Tue Mar 3 03:06:20 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E0C1A017D for ; Tue, 3 Mar 2015 03:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 f3r6-EW3egfA for ; Tue, 3 Mar 2015 03:06:17 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 CF9E61A01A5 for ; Tue, 3 Mar 2015 03:06:16 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 9F0DBCFFC653A; Tue, 3 Mar 2015 11:06:12 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t23B6EMo014019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Mar 2015 12:06:15 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.230]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 3 Mar 2015 12:06:14 +0100 From: "DRAGE, Keith (Keith)" To: Hannes Tschofenig , "ecrit@ietf.org" Thread-Topic: [Ecrit] car-crash & ecrit-ecall drafts Thread-Index: AQHQVYglqZ+fiXaxdUmgmyIKTEhLPJ0KmKmQ Date: Tue, 3 Mar 2015 11:06:13 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B4A10D5D7@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <54E36FCD.6060301@gmx.net> <949EF20990823C4C85C18D59AA11AD8B4A0F2A5E@FR712WXCHMBA11.zeu.alcatel-lucent.com> <54F56A20.2020607@gmx.net> In-Reply-To: <54F56A20.2020607@gmx.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Ecrit] car-crash & ecrit-ecall drafts X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 11:06:18 -0000 So answer the question I posed - do you intend this usage to occur as an em= ergency call in a 3GPP network, do you intend this usage to occur as an ord= inary call in a 3GPP network, or do you intend this to use some other netwo= rk other that a 3GPP network, and if so what? Keith=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 > Sent: 03 March 2015 08:01 > To: DRAGE, Keith (Keith); ecrit@ietf.org > Subject: Re: [Ecrit] car-crash & ecrit-ecall drafts >=20 > Hi Keith, >=20 > if 3GPP wants to use the work then that's great. If they=20 > don't then that's OK as well. >=20 > The documents illustrate how you can re-use existing=20 > functionality for placing an emergency call from a car. We=20 > have developed lots of building blocks in ECRIT, GEOPRIV and=20 > other IETF groups that can be re-used (as you can see from=20 > the references in the documents). >=20 > Given there is always a lot of excitement in re-building=20 > everything from scratch I believe that's a pretty solid story=20 > we have created here. >=20 > Ciao > Hannes >=20 > On 02/19/2015 03:21 PM, DRAGE, Keith (Keith) wrote: > > I believe the only realistic use case is where it is used through a=20 > > 3GPP access. > >=20 > > Unless you are saying you have an over the top use case=20 > where the 3GPP=20 > > aspect is not an emergency call, then you have an underlying=20 > > dependency on 3GPP, and in particular the successful use of the new=20 > > URN values. > >=20 > > Of particular criticality is what happens when the=20 > underlying system=20 > > does not understand the new URN, and therefore ignores the subtypes. > > 3GPP needs to tell you whether it is appropriate that that=20 > is always=20 > > delivered to an ordinary PSAP. Also an issue is whether service=20 > > continuity is meant to operate on such a call, and if so, how. > >=20 > > Unfortunately, you do not seem to have created sufficient=20 > interest in=20 > > the 3GPP community for anyone to start a related work item. That=20 > > implies to me that there is not yet consensus behind getting this=20 > > right as a capability. > >=20 > > Keith > >=20 > >> -----Original Message----- From: Ecrit=20 > >> [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig > >> Sent: 17 February 2015 16:44 To: ecrit@ietf.org Subject: [Ecrit]=20 > >> car-crash & ecrit-ecall drafts > >>=20 > >> FWIW, I would like to see these two documents to advance:=20 > >> https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ > >> https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ > >>=20 > >> I see no need to create a dependency on 3GPP work since there are=20 > >> other customers for these documents. > >>=20 > >> Ciao Hannes > >>=20 >=20 > = From nobody Tue Mar 3 04:47:20 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67ED01A6F2D for ; Tue, 3 Mar 2015 04:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 L99R0l51MMOI for ; Tue, 3 Mar 2015 04:47:15 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B00811A6EE9 for ; Tue, 3 Mar 2015 04:47:14 -0800 (PST) Received: from [192.168.131.140] ([80.92.121.102]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lj25i-1Xv56H28Uw-00dETm; Tue, 03 Mar 2015 13:47:11 +0100 Message-ID: <54F5AD4E.1060704@gmx.net> Date: Tue, 03 Mar 2015 13:47:10 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" , "ecrit@ietf.org" References: <54E36FCD.6060301@gmx.net> <949EF20990823C4C85C18D59AA11AD8B4A0F2A5E@FR712WXCHMBA11.zeu.alcatel-lucent.com> <54F56A20.2020607@gmx.net> <949EF20990823C4C85C18D59AA11AD8B4A10D5D7@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B4A10D5D7@FR712WXCHMBA11.zeu.alcatel-lucent.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="D8C8JJnOcOf0KqdrIJGaMe91eJUmaawlB" X-Provags-ID: V03:K0:eueDHTUPCA1mTfBJlUT4Bm/HOzCIu5jwm2KKVHmwHAmSypAX5ze UaR8RUqXPXDleLAH6IDD/76fmzUAnBtvKHO0r4amrxdmoR/7zeoi6SRWhJNog+HhlKtZOdP DB0VLy2DcjEaFPcuz8hTEnHX2Sx77vAp8wRf6mbepL5ToQYoRyZYj5tuNw0P13ifwOT/BIS MbHmpqvZf+wTnl71y7SZg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [Ecrit] car-crash & ecrit-ecall drafts X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 12:47:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --D8C8JJnOcOf0KqdrIJGaMe91eJUmaawlB Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Keith, the document leaves both options possible. I envision it to be used in both scenarios. If you look at what car manufacturers do then you can easily see that there is a lot of work ongoing already in that area. Ciao Hannes On 03/03/2015 12:06 PM, DRAGE, Keith (Keith) wrote: > So answer the question I posed - do you intend this usage to occur as a= n emergency call in a 3GPP network, do you intend this usage to occur as = an ordinary call in a 3GPP network, or do you intend this to use some oth= er network other that a 3GPP network, and if so what? >=20 > Keith=20 >=20 >> -----Original Message----- >> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 >> Sent: 03 March 2015 08:01 >> To: DRAGE, Keith (Keith); ecrit@ietf.org >> Subject: Re: [Ecrit] car-crash & ecrit-ecall drafts >> >> Hi Keith, >> >> if 3GPP wants to use the work then that's great. If they=20 >> don't then that's OK as well. >> >> The documents illustrate how you can re-use existing=20 >> functionality for placing an emergency call from a car. We=20 >> have developed lots of building blocks in ECRIT, GEOPRIV and=20 >> other IETF groups that can be re-used (as you can see from=20 >> the references in the documents). >> >> Given there is always a lot of excitement in re-building=20 >> everything from scratch I believe that's a pretty solid story=20 >> we have created here. >> >> Ciao >> Hannes >> >> On 02/19/2015 03:21 PM, DRAGE, Keith (Keith) wrote: >>> I believe the only realistic use case is where it is used through a=20 >>> 3GPP access. >>> >>> Unless you are saying you have an over the top use case=20 >> where the 3GPP=20 >>> aspect is not an emergency call, then you have an underlying=20 >>> dependency on 3GPP, and in particular the successful use of the new=20 >>> URN values. >>> >>> Of particular criticality is what happens when the=20 >> underlying system=20 >>> does not understand the new URN, and therefore ignores the subtypes. >>> 3GPP needs to tell you whether it is appropriate that that=20 >> is always=20 >>> delivered to an ordinary PSAP. Also an issue is whether service=20 >>> continuity is meant to operate on such a call, and if so, how. >>> >>> Unfortunately, you do not seem to have created sufficient=20 >> interest in=20 >>> the 3GPP community for anyone to start a related work item. That=20 >>> implies to me that there is not yet consensus behind getting this=20 >>> right as a capability. >>> >>> Keith >>> >>>> -----Original Message----- From: Ecrit=20 >>>> [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig >>>> Sent: 17 February 2015 16:44 To: ecrit@ietf.org Subject: [Ecrit]=20 >>>> car-crash & ecrit-ecall drafts >>>> >>>> FWIW, I would like to see these two documents to advance:=20 >>>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ >>>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ >>>> >>>> I see no need to create a dependency on 3GPP work since there are=20 >>>> other customers for these documents. >>>> >>>> Ciao Hannes >>>> >> --D8C8JJnOcOf0KqdrIJGaMe91eJUmaawlB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU9a1OAAoJEGhJURNOOiAtpCEH/Al3o+uuwnLDTvzN4fe1wAUy GrdOrXKgzBThM6AR43TXzUDyayDmFsjzI5PcDXchFB01KRWGm/DlFSMUmW68fMHF pgd+iPiwmkOK6sx2hLzJ1uXW2i137v08rI9GX0Py9DP2nG6ZlAowFJ7Stbcta4bx JHqXg2wxwK90zLyiHP31BMUvkxinYL5IJE3c2MtcazCbFGO3xvr9SM7DuFHO5zJ3 tiwLs+G1tMPxwPhvQpi7gF0sPJynLrjuUchvYvJVbn48tLJvTpGYMIBBPsLdrJQ9 TN91PyNEJB8U5OuTKG/ThQcrdABlz1/zbUsQ8/dRNvJ6V4kIbBM5OsCDf/7cdfs= =1T5k -----END PGP SIGNATURE----- --D8C8JJnOcOf0KqdrIJGaMe91eJUmaawlB-- From nobody Wed Mar 4 00:42:21 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A9E1A19F2 for ; Wed, 4 Mar 2015 00:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 NSBrIH1lZxDS for ; Wed, 4 Mar 2015 00:42:19 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A97FD1A036B for ; Wed, 4 Mar 2015 00:42:18 -0800 (PST) X-AuditID: c1b4fb25-f79446d000003f3f-85-54f6c568f6ac Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 08.F7.16191.865C6F45; Wed, 4 Mar 2015 09:42:16 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.39]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0210.002; Wed, 4 Mar 2015 09:42:15 +0100 From: Ivo Sedlacek To: Hannes Tschofenig , "DRAGE, Keith (Keith)" , "ecrit@ietf.org" Thread-Topic: [Ecrit] car-crash & ecrit-ecall drafts Thread-Index: AQHQVbA3bBmkwtp2dE6+4fYZ+Ju49p0L/s0A Date: Wed, 4 Mar 2015 08:42:15 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101128320E7@ESESSMB301.ericsson.se> References: <54E36FCD.6060301@gmx.net> <949EF20990823C4C85C18D59AA11AD8B4A0F2A5E@FR712WXCHMBA11.zeu.alcatel-lucent.com> <54F56A20.2020607@gmx.net> <949EF20990823C4C85C18D59AA11AD8B4A10D5D7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <54F5AD4E.1060704@gmx.net> In-Reply-To: <54F5AD4E.1060704@gmx.net> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+JvjW7G0W8hBm+myFg0LnrKarF05z1W i6eNZxkdmD1an+1l9Vi8aT+bx5IlP5kCmKO4bFJSczLLUov07RK4Mg4+fMBc8E6+4uTsBawN jFcluxg5OSQETCS2XDjMAmGLSVy4t56ti5GLQ0jgCKPE0c17oZxFjBL799xkA6liE9CTmLjl CCtIQkSgn1HiztQPTCAJYQFjiZsX17GD2CJAY/9OmARlG0m8O/GQEcRmEVCRWHv8NyuIzSvg K9GyfgkTxIY2JomWxWvA7uAUUJdYNf8d2FBGAVmJq396wZqZBcQlbj2ZzwRxq4DEkj3nmSFs UYmXj/8BDeUAspUkpm1NgyjXk3h2ahYLhK0tsWzha2aIvYISJ2c+YZnAKDoLydRZSFpmIWmZ haRlASPLKkbR4tTipNx0I2O91KLM5OLi/Dy9vNSSTYzA+Dm45bfqDsbLbxwPMQpwMCrx8BqU fgsRYk0sK67MPcQozcGiJM5rZ3woREggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANjgvHKifPz r2admMph1WW9dXFDCu/K9+aVOttfcCybojIjvp7b9LNbdF5U8mThUJVq8XN9qio3zd3Od7N1 nmibrsxwYOXN9sszDrAI7zETKD0Q+vlmicSHnMutXfpLNDe2xb9ffCSa87zmzi2LJzYFfgww zMvjNd+mp9t6UXZHquAOpsT8x5eUWIozEg21mIuKEwGZ+Xj7gAIAAA== Archived-At: Subject: Re: [Ecrit] car-crash & ecrit-ecall drafts X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 08:42:20 -0000 Hello, draft-ietf-ecrit-ecall-01 states: ----------- NG-eCall is a **3GPP** **IMS** emergency call with additional elements identifying the call as an eCall and as carrying eCall data and with mechanisms for carrying the data. ----------- 3GPP has not stated requirements for such service yet. When 3GPP states req= uirements, the solution in the draft will not necessarily fit. Given that the NG-eCall is "3GPP IMS emergency call" and given that 3GPP ha= s not stated requirements for such service yet, then IMO it is too early to= progress this draft. Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer=20 -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: 3. b=F8ezna 2015 13:47 To: DRAGE, Keith (Keith); ecrit@ietf.org Subject: Re: [Ecrit] car-crash & ecrit-ecall drafts Hi Keith, the document leaves both options possible. I envision it to be used in both= scenarios. If you look at what car manufacturers do then you can easily see that there= is a lot of work ongoing already in that area. Ciao Hannes On 03/03/2015 12:06 PM, DRAGE, Keith (Keith) wrote: > So answer the question I posed - do you intend this usage to occur as an = emergency call in a 3GPP network, do you intend this usage to occur as an o= rdinary call in a 3GPP network, or do you intend this to use some other net= work other that a 3GPP network, and if so what? >=20 > Keith >=20 >> -----Original Message----- >> From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net] >> Sent: 03 March 2015 08:01 >> To: DRAGE, Keith (Keith); ecrit@ietf.org >> Subject: Re: [Ecrit] car-crash & ecrit-ecall drafts >> >> Hi Keith, >> >> if 3GPP wants to use the work then that's great. If they don't then=20 >> that's OK as well. >> >> The documents illustrate how you can re-use existing functionality=20 >> for placing an emergency call from a car. We have developed lots of=20 >> building blocks in ECRIT, GEOPRIV and other IETF groups that can be=20 >> re-used (as you can see from the references in the documents). >> >> Given there is always a lot of excitement in re-building everything=20 >> from scratch I believe that's a pretty solid story we have created=20 >> here. >> >> Ciao >> Hannes >> >> On 02/19/2015 03:21 PM, DRAGE, Keith (Keith) wrote: >>> I believe the only realistic use case is where it is used through a=20 >>> 3GPP access. >>> >>> Unless you are saying you have an over the top use case >> where the 3GPP >>> aspect is not an emergency call, then you have an underlying=20 >>> dependency on 3GPP, and in particular the successful use of the new=20 >>> URN values. >>> >>> Of particular criticality is what happens when the >> underlying system >>> does not understand the new URN, and therefore ignores the subtypes. >>> 3GPP needs to tell you whether it is appropriate that that >> is always >>> delivered to an ordinary PSAP. Also an issue is whether service=20 >>> continuity is meant to operate on such a call, and if so, how. >>> >>> Unfortunately, you do not seem to have created sufficient >> interest in >>> the 3GPP community for anyone to start a related work item. That=20 >>> implies to me that there is not yet consensus behind getting this=20 >>> right as a capability. >>> >>> Keith >>> >>>> -----Original Message----- From: Ecrit=20 >>>> [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig >>>> Sent: 17 February 2015 16:44 To: ecrit@ietf.org Subject: [Ecrit]=20 >>>> car-crash & ecrit-ecall drafts >>>> >>>> FWIW, I would like to see these two documents to advance:=20 >>>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ >>>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ >>>> >>>> I see no need to create a dependency on 3GPP work since there are=20 >>>> other customers for these documents. >>>> >>>> Ciao Hannes >>>> >> From nobody Wed Mar 4 00:44:58 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5BE1A6FED for ; Wed, 4 Mar 2015 00:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 TC31ySy2R0Ss for ; Wed, 4 Mar 2015 00:44:51 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B40B51A1A32 for ; Wed, 4 Mar 2015 00:44:50 -0800 (PST) Received: from [192.168.131.141] ([80.92.121.102]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MXEs5-1XxQro2Pbh-00WIGV; Wed, 04 Mar 2015 09:44:45 +0100 Message-ID: <54F6C5FC.3020809@gmx.net> Date: Wed, 04 Mar 2015 09:44:44 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ivo Sedlacek , "DRAGE, Keith (Keith)" , "ecrit@ietf.org" References: <54E36FCD.6060301@gmx.net> <949EF20990823C4C85C18D59AA11AD8B4A0F2A5E@FR712WXCHMBA11.zeu.alcatel-lucent.com> <54F56A20.2020607@gmx.net> <949EF20990823C4C85C18D59AA11AD8B4A10D5D7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <54F5AD4E.1060704@gmx.net> <39B5E4D390E9BD4890E2B31079006101128320E7@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101128320E7@ESESSMB301.ericsson.se> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GC88DDQbq08E3J85uJ1HloBt72jnp5ouK" X-Provags-ID: V03:K0:tML5c4sGHlXQh/++de9wyLxMZIdMxDlcFK4GR16Msn/AFKYSEGC p/hrNO8rV8HnmSCE1N1pH3QJL00h9qz1ZOeSJGTwJDKIcUDFQwFvniKmcvUfVHkTdEqdxpO mW+9TOnAQedB3+ZaSBqtmqKv7n3CHcQYohSEkuZKeF0yeUR5rUedOFWkBPtI1hT/oajsUqB O18vyELiZVAEVVFzV+O2g== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [Ecrit] car-crash & ecrit-ecall drafts X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 08:44:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GC88DDQbq08E3J85uJ1HloBt72jnp5ouK Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Hi Ivo, thanks for pointing this out. I will work with my co-authors to suggest an appropriate wording. On 03/04/2015 09:42 AM, Ivo Sedlacek wrote: > NG-eCall is a **3GPP** **IMS** emergency call with additional elemen= ts > identifying the call as an eCall and as carrying eCall data and with= > mechanisms for carrying the data. Ciao Hannes --GC88DDQbq08E3J85uJ1HloBt72jnp5ouK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU9sX8AAoJEGhJURNOOiAtK0EH/RSS1emUAzikd+ZcbDE+yDTB 0rhyygLGVtQ5/amqdTF45zJnBLB0pGgm+m89smNSw0KO+mhQOU94oZ1gR1WvKMS/ AZF6WzSoqCPFMHWaf3ilcjMVEkH8pX/qiryPPD8+pjictidPy2VULVtuOOtn1h+S WMmJvXeGgaMDbzqIiM4GXIekkibp1dvVJD8J4Ior+hR3kkbzFpBWz9sXFA26a8os CoA1n9faWfrh1nrrFHEGPh8xZrRxj288RIWDjpyQ8FfUKfI4bTplaDCl795lHqoE WJrHLh94kbRH+5I7m5oH4+uWr2x8ZBawUv8hNmyvE1CieqYKVGQlzXTLHiqu36k= =TtA/ -----END PGP SIGNATURE----- --GC88DDQbq08E3J85uJ1HloBt72jnp5ouK-- From nobody Wed Mar 4 17:00:25 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148A71A0068 for ; Wed, 4 Mar 2015 17:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.011 X-Spam-Level: X-Spam-Status: No, score=-9.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 PjUbh1_Gc4Hm for ; Wed, 4 Mar 2015 17:00:22 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC7391A7012 for ; Wed, 4 Mar 2015 17:00:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1425517222; x=1457053222; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=rMkpNLf4PEmYiAFTgSTpLPjApD7R8830DQPySNK/c2s=; b=ygRnWMsExHkLr0Cag5Tgr3eqSVEcYPgw+LLzRpW8kQC1fI5rVv5/n9mw W/Hz57SSQS+1UE+kK1YdXST0282gVGQ0HNNSbimUb/rG1dQprIOrTdN/P k8g/Md1wCtM93GyJbZhLAYUHFVj/9RqWpn1ikn6K5E+grkoTtsq5CvLcI 4=; X-IronPort-AV: E=McAfee;i="5600,1067,7730"; a="84252194" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Mar 2015 17:00:21 -0800 X-IronPort-AV: E=Sophos;i="5.11,344,1422950400"; d="scan'208";a="863701806" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Mar 2015 17:00:11 -0800 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 4 Mar 2015 17:00:06 -0800 Message-ID: In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B4A0F2A5E@FR712WXCHMBA11.zeu.alcatel-l ucent.com> References: <54E36FCD.6060301@gmx.net> <949EF20990823C4C85C18D59AA11AD8B4A0F2A5E@FR712WXCHMBA11.zeu.alcatel-l ucent.com> X-Mailer: Eudora for Mac OS X Date: Wed, 4 Mar 2015 17:00:04 -0800 To: "DRAGE, Keith (Keith)" , Hannes Tschofenig , "ecrit@ietf.org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (10.85.0.82) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Subject: Re: [Ecrit] car-crash & ecrit-ecall drafts X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 01:00:24 -0000 At 2:21 PM +0000 2/19/15, Keith (Keith) DRAGE wrote: > Of particular criticality is what happens when the underlying > system does not understand the new URN, and therefore ignores the > subtypes. 3GPP needs to tell you whether it is appropriate that > that is always delivered to an ordinary PSAP. Also an issue is > whether service continuity is meant to operate on such a call, and > if so, how. The correct routing of emergency calls is usually handled by local agreements between the emergency authorities and the network operators, but in any event is out of scope of this document. Likewise, service continuity questions are out of scope of the IETF. > Unfortunately, you do not seem to have created sufficient interest > in the 3GPP community for anyone to start a related work item. That > implies to me that there is not yet consensus behind getting this > right as a capability. I'd disagree with this. My understanding is that there is interest, and a general expectation that the work will start shortly, and that the CEN document lays out the direction, but that there are details to be worked out regarding progressing the work. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- 1. People to whom you are attracted invariably think you remind them of someone else. 2. The love letter you finally got the courage to send will be delayed in the mail long enough for you to make a fool of yourself in person. From nobody Thu Mar 5 02:35:07 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C11C1A0A6A for ; Thu, 5 Mar 2015 02:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 9q38lS1GK239 for ; Thu, 5 Mar 2015 02:35:03 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FCE81A88F9 for ; Thu, 5 Mar 2015 02:35:03 -0800 (PST) Received: from [192.168.131.142] ([80.92.121.102]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LkOaJ-1Xt2lt0anT-00cMvO; Thu, 05 Mar 2015 11:34:58 +0100 Message-ID: <54F83150.7010805@gmx.net> Date: Thu, 05 Mar 2015 11:34:56 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Dan Banks , "ecrit@ietf.org" References: In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0kPWGc7e1aTBeIvad5QnTiVcfK9Qt9x6A" X-Provags-ID: V03:K0:EOHo0mbQjY+t8+ZIcuPx0oEOjBwolP4hPMNOydkTeCPEef7y2zX dnI7MkBFcKw11fvuom/licJflgAUcwTldXuC7UqXQzvvtbUtDmmGuonW1IJIbnaKpcAsatJ q7a/TzDFfZh9H/vrCHPi9LDZee/MOO6Gya8djOky0eE+IQNU5e2X5QO3z5ROL9tDBWinTWM jQG94u92n+Q9FCE2CVmXw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [Ecrit] Comments re: draft-ietf-additional-data-28 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 10:35:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0kPWGc7e1aTBeIvad5QnTiVcfK9Qt9x6A Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Dan, thanks for this very good review. On 03/02/2015 05:42 PM, Dan Banks wrote: > While working through draft-ietf-additional-data-28, I noted a few issu= es: >=20 > =20 >=20 > 1) >=20 > The text states in section 4.1.6 that the element in > ProviderInfo uses ISO 639-1:2002 codes, which seems appropriate.=20 > However, the schema (section 7.1) uses the name =93iso3166a2=94 as the = type > name. It would be better if the type name in the schema reflected the > actual standard uses for the element. Additionally, the type definitio= n > indicates uppercase letters (which is typical for ISO 3166 codes), but > it is recommended that language codes be expressed in lower case (see > http://www.loc.gov/standards/iso639-2/faq.html#21). >=20 > =20 >=20 > I suggest that the schema be updated by renaming the =93iso3166a2=94 ty= pe > and changing the pattern to lowercase, and that all examples be updated= > accordingly. >=20 Good catch. I believe I have two choices: Option #1: I could now reference ISO.3166-1 and adjust the definition of the type in the XML schema to allow both lower case and upper case characters. Option #2: I could instead reference the IANA language tags registry (as defined in [RFC5646]): http://www.iana.org/assignments/language-subtag-registry/language-subtag-= registry I prefer option#2. Would this be OK for you? > =20 >=20 > 2) >=20 > Section 4.2.1 states that the element is =93Option= al > when a 'ServiceType' value is 'wireless'; required otherwise.=94 Howev= er, > the schema in section 7.2 shows the ServiceEnvironment element as > minOccurrs=3D=941=94. >=20 Fixed. > =20 >=20 > 3) >=20 > In section 7.6, the =93provided-by=94 element is defined, but I=92m not= sure > if it is correct the way it is written since the =93provided-by=94 elem= ent > itself is defined elsewhere for PIDF-LO, and I don=92t believe that the= re > is a use described for a =93provided-by=94 element with the > urn:ietf:params:xml:ns:EmergencyCallData namespace. >=20 The element is defined in [RFC4119] and we use it to convey the additional data structures, as described in Section 5. > =20 >=20 > 4) >=20 > For the XML fragments given as examples in sections 5.2 and 5.3, I thin= k > it would be more clear if the applicable namespaces were spelled out > instead of using prefixes that aren=92t declared in that particular > fragment (but are used for examples elsewhere). >=20 I agree that this makes things clearer. I updated the examples. > =20 >=20 > 5) >=20 > In the example on page 39 (section 6) and other places, the > DataProviderContact element is written in the xCard namespace, which > appears to be incorrect. That element is in the > EmergencyCallData:ProviderInfo namespace in the schema. >=20 >=20 Again a good catch. Fixed. >=20 > 6) >=20 > Looking at the ProviderInfoType definition (section 7.1), it appears > that the DataProviderContact element is required, but can be empty.=20 > Section 4.1.7, however, states that the use of the element is optional.= =20 > Am I interpreting the schema correctly, and is that the intended defini= tion? >=20 > =20 Declared DataProviderContact as optional in the XML. I noticed that the data provider contact is optional itself and so I explicitly declared the structure as Thanks again for your detailed review. Ciao Hannes >=20 > Dan Banks >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 --0kPWGc7e1aTBeIvad5QnTiVcfK9Qt9x6A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJU+DFQAAoJEGhJURNOOiAt4YwIAJZ9GcYnKHnvvDRfmY8qSCV6 0gKF1GpvA8HxziDbfnbrgnWpJZyDyVYtdgHKmmPrG6sHmlOJ0kFDqlB1IvocvgGT hDZslNbP0RCDw0ZEV5sKshFK+FIlRAy2iKz2FvO4Sp+aP2AJBQALwMdbY0bts+/a Lq+tAfe9RErMNmRyiVFHL1ygWtmi8qxpl0Q31vH+D25RuFMm/z3a5i05A+wFEiP7 U+Nkihi0l3cpA4L+ThjtjmgpwrFvWovT9+nToYFbFSzIiNFHylSWl3moyAnt9/+5 4z9l//4JdgRRnJjjwlwyF5BSEfPWMbSJIqsUfcmlxHWjDzGgYCuClTbmQAP08fQ= =aCsA -----END PGP SIGNATURE----- --0kPWGc7e1aTBeIvad5QnTiVcfK9Qt9x6A-- From nobody Thu Mar 5 03:15:38 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9189C1B2BC1 for ; Thu, 5 Mar 2015 03:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 o5GmCCGoZ6WC for ; Thu, 5 Mar 2015 03:15:34 -0800 (PST) Received: from bin-vsp-out-05.atm.binero.net (vsp-unauthed01.binero.net [195.74.38.225]) (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 683321A87F1 for ; Thu, 5 Mar 2015 03:15:21 -0800 (PST) X-Halon-ID: e87bcd8a-c328-11e4-a4af-005056916f53 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.42] (unknown [77.53.231.174]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Thu, 5 Mar 2015 12:15:19 +0100 (CET) Message-ID: <54F83AC2.3000901@omnitor.se> Date: Thu, 05 Mar 2015 12:15:14 +0100 From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Hannes Tschofenig , Dan Banks , "ecrit@ietf.org" References: <54F83150.7010805@gmx.net> In-Reply-To: <54F83150.7010805@gmx.net> Content-Type: multipart/alternative; boundary="------------010805020808090209040007" Archived-At: Subject: Re: [Ecrit] Comments re: draft-ietf-additional-data-28 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 11:15:37 -0000 This is a multi-part message in MIME format. --------------010805020808090209040007 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit For 1) the language tags, I agree that option #2 seems to be the proper one to use. Regards /Gunnar Hannes Tschofenig skrev den 2015-03-05 11:34: > Hi Dan, > > thanks for this very good review. > > On 03/02/2015 05:42 PM, Dan Banks wrote: >> While working through draft-ietf-additional-data-28, I noted a few issues: >> >> >> >> 1) >> >> The text states in section 4.1.6 that the element in >> ProviderInfo uses ISO 639-1:2002 codes, which seems appropriate. >> However, the schema (section 7.1) uses the name “iso3166a2” as the type >> name. It would be better if the type name in the schema reflected the >> actual standard uses for the element. Additionally, the type definition >> indicates uppercase letters (which is typical for ISO 3166 codes), but >> it is recommended that language codes be expressed in lower case (see >> http://www.loc.gov/standards/iso639-2/faq.html#21). >> >> >> >> I suggest that the schema be updated by renaming the “iso3166a2” type >> and changing the pattern to lowercase, and that all examples be updated >> accordingly. >> > Good catch. > > I believe I have two choices: > > Option #1: I could now reference ISO.3166-1 and adjust the definition of > the type in the XML schema to allow both lower case and upper case > characters. > > Option #2: I could instead reference the IANA language tags registry (as > defined in [RFC5646]): > http://www.iana.org/assignments/language-subtag-registry/language-subtag-registry > > I prefer option#2. > > Would this be OK for you? > >> >> >> 2) >> >> Section 4.2.1 states that the element is “Optional >> when a 'ServiceType' value is 'wireless'; required otherwise.” However, >> the schema in section 7.2 shows the ServiceEnvironment element as >> minOccurrs=”1”. >> > Fixed. > >> >> >> 3) >> >> In section 7.6, the “provided-by” element is defined, but I’m not sure >> if it is correct the way it is written since the “provided-by” element >> itself is defined elsewhere for PIDF-LO, and I don’t believe that there >> is a use described for a “provided-by” element with the >> urn:ietf:params:xml:ns:EmergencyCallData namespace. >> > The element is defined in [RFC4119] and we use it to > convey the additional data structures, as described in Section 5. > >> >> >> 4) >> >> For the XML fragments given as examples in sections 5.2 and 5.3, I think >> it would be more clear if the applicable namespaces were spelled out >> instead of using prefixes that aren’t declared in that particular >> fragment (but are used for examples elsewhere). >> > I agree that this makes things clearer. I updated the examples. > >> >> >> 5) >> >> In the example on page 39 (section 6) and other places, the >> DataProviderContact element is written in the xCard namespace, which >> appears to be incorrect. That element is in the >> EmergencyCallData:ProviderInfo namespace in the schema. >> >> > Again a good catch. Fixed. > > >> 6) >> >> Looking at the ProviderInfoType definition (section 7.1), it appears >> that the DataProviderContact element is required, but can be empty. >> Section 4.1.7, however, states that the use of the element is optional. >> Am I interpreting the schema correctly, and is that the intended definition? >> >> > Declared DataProviderContact as optional in the XML. > > minOccurs="0" maxOccurs="1"> > > > maxOccurs="unbounded" ref="xc:vcard"/> > > > > > I noticed that the data provider contact is optional itself and so I > explicitly declared the structure as > > name="EmergencyCallData.ProviderInfo" > type="pi:ProviderInfoType" > minOccurs="0" maxOccurs="1"/> > > Thanks again for your detailed review. > > Ciao > Hannes > >> Dan Banks >> >> >> >> _______________________________________________ >> 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 -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------010805020808090209040007 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit For 1) the language tags, I agree that option #2 seems to be the proper one to use.

Regards
/Gunnar

Hannes Tschofenig skrev den 2015-03-05 11:34:
Hi Dan,

thanks for this very good review.

On 03/02/2015 05:42 PM, Dan Banks wrote:

While working through draft-ietf-additional-data-28, I noted a few issues:

 

1)

The text states in section 4.1.6 that the <language> element in
ProviderInfo uses ISO 639-1:2002 codes, which seems appropriate. 
However, the schema (section 7.1) uses the name “iso3166a2” as the type
name.  It would be better if the type name in the schema reflected the
actual standard uses for the element.  Additionally, the type definition
indicates uppercase letters (which is typical for ISO 3166 codes), but
it is recommended that language codes be expressed in lower case (see
http://www.loc.gov/standards/iso639-2/faq.html#21).

 

I suggest that the schema be updated by renaming the “iso3166a2” type
and changing the pattern to lowercase, and that all examples be updated
accordingly.


Good catch.

I believe I have two choices:

Option #1: I could now reference ISO.3166-1 and adjust the definition of
the type in the XML schema to allow both lower case and upper case
characters.

Option #2: I could instead reference the IANA language tags registry (as
defined in [RFC5646]):
http://www.iana.org/assignments/language-subtag-registry/language-subtag-registry

I prefer option#2.

Would this be OK for you?


 

2)

Section 4.2.1 states that the <ServiceEnvironment> element is “Optional
when a 'ServiceType' value is 'wireless'; required otherwise.”  However,
the schema in section 7.2 shows the ServiceEnvironment element as
minOccurrs=”1”.


Fixed.


 

3)

In section 7.6, the “provided-by” element is defined, but I’m not sure
if it is correct the way it is written since the “provided-by” element
itself is defined elsewhere for PIDF-LO, and I don’t believe that there
is a use described for a “provided-by” element with the
urn:ietf:params:xml:ns:EmergencyCallData namespace.


The <provided-by> element is defined in [RFC4119] and we use it to
convey the additional data structures, as described in Section 5.


 

4)

For the XML fragments given as examples in sections 5.2 and 5.3, I think
it would be more clear if the applicable namespaces were spelled out
instead of using prefixes that aren’t declared in that particular
fragment (but are used for examples elsewhere).


I agree that this makes things clearer. I updated the examples.


 

5)

In the example on page 39 (section 6) and other places, the
DataProviderContact element is written in the xCard namespace, which
appears to be incorrect.  That element is in the
EmergencyCallData:ProviderInfo namespace in the schema.



Again a good catch. Fixed.



6)

Looking at the ProviderInfoType definition (section 7.1), it appears
that the DataProviderContact element is required, but can be empty. 
Section 4.1.7, however, states that the use of the element is optional. 
Am I interpreting the schema correctly, and is that the intended definition?

 

Declared DataProviderContact as optional in the XML.

 <xs:element name="DataProviderContact"
                    minOccurs="0" maxOccurs="1">
                  <xs:complexType>
                     <xs:sequence>
                       <xs:element minOccurs="0"
                           maxOccurs="unbounded" ref="xc:vcard"/>
                     </xs:sequence>
                  </xs:complexType>
                </xs:element>

I noticed that the data provider contact is optional itself and so I
explicitly declared the structure as

  <xs:element
        name="EmergencyCallData.ProviderInfo"
        type="pi:ProviderInfoType"
        minOccurs="0" maxOccurs="1"/>

Thanks again for your detailed review.

Ciao
Hannes


Dan Banks



_______________________________________________
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


    

    

    
-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288

  


--------------010805020808090209040007--


From nobody Thu Mar  5 12:50:27 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE7AE1A8AD9 for ; Thu,  5 Mar 2015 12:50:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.601
X-Spam-Level: 
X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 kmanSrlTtD7F for ; Thu,  5 Mar 2015 12:50:20 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0053.outbound.protection.outlook.com [65.55.169.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32F361A8AC5 for ; Thu,  5 Mar 2015 12:50:19 -0800 (PST)
Received: from DM2PR0701MB1309.namprd07.prod.outlook.com (25.161.225.23) by DM2PR0701MB1263.namprd07.prod.outlook.com (25.161.225.13) with Microsoft SMTP Server (TLS) id 15.1.106.15; Thu, 5 Mar 2015 20:50:17 +0000
Received: from DM2PR0701MB1311.namprd07.prod.outlook.com (25.161.225.25) by DM2PR0701MB1309.namprd07.prod.outlook.com (25.161.225.23) with Microsoft SMTP Server (TLS) id 15.1.106.15; Thu, 5 Mar 2015 20:50:15 +0000
Received: from DM2PR0701MB1311.namprd07.prod.outlook.com ([25.161.225.25]) by DM2PR0701MB1311.namprd07.prod.outlook.com ([25.161.225.25]) with mapi id 15.01.0106.007; Thu, 5 Mar 2015 20:50:15 +0000
From: Dan Banks 
To: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= , "Hannes Tschofenig" , "ecrit@ietf.org" 
Thread-Topic: [Ecrit] Comments re: draft-ietf-additional-data-28
Thread-Index: AdBVAgOel91qtnpkTouCc8kTpj7cnwCLgIcAAAFoTwAAE/psgA==
Date: Thu, 5 Mar 2015 20:50:14 +0000
Message-ID: 
References:  <54F83150.7010805@gmx.net> <54F83AC2.3000901@omnitor.se>
In-Reply-To: <54F83AC2.3000901@omnitor.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [4.53.197.18]
authentication-results: omnitor.se; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0701MB1309; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0701MB1263; 
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(51444003)(43784003)(24454002)(377454003)(377424004)(124975003)(479174004)(19617315012)(77156002)(15975445007)(46102003)(122556002)(107886001)(99286002)(62966003)(19580405001)(2950100001)(33656002)(2656002)(19625215002)(66066001)(92566002)(86362001)(16236675004)(76576001)(230783001)(2900100001)(40100003)(19580395003)(87936001)(102836002)(54356999)(2501003)(76176999)(19300405004)(50986999)(74316001)(80792004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0701MB1309; H:DM2PR0701MB1311.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002007)(5005006); SRVR:DM2PR0701MB1309; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0701MB1309; 
x-forefront-prvs: 05066DEDBB
Content-Type: multipart/alternative; boundary="_000_DM2PR0701MB131187838759F51CFCE843FDA71F0DM2PR0701MB1311_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2015 20:50:14.4549 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4c0f48ba-5f29-44b1-b29c-1aff8251101b
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0701MB1309
X-OriginatorOrg: ddti.net
Archived-At: 
Subject: Re: [Ecrit] Comments re: draft-ietf-additional-data-28
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 Mar 2015 20:50:24 -0000

--_000_DM2PR0701MB131187838759F51CFCE843FDA71F0DM2PR0701MB1311_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I agree, I think that option #2 is best.

Dan

From: Gunnar Hellstr=F6m [mailto:gunnar.hellstrom@omnitor.se]
Sent: Thursday, March 05, 2015 6:15 AM
To: Hannes Tschofenig; Dan Banks; ecrit@ietf.org
Subject: Re: [Ecrit] Comments re: draft-ietf-additional-data-28

For 1) the language tags, I agree that option #2 seems to be the proper one=
 to use.

Regards
/Gunnar
Hannes Tschofenig skrev den 2015-03-05 11:34:

Hi Dan,



thanks for this very good review.



On 03/02/2015 05:42 PM, Dan Banks wrote:

While working through draft-ietf-additional-data-28, I noted a few issues:







1)



The text states in section 4.1.6 that the  element in

ProviderInfo uses ISO 639-1:2002 codes, which seems appropriate.

However, the schema (section 7.1) uses the name "iso3166a2" as the type

name.  It would be better if the type name in the schema reflected the

actual standard uses for the element.  Additionally, the type definition

indicates uppercase letters (which is typical for ISO 3166 codes), but

it is recommended that language codes be expressed in lower case (see

http://www.loc.gov/standards/iso639-2/faq.html#21).







I suggest that the schema be updated by renaming the "iso3166a2" type

and changing the pattern to lowercase, and that all examples be updated

accordingly.





Good catch.



I believe I have two choices:



Option #1: I could now reference ISO.3166-1 and adjust the definition of

the type in the XML schema to allow both lower case and upper case

characters.



Option #2: I could instead reference the IANA language tags registry (as

defined in [RFC5646]):

http://www.iana.org/assignments/language-subtag-registry/language-subtag-re=
gistry



I prefer option#2.



Would this be OK for you?







2)



Section 4.2.1 states that the  element is "Optional

when a 'ServiceType' value is 'wireless'; required otherwise."  However,

the schema in section 7.2 shows the ServiceEnvironment element as

minOccurrs=3D"1".





Fixed.







3)



In section 7.6, the "provided-by" element is defined, but I'm not sure

if it is correct the way it is written since the "provided-by" element

itself is defined elsewhere for PIDF-LO, and I don't believe that there

is a use described for a "provided-by" element with the

urn:ietf:params:xml:ns:EmergencyCallData namespace.



The  element is defined in [RFC4119] and we use it to

convey the additional data structures, as described in Section 5.







4)



For the XML fragments given as examples in sections 5.2 and 5.3, I think

it would be more clear if the applicable namespaces were spelled out

instead of using prefixes that aren't declared in that particular

fragment (but are used for examples elsewhere).





I agree that this makes things clearer. I updated the examples.







5)



In the example on page 39 (section 6) and other places, the

DataProviderContact element is written in the xCard namespace, which

appears to be incorrect.  That element is in the

EmergencyCallData:ProviderInfo namespace in the schema.





Again a good catch. Fixed.







6)



Looking at the ProviderInfoType definition (section 7.1), it appears

that the DataProviderContact element is required, but can be empty.

Section 4.1.7, however, states that the use of the element is optional.

Am I interpreting the schema correctly, and is that the intended definition=
?





Declared DataProviderContact as optional in the XML.



 

                  

                     

                       

                     

                  

                



I noticed that the data provider contact is optional itself and so I

explicitly declared the structure as



  



Thanks again for your detailed review.



Ciao

Hannes





Dan Banks







_______________________________________________

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



--

-----------------------------------------

Gunnar Hellstr=F6m

Omnitor

gunnar.hellstrom@omnitor.se

+46 708 204 288

--_000_DM2PR0701MB131187838759F51CFCE843FDA71F0DM2PR0701MB1311_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











I agree, I think that opt=
ion #2 is best.


 <=
/p>

Dan


 <=
/p>





From: Gunnar Hellstr=F6m [mailto:gunnar.hellstrom@omnit=
or.se]


Sent: Thursday, March 05, 2015 6:15 AM

To: Hannes Tschofenig; Dan Banks; ecrit@ietf.org

Subject: Re: [Ecrit] Comments re: draft-ietf-additional-data-28=







 


For 1) the language t=
ags, I agree that option #2 seems to be the proper one to use.



Regards

/Gunnar




Hannes Tschofenig skrev den 2015-03-05 11:34:






Hi Dan,


 


thanks for this very good review.


 


On 03/02/2015 05:42 PM, Dan Banks wrote:




While working through draft-ietf-additional-data-28, I noted a few iss=
ues:


 


 


 


1)


 


The text states in section 4.1.6 that the <language> element in<=
o:p>


ProviderInfo uses ISO 639-1:2002 codes, which seems appropriate. =



However, the schema (section 7.1) uses the name “iso3166a2”=
; as the type


name.  It would be better if the type name in the schema reflecte=
d the


actual standard uses for the element.  Additionally, the type def=
inition


indicates uppercase letters (which is typical for ISO 3166 codes), but=



it is recommended that language codes be expressed in lower case (see<=
o:p>


http://w=
ww.loc.gov/standards/iso639-2/faq.html#21).


 


 


 


I suggest that the schema be updated by renaming the “iso3166a2&=
#8221; type


and changing the pattern to lowercase, and that all examples be update=
d


accordingly.


 




 


Good catch.


 


I believe I have two choices:


 


Option #1: I could now reference ISO.3166-1 and adjust the definition =
of


the type in the XML schema to allow both lower case and upper case


characters.


 


Option #2: I could instead reference the IANA language tags registry (=
as


defined in [RFC5646]):


http://www.iana.org/assignments/language-subtag-reg=
istry/language-subtag-registry


 


I prefer option#2.


 


Would this be OK for you?


 




 


 


2)


 


Section 4.2.1 states that the <ServiceEnvironment> element is &#=
8220;Optional


when a 'ServiceType' value is 'wireless'; required otherwise.”&n=
bsp; However,


the schema in section 7.2 shows the ServiceEnvironment element as=



minOccurrs=3D”1”.


 




 


Fixed.


 




 


 


3)


 


In section 7.6, the “provided-by” element is defined, but =
I’m not sure


if it is correct the way it is written since the “provided-by=
221; element


itself is defined elsewhere for PIDF-LO, and I don’t believe tha=
t there


is a use described for a “provided-by” element with the


urn:ietf:params:xml:ns:EmergencyCallData namespace.


 




The <provided-by> element is defined in [RFC4119] and we use it =
to


convey the additional data structures, as described in Section 5.=



 




 


 


4)


 


For the XML fragments given as examples in sections 5.2 and 5.3, I thi=
nk


it would be more clear if the applicable namespaces were spelled out


instead of using prefixes that aren’t declared in that particula=
r


fragment (but are used for examples elsewhere).


 




 


I agree that this makes things clearer. I updated the examples.


 




 


 


5)


 


In the example on page 39 (section 6) and other places, the=



DataProviderContact element is written in the xCard namespace, which


appears to be incorrect.  That element is in the


EmergencyCallData:ProviderInfo namespace in the schema.

 


 




Again a good catch. Fixed.


 


 




 


6)


 


Looking at the ProviderInfoType definition (section 7.1), it appears


that the DataProviderContact element is required, but can be empty. 


Section 4.1.7, however, states that the use of the element is optional=
. 


Am I interpreting the schema correctly, and is that the intended defin=
ition?


 


 




Declared DataProviderContact as optional in the XML.


 


 <xs:element name=3D"DataProviderContact"

           &nbs=
p;        minOccurs=3D"0" maxO=
ccurs=3D"1">


           &nbs=
p;      <xs:complexType>


           &nbs=
p;         <xs:sequence>=



           &nbs=
p;           <xs:eleme=
nt minOccurs=3D"0"


           &nbs=
p;            &=
nbsp;  maxOccurs=3D"unbounded" ref=3D"xc:vcard"/&g=
t;


           &nbs=
p;         </xs:sequence>


           &nbs=
p;      </xs:complexType>


           &nbs=
p;    </xs:element>


 


I noticed that the data provider contact is optional itself and so I


explicitly declared the structure as


 


  <xs:element


        name=3D"EmergencyCallD=
ata.ProviderInfo"


        type=3D"pi:ProviderInf=
oType"


        minOccurs=3D"0" m=
axOccurs=3D"1"/>


 


Thanks again for your detailed review.


 


Ciao


Hannes


 




 


Dan Banks


 


 


 


_______________________________________________


Ecrit mailing list


Ecrit@ietf.org


https://www.ie=
tf.org/mailman/listinfo/ecrit


 




 











_______________________________________________


Ecrit mailing list


Ecrit@ietf.org


https://www.ie=
tf.org/mailman/listinfo/ecrit











-- 


-----------------------------------------


Gunnar Hellstr=F6m


Omnitor


gunnar.hellstrom@omnito=
r.se


+46 708 204 288






--_000_DM2PR0701MB131187838759F51CFCE843FDA71F0DM2PR0701MB1311_--


From nobody Fri Mar  6 16:24:18 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415731A876C for ; Fri,  6 Mar 2015 16:24:17 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level: 
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 ubNgQa7-DJuQ for ; Fri,  6 Mar 2015 16:24:15 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E75C31A873E for ; Fri,  6 Mar 2015 16:24:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1425687856; x=1457223856; h=message-id:in-reply-to:references:date:to:from:subject; bh=C4itA8LA/BWJvkWM72rwDMu4xRkRwh4gznGuX6UWQ3M=; b=BtXtoInl7no5vug/0vOHuofOqG0RPyUuz/SA/EgeAgI/J1LWN3KXOUxL OqE+2a+zadL96tfr/QB+WhIdtLhDYT2iUhvPNfz1zIrlLW7atJd0+Y0Cu 4EYOS1YdGwnrFw5FOLRTafpwqOSwF+O9Z6lR4R0egH4QHlBW7RTk+nPAM Q=;
X-IronPort-AV: E=McAfee;i="5600,1067,7732"; a="198813227"
Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Mar 2015 16:24:16 -0800
X-IronPort-AV: E=Sophos;i="5.11,355,1422950400"; d="scan'208";a="855720965"
Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Mar 2015 16:24:14 -0800
Received: from Ironmsg03-L.qualcomm.com (ironmsg03-L.qualcomm.com [172.30.48.18]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t270ODsm001848; Fri, 6 Mar 2015 16:24:13 -0800
X-IronPort-AV: E=Sophos;i="5.11,355,1422950400"; d="scan'208";a="855720934"
X-ojodefuego: yes
Received: from unknown (HELO [99.111.97.136]) ([10.64.166.151]) by Ironmsg03-L.qualcomm.com with ESMTP; 06 Mar 2015 16:24:11 -0800
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <54F83150.7010805@gmx.net>
References:  <54F83150.7010805@gmx.net>
X-Mailer: Eudora for Mac OS X
Date: Fri, 6 Mar 2015 16:24:10 -0800
To: Hannes Tschofenig , Dan Banks , "ecrit@ietf.org" 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Subject: Re: [Ecrit] Comments re: draft-ietf-additional-data-28
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 07 Mar 2015 00:24:17 -0000

At 11:34 AM +0100 3/5/15, Hannes Tschofenig wrote:

>  Option #2: I could instead reference the IANA language tags registry (as
>  defined in [RFC5646]):
> 
> http://www.iana.org/assignments/language-subtag-registry/language-subtag-registry

This seems the best choice.  As an example, 
draft-gellens-slim-negotiating-human-language uses the wording "a 
single [RFC3066] language tag in US-ASCII [RFC3066]".



-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Change is inevitable, except from a vending machine.


From nobody Sat Mar  7 20:38:08 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25AB1A1B47; Sat,  7 Mar 2015 20:38:06 -0800 (PST)
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] autolearn=ham
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 qa0cg3NkZwk6; Sat,  7 Mar 2015 20:38:05 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC231A1B3E; Sat,  7 Mar 2015 20:38:05 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.12.0.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150308043805.16640.12526.idtracker@ietfa.amsl.com>
Date: Sat, 07 Mar 2015 20:38:05 -0800
Archived-At: 
Cc: ecrit@ietf.org
Subject: [Ecrit] I-D Action: draft-ietf-ecrit-held-routing-01.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 08 Mar 2015 04:38:07 -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 Working Group of the IETF.

        Title           : A Routing Request Extension for the HELD Protocol
        Authors         : James Winterbottom
                          Hannes Tschofenig
                          Laura Liess
	Filename        : draft-ietf-ecrit-held-routing-01.txt
	Pages           : 13
	Date            : 2015-03-07

Abstract:
   In many circumstances public LoST servers or a distributed network of
   forest guides linking public LoST servers is not available.  The
   general ECRIT calling models breakdown without publically accessible
   LoST servers.  Sometimes location servers may have access to
   emergency routing information.  This document defines an extension to
   the HELD protocol so a location request can include a request for
   routing information and allowing the subsequent location response to
   include routing information.


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ecrit-held-routing-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-held-routing-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From nobody Sat Mar  7 20:41:21 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053F01A1B61 for ; Sat,  7 Mar 2015 20:41:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 oK1J8jIfWNBb for ; Sat,  7 Mar 2015 20:41:14 -0800 (PST)
Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (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 D3BC81A1B60 for ; Sat,  7 Mar 2015 20:41:13 -0800 (PST)
Received: by pdev10 with SMTP id v10so39640417pde.0 for ; Sat, 07 Mar 2015 20:41:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=a1yWMOteQL7ea4kEJrL68kBjb/7Rp/ADZpztaeieUVw=; b=kcq3cueI3g6DJI9+S71Y5G3mfHqbqTJrC0oyLcpWXQOqmNwW8z0fL7le4CcGZyznR6 yhaNs91Vif9ijusfh+AC6XCL1ymzkgwtgKDW9N6JVHI/FGCb2yfWdH3CoD4CHsiU01SS xxZmg+81F1871F9enLMLOW/w79QhX9xZPdqb11uSdm8/c5jJ5nLCN1QbubbPHRJJmxqS kYIfXIw0F3fO92MoPwwkdPPY4kwBo50RPt2leekJGLw1qb5Xjh3m/FlAC/XugBOp6mxA WwtFWaxs7N/bI/4T8GzyLk4VqNa8+mBKi6FxH57RUGwH1K0bYwdXI4tYe7hX5dLzC/Ld VjjQ==
X-Received: by 10.70.133.197 with SMTP id pe5mr39717131pdb.64.1425789673483; Sat, 07 Mar 2015 20:41:13 -0800 (PST)
Received: from [192.168.1.100] ([101.170.247.151]) by mx.google.com with ESMTPSA id zz7sm13724242pbc.28.2015.03.07.20.41.11 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Mar 2015 20:41:12 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: James Winterbottom 
In-Reply-To: <20150308043805.16640.12526.idtracker@ietfa.amsl.com>
Date: Sun, 8 Mar 2015 15:41:07 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E9C9DD0-E952-4CE0-9F4C-611629B18A25@gmail.com>
References: <20150308043805.16640.12526.idtracker@ietfa.amsl.com>
To: "ecrit_ietf.org" 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-held-routing-01.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 08 Mar 2015 04:41:19 -0000

Hi All,

A few changes.
Took on board Randall=E2=80=99s suggesting to only return stuff for a =
single service URN and to allow the requestor to specify a service URN =
if they want, but the default is always und:service:sos.

Applied the changes I said I would do then I responded to Roger=E2=80=99s =
comments.


Cheers
James



> On 8 Mar 2015, at 3:38 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 Working Group of the IETF.
>=20
>        Title           : A Routing Request Extension for the HELD =
Protocol
>        Authors         : James Winterbottom
>                          Hannes Tschofenig
>                          Laura Liess
> 	Filename        : draft-ietf-ecrit-held-routing-01.txt
> 	Pages           : 13
> 	Date            : 2015-03-07
>=20
> Abstract:
>   In many circumstances public LoST servers or a distributed network =
of
>   forest guides linking public LoST servers is not available.  The
>   general ECRIT calling models breakdown without publically accessible
>   LoST servers.  Sometimes location servers may have access to
>   emergency routing information.  This document defines an extension =
to
>   the HELD protocol so a location request can include a request for
>   routing information and allowing the subsequent location response to
>   include routing information.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ecrit-held-routing/
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-ecrit-held-routing-01
>=20
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-held-routing-01
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit


From nobody Sun Mar  8 16:28:33 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C84B1A0275; Sun,  8 Mar 2015 16:28:29 -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] autolearn=ham
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 9cIeaN90_z9y; Sun,  8 Mar 2015 16:28:27 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DECB1A0222; Sun,  8 Mar 2015 16:28:27 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.12.0.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150308232827.6397.30116.idtracker@ietfa.amsl.com>
Date: Sun, 08 Mar 2015 16:28:27 -0700
Archived-At: 
Cc: ecrit@ietf.org
Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-29.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 08 Mar 2015 23:28:29 -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 Working Group of the IETF.

        Title           : Additional Data Related to an Emergency Call
        Authors         : Randall Gellens
                          Brian Rosen
                          Hannes Tschofenig
                          Roger Marshall
                          James Winterbottom
	Filename        : draft-ietf-ecrit-additional-data-29.txt
	Pages           : 107
	Date            : 2015-03-08

Abstract:
   When an emergency call is sent to a Public Safety Answering Point
   (PSAP), the device that sends it, as well as any application service
   provider in the path of the call, or access network provider through
   which the call originated may have information about the call, the
   caller or the location which the PSAP may be able to use.  This
   document describes data structures and a mechanism to convey such
   data to the PSAP.  The mechanism uses a Uniform Resource Identifier
   (URI), which may point to either an external resource or an object in
   the body of the SIP message.  The mechanism thus allows the data to
   be passed by reference (when the URI points to an external resource)
   or by value (when it points into the body of the message).  This
   follows the tradition of prior emergency services standardization
   work where data can be conveyed by value within the call signaling
   (i.e., in body of the SIP message) and also by reference.


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-29

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-additional-data-29


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From nobody Sun Mar  8 16:28:35 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311A31A0275; Sun,  8 Mar 2015 16:28:30 -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] autolearn=ham
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 5iEMHXslaqne; Sun,  8 Mar 2015 16:28:29 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BCE1A0235; Sun,  8 Mar 2015 16:28:27 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: , , , , , "Marc Linsner" , 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.12.0.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150308232827.6397.25964.idtracker@ietfa.amsl.com>
Date: Sun, 08 Mar 2015 16:28:27 -0700
Archived-At: 
Subject: [Ecrit] New Version Notification - draft-ietf-ecrit-additional-data-29.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 08 Mar 2015 23:28:30 -0000

A new version (-29) has been submitted for draft-ietf-ecrit-additional-data:
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-additional-data-29.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-additional-data-29

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.


From nobody Sun Mar  8 16:35:55 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC371A0275 for ; Sun,  8 Mar 2015 16:35:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.514
X-Spam-Level: *
X-Spam-Status: No, score=1.514 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 ED7sFsRqrCv1 for ; Sun,  8 Mar 2015 16:35:52 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 736581A0282 for ; Sun,  8 Mar 2015 16:35:46 -0700 (PDT)
Received: from [217.140.96.140] by 3capp-gmx-bs34.server.lan (via HTTP); Mon, 9 Mar 2015 00:35:44 +0100
MIME-Version: 1.0
Message-ID: 
From: "Hannes Tschofenig" 
To: ecrit@ietf.org
Content-Type: text/html; charset=UTF-8
Date: Mon, 9 Mar 2015 00:35:44 +0100
Importance: normal
Sensitivity: Normal
X-Priority: 3
X-Provags-ID: V03:K0:x03QUGl7OLOHfCz3yYYLdrL4wJz0fHkAQS50IhZGM4a nxsABIuazmK5cFYwNmLRtBDUdbD0/RNzIy0oDzeAAW72RdAadM pImz5QIAwJzVG7o7mq/n1wE9GlBrSOEJkeyhxxJrTpiX0KdK6n P6gc1YdUKRpO5bb1EUVI21e+DeX4pCYxAolfHr5qeGnk4yivTr adavHHFwIt4vymF72f9ur5L4MOjhqtavFnHxwPNJ3RSt8N9iq2 JFETXSgisfXdvJ26fw6xMk+5x4ObqbjmCuu5Fvzti7gTCe8wWh d+ri/M=
X-UI-Out-Filterresults: notjunk:1;
Archived-At: 
Subject: [Ecrit] draft-ietf-ecrit-additional-data-29.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 08 Mar 2015 23:35:53 -0000


Version -29 of the additional data draft addresses comments raised by Dan Banks in his review (see http://www.ietf.org/mail-archive/web/ecrit/current/msg09020.html). 



 



Ciao



Hannes



 



From nobody Sun Mar  8 18:05:24 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D9C1A008B; Sun,  8 Mar 2015 18:05:20 -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] autolearn=ham
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 CK5p_9TLWFp9; Sun,  8 Mar 2015 18:05:18 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3A51A0064; Sun,  8 Mar 2015 18:05:18 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.12.0.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150309010518.11202.22367.idtracker@ietfa.amsl.com>
Date: Sun, 08 Mar 2015 18:05:18 -0700
Archived-At: 
Cc: ecrit@ietf.org
Subject: [Ecrit] I-D Action: draft-ietf-ecrit-ecall-02.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Mar 2015 01:05:20 -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 Working Group of the IETF.

        Title           : Next-Generation Pan-European eCall
        Authors         : Randall Gellens
                          Hannes Tschofenig
	Filename        : draft-ietf-ecrit-ecall-02.txt
	Pages           : 34
	Date            : 2015-03-08

Abstract:
   This document describes how to use IP-based emergency services
   mechanisms to support the next generation of the Pan European in-
   vehicle emergency call service defined under the eSafety initiative
   of the European Commission (generally referred to as "eCall"). eCall
   is a standardized and mandated system for a special form of emergency
   calls placed by vehicles.  eCall deployment is required in the very
   near future in European Union member states, and eCall (and eCall-
   compatible systems) are also being deployed in other regions.  eCall
   provides an integrated voice path and a standardized set of vehicle,
   sensor (e.g., crash related), and location data.  An eCall is
   recognized and handled as a specialized form of emergency call and is
   routed to a specialized eCall-capable Public Safety Answering Point
   (PSAP) capable of processing the vehicle data and trained in handling
   emergency calls from vehicles.

   Currently, eCall functions over circuit-switched cellular telephony;
   work on next-generation eCall (NG-eCall, sometimes called packet-
   switched eCall or PS-eCall) is now in process, and this document
   assists in that work by describing how to support eCall within the
   IP-based emergency services infrastructure.

   This document also registers a MIME Content Type and an Emergency
   Call Additional Data Block for the eCall vehicle data.


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ecrit-ecall-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-ecall-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From nobody Sun Mar  8 18:05:30 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E7C1A00A2; Sun,  8 Mar 2015 18:05:23 -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] autolearn=ham
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 2Dq_NsvVBSCA; Sun,  8 Mar 2015 18:05:21 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E98881A0074; Sun,  8 Mar 2015 18:05:21 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.12.0.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150309010521.18590.69064.idtracker@ietfa.amsl.com>
Date: Sun, 08 Mar 2015 18:05:21 -0700
Archived-At: 
Cc: ecrit@ietf.org
Subject: [Ecrit] I-D Action: draft-ietf-ecrit-car-crash-02.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Mar 2015 01:05:23 -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 Working Group of the IETF.

        Title           : Next-Generation Vehicle-Initiated Emergency Calls
        Authors         : Randall Gellens
                          Brian Rosen
                          Hannes Tschofenig
	Filename        : draft-ietf-ecrit-car-crash-02.txt
	Pages           : 22
	Date            : 2015-03-08

Abstract:
   This document describes how to use IP-based emergency services
   mechanisms to support the next generation of emergency calls placed
   by vehicles (automatically in the event of a crash or serious
   incident, or manually invoked by a vehicle occupant) and conveying
   vehicle, sensor, and location data related to the crash or incident.
   Such calls are often referred to as "Automatic Crash Notification"
   (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the
   case of manual trigger.  The "Advanced" qualifier refers to the
   ability to carry a richer set of data.

   This document also registers a MIME Content Type and an Emergency
   Call Additional Data Block for the vehicle, sensor, and location data
   (often referred to as "crash data" even though there is not
   necessarily a crash).  An external specification for the data format,
   contents, and structure are referenced in this document.

   Profiling and simplifications of the general emergency call
   mechanism, as described in [RFC6443] and [RFC6881], are possible due
   to the nature of the functionality that is provided in vehicles such
   as the usage of Global Satellite Navigation System (GNSS).

   This document reuses the technical aspects of next-generation pan-
   European eCall (a mandated and standardized system for emergency
   calls by in-vehicle systems within Europe and other regions), as
   described in [I-D.ietf-ecrit-ecall].  However, this document
   specifies a different set of vehicle (crash) data, specifically, the
   Vehicle Emergency Data Set (VEDS) rather than the eCall Minimum Set
   of Data (MSD).


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ecrit-car-crash-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-car-crash-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From nobody Mon Mar  9 07:16:03 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4051A8972 for ; Mon,  9 Mar 2015 07:16:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 8ijNnOoVkVQB for ; Mon,  9 Mar 2015 07:15:57 -0700 (PDT)
Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 150361A8997 for ; Mon,  9 Mar 2015 07:15:07 -0700 (PDT)
Received: from SEA-EXCAS-2.telecomsys.com (exc2010-local2.telecomsys.com [10.32.12.187]) by sea-mx-02.telecomsys.com (8.14.7/8.14.7) with ESMTP id t29EF5dk010048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Mar 2015 07:15:06 -0700
Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.115]) by SEA-EXCAS-2.telecomsys.com ([10.32.12.187]) with mapi id 14.03.0195.001; Mon, 9 Mar 2015 07:15:05 -0700
From: Roger Marshall 
To: "ecrit@ietf.org" 
Thread-Topic: IETF92 - ECRIT meeting agenda time
Thread-Index: AdBac0sqOzMmRRe1RvOBrKCZUaO+dg==
Date: Mon, 9 Mar 2015 14:15:04 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.32.12.134]
Content-Type: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC282D9D4FSEAEXMB2telecom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Ecrit] IETF92 - ECRIT meeting agenda time
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Mar 2015 14:16:02 -0000

--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC282D9D4FSEAEXMB2telecom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Please let us know if you want to present your ECRIT related draft(s) at IE=
TF92.

Roger Marshall & Marc Linsner - ECRIT chairs



--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC282D9D4FSEAEXMB2telecom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Please let us know if you want to present your ECRIT related draft(=
s) at IETF92.


Roger Marshall & Marc Linsner – ECRIT chairs


 






--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC282D9D4FSEAEXMB2telecom_--


From nobody Tue Mar 24 13:49:05 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755211A035F for ; Tue, 24 Mar 2015 13:49:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 VDZ4XC66w35Q for ; Tue, 24 Mar 2015 13:49:03 -0700 (PDT)
Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (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 27C601A00FD for ; Tue, 24 Mar 2015 13:49:03 -0700 (PDT)
Received: by padcy3 with SMTP id cy3so4709946pad.3 for ; Tue, 24 Mar 2015 13:49:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=rWTESqBRqoyBUAq1uDURHoHScCqnftJVAwMfkNiwq/I=; b=XK7/MaDyDIPbQbjYkj2g1rmECzUUIRaULb5M2DwALUp0+KlnQpLysERVQsCZiQx4Ed OM3AZ/bG+zurAclqIlhNQZPwT+YZBpp+2kfdwt0w6Xop5AX/p73qSVjx8pV6r7Btfx5D 4vWE/KnOCBr5gQfOjLgqo4CMgZf3tZDcga+sA480zrEkkYL8xF+PDNko9RIE60jSCZn7 Vl2npHNPeYH/dWjH8oFgro/v1g6P8sdOKhIuaNXHQ9vvW/cePKBNbVv3RDqo6R509w/+ qKZ5+fGULdl/MXLn6+rSVlmK0l3CLLB77GAJRzhV9dBY6l0MQxLnvbV4Rc730BzzT55x cyhA==
X-Received: by 10.66.139.135 with SMTP id qy7mr10824063pab.144.1427230142820;  Tue, 24 Mar 2015 13:49:02 -0700 (PDT)
Received: from [192.168.1.100] ([1.129.122.187]) by mx.google.com with ESMTPSA id i10sm228867pdk.53.2015.03.24.13.49.01 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Mar 2015 13:49:02 -0700 (PDT)
From: James Winterbottom 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: 
Date: Wed, 25 Mar 2015 07:48:59 +1100
To: "ecrit_ietf.org" 
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Subject: [Ecrit] Sorry about the presentation
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Mar 2015 20:49:04 -0000

Hi All,

It seems that both primary and fallback options for presenting =
HELD-Routing have broken.
Sorry about that.

I have updated the document with the comments provided I think, and the =
changes are reflected in the slides.


Cheers
James


From nobody Tue Mar 24 13:58:50 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBCE1A0364 for ; Tue, 24 Mar 2015 13:58:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 EnVF3DjBYH_m for ; Tue, 24 Mar 2015 13:58:47 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 E534A1A036F for ; Tue, 24 Mar 2015 13:58:46 -0700 (PDT)
Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.14.7/8.14.7) with SMTP id t2OKvs3e030767; Tue, 24 Mar 2015 16:58:46 -0400
Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 1tbdax86yg-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Mar 2015 16:58:46 -0400
Received: from STNTEXMB13.cis.neustar.com ([169.254.3.204]) by stntexhc10.cis.neustar.com ([169.254.4.213]) with mapi id 14.03.0158.001; Tue, 24 Mar 2015 16:58:44 -0400
From: "Rosen, Brian" 
To: Randall Gellens 
Thread-Topic: Justification for Data-only (and MSRP only) car-crash
Thread-Index: AQHQZnVQvCbx497qpEq09eE2XE6XHw==
Date: Tue, 24 Mar 2015 20:58:44 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [192.168.132.33]
Content-Type: multipart/alternative; boundary="_000_D1373A3297622brianrosenneustarbiz_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=nai engine=5700 definitions=7750 signatures=670576
X-Proofpoint-Spam-Reason: safe
Archived-At: 
Cc: "ecrit@ietf.org" 
Subject: [Ecrit] Justification for Data-only (and MSRP only) car-crash
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Mar 2015 20:58:49 -0000

--_000_D1373A3297622brianrosenneustarbiz_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QWx0aG91Z2ggY3VycmVudCBjYXIgdGVsZW1hdGljcyBzeXN0ZW1zIGFsd2F5cyBoYXZlIGFuIGF1
ZGlvIHBhdGgsIHRoZXJlIGFyZSBzY2VuYXJpb3Mgd2hlcmUgYSBkYXRhLW9ubHkgY2FsbCBpcyBk
ZXNpcmVkLiAgVGhlcmUgYXJlLCBmb3IgZXhhbXBsZSwgdHJ1Y2sgdGVsZW1hdGljcyBzeXN0ZW1z
IHRoYXQgb25seSBzZW5kIGRhdGEuICBUaGVyZSBhcmUgZmFpbHVyZSBzY2VuYXJpb3Mgd2hlcmUg
YW4gYXVkaW8gcGF0aCBjYW7igJl0IGJlIGNyZWF0ZWQuICBUaGVyZSBhcmUgbmV3ZXIsIGxvd2Vy
IGNvc3Qgc3lzdGVtcyB0aGF0IGRvbuKAmXQgaW52b2x2ZSBhIGNhbGwgY2VudGVyLiAgSW4gYWRk
aXRpb24sIHRoZXJlIGNvdWxkIGJlIHRleHQtb25seSBjYWxscywgcmF0aGVyIHRoYW4gYXVkaW8u
DQoNCkkgd291bGQgbGlrZSB0byBzZWUgdGhlc2UgYWxsb3dlZCBpbiAtY2Fy4oCTY3Jhc2guICBE
dWUgdG8gbGltaXRhdGlvbnMgYW5kIGRlc2lnbiBkZWNpc2lvbnMgaW4gM0dQUCwgdGhpcyBjYXBh
YmlsaXR5IGlzIG5vdCBwb3NzaWJsZSBpbiBlY2FsbCwgYW5kIHRodXMgdGhpcyB0ZXh0IHdvdWxk
IGhhdmUgdG8gYmUgc3BlY2lmaWMgdG8gLWNhcuKAk2NyYXNoLg0KDQpCcmlhbg0K

--_000_D1373A3297622brianrosenneustarbiz_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5BbHRob3VnaCBj
dXJyZW50IGNhciB0ZWxlbWF0aWNzIHN5c3RlbXMgYWx3YXlzIGhhdmUgYW4gYXVkaW8gcGF0aCwg
dGhlcmUgYXJlIHNjZW5hcmlvcyB3aGVyZSBhIGRhdGEtb25seSBjYWxsIGlzIGRlc2lyZWQuICZu
YnNwO1RoZXJlIGFyZSwgZm9yIGV4YW1wbGUsIHRydWNrIHRlbGVtYXRpY3Mgc3lzdGVtcyB0aGF0
IG9ubHkgc2VuZCBkYXRhLiAmbmJzcDtUaGVyZSBhcmUgZmFpbHVyZSBzY2VuYXJpb3Mgd2hlcmUg
YW4gYXVkaW8gcGF0aCBjYW7igJl0IGJlIGNyZWF0ZWQuDQogJm5ic3A7VGhlcmUgYXJlIG5ld2Vy
LCBsb3dlciBjb3N0IHN5c3RlbXMgdGhhdCBkb27igJl0IGludm9sdmUgYSBjYWxsIGNlbnRlci4g
Jm5ic3A7SW4gYWRkaXRpb24sIHRoZXJlIGNvdWxkIGJlIHRleHQtb25seSBjYWxscywgcmF0aGVy
IHRoYW4gYXVkaW8uPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIHdvdWxkIGxpa2Ug
dG8gc2VlIHRoZXNlIGFsbG93ZWQgaW4gLWNhcuKAk2NyYXNoLiAmbmJzcDtEdWUgdG8gbGltaXRh
dGlvbnMgYW5kIGRlc2lnbiBkZWNpc2lvbnMgaW4gM0dQUCwgdGhpcyBjYXBhYmlsaXR5IGlzIG5v
dCBwb3NzaWJsZSBpbiBlY2FsbCwgYW5kIHRodXMgdGhpcyB0ZXh0IHdvdWxkIGhhdmUgdG8gYmUg
c3BlY2lmaWMgdG8gLWNhcuKAk2NyYXNoLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+
QnJpYW48L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_D1373A3297622brianrosenneustarbiz_--


From nobody Tue Mar 24 14:02:21 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11D11A908D for ; Tue, 24 Mar 2015 14:02:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level: 
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 OnA2XL8tGBSx for ; Tue, 24 Mar 2015 14:02:09 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 818941A90F6 for ; Tue, 24 Mar 2015 14:01:42 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id AB547641BBD94; Tue, 24 Mar 2015 21:01:36 +0000 (GMT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t2OL1dk4029541 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Mar 2015 22:01:40 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.230]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 24 Mar 2015 22:01:40 +0100
From: "DRAGE, Keith (Keith)" 
To: "Rosen, Brian" , Randall Gellens 
Thread-Topic: Justification for Data-only (and MSRP only) car-crash
Thread-Index: AQHQZnVQvCbx497qpEq09eE2XE6XH50sHhpA
Date: Tue, 24 Mar 2015 21:01:39 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B4A11C0B2@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B4A11C0B2FR712WXCHMBA11z_"
MIME-Version: 1.0
Archived-At: 
Cc: "ecrit@ietf.org" 
Subject: Re: [Ecrit] Justification for Data-only (and MSRP only) car-crash
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Mar 2015 21:02:13 -0000

--_000_949EF20990823C4C85C18D59AA11AD8B4A11C0B2FR712WXCHMBA11z_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

And without a change to 3GPP specifications (starting from 3GPP TS 22.101),=
 would also be precluded from a 3GPP emergency call.

3GPP emergency calls essentially make the provision of a voice media path a=
s mandatory. What you have in addition to that is more flexible, but the PS=
AP expects a voice path to be supported.

Keith

________________________________
From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Rosen, Brian
Sent: 24 March 2015 20:59
To: Randall Gellens
Cc: ecrit@ietf.org
Subject: [Ecrit] Justification for Data-only (and MSRP only) car-crash

Although current car telematics systems always have an audio path, there ar=
e scenarios where a data-only call is desired.  There are, for example, tru=
ck telematics systems that only send data.  There are failure scenarios whe=
re an audio path can't be created.  There are newer, lower cost systems tha=
t don't involve a call center.  In addition, there could be text-only calls=
, rather than audio.

I would like to see these allowed in -car-crash.  Due to limitations and de=
sign decisions in 3GPP, this capability is not possible in ecall, and thus =
this text would have to be specific to -car-crash.

Brian

--_000_949EF20990823C4C85C18D59AA11AD8B4A11C0B2FR712WXCHMBA11z_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









And without a chan=
ge to 3GPP specifications (starting from 3GPP TS 22.101), would also be pre=
cluded from a 3GPP emergency call.


&nbs=
p;


3GPP emergency cal=
ls essentially make the provision of a voice media path as mandatory. What =
you have in addition to that is more flexible, but the PSAP expects a voice=
 path to be supported.


&nbs=
p;


Keith









From: Ecrit [mailto:ecrit-bounces@i=
etf.org] 
On Behalf Of Rosen, Brian

Sent: 24 March 2015 20:59

To: Randall Gellens

Cc: ecrit@ietf.org

Subject: [Ecrit] Justification for Data-only (and MSRP only) car-cra=
sh








Although current car telematics systems always have an audio path, the=
re are scenarios where a data-only call is desired.  There are, for ex=
ample, truck telematics systems that only send data.  There are failur=
e scenarios where an audio path can’t be created.
  There are newer, lower cost systems that don’t involve a call =
center.  In addition, there could be text-only calls, rather than audi=
o.







I would like to see these allowed in -car–crash.  Due to li=
mitations and design decisions in 3GPP, this capability is not possible in =
ecall, and thus this text would have to be specific to -car–crash.






Brian






--_000_949EF20990823C4C85C18D59AA11AD8B4A11C0B2FR712WXCHMBA11z_--


From nobody Tue Mar 24 14:38:57 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F641A1B25 for ; Tue, 24 Mar 2015 14:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 ejbVq8K-J4mo for ; Tue, 24 Mar 2015 14:38:47 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 AB3B21A8AF4 for ; Tue, 24 Mar 2015 14:38:47 -0700 (PDT)
Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.14.7/8.14.7) with SMTP id t2OLXa83012467; Tue, 24 Mar 2015 17:38:46 -0400
Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1tbdax08pq-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Mar 2015 17:38:46 -0400
Received: from STNTEXMB13.cis.neustar.com ([169.254.3.204]) by stntexhc10.cis.neustar.com ([169.254.4.213]) with mapi id 14.03.0158.001; Tue, 24 Mar 2015 17:38:44 -0400
From: "Rosen, Brian" 
To: James Winterbottom 
Thread-Topic: Allowing a full LoST response in the Held Routing response
Thread-Index: AQHQZnrm5/Y5NlQVqU2Az0Xn9N4YKA==
Date: Tue, 24 Mar 2015 21:38:43 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [192.168.132.33]
Content-Type: multipart/alternative; boundary="_000_D137439097674brianrosenneustarbiz_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=nai engine=5700 definitions=7750 signatures=670576
X-Proofpoint-Spam-Reason: safe
Archived-At: 
Cc: "ecrit@ietf.org" 
Subject: [Ecrit] Allowing a full LoST response in the Held Routing response
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Mar 2015 21:38:51 -0000

--_000_D137439097674brianrosenneustarbiz_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QXMgSSBzdGF0ZWQgaW4gSUVURiA5MiwgSSBiZWxpZXZlIHRoZSBJRVRGIHNob3VsZCBhbGxvdyBh
bGwgdGhlIHBvc3NpYmxlIHZhbHVlcyBpbiBhIExvU1QgcmVzcG9uc2UgdG8gYmUgcmV0dXJuZWQg
ZnJvbSBhIEhFTEQgcmVzcG9uc2UgaW4gc2l0dWF0aW9ucyB3aGVyZSBhIHNpbmdsZSBxdWVyeSBp
cyBuZWVkZWQgb3IgZGVzaXJhYmxlLiAgQXMgYW4gZXhhbXBsZSwgdGhlIHNlcnZpY2UgYm91bmRh
cnkgbWF5IGJlIHVzZWZ1bCBmb3IgbW9iaWxlIGRldmljZXMsIHRoZSBzZXJ2aWNlIG51bWJlciBp
cyB2ZXJ5IHVzZWZ1bCwgYW5kDQoNCkkgZnVydGhlciB0YWtlIGV4Y2VwdGlvbiB0byB0aGUgbm90
aW9uIHRoYXQgdGhlIG1hcHBpbmcgcmVzcG9uc2UgaW4gYSByZXN0cmljdGVkIHVzZSBjYXNlIHdv
dWxkIG5lY2Vzc2FyaWx5IGJlIGRpZmZpY3VsdCBvciBpbnZvbHZlIG1pc2xlYWRpbmcgZGF0YS4g
IFRoZSBleGFtcGxlIGdpdmVuIGlzIHRoZSDigJxzb3VyY2XigJ0gcGFyYW1ldGVyLiAgSW4gdGhl
IGNpdGVkIHVzZSBjYXNlLCB0aGUgSEVMRCBzZXJ2ZXIgaXMgdGhlIGF1dGhvcml0YXRpdmUgc291
cmNlIG9mIHRoZSByZXNwb25zZSwgYW5kIGl04oCZcyBVUkkgaXMgYSB2ZXJ5IGFwcHJvcHJpYXRl
IHZhbHVlIGZvciBzb3VyY2UuICBJZiBpdCByZWFsbHkgb25seSBoYXMgb25lIHZhbHVlLCB0aGUg
4oCcc291cmNlSWTigJ0gY291bGQgYmUgYSBmaXhlZCwgc2hvcnQgc3RyaW5nLg0KDQpJIHdvdWxk
IGxpa2UgdG8gc3VnZ2VzdCB0aGF0IHRoZSB0ZXh0IGJlIHJld29yZGVkIHNvIHRoZSBMb1NUIDxt
YXBwaW5nPiByZXNwb25zZSBpcyB1c2VkIGluc3RlYWQgb2YgPHJvdXRpbmdJbmZvcm1hdGlvbj4g
YW5kIHRvIGJlIHNvbWV0aGluZyBsaWtlOg0KDQpUaGlzIGRvY3VtZW50IGltcG9ydHMgdGhlIDxt
YXBwaW5nPiBzY2hlbWEgZnJvbSBSRkM1MjIyIGFzIHRoZSByZXNwb25zZSBmcm9tIHRoZSBIRUxE
IHJvdXRpbmcgcXVlcnkuICAgV2hlcmUgdGhlIEhFTEQgc2VydmVyIGlzIG5vdCBjb25zdWx0aW5n
IGFueSBvdGhlciBzZXJ2aWNlIGZvciB0aGUgcm91dGluZyBkYXRhLCBpdCB3b3VsZCB1c2UgaXTi
gJlzIG93biBVUkkgZm9yIHRoZSDigJxzb3VyY2XigJ0gZnVuY3Rpb24uICBNYW55IG9mIHRoZSA8
bWFwcGluZz4gZWxlbWVudHMgYXJlIG9wdGlvbmFsIGFuZCB3aGlsZSB0aGV5IG1heSBub3QgYmUg
c2VlbiBpbiBtYW55IGltcGxlbWVudGF0aW9ucyBvZiBIRUxEIHJvdXRpbmcsIHRoZXkgaGF2ZSBz
b21lIHZhbHVlIGluIG90aGVyIGRlcGxveW1lbnRzLg0KDQpCcmlhbg0K

--_000_D137439097674brianrosenneustarbiz_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5BcyBJIHN0YXRl
ZCBpbiBJRVRGIDkyLCBJIGJlbGlldmUgdGhlIElFVEYgc2hvdWxkIGFsbG93IGFsbCB0aGUgcG9z
c2libGUgdmFsdWVzIGluIGEgTG9TVCByZXNwb25zZSB0byBiZSByZXR1cm5lZCBmcm9tIGEgSEVM
RCByZXNwb25zZSBpbiBzaXR1YXRpb25zIHdoZXJlIGEgc2luZ2xlIHF1ZXJ5IGlzIG5lZWRlZCBv
ciBkZXNpcmFibGUuICZuYnNwO0FzIGFuIGV4YW1wbGUsIHRoZSBzZXJ2aWNlIGJvdW5kYXJ5IG1h
eSBiZSB1c2VmdWwgZm9yIG1vYmlsZQ0KIGRldmljZXMsIHRoZSBzZXJ2aWNlIG51bWJlciBpcyB2
ZXJ5IHVzZWZ1bCwgYW5kJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGZ1
cnRoZXIgdGFrZSBleGNlcHRpb24gdG8gdGhlIG5vdGlvbiB0aGF0IHRoZSBtYXBwaW5nIHJlc3Bv
bnNlIGluIGEgcmVzdHJpY3RlZCB1c2UgY2FzZSB3b3VsZCBuZWNlc3NhcmlseSBiZSBkaWZmaWN1
bHQgb3IgaW52b2x2ZSBtaXNsZWFkaW5nIGRhdGEuICZuYnNwO1RoZSBleGFtcGxlIGdpdmVuIGlz
IHRoZSDigJxzb3VyY2XigJ0gcGFyYW1ldGVyLiAmbmJzcDtJbiB0aGUgY2l0ZWQgdXNlIGNhc2Us
IHRoZSBIRUxEIHNlcnZlciBpcyB0aGUgYXV0aG9yaXRhdGl2ZQ0KIHNvdXJjZSBvZiB0aGUgcmVz
cG9uc2UsIGFuZCBpdOKAmXMgVVJJIGlzIGEgdmVyeSBhcHByb3ByaWF0ZSB2YWx1ZSBmb3Igc291
cmNlLiAmbmJzcDtJZiBpdCByZWFsbHkgb25seSBoYXMgb25lIHZhbHVlLCB0aGUg4oCcc291cmNl
SWTigJ0gY291bGQgYmUgYSBmaXhlZCwgc2hvcnQgc3RyaW5nLjwvZGl2Pg0KPGRpdj48YnI+DQo8
L2Rpdj4NCjxkaXY+SSB3b3VsZCBsaWtlIHRvIHN1Z2dlc3QgdGhhdCB0aGUgdGV4dCBiZSByZXdv
cmRlZCBzbyB0aGUgTG9TVCAmbHQ7bWFwcGluZyZndDsgcmVzcG9uc2UgaXMgdXNlZCBpbnN0ZWFk
IG9mICZsdDtyb3V0aW5nSW5mb3JtYXRpb24mZ3Q7IGFuZCB0byBiZSBzb21ldGhpbmcgbGlrZTo8
L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoaXMgZG9jdW1lbnQgaW1wb3J0cyB0aGUg
Jmx0O21hcHBpbmcmZ3Q7IHNjaGVtYSBmcm9tIFJGQzUyMjIgYXMgdGhlIHJlc3BvbnNlIGZyb20g
dGhlIEhFTEQgcm91dGluZyBxdWVyeS4gJm5ic3A7IFdoZXJlIHRoZSBIRUxEIHNlcnZlciBpcyBu
b3QgY29uc3VsdGluZyBhbnkgb3RoZXIgc2VydmljZSBmb3IgdGhlIHJvdXRpbmcgZGF0YSwgaXQg
d291bGQgdXNlIGl04oCZcyBvd24gVVJJIGZvciB0aGUg4oCcc291cmNl4oCdIGZ1bmN0aW9uLiAm
bmJzcDtNYW55IG9mIHRoZSAmbHQ7bWFwcGluZyZndDsNCiBlbGVtZW50cyBhcmUgb3B0aW9uYWwg
YW5kIHdoaWxlIHRoZXkgbWF5IG5vdCBiZSBzZWVuIGluIG1hbnkgaW1wbGVtZW50YXRpb25zIG9m
IEhFTEQgcm91dGluZywgdGhleSBoYXZlIHNvbWUgdmFsdWUgaW4gb3RoZXIgZGVwbG95bWVudHMu
PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5CcmlhbjwvZGl2Pg0KPC9ib2R5Pg0KPC9o
dG1sPg0K

--_000_D137439097674brianrosenneustarbiz_--


From nobody Tue Mar 24 14:56:54 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBA41A1A7C for ; Tue, 24 Mar 2015 14:56:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level: 
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 TfW2OJhZ_daL for ; Tue, 24 Mar 2015 14:56:50 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 DBE491A1AE8 for ; Tue, 24 Mar 2015 14:56:49 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 9F17FF482DF29; Tue, 24 Mar 2015 21:56:44 +0000 (GMT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t2OLukVR006732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Mar 2015 22:56:46 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.230]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 24 Mar 2015 22:56:46 +0100
From: "DRAGE, Keith (Keith)" 
To: "Rosen, Brian" , James Winterbottom 
Thread-Topic: Allowing a full LoST response in the Held Routing response
Thread-Index: AQHQZnrm5/Y5NlQVqU2Az0Xn9N4YKJ0sLIzQ
Date: Tue, 24 Mar 2015 21:56:45 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B4A11C1B6@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B4A11C1B6FR712WXCHMBA11z_"
MIME-Version: 1.0
Archived-At: 
Cc: "ecrit@ietf.org" 
Subject: Re: [Ecrit] Allowing a full LoST response in the Held Routing response
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Mar 2015 21:56:52 -0000

--_000_949EF20990823C4C85C18D59AA11AD8B4A11C1B6FR712WXCHMBA11z_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

One problem I am having with your argument is that I read RFC 5985 as provi=
ding a protocol between a client and a service which is a LIS. I do not see=
 anything that says the major application supported on that protocol is Los=
t, whereas your argument seems to be that all applications on that protocol=
 need to support Lost.

Can you point me to something that supports your viewpoint.

regards

Keith

________________________________
From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Rosen, Brian
Sent: 24 March 2015 21:39
To: James Winterbottom
Cc: ecrit@ietf.org
Subject: [Ecrit] Allowing a full LoST response in the Held Routing response

As I stated in IETF 92, I believe the IETF should allow all the possible va=
lues in a LoST response to be returned from a HELD response in situations w=
here a single query is needed or desirable.  As an example, the service bou=
ndary may be useful for mobile devices, the service number is very useful, =
and

I further take exception to the notion that the mapping response in a restr=
icted use case would necessarily be difficult or involve misleading data.  =
The example given is the "source" parameter.  In the cited use case, the HE=
LD server is the authoritative source of the response, and it's URI is a ve=
ry appropriate value for source.  If it really only has one value, the "sou=
rceId" could be a fixed, short string.

I would like to suggest that the text be reworded so the LoST  res=
ponse is used instead of  and to be something like:

This document imports the  schema from RFC5222 as the response fro=
m the HELD routing query.   Where the HELD server is not consulting any oth=
er service for the routing data, it would use it's own URI for the "source"=
 function.  Many of the  elements are optional and while they may =
not be seen in many implementations of HELD routing, they have some value i=
n other deployments.

Brian

--_000_949EF20990823C4C85C18D59AA11AD8B4A11C1B6FR712WXCHMBA11z_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









One problem I am h=
aving with your argument is that I read RFC 5985 as providing a protocol be=
tween a client and a service which is a LIS. I do not see anything that say=
s the major application supported on
 that protocol is Lost, whereas your argument seems to be that all applicat=
ions on that protocol need to support Lost.


&nbs=
p;


Can you point me t=
o something that supports your viewpoint.


&nbs=
p;


regards


&nbs=
p;


Keith









From: Ecrit [mailto:ecrit-bounces@i=
etf.org] 
On Behalf Of Rosen, Brian

Sent: 24 March 2015 21:39

To: James Winterbottom

Cc: ecrit@ietf.org

Subject: [Ecrit] Allowing a full LoST response in the Held Routing r=
esponse








As I stated in IETF 92, I believe the IETF should allow all the possib=
le values in a LoST response to be returned from a HELD response in situati=
ons where a single query is needed or desirable.  As an example, the s=
ervice boundary may be useful for mobile
 devices, the service number is very useful, and 







I further take exception to the notion that the mapping response in a =
restricted use case would necessarily be difficult or involve misleading da=
ta.  The example given is the “source” parameter.  In=
 the cited use case, the HELD server is the authoritative
 source of the response, and it’s URI is a very appropriate value for=
 source.  If it really only has one value, the “sourceId” =
could be a fixed, short string.







I would like to suggest that the text be reworded so the LoST <mapp=
ing> response is used instead of <routingInformation> and to be so=
mething like:







This document imports the <mapping> schema from RFC5222 as the r=
esponse from the HELD routing query.   Where the HELD server is not co=
nsulting any other service for the routing data, it would use it’s ow=
n URI for the “source” function.  Many of the <mapping&=
gt;
 elements are optional and while they may not be seen in many implementatio=
ns of HELD routing, they have some value in other deployments.







Brian






--_000_949EF20990823C4C85C18D59AA11AD8B4A11C1B6FR712WXCHMBA11z_--


From nobody Tue Mar 24 14:59:03 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF801A1B83 for ; Tue, 24 Mar 2015 14:59:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.859
X-Spam-Level: 
X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 kuflV3DZIod6 for ; Tue, 24 Mar 2015 14:58:58 -0700 (PDT)
Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECFA41AC40D for ; Tue, 24 Mar 2015 14:58:56 -0700 (PDT)
Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail91.telekom.de with ESMTP; 24 Mar 2015 22:58:54 +0100
X-IronPort-AV: E=Sophos;i="5.11,460,1422918000";  d="scan'208,217";a="791671042"
Received: from he113470.emea1.cds.t-internal.com ([10.134.93.128]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES128-SHA; 24 Mar 2015 22:58:54 +0100
Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE113470.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 24 Mar 2015 22:58:53 +0100
From: 
To: , , 
Date: Tue, 24 Mar 2015 22:58:46 +0100
Thread-Topic: [Ecrit] Allowing a full LoST response in the Held Routing response
Thread-Index: AQHQZnrm5/Y5NlQVqU2Az0Xn9N4YKJ0sLIzQgAABr1A=
Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01E9E4F7F6C9@HE113667.emea1.cds.t-internal.com>
References:  <949EF20990823C4C85C18D59AA11AD8B4A11C1B6@FR712WXCHMBA11.zeu.alcatel-lucent.com>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B4A11C1B6@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE
Content-Type: multipart/alternative; boundary="_000_058CE00BD4D6B94FAD033A2439EA1E4B01E9E4F7F6C9HE113667eme_"
MIME-Version: 1.0
Archived-At: 
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] Allowing a full LoST response in the Held Routing response
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Mar 2015 21:59:02 -0000

--_000_058CE00BD4D6B94FAD033A2439EA1E4B01E9E4F7F6C9HE113667eme_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Keith,
thank you for pointing to this. I support your view.
I'm happy to go with the draft as it is.

Regards

Roland

Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von DRAGE, Keith (Kei=
th)
Gesendet: Dienstag, 24. M=E4rz 2015 22:57
An: Rosen, Brian; James Winterbottom
Cc: ecrit@ietf.org
Betreff: Re: [Ecrit] Allowing a full LoST response in the Held Routing resp=
onse

One problem I am having with your argument is that I read RFC 5985 as provi=
ding a protocol between a client and a service which is a LIS. I do not see=
 anything that says the major application supported on that protocol is Los=
t, whereas your argument seems to be that all applications on that protocol=
 need to support Lost.

Can you point me to something that supports your viewpoint.

regards

Keith

________________________________
From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Rosen, Brian
Sent: 24 March 2015 21:39
To: James Winterbottom
Cc: ecrit@ietf.org
Subject: [Ecrit] Allowing a full LoST response in the Held Routing response
As I stated in IETF 92, I believe the IETF should allow all the possible va=
lues in a LoST response to be returned from a HELD response in situations w=
here a single query is needed or desirable.  As an example, the service bou=
ndary may be useful for mobile devices, the service number is very useful, =
and

I further take exception to the notion that the mapping response in a restr=
icted use case would necessarily be difficult or involve misleading data.  =
The example given is the "source" parameter.  In the cited use case, the HE=
LD server is the authoritative source of the response, and it's URI is a ve=
ry appropriate value for source.  If it really only has one value, the "sou=
rceId" could be a fixed, short string.

I would like to suggest that the text be reworded so the LoST  res=
ponse is used instead of  and to be something like:

This document imports the  schema from RFC5222 as the response fro=
m the HELD routing query.   Where the HELD server is not consulting any oth=
er service for the routing data, it would use it's own URI for the "source"=
 function.  Many of the  elements are optional and while they may =
not be seen in many implementations of HELD routing, they have some value i=
n other deployments.

Brian

--_000_058CE00BD4D6B94FAD033A2439EA1E4B01E9E4F7F6C9HE113667eme_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



Hi Keith,
thank you for pointing to t=
his. I support your view.
I’m happy to go with the draft as it is.
 
=

Regards
 
Roland
 
=

Von: Ecrit [mailto:ecrit-bounces@ietf.org]=
 Im Auftrag von DRAGE, Keith (Keith)
Gesendet: Dienstag, 2=
4. M=E4rz 2015 22:57
An: Rosen, Brian; James Winterbottom
C=
c: ecrit@ietf.org
Betreff: Re: [Ecrit] Allowing a full LoST r=
esponse in the Held Routing response
 
One pr=
oblem I am having with your argument is that I read RFC 5985 as providing a=
 protocol between a client and a service which is a LIS. I do not see anyth=
ing that says the major application supported on that protocol is Lost, whe=
reas your argument seems to be that all applications on that protocol need =
to support Lost.
 
Can you point me to something that supports your viewpoint.
 <=
/span>
regards
 <=
/p>
Keith=

 
From: Ecrit [mai=
lto:ecrit-bounces@ietf.org] On Behalf Of Rosen, Brian
Sent=
: 24 March 2015 21:39
To: James Winterbottom
Cc: ecrit@ietf.org
Subject: [Ecri=
t] Allowing a full LoST response in the Held Routing response
As I stated=
 in IETF 92, I believe the IETF should allow all the possible values in a L=
oST response to be returned from a HELD response in situations where a sing=
le query is needed or desirable.  As an example, the service boundary =
may be useful for mobile devices, the service number is very useful, and&nb=
sp;
 
I further take exceptio=
n to the notion that the mapping response in a restricted use case would ne=
cessarily be difficult or involve misleading data.  The example given =
is the “source” parameter.  In the cited use case, the HEL=
D server is the authoritative source of the response, and it’s URI is=
 a very appropriate value for source.  If it really only has one value=
, the “sourceId” could be a fixed, short string.
 
I would like to suggest that the text be =
reworded so the LoST <mapping> response is used instead of <routin=
gInformation> and to be something like:
=

 
This document imports the <mapping> schema from RFC=
5222 as the response from the HELD routing query.   Where the HELD ser=
ver is not consulting any other service for the routing data, it would use =
it’s own URI for the “source” function.  Many of the=
 <mapping> elements are optional and while they may not be seen in ma=
ny implementations of HELD routing, they have some value in other deploymen=
ts.
 
Brian=

=

--_000_058CE00BD4D6B94FAD033A2439EA1E4B01E9E4F7F6C9HE113667eme_--


From nobody Tue Mar 24 15:07:06 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186F91A916C for ; Tue, 24 Mar 2015 15:06:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 CtXZqSpET4On for ; Tue, 24 Mar 2015 15:06:52 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 62D461A908D for ; Tue, 24 Mar 2015 15:06:17 -0700 (PDT)
Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.14.7/8.14.7) with SMTP id t2OM3xnD028549; Tue, 24 Mar 2015 18:06:15 -0400
Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1tbdax09u1-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Mar 2015 18:06:15 -0400
Received: from STNTEXMB13.cis.neustar.com ([169.254.3.204]) by stntexhc10.cis.neustar.com ([169.254.4.213]) with mapi id 14.03.0158.001; Tue, 24 Mar 2015 18:06:13 -0400
From: "Rosen, Brian" 
To: "DRAGE, Keith (Keith)" , "James Winterbottom" 
Thread-Topic: Allowing a full LoST response in the Held Routing response
Thread-Index: AQHQZnrm5/Y5NlQVqU2Az0Xn9N4YKJ0sLIzQ///zMgA=
Date: Tue, 24 Mar 2015 22:06:13 +0000
Message-ID: 
References:  <949EF20990823C4C85C18D59AA11AD8B4A11C1B6@FR712WXCHMBA11.zeu.alcatel-lucent.com>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B4A11C1B6@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [192.168.132.33]
Content-Type: multipart/alternative; boundary="_000_D137498097689brianrosenneustarbiz_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=nai engine=5700 definitions=7750 signatures=670576
X-Proofpoint-Spam-Reason: safe
Archived-At: 
Cc: "ecrit@ietf.org" 
Subject: Re: [Ecrit] Allowing a full LoST response in the Held Routing response
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Mar 2015 22:06:54 -0000

--_000_D137498097689brianrosenneustarbiz_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SeKAmW0gbm90IHN1Z2dlc3RpbmcgdGhhdCB0aGVyZSBpcyBhIExvU1Qgc2VydmVyIGluIHRoaXMg
YXJjaGl0ZWN0dXJlLiAgSeKAmW0gc3VnZ2VzdGluZyB0aGF0IHRoZSBIRUxEIHNlcnZlciB0aGF0
IGlzIHJldHVybmluZyB0aGUgcm91dGluZyBpbmZvcm1hdGlvbiBzaG91bGQgYmUgYWJsZSB0byBy
ZXR1cm4gZXZlcnl0aGluZyB0aGF0IGEgTG9TVCBzZXJ2ZXIgY291bGQgcmV0dXJuLg0KDQpCcmlh
bg0KDQpGcm9tOiA8RFJBR0U+LCAiS2VpdGggKEtlaXRoKSIgPGtlaXRoLmRyYWdlQGFsY2F0ZWwt
bHVjZW50LmNvbTxtYWlsdG86a2VpdGguZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tPj4NCkRhdGU6
IFR1ZXNkYXksIE1hcmNoIDI0LCAyMDE1IGF0IDQ6NTYgUE0NClRvOiBCcmlhbiBSb3NlbiA8YnJp
YW4ucm9zZW5AbmV1c3Rhci5iaXo8bWFpbHRvOmJyaWFuLnJvc2VuQG5ldXN0YXIuYml6Pj4sIEph
bWVzIFdpbnRlcmJvdHRvbSA8YS5qYW1lcy53aW50ZXJib3R0b21AZ21haWwuY29tPG1haWx0bzph
LmphbWVzLndpbnRlcmJvdHRvbUBnbWFpbC5jb20+Pg0KQ2M6ICJlY3JpdEBpZXRmLm9yZzxtYWls
dG86ZWNyaXRAaWV0Zi5vcmc+IiA8ZWNyaXRAaWV0Zi5vcmc8bWFpbHRvOmVjcml0QGlldGYub3Jn
Pj4NClN1YmplY3Q6IFJFOiBBbGxvd2luZyBhIGZ1bGwgTG9TVCByZXNwb25zZSBpbiB0aGUgSGVs
ZCBSb3V0aW5nIHJlc3BvbnNlDQoNCk9uZSBwcm9ibGVtIEkgYW0gaGF2aW5nIHdpdGggeW91ciBh
cmd1bWVudCBpcyB0aGF0IEkgcmVhZCBSRkMgNTk4NSBhcyBwcm92aWRpbmcgYSBwcm90b2NvbCBi
ZXR3ZWVuIGEgY2xpZW50IGFuZCBhIHNlcnZpY2Ugd2hpY2ggaXMgYSBMSVMuIEkgZG8gbm90IHNl
ZSBhbnl0aGluZyB0aGF0IHNheXMgdGhlIG1ham9yIGFwcGxpY2F0aW9uIHN1cHBvcnRlZCBvbiB0
aGF0IHByb3RvY29sIGlzIExvc3QsIHdoZXJlYXMgeW91ciBhcmd1bWVudCBzZWVtcyB0byBiZSB0
aGF0IGFsbCBhcHBsaWNhdGlvbnMgb24gdGhhdCBwcm90b2NvbCBuZWVkIHRvIHN1cHBvcnQgTG9z
dC4NCg0KQ2FuIHlvdSBwb2ludCBtZSB0byBzb21ldGhpbmcgdGhhdCBzdXBwb3J0cyB5b3VyIHZp
ZXdwb2ludC4NCg0KcmVnYXJkcw0KDQpLZWl0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KRnJvbTogRWNyaXQgW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXSBPbiBC
ZWhhbGYgT2YgUm9zZW4sIEJyaWFuDQpTZW50OiAyNCBNYXJjaCAyMDE1IDIxOjM5DQpUbzogSmFt
ZXMgV2ludGVyYm90dG9tDQpDYzogZWNyaXRAaWV0Zi5vcmc8bWFpbHRvOmVjcml0QGlldGYub3Jn
Pg0KU3ViamVjdDogW0Vjcml0XSBBbGxvd2luZyBhIGZ1bGwgTG9TVCByZXNwb25zZSBpbiB0aGUg
SGVsZCBSb3V0aW5nIHJlc3BvbnNlDQoNCkFzIEkgc3RhdGVkIGluIElFVEYgOTIsIEkgYmVsaWV2
ZSB0aGUgSUVURiBzaG91bGQgYWxsb3cgYWxsIHRoZSBwb3NzaWJsZSB2YWx1ZXMgaW4gYSBMb1NU
IHJlc3BvbnNlIHRvIGJlIHJldHVybmVkIGZyb20gYSBIRUxEIHJlc3BvbnNlIGluIHNpdHVhdGlv
bnMgd2hlcmUgYSBzaW5nbGUgcXVlcnkgaXMgbmVlZGVkIG9yIGRlc2lyYWJsZS4gIEFzIGFuIGV4
YW1wbGUsIHRoZSBzZXJ2aWNlIGJvdW5kYXJ5IG1heSBiZSB1c2VmdWwgZm9yIG1vYmlsZSBkZXZp
Y2VzLCB0aGUgc2VydmljZSBudW1iZXIgaXMgdmVyeSB1c2VmdWwsIGFuZA0KDQpJIGZ1cnRoZXIg
dGFrZSBleGNlcHRpb24gdG8gdGhlIG5vdGlvbiB0aGF0IHRoZSBtYXBwaW5nIHJlc3BvbnNlIGlu
IGEgcmVzdHJpY3RlZCB1c2UgY2FzZSB3b3VsZCBuZWNlc3NhcmlseSBiZSBkaWZmaWN1bHQgb3Ig
aW52b2x2ZSBtaXNsZWFkaW5nIGRhdGEuICBUaGUgZXhhbXBsZSBnaXZlbiBpcyB0aGUg4oCcc291
cmNl4oCdIHBhcmFtZXRlci4gIEluIHRoZSBjaXRlZCB1c2UgY2FzZSwgdGhlIEhFTEQgc2VydmVy
IGlzIHRoZSBhdXRob3JpdGF0aXZlIHNvdXJjZSBvZiB0aGUgcmVzcG9uc2UsIGFuZCBpdOKAmXMg
VVJJIGlzIGEgdmVyeSBhcHByb3ByaWF0ZSB2YWx1ZSBmb3Igc291cmNlLiAgSWYgaXQgcmVhbGx5
IG9ubHkgaGFzIG9uZSB2YWx1ZSwgdGhlIOKAnHNvdXJjZUlk4oCdIGNvdWxkIGJlIGEgZml4ZWQs
IHNob3J0IHN0cmluZy4NCg0KSSB3b3VsZCBsaWtlIHRvIHN1Z2dlc3QgdGhhdCB0aGUgdGV4dCBi
ZSByZXdvcmRlZCBzbyB0aGUgTG9TVCA8bWFwcGluZz4gcmVzcG9uc2UgaXMgdXNlZCBpbnN0ZWFk
IG9mIDxyb3V0aW5nSW5mb3JtYXRpb24+IGFuZCB0byBiZSBzb21ldGhpbmcgbGlrZToNCg0KVGhp
cyBkb2N1bWVudCBpbXBvcnRzIHRoZSA8bWFwcGluZz4gc2NoZW1hIGZyb20gUkZDNTIyMiBhcyB0
aGUgcmVzcG9uc2UgZnJvbSB0aGUgSEVMRCByb3V0aW5nIHF1ZXJ5LiAgIFdoZXJlIHRoZSBIRUxE
IHNlcnZlciBpcyBub3QgY29uc3VsdGluZyBhbnkgb3RoZXIgc2VydmljZSBmb3IgdGhlIHJvdXRp
bmcgZGF0YSwgaXQgd291bGQgdXNlIGl04oCZcyBvd24gVVJJIGZvciB0aGUg4oCcc291cmNl4oCd
IGZ1bmN0aW9uLiAgTWFueSBvZiB0aGUgPG1hcHBpbmc+IGVsZW1lbnRzIGFyZSBvcHRpb25hbCBh
bmQgd2hpbGUgdGhleSBtYXkgbm90IGJlIHNlZW4gaW4gbWFueSBpbXBsZW1lbnRhdGlvbnMgb2Yg
SEVMRCByb3V0aW5nLCB0aGV5IGhhdmUgc29tZSB2YWx1ZSBpbiBvdGhlciBkZXBsb3ltZW50cy4N
Cg0KQnJpYW4NCg==

--_000_D137498097689brianrosenneustarbiz_
Content-Type: text/html; charset="utf-8"
Content-ID: <908B13F2D3B0274BBE028C20A63F44D3@neustar.biz>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5J4oCZbSBub3Qg
c3VnZ2VzdGluZyB0aGF0IHRoZXJlIGlzIGEgTG9TVCBzZXJ2ZXIgaW4gdGhpcyBhcmNoaXRlY3R1
cmUuICZuYnNwO0nigJltIHN1Z2dlc3RpbmcgdGhhdCB0aGUgSEVMRCBzZXJ2ZXIgdGhhdCBpcyBy
ZXR1cm5pbmcgdGhlIHJvdXRpbmcgaW5mb3JtYXRpb24gc2hvdWxkIGJlIGFibGUgdG8gcmV0dXJu
IGV2ZXJ5dGhpbmcgdGhhdCBhIExvU1Qgc2VydmVyIGNvdWxkIHJldHVybi48L2Rpdj4NCjxkaXY+
PGJyPg0KPC9kaXY+DQo8ZGl2PkJyaWFuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4g
aWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli
cmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVIt
Qk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJP
VFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVIt
VE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElO
Ry1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFu
PiZsdDtEUkFHRSZndDssICZxdW90O0tlaXRoIChLZWl0aCkmcXVvdDsgJmx0OzxhIGhyZWY9Im1h
aWx0bzprZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb20iPmtlaXRoLmRyYWdlQGFsY2F0ZWwt
bHVjZW50LmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRh
dGU6IDwvc3Bhbj5UdWVzZGF5LCBNYXJjaCAyNCwgMjAxNSBhdCA0OjU2IFBNPGJyPg0KPHNwYW4g
c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+QnJpYW4gUm9zZW4gJmx0OzxhIGhy
ZWY9Im1haWx0bzpicmlhbi5yb3NlbkBuZXVzdGFyLmJpeiI+YnJpYW4ucm9zZW5AbmV1c3Rhci5i
aXo8L2E+Jmd0OywgSmFtZXMgV2ludGVyYm90dG9tICZsdDs8YSBocmVmPSJtYWlsdG86YS5qYW1l
cy53aW50ZXJib3R0b21AZ21haWwuY29tIj5hLmphbWVzLndpbnRlcmJvdHRvbUBnbWFpbC5jb208
L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZx
dW90OzxhIGhyZWY9Im1haWx0bzplY3JpdEBpZXRmLm9yZyI+ZWNyaXRAaWV0Zi5vcmc8L2E+JnF1
b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZWNyaXRAaWV0Zi5vcmciPmVjcml0QGlldGYub3JnPC9h
PiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFu
PlJFOiBBbGxvd2luZyBhIGZ1bGwgTG9TVCByZXNwb25zZSBpbiB0aGUgSGVsZCBSb3V0aW5nIHJl
c3BvbnNlPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxtZXRhIGNvbnRl
bnQ9Ik1TSFRNTCA2LjAwLjI5MDAuNjU1MCIgbmFtZT0iR0VORVJBVE9SIj4NCjxkaXYgc3R5bGU9
IkZPTlQtU0laRTogMTRweDsgQ09MT1I6IHJnYigwLDAsMCk7IEZPTlQtRkFNSUxZOiBDYWxpYnJp
LCBzYW5zLXNlcmlmOyBXT1JELVdSQVA6IGJyZWFrLXdvcmQ7IHdlYmtpdC1uYnNwLW1vZGU6IHNw
YWNlOyB3ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2UiPg0KPGRpdj48c3BhbiBj
bGFzcz0iMzM5NTk1MTIxLTI0MDMyMDE1Ij48Zm9udCBzaXplPSI0Ij5PbmUgcHJvYmxlbSBJIGFt
IGhhdmluZyB3aXRoIHlvdXIgYXJndW1lbnQgaXMgdGhhdCBJIHJlYWQgUkZDIDU5ODUgYXMgcHJv
dmlkaW5nIGEgcHJvdG9jb2wgYmV0d2VlbiBhIGNsaWVudCBhbmQgYSBzZXJ2aWNlIHdoaWNoIGlz
IGEgTElTLiBJIGRvIG5vdCBzZWUgYW55dGhpbmcgdGhhdCBzYXlzIHRoZSBtYWpvciBhcHBsaWNh
dGlvbiBzdXBwb3J0ZWQgb24NCiB0aGF0IHByb3RvY29sIGlzIExvc3QsIHdoZXJlYXMgeW91ciBh
cmd1bWVudCBzZWVtcyB0byBiZSB0aGF0IGFsbCBhcHBsaWNhdGlvbnMgb24gdGhhdCBwcm90b2Nv
bCBuZWVkIHRvIHN1cHBvcnQgTG9zdC48L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBj
bGFzcz0iMzM5NTk1MTIxLTI0MDMyMDE1Ij48Zm9udCBzaXplPSI0Ij48L2ZvbnQ+PC9zcGFuPiZu
YnNwOzwvZGl2Pg0KPGRpdj48c3BhbiBjbGFzcz0iMzM5NTk1MTIxLTI0MDMyMDE1Ij48Zm9udCBz
aXplPSI0Ij5DYW4geW91IHBvaW50IG1lIHRvIHNvbWV0aGluZyB0aGF0IHN1cHBvcnRzIHlvdXIg
dmlld3BvaW50LjwvZm9udD48L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIGNsYXNzPSIzMzk1OTUx
MjEtMjQwMzIwMTUiPjxmb250IHNpemU9IjQiPjwvZm9udD48L3NwYW4+Jm5ic3A7PC9kaXY+DQo8
ZGl2PjxzcGFuIGNsYXNzPSIzMzk1OTUxMjEtMjQwMzIwMTUiPjxmb250IHNpemU9IjQiPnJlZ2Fy
ZHM8L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBjbGFzcz0iMzM5NTk1MTIxLTI0MDMy
MDE1Ij48Zm9udCBzaXplPSI0Ij48L2ZvbnQ+PC9zcGFuPiZuYnNwOzwvZGl2Pg0KPGRpdj48c3Bh
biBjbGFzcz0iMzM5NTk1MTIxLTI0MDMyMDE1Ij48Zm9udCBzaXplPSI0Ij5LZWl0aDwvZm9udD48
L3NwYW4+PC9kaXY+DQo8YnI+DQo8YmxvY2txdW90ZSBkaXI9Imx0ciIgc3R5bGU9IlBBRERJTkct
TEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29s
aWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCjxkaXYgY2xhc3M9Ik91dGxvb2tNZXNzYWdlSGVhZGVy
IiBsYW5nPSJlbi11cyIgZGlyPSJsdHIiIGFsaWduPSJsZWZ0Ij4NCjxociB0YWJpbmRleD0iLTEi
Pg0KPGZvbnQgZmFjZT0iVGFob21hIiBzaXplPSIyIj48Yj5Gcm9tOjwvYj4gRWNyaXQgWzxhIGhy
ZWY9Im1haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZWNyaXQtYm91bmNlc0Bp
ZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvc2VuLCBCcmlhbjxicj4NCjxiPlNl
bnQ6PC9iPiAyNCBNYXJjaCAyMDE1IDIxOjM5PGJyPg0KPGI+VG86PC9iPiBKYW1lcyBXaW50ZXJi
b3R0b208YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzplY3JpdEBpZXRmLm9yZyI+ZWNy
aXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtFY3JpdF0gQWxsb3dpbmcgYSBm
dWxsIExvU1QgcmVzcG9uc2UgaW4gdGhlIEhlbGQgUm91dGluZyByZXNwb25zZTxicj4NCjwvZm9u
dD48YnI+DQo8L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2PkFzIEkgc3RhdGVkIGluIElFVEYgOTIs
IEkgYmVsaWV2ZSB0aGUgSUVURiBzaG91bGQgYWxsb3cgYWxsIHRoZSBwb3NzaWJsZSB2YWx1ZXMg
aW4gYSBMb1NUIHJlc3BvbnNlIHRvIGJlIHJldHVybmVkIGZyb20gYSBIRUxEIHJlc3BvbnNlIGlu
IHNpdHVhdGlvbnMgd2hlcmUgYSBzaW5nbGUgcXVlcnkgaXMgbmVlZGVkIG9yIGRlc2lyYWJsZS4g
Jm5ic3A7QXMgYW4gZXhhbXBsZSwgdGhlIHNlcnZpY2UgYm91bmRhcnkgbWF5IGJlIHVzZWZ1bCBm
b3IgbW9iaWxlDQogZGV2aWNlcywgdGhlIHNlcnZpY2UgbnVtYmVyIGlzIHZlcnkgdXNlZnVsLCBh
bmQmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgZnVydGhlciB0YWtlIGV4
Y2VwdGlvbiB0byB0aGUgbm90aW9uIHRoYXQgdGhlIG1hcHBpbmcgcmVzcG9uc2UgaW4gYSByZXN0
cmljdGVkIHVzZSBjYXNlIHdvdWxkIG5lY2Vzc2FyaWx5IGJlIGRpZmZpY3VsdCBvciBpbnZvbHZl
IG1pc2xlYWRpbmcgZGF0YS4gJm5ic3A7VGhlIGV4YW1wbGUgZ2l2ZW4gaXMgdGhlIOKAnHNvdXJj
ZeKAnSBwYXJhbWV0ZXIuICZuYnNwO0luIHRoZSBjaXRlZCB1c2UgY2FzZSwgdGhlIEhFTEQgc2Vy
dmVyIGlzIHRoZSBhdXRob3JpdGF0aXZlDQogc291cmNlIG9mIHRoZSByZXNwb25zZSwgYW5kIGl0
4oCZcyBVUkkgaXMgYSB2ZXJ5IGFwcHJvcHJpYXRlIHZhbHVlIGZvciBzb3VyY2UuICZuYnNwO0lm
IGl0IHJlYWxseSBvbmx5IGhhcyBvbmUgdmFsdWUsIHRoZSDigJxzb3VyY2VJZOKAnSBjb3VsZCBi
ZSBhIGZpeGVkLCBzaG9ydCBzdHJpbmcuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5J
IHdvdWxkIGxpa2UgdG8gc3VnZ2VzdCB0aGF0IHRoZSB0ZXh0IGJlIHJld29yZGVkIHNvIHRoZSBM
b1NUICZsdDttYXBwaW5nJmd0OyByZXNwb25zZSBpcyB1c2VkIGluc3RlYWQgb2YgJmx0O3JvdXRp
bmdJbmZvcm1hdGlvbiZndDsgYW5kIHRvIGJlIHNvbWV0aGluZyBsaWtlOjwvZGl2Pg0KPGRpdj48
YnI+DQo8L2Rpdj4NCjxkaXY+VGhpcyBkb2N1bWVudCBpbXBvcnRzIHRoZSAmbHQ7bWFwcGluZyZn
dDsgc2NoZW1hIGZyb20gUkZDNTIyMiBhcyB0aGUgcmVzcG9uc2UgZnJvbSB0aGUgSEVMRCByb3V0
aW5nIHF1ZXJ5LiAmbmJzcDsgV2hlcmUgdGhlIEhFTEQgc2VydmVyIGlzIG5vdCBjb25zdWx0aW5n
IGFueSBvdGhlciBzZXJ2aWNlIGZvciB0aGUgcm91dGluZyBkYXRhLCBpdCB3b3VsZCB1c2UgaXTi
gJlzIG93biBVUkkgZm9yIHRoZSDigJxzb3VyY2XigJ0gZnVuY3Rpb24uICZuYnNwO01hbnkgb2Yg
dGhlICZsdDttYXBwaW5nJmd0Ow0KIGVsZW1lbnRzIGFyZSBvcHRpb25hbCBhbmQgd2hpbGUgdGhl
eSBtYXkgbm90IGJlIHNlZW4gaW4gbWFueSBpbXBsZW1lbnRhdGlvbnMgb2YgSEVMRCByb3V0aW5n
LCB0aGV5IGhhdmUgc29tZSB2YWx1ZSBpbiBvdGhlciBkZXBsb3ltZW50cy48L2Rpdj4NCjxkaXY+
PGJyPg0KPC9kaXY+DQo8ZGl2PkJyaWFuPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_D137498097689brianrosenneustarbiz_--


From nobody Tue Mar 24 15:10:13 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73CFB1A1B2E for ; Tue, 24 Mar 2015 15:10:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level: 
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 IW_ZgsZXp9Hn for ; Tue, 24 Mar 2015 15:10:08 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 730F31A0404 for ; Tue, 24 Mar 2015 15:10:07 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 4C02355ADA62; Tue, 24 Mar 2015 22:10:02 +0000 (GMT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t2OMA302016252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Mar 2015 23:10:03 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.230]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 24 Mar 2015 23:10:03 +0100
From: "DRAGE, Keith (Keith)" 
To: "Rosen, Brian" , James Winterbottom 
Thread-Topic: Allowing a full LoST response in the Held Routing response
Thread-Index: AQHQZn7EREH5jzL62U6iU7ch2UQ/oZ0sMSGg
Date: Tue, 24 Mar 2015 22:10:03 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B4A11C21E@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References:  <949EF20990823C4C85C18D59AA11AD8B4A11C1B6@FR712WXCHMBA11.zeu.alcatel-lucent.com> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B4A11C21EFR712WXCHMBA11z_"
MIME-Version: 1.0
Archived-At: 
Cc: "ecrit@ietf.org" 
Subject: Re: [Ecrit] Allowing a full LoST response in the Held Routing response
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Mar 2015 22:10:11 -0000

--_000_949EF20990823C4C85C18D59AA11AD8B4A11C21EFR712WXCHMBA11z_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

OK, so lets ask the question a different way.

Why should an extension to an extendible protocol cover what should be allo=
wed to be sent in relation to other extensions. Surely anything that the IE=
TF wanted in that respect should have been covered in RFC 5985 itself.

Keith

________________________________
From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]
Sent: 24 March 2015 22:06
To: DRAGE, Keith (Keith); James Winterbottom
Cc: ecrit@ietf.org
Subject: Re: Allowing a full LoST response in the Held Routing response

I'm not suggesting that there is a LoST server in this architecture.  I'm s=
uggesting that the HELD server that is returning the routing information sh=
ould be able to return everything that a LoST server could return.

Brian

From: , "Keith (Keith)" >
Date: Tuesday, March 24, 2015 at 4:56 PM
To: Brian Rosen >, =
James Winterbottom >
Cc: "ecrit@ietf.org" >
Subject: RE: Allowing a full LoST response in the Held Routing response

One problem I am having with your argument is that I read RFC 5985 as provi=
ding a protocol between a client and a service which is a LIS. I do not see=
 anything that says the major application supported on that protocol is Los=
t, whereas your argument seems to be that all applications on that protocol=
 need to support Lost.

Can you point me to something that supports your viewpoint.

regards

Keith

________________________________
From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Rosen, Brian
Sent: 24 March 2015 21:39
To: James Winterbottom
Cc: ecrit@ietf.org
Subject: [Ecrit] Allowing a full LoST response in the Held Routing response

As I stated in IETF 92, I believe the IETF should allow all the possible va=
lues in a LoST response to be returned from a HELD response in situations w=
here a single query is needed or desirable.  As an example, the service bou=
ndary may be useful for mobile devices, the service number is very useful, =
and

I further take exception to the notion that the mapping response in a restr=
icted use case would necessarily be difficult or involve misleading data.  =
The example given is the "source" parameter.  In the cited use case, the HE=
LD server is the authoritative source of the response, and it's URI is a ve=
ry appropriate value for source.  If it really only has one value, the "sou=
rceId" could be a fixed, short string.

I would like to suggest that the text be reworded so the LoST  res=
ponse is used instead of  and to be something like:

This document imports the  schema from RFC5222 as the response fro=
m the HELD routing query.   Where the HELD server is not consulting any oth=
er service for the routing data, it would use it's own URI for the "source"=
 function.  Many of the  elements are optional and while they may =
not be seen in many implementations of HELD routing, they have some value i=
n other deployments.

Brian

--_000_949EF20990823C4C85C18D59AA11AD8B4A11C21EFR712WXCHMBA11z_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









OK, so lets ask th=
e question a different way.


&nbs=
p;


Why should an exte=
nsion to an extendible protocol cover what should be allowed to be sent in =
relation to other extensions. Surely anything that the IETF wanted in that =
respect should have been covered in
 RFC 5985 itself.


&nbs=
p;


Keith









From: Rosen, Brian [mailto:Brian.Ro=
sen@neustar.biz]


Sent: 24 March 2015 22:06

To: DRAGE, Keith (Keith); James Winterbottom

Cc: ecrit@ietf.org

Subject: Re: Allowing a full LoST response in the Held Routing respo=
nse








I’m not suggesting that there is a LoST server in this architect=
ure.  I’m suggesting that the HELD server that is returning the =
routing information should be able to return everything that a LoST server =
could return.







Brian









From: <DRAGE>, "Keith (=
Keith)" <keith.dr=
age@alcatel-lucent.com>

Date: Tuesday, March 24, 2015 at 4=
:56 PM

To: Brian Rosen <brian.rosen@neustar.biz>, James Winterb=
ottom <a.james.winterb=
ottom@gmail.com>

Cc: "ecrit@ietf.org" <ec=
rit@ietf.org>

Subject: RE: Allowing a full LoST =
response in the Held Routing response














One problem I am h=
aving with your argument is that I read RFC 5985 as providing a protocol be=
tween a client and a service which is a LIS. I do not see anything that say=
s the major application supported on
 that protocol is Lost, whereas your argument seems to be that all applicat=
ions on that protocol need to support Lost.


&nbs=
p;


Can you point me t=
o something that supports your viewpoint.


&nbs=
p;


regards


&nbs=
p;


Keith









From: Ecrit [mailto:ecrit-bounces@ietf.org]
On Behalf Of Rosen, Brian

Sent: 24 March 2015 21:39

To: James Winterbottom

Cc: ecrit@ietf.org

Subject: [Ecrit] Allowing a full LoST response in the Held Routing r=
esponse








As I stated in IETF 92, I believe the IETF should allow all the possib=
le values in a LoST response to be returned from a HELD response in situati=
ons where a single query is needed or desirable.  As an example, the s=
ervice boundary may be useful for mobile
 devices, the service number is very useful, and 







I further take exception to the notion that the mapping response in a =
restricted use case would necessarily be difficult or involve misleading da=
ta.  The example given is the “source” parameter.  In=
 the cited use case, the HELD server is the authoritative
 source of the response, and it’s URI is a very appropriate value for=
 source.  If it really only has one value, the “sourceId” =
could be a fixed, short string.







I would like to suggest that the text be reworded so the LoST <mapp=
ing> response is used instead of <routingInformation> and to be so=
mething like:







This document imports the <mapping> schema from RFC5222 as the r=
esponse from the HELD routing query.   Where the HELD server is not co=
nsulting any other service for the routing data, it would use it’s ow=
n URI for the “source” function.  Many of the <mapping&=
gt;
 elements are optional and while they may not be seen in many implementatio=
ns of HELD routing, they have some value in other deployments.







Brian













--_000_949EF20990823C4C85C18D59AA11AD8B4A11C21EFR712WXCHMBA11z_--


From nobody Tue Mar 24 15:13:13 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2DC1A0404 for ; Tue, 24 Mar 2015 15:13:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham
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 56jkAm2p_hkK for ; Tue, 24 Mar 2015 15:13:05 -0700 (PDT)
Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (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 740911A1A9D for ; Tue, 24 Mar 2015 15:13:01 -0700 (PDT)
Received: by pabxg6 with SMTP id xg6so6899437pab.0 for ; Tue, 24 Mar 2015 15:13:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=470evNTd2Xve/50Hr835dgQgza9+92M82YEhrd2c7yg=; b=zH4luS5GymeUp7NvYw2haILt4nA5BJux1jnnmzLIoGeVjFrpr/O5an7j+qq5fJ8aNq 4yTAPQHirRfPLgLw4QXx8HSmVaB32L3OkfT2lbPPYRL7r72apXXe0NN2uNbRszRm+Svk GLeYTpQrhJuG6kg+e5B9yWIfIoN3cpkgK58Ld46SQg0N76IUbdOO0JyH6AOIfZdSfdTS Af1BsU8q0u98RtGa5QIF1VJjPdMoLWJ/SjeiMyFPdWN+jCN6EhNNiA0AertaPFStJez9 giNIEJSCh4rvWb2jEkxb3szl0K6rAub16JYV4sV9TOfniHYTxwh523uYUgbmdAC57pGl MyeQ==
X-Received: by 10.70.102.8 with SMTP id fk8mr10946744pdb.141.1427235181046; Tue, 24 Mar 2015 15:13:01 -0700 (PDT)
Received: from [10.166.114.205] ([1.129.78.151]) by mx.google.com with ESMTPSA id z6sm317386pdm.78.2015.03.24.15.12.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Mar 2015 15:13:00 -0700 (PDT)
References:  <949EF20990823C4C85C18D59AA11AD8B4A11C1B6@FR712WXCHMBA11.zeu.alcatel-lucent.com>  <949EF20990823C4C85C18D59AA11AD8B4A11C21E@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B4A11C21E@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-0D586149-5954-4782-BBC7-190E362E70E0
Content-Transfer-Encoding: 7bit
Message-Id: <0085A304-7F6E-45FC-B7E3-6594AFD0F54F@gmail.com>
X-Mailer: iPhone Mail (11D201)
From: James Winterbottom 
Date: Wed, 25 Mar 2015 09:12:53 +1100
To: "DRAGE, Keith (Keith)" 
Archived-At: 
Cc: "Rosen, Brian" , "ecrit@ietf.org" 
Subject: Re: [Ecrit] Allowing a full LoST response in the Held Routing response
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Mar 2015 22:13:12 -0000

--Apple-Mail-0D586149-5954-4782-BBC7-190E362E70E0
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I don't understand why simply adding an extension point to the sequence in t=
he server element won't address your requirement Brian.

Then if you want to return the stuff you can, but applications that don't wa=
nt or need it don't have to be concerned with it.

Cheers
James

Sent from my iPhone

> On 25 Mar 2015, at 9:10 am, "DRAGE, Keith (Keith)"  wrote:
>=20
> OK, so lets ask the question a different way.
> =20
> Why should an extension to an extendible protocol cover what should be all=
owed to be sent in relation to other extensions. Surely anything that the IE=
TF wanted in that respect should have been covered in RFC 5985 itself.
> =20
> Keith
>=20
> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20
> Sent: 24 March 2015 22:06
> To: DRAGE, Keith (Keith); James Winterbottom
> Cc: ecrit@ietf.org
> Subject: Re: Allowing a full LoST response in the Held Routing response
>=20
> I=E2=80=99m not suggesting that there is a LoST server in this architectur=
e.  I=E2=80=99m suggesting that the HELD server that is returning the routin=
g information should be able to return everything that a LoST server could r=
eturn.
>=20
> Brian
>=20
> From: , "Keith (Keith)" 
> Date: Tuesday, March 24, 2015 at 4:56 PM
> To: Brian Rosen , James Winterbottom 
> Cc: "ecrit@ietf.org" 
> Subject: RE: Allowing a full LoST response in the Held Routing response
>=20
> One problem I am having with your argument is that I read RFC 5985 as prov=
iding a protocol between a client and a service which is a LIS. I do not see=
 anything that says the major application supported on that protocol is Lost=
, whereas your argument seems to be that all applications on that protocol n=
eed to support Lost.
> =20
> Can you point me to something that supports your viewpoint.
> =20
> regards
> =20
> Keith
>=20
> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Rosen, Brian
> Sent: 24 March 2015 21:39
> To: James Winterbottom
> Cc: ecrit@ietf.org
> Subject: [Ecrit] Allowing a full LoST response in the Held Routing respons=
e
>=20
> As I stated in IETF 92, I believe the IETF should allow all the possible v=
alues in a LoST response to be returned from a HELD response in situations w=
here a single query is needed or desirable.  As an example, the service boun=
dary may be useful for mobile devices, the service number is very useful, an=
d=20
>=20
> I further take exception to the notion that the mapping response in a rest=
ricted use case would necessarily be difficult or involve misleading data.  T=
he example given is the =E2=80=9Csource=E2=80=9D parameter.  In the cited us=
e case, the HELD server is the authoritative source of the response, and it=E2=
=80=99s URI is a very appropriate value for source.  If it really only has o=
ne value, the =E2=80=9CsourceId=E2=80=9D could be a fixed, short string.
>=20
> I would like to suggest that the text be reworded so the LoST  re=
sponse is used instead of  and to be something like:
>=20
> This document imports the  schema from RFC5222 as the response fr=
om the HELD routing query.   Where the HELD server is not consulting any oth=
er service for the routing data, it would use it=E2=80=99s own URI for the =E2=
=80=9Csource=E2=80=9D function.  Many of the  elements are optional=
 and while they may not be seen in many implementations of HELD routing, the=
y have some value in other deployments.
>=20
> Brian

--Apple-Mail-0D586149-5954-4782-BBC7-190E362E70E0
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


I don't understand why simply adding a=
n extension point to the sequence in the server element won't address your r=
equirement Brian.

Then if you want to return the st=
uff you can, but applications that don't want or need it don't have to be co=
ncerned with it.

Cheers
James

Sent=
 from my iPhone

On 25 Mar 2015, at 9:10 am, "DRAGE, Keith (Kei=
th)" <keith.drage@alcat=
el-lucent.com> wrote:




=





OK, so lets ask the=
 question a different way.


 =
;


Why should an exten=
sion to an extendible protocol cover what should be allowed to be sent in re=
lation to other extensions. Surely anything that the IETF wanted in that res=
pect should have been covered in
 RFC 5985 itself.


 =
;


Keith=










From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]


Sent: 24 March 2015 22:06

To: DRAGE, Keith (Keith); James Winterbottom

Cc: ecrit@ietf.org

Subject: Re: Allowing a full LoST response in the Held Routing respon=
se








I=E2=80=99m not suggesting that there is a LoST server in this architec=
ture.  I=E2=80=99m suggesting that the HELD server that is returning th=
e routing information should be able to return everything that a LoST server=
 could return.







Brian









From: <DRAGE>, "Keith (Keith)=
" <keith.drage@alcatel-=
lucent.com>

Date: Tuesday, March 24, 2015 at 4:=
56 PM

To: Brian Rosen <brian.rosen@neustar.biz>, James Winterbot=
tom <a.james.winterbott=
om@gmail.com>

Cc: "ecrit@ietf.org" <ecrit@ietf.org=
>

Subject: RE: Allowing a full LoST r=
esponse in the Held Routing response














One problem I am ha=
ving with your argument is that I read RFC 5985 as providing a protocol betw=
een a client and a service which is a LIS. I do not see anything that says t=
he major application supported on
 that protocol is Lost, whereas your argument seems to be that all applicati=
ons on that protocol need to support Lost.


 =
;


Can you point me to=
 something that supports your viewpoint.


 =
;


regards


 =
;


Keith=










From: Ecrit [mailto:ecrit-bounces@ietf.org]
On Behalf Of Rosen, Brian

Sent: 24 March 2015 21:39

To: James Winterbottom

Cc: ecrit@ietf.org

Subject: [Ecrit] Allowing a full LoST response in the Held Routing re=
sponse








As I stated in IETF 92, I believe the IETF should allow all the possibl=
e values in a LoST response to be returned from a HELD response in situation=
s where a single query is needed or desirable.  As an example, the serv=
ice boundary may be useful for mobile
 devices, the service number is very useful, and 







I further take exception to the notion that the mapping response in a r=
estricted use case would necessarily be difficult or involve misleading data=
.  The example given is the =E2=80=9Csource=E2=80=9D parameter.  I=
n the cited use case, the HELD server is the authoritative
 source of the response, and it=E2=80=99s URI is a very appropriate value fo=
r source.  If it really only has one value, the =E2=80=9CsourceId=E2=80=
=9D could be a fixed, short string.







I would like to suggest that the text be reworded so the LoST <mappi=
ng> response is used instead of <routingInformation> and to be some=
thing like:







This document imports the <mapping> schema from RFC5222 as the re=
sponse from the HELD routing query.   Where the HELD server is not cons=
ulting any other service for the routing data, it would use it=E2=80=99s own=
 URI for the =E2=80=9Csource=E2=80=9D function.  Many of the <mappin=
g>
 elements are optional and while they may not be seen in many implementation=
s of HELD routing, they have some value in other deployments.







Brian













=

--Apple-Mail-0D586149-5954-4782-BBC7-190E362E70E0--


From nobody Tue Mar 24 15:16:31 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7571A1A66 for ; Tue, 24 Mar 2015 15:16:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 50cjOWrNv52H for ; Tue, 24 Mar 2015 15:16:27 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 E6BBC1A1B28 for ; Tue, 24 Mar 2015 15:16:26 -0700 (PDT)
Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.14.7/8.14.7) with SMTP id t2OMGPg1002389; Tue, 24 Mar 2015 18:16:25 -0400
Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1tbdawraak-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Mar 2015 18:16:25 -0400
Received: from STNTEXMB13.cis.neustar.com ([169.254.3.204]) by stntexhc10.cis.neustar.com ([169.254.4.213]) with mapi id 14.03.0158.001; Tue, 24 Mar 2015 18:16:23 -0400
From: "Rosen, Brian" 
To: "DRAGE, Keith (Keith)" , "James Winterbottom" 
Thread-Topic: Allowing a full LoST response in the Held Routing response
Thread-Index: AQHQZnrm5/Y5NlQVqU2Az0Xn9N4YKJ0sLIzQ///zMgCAAFTogP//re6A
Date: Tue, 24 Mar 2015 22:16:22 +0000
Message-ID: 
References:  <949EF20990823C4C85C18D59AA11AD8B4A11C1B6@FR712WXCHMBA11.zeu.alcatel-lucent.com>  <949EF20990823C4C85C18D59AA11AD8B4A11C21E@FR712WXCHMBA11.zeu.alcatel-lucent.com>
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B4A11C21E@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [192.168.132.33]
Content-Type: multipart/alternative; boundary="_000_D1374B8497691brianrosenneustarbiz_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=nai engine=5700 definitions=7750 signatures=670576
X-Proofpoint-Spam-Reason: safe
Archived-At: 
Cc: "ecrit@ietf.org" 
Subject: Re: [Ecrit] Allowing a full LoST response in the Held Routing response
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Mar 2015 22:16:30 -0000

--_000_D1374B8497691brianrosenneustarbiz_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlIGRvY3VtZW50IGF0IGlzc3VlIGlzIGFuIGV4dGVuc2lvbi4gIEl04oCZcyBwcm92aWRpbmcg
c29tZXRoaW5nIG90aGVyIHRoYW4gbG9jYXRpb24uICBJdCBpcyBiZXlvbmQgd2hhdCB0aGUgd29y
a2luZyBncm91cCBjb25zaWRlcmVkIHdoZW4gSEVMRCB3YXMgZGVmaW5lZC4NCg0KVGhlIExvU1Qg
cmVzcG9uc2Ugd2FzIGNhcmVmdWxseSBjb25zaWRlcmVkIGJ5IHRoZSB3b3JraW5nIGdyb3VwIGFu
ZCBjb250YWlucyBzZXZlcmFsIGl0ZW1zIHRob3VnaHQgdG8gYmUgdXNlZnVsIHRvIGFuIGVudGl0
eSBxdWVyeWluZyBmb3Igcm91dGluZyBvZiBhbiBlbWVyZ2VuY3kgY2FsbC4gIEkgdGhpbmsgdGhh
dCBjb25zaWRlcmF0aW9uIGFwcGxpZXMgZnVsbHkgdG8gdGhlIHByZXNlbnQgZXh0ZW5zaW9uIHRv
IEhFTEQuDQpUaGVyZSBpcyBubyBmdW5kYW1lbnRhbCBkaWZmZXJlbmNlIHRvIGV4dGVuZGluZyBI
RUxEIHRvIGluY2x1ZGUgYSByb3V0ZSB0aGFuIGV4dGVuZGluZyBpdCB0byByZXR1cm4gYW4gZXhw
aXJhdGlvbiBmb3IgdGhhdCByb3V0ZSAoSEVMRCBjb3VsZCBiZSBpbnZva2VkIGJlZm9yZSBhIGNh
bGwsIGZvciBleGFtcGxlKSwgb3IsIG1vcmUgc3BlY2lmaWNhbGx5LCBmb3IgYSBzZXJ2aWNlIG51
bWJlci4NCg0KQnJpYW4NCg0KRnJvbTogPERSQUdFPiwgIktlaXRoIChLZWl0aCkiIDxrZWl0aC5k
cmFnZUBhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRvOmtlaXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50
LmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBNYXJjaCAyNCwgMjAxNSBhdCA1OjEwIFBNDQpUbzogQnJp
YW4gUm9zZW4gPGJyaWFuLnJvc2VuQG5ldXN0YXIuYml6PG1haWx0bzpicmlhbi5yb3NlbkBuZXVz
dGFyLmJpej4+LCBKYW1lcyBXaW50ZXJib3R0b20gPGEuamFtZXMud2ludGVyYm90dG9tQGdtYWls
LmNvbTxtYWlsdG86YS5qYW1lcy53aW50ZXJib3R0b21AZ21haWwuY29tPj4NCkNjOiAiZWNyaXRA
aWV0Zi5vcmc8bWFpbHRvOmVjcml0QGlldGYub3JnPiIgPGVjcml0QGlldGYub3JnPG1haWx0bzpl
Y3JpdEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogQWxsb3dpbmcgYSBmdWxsIExvU1QgcmVzcG9u
c2UgaW4gdGhlIEhlbGQgUm91dGluZyByZXNwb25zZQ0KDQpPSywgc28gbGV0cyBhc2sgdGhlIHF1
ZXN0aW9uIGEgZGlmZmVyZW50IHdheS4NCg0KV2h5IHNob3VsZCBhbiBleHRlbnNpb24gdG8gYW4g
ZXh0ZW5kaWJsZSBwcm90b2NvbCBjb3ZlciB3aGF0IHNob3VsZCBiZSBhbGxvd2VkIHRvIGJlIHNl
bnQgaW4gcmVsYXRpb24gdG8gb3RoZXIgZXh0ZW5zaW9ucy4gU3VyZWx5IGFueXRoaW5nIHRoYXQg
dGhlIElFVEYgd2FudGVkIGluIHRoYXQgcmVzcGVjdCBzaG91bGQgaGF2ZSBiZWVuIGNvdmVyZWQg
aW4gUkZDIDU5ODUgaXRzZWxmLg0KDQpLZWl0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KRnJvbTogUm9zZW4sIEJyaWFuIFttYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5i
aXpdDQpTZW50OiAyNCBNYXJjaCAyMDE1IDIyOjA2DQpUbzogRFJBR0UsIEtlaXRoIChLZWl0aCk7
IEphbWVzIFdpbnRlcmJvdHRvbQ0KQ2M6IGVjcml0QGlldGYub3JnPG1haWx0bzplY3JpdEBpZXRm
Lm9yZz4NClN1YmplY3Q6IFJlOiBBbGxvd2luZyBhIGZ1bGwgTG9TVCByZXNwb25zZSBpbiB0aGUg
SGVsZCBSb3V0aW5nIHJlc3BvbnNlDQoNCknigJltIG5vdCBzdWdnZXN0aW5nIHRoYXQgdGhlcmUg
aXMgYSBMb1NUIHNlcnZlciBpbiB0aGlzIGFyY2hpdGVjdHVyZS4gIEnigJltIHN1Z2dlc3Rpbmcg
dGhhdCB0aGUgSEVMRCBzZXJ2ZXIgdGhhdCBpcyByZXR1cm5pbmcgdGhlIHJvdXRpbmcgaW5mb3Jt
YXRpb24gc2hvdWxkIGJlIGFibGUgdG8gcmV0dXJuIGV2ZXJ5dGhpbmcgdGhhdCBhIExvU1Qgc2Vy
dmVyIGNvdWxkIHJldHVybi4NCg0KQnJpYW4NCg0KRnJvbTogPERSQUdFPiwgIktlaXRoIChLZWl0
aCkiIDxrZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRvOmtlaXRoLmRyYWdlQGFs
Y2F0ZWwtbHVjZW50LmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBNYXJjaCAyNCwgMjAxNSBhdCA0OjU2
IFBNDQpUbzogQnJpYW4gUm9zZW4gPGJyaWFuLnJvc2VuQG5ldXN0YXIuYml6PG1haWx0bzpicmlh
bi5yb3NlbkBuZXVzdGFyLmJpej4+LCBKYW1lcyBXaW50ZXJib3R0b20gPGEuamFtZXMud2ludGVy
Ym90dG9tQGdtYWlsLmNvbTxtYWlsdG86YS5qYW1lcy53aW50ZXJib3R0b21AZ21haWwuY29tPj4N
CkNjOiAiZWNyaXRAaWV0Zi5vcmc8bWFpbHRvOmVjcml0QGlldGYub3JnPiIgPGVjcml0QGlldGYu
b3JnPG1haWx0bzplY3JpdEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogQWxsb3dpbmcgYSBmdWxs
IExvU1QgcmVzcG9uc2UgaW4gdGhlIEhlbGQgUm91dGluZyByZXNwb25zZQ0KDQpPbmUgcHJvYmxl
bSBJIGFtIGhhdmluZyB3aXRoIHlvdXIgYXJndW1lbnQgaXMgdGhhdCBJIHJlYWQgUkZDIDU5ODUg
YXMgcHJvdmlkaW5nIGEgcHJvdG9jb2wgYmV0d2VlbiBhIGNsaWVudCBhbmQgYSBzZXJ2aWNlIHdo
aWNoIGlzIGEgTElTLiBJIGRvIG5vdCBzZWUgYW55dGhpbmcgdGhhdCBzYXlzIHRoZSBtYWpvciBh
cHBsaWNhdGlvbiBzdXBwb3J0ZWQgb24gdGhhdCBwcm90b2NvbCBpcyBMb3N0LCB3aGVyZWFzIHlv
dXIgYXJndW1lbnQgc2VlbXMgdG8gYmUgdGhhdCBhbGwgYXBwbGljYXRpb25zIG9uIHRoYXQgcHJv
dG9jb2wgbmVlZCB0byBzdXBwb3J0IExvc3QuDQoNCkNhbiB5b3UgcG9pbnQgbWUgdG8gc29tZXRo
aW5nIHRoYXQgc3VwcG9ydHMgeW91ciB2aWV3cG9pbnQuDQoNCnJlZ2FyZHMNCg0KS2VpdGgNCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IEVjcml0IFttYWlsdG86ZWNy
aXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvc2VuLCBCcmlhbg0KU2VudDogMjQg
TWFyY2ggMjAxNSAyMTozOQ0KVG86IEphbWVzIFdpbnRlcmJvdHRvbQ0KQ2M6IGVjcml0QGlldGYu
b3JnPG1haWx0bzplY3JpdEBpZXRmLm9yZz4NClN1YmplY3Q6IFtFY3JpdF0gQWxsb3dpbmcgYSBm
dWxsIExvU1QgcmVzcG9uc2UgaW4gdGhlIEhlbGQgUm91dGluZyByZXNwb25zZQ0KDQpBcyBJIHN0
YXRlZCBpbiBJRVRGIDkyLCBJIGJlbGlldmUgdGhlIElFVEYgc2hvdWxkIGFsbG93IGFsbCB0aGUg
cG9zc2libGUgdmFsdWVzIGluIGEgTG9TVCByZXNwb25zZSB0byBiZSByZXR1cm5lZCBmcm9tIGEg
SEVMRCByZXNwb25zZSBpbiBzaXR1YXRpb25zIHdoZXJlIGEgc2luZ2xlIHF1ZXJ5IGlzIG5lZWRl
ZCBvciBkZXNpcmFibGUuICBBcyBhbiBleGFtcGxlLCB0aGUgc2VydmljZSBib3VuZGFyeSBtYXkg
YmUgdXNlZnVsIGZvciBtb2JpbGUgZGV2aWNlcywgdGhlIHNlcnZpY2UgbnVtYmVyIGlzIHZlcnkg
dXNlZnVsLCBhbmQNCg0KSSBmdXJ0aGVyIHRha2UgZXhjZXB0aW9uIHRvIHRoZSBub3Rpb24gdGhh
dCB0aGUgbWFwcGluZyByZXNwb25zZSBpbiBhIHJlc3RyaWN0ZWQgdXNlIGNhc2Ugd291bGQgbmVj
ZXNzYXJpbHkgYmUgZGlmZmljdWx0IG9yIGludm9sdmUgbWlzbGVhZGluZyBkYXRhLiAgVGhlIGV4
YW1wbGUgZ2l2ZW4gaXMgdGhlIOKAnHNvdXJjZeKAnSBwYXJhbWV0ZXIuICBJbiB0aGUgY2l0ZWQg
dXNlIGNhc2UsIHRoZSBIRUxEIHNlcnZlciBpcyB0aGUgYXV0aG9yaXRhdGl2ZSBzb3VyY2Ugb2Yg
dGhlIHJlc3BvbnNlLCBhbmQgaXTigJlzIFVSSSBpcyBhIHZlcnkgYXBwcm9wcmlhdGUgdmFsdWUg
Zm9yIHNvdXJjZS4gIElmIGl0IHJlYWxseSBvbmx5IGhhcyBvbmUgdmFsdWUsIHRoZSDigJxzb3Vy
Y2VJZOKAnSBjb3VsZCBiZSBhIGZpeGVkLCBzaG9ydCBzdHJpbmcuDQoNCkkgd291bGQgbGlrZSB0
byBzdWdnZXN0IHRoYXQgdGhlIHRleHQgYmUgcmV3b3JkZWQgc28gdGhlIExvU1QgPG1hcHBpbmc+
IHJlc3BvbnNlIGlzIHVzZWQgaW5zdGVhZCBvZiA8cm91dGluZ0luZm9ybWF0aW9uPiBhbmQgdG8g
YmUgc29tZXRoaW5nIGxpa2U6DQoNClRoaXMgZG9jdW1lbnQgaW1wb3J0cyB0aGUgPG1hcHBpbmc+
IHNjaGVtYSBmcm9tIFJGQzUyMjIgYXMgdGhlIHJlc3BvbnNlIGZyb20gdGhlIEhFTEQgcm91dGlu
ZyBxdWVyeS4gICBXaGVyZSB0aGUgSEVMRCBzZXJ2ZXIgaXMgbm90IGNvbnN1bHRpbmcgYW55IG90
aGVyIHNlcnZpY2UgZm9yIHRoZSByb3V0aW5nIGRhdGEsIGl0IHdvdWxkIHVzZSBpdOKAmXMgb3du
IFVSSSBmb3IgdGhlIOKAnHNvdXJjZeKAnSBmdW5jdGlvbi4gIE1hbnkgb2YgdGhlIDxtYXBwaW5n
PiBlbGVtZW50cyBhcmUgb3B0aW9uYWwgYW5kIHdoaWxlIHRoZXkgbWF5IG5vdCBiZSBzZWVuIGlu
IG1hbnkgaW1wbGVtZW50YXRpb25zIG9mIEhFTEQgcm91dGluZywgdGhleSBoYXZlIHNvbWUgdmFs
dWUgaW4gb3RoZXIgZGVwbG95bWVudHMuDQoNCkJyaWFuDQo=

--_000_D1374B8497691brianrosenneustarbiz_
Content-Type: text/html; charset="utf-8"
Content-ID: <605AA2280C96554EB703B524F9801A33@neustar.biz>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5UaGUgZG9jdW1l
bnQgYXQgaXNzdWUgaXMgYW4gZXh0ZW5zaW9uLiAmbmJzcDtJdOKAmXMgcHJvdmlkaW5nIHNvbWV0
aGluZyBvdGhlciB0aGFuIGxvY2F0aW9uLiAmbmJzcDtJdCBpcyBiZXlvbmQgd2hhdCB0aGUgd29y
a2luZyBncm91cCBjb25zaWRlcmVkIHdoZW4gSEVMRCB3YXMgZGVmaW5lZC48L2Rpdj4NCjxkaXY+
PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBMb1NUIHJlc3BvbnNlIHdhcyBjYXJlZnVsbHkgY29uc2lk
ZXJlZCBieSB0aGUgd29ya2luZyBncm91cCBhbmQgY29udGFpbnMgc2V2ZXJhbCBpdGVtcyB0aG91
Z2h0IHRvIGJlIHVzZWZ1bCB0byBhbiBlbnRpdHkgcXVlcnlpbmcgZm9yIHJvdXRpbmcgb2YgYW4g
ZW1lcmdlbmN5IGNhbGwuICZuYnNwO0kgdGhpbmsgdGhhdCBjb25zaWRlcmF0aW9uIGFwcGxpZXMg
ZnVsbHkgdG8gdGhlIHByZXNlbnQgZXh0ZW5zaW9uIHRvIEhFTEQuPC9kaXY+DQo8ZGl2PlRoZXJl
IGlzIG5vIGZ1bmRhbWVudGFsIGRpZmZlcmVuY2UgdG8gZXh0ZW5kaW5nIEhFTEQgdG8gaW5jbHVk
ZSBhIHJvdXRlIHRoYW4gZXh0ZW5kaW5nIGl0IHRvIHJldHVybiBhbiBleHBpcmF0aW9uIGZvciB0
aGF0IHJvdXRlIChIRUxEIGNvdWxkIGJlIGludm9rZWQgYmVmb3JlIGEgY2FsbCwgZm9yIGV4YW1w
bGUpLCBvciwgbW9yZSBzcGVjaWZpY2FsbHksIGZvciBhIHNlcnZpY2UgbnVtYmVyLjwvZGl2Pg0K
PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QnJpYW48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8
c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6
Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJP
UkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJ
TkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJP
UkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQ
QURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8
L3NwYW4+Jmx0O0RSQUdFJmd0OywgJnF1b3Q7S2VpdGggKEtlaXRoKSZxdW90OyAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOmtlaXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbSI+a2VpdGguZHJhZ2VAYWxj
YXRlbC1sdWNlbnQuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s
ZCI+RGF0ZTogPC9zcGFuPlR1ZXNkYXksIE1hcmNoIDI0LCAyMDE1IGF0IDU6MTAgUE08YnI+DQo8
c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5CcmlhbiBSb3NlbiAmbHQ7
PGEgaHJlZj0ibWFpbHRvOmJyaWFuLnJvc2VuQG5ldXN0YXIuYml6Ij5icmlhbi5yb3NlbkBuZXVz
dGFyLmJpejwvYT4mZ3Q7LCBKYW1lcyBXaW50ZXJib3R0b20gJmx0OzxhIGhyZWY9Im1haWx0bzph
LmphbWVzLndpbnRlcmJvdHRvbUBnbWFpbC5jb20iPmEuamFtZXMud2ludGVyYm90dG9tQGdtYWls
LmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3Nw
YW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmVjcml0QGlldGYub3JnIj5lY3JpdEBpZXRmLm9yZzwv
YT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzplY3JpdEBpZXRmLm9yZyI+ZWNyaXRAaWV0Zi5v
cmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8
L3NwYW4+UkU6IEFsbG93aW5nIGEgZnVsbCBMb1NUIHJlc3BvbnNlIGluIHRoZSBIZWxkIFJvdXRp
bmcgcmVzcG9uc2U8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPG1ldGEg
Y29udGVudD0iTVNIVE1MIDYuMDAuMjkwMC42NTUwIiBuYW1lPSJHRU5FUkFUT1IiPg0KPGRpdiBz
dHlsZT0iRk9OVC1TSVpFOiAxNHB4OyBDT0xPUjogcmdiKDAsMCwwKTsgRk9OVC1GQU1JTFk6IENh
bGlicmksIHNhbnMtc2VyaWY7IFdPUkQtV1JBUDogYnJlYWstd29yZDsgd2Via2l0LW5ic3AtbW9k
ZTogc3BhY2U7IHdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZSI+DQo8ZGl2Pjxz
cGFuIGNsYXNzPSI5MDUyOTA4MjItMjQwMzIwMTUiPjxmb250IHNpemU9IjQiPk9LLCBzbyBsZXRz
IGFzayB0aGUgcXVlc3Rpb24gYSBkaWZmZXJlbnQgd2F5LjwvZm9udD48L3NwYW4+PC9kaXY+DQo8
ZGl2PjxzcGFuIGNsYXNzPSI5MDUyOTA4MjItMjQwMzIwMTUiPjxmb250IHNpemU9IjQiPjwvZm9u
dD48L3NwYW4+Jm5ic3A7PC9kaXY+DQo8ZGl2PjxzcGFuIGNsYXNzPSI5MDUyOTA4MjItMjQwMzIw
MTUiPjxmb250IHNpemU9IjQiPldoeSBzaG91bGQgYW4gZXh0ZW5zaW9uIHRvIGFuIGV4dGVuZGli
bGUgcHJvdG9jb2wgY292ZXIgd2hhdCBzaG91bGQgYmUgYWxsb3dlZCB0byBiZSBzZW50IGluIHJl
bGF0aW9uIHRvIG90aGVyIGV4dGVuc2lvbnMuIFN1cmVseSBhbnl0aGluZyB0aGF0IHRoZSBJRVRG
IHdhbnRlZCBpbiB0aGF0IHJlc3BlY3Qgc2hvdWxkIGhhdmUgYmVlbiBjb3ZlcmVkIGluDQogUkZD
IDU5ODUgaXRzZWxmLjwvZm9udD48L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIGNsYXNzPSI5MDUy
OTA4MjItMjQwMzIwMTUiPjxmb250IHNpemU9IjQiPjwvZm9udD48L3NwYW4+Jm5ic3A7PC9kaXY+
DQo8ZGl2PjxzcGFuIGNsYXNzPSI5MDUyOTA4MjItMjQwMzIwMTUiPjxmb250IHNpemU9IjQiPktl
aXRoPC9mb250Pjwvc3Bhbj48L2Rpdj4NCjxicj4NCjxibG9ja3F1b3RlIGRpcj0ibHRyIiBzdHls
ZT0iUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAw
MDAwIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KPGRpdiBjbGFzcz0iT3V0bG9va01l
c3NhZ2VIZWFkZXIiIGxhbmc9ImVuLXVzIiBkaXI9Imx0ciIgYWxpZ249ImxlZnQiPg0KPGhyIHRh
YmluZGV4PSItMSI+DQo8Zm9udCBmYWNlPSJUYWhvbWEiIHNpemU9IjIiPjxiPkZyb206PC9iPiBS
b3NlbiwgQnJpYW4gWzxhIGhyZWY9Im1haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpeiI+bWFp
bHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAyNCBN
YXJjaCAyMDE1IDIyOjA2PGJyPg0KPGI+VG86PC9iPiBEUkFHRSwgS2VpdGggKEtlaXRoKTsgSmFt
ZXMgV2ludGVyYm90dG9tPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86ZWNyaXRAaWV0
Zi5vcmciPmVjcml0QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogQWxsb3dp
bmcgYSBmdWxsIExvU1QgcmVzcG9uc2UgaW4gdGhlIEhlbGQgUm91dGluZyByZXNwb25zZTxicj4N
CjwvZm9udD48YnI+DQo8L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2PknigJltIG5vdCBzdWdnZXN0
aW5nIHRoYXQgdGhlcmUgaXMgYSBMb1NUIHNlcnZlciBpbiB0aGlzIGFyY2hpdGVjdHVyZS4gJm5i
c3A7SeKAmW0gc3VnZ2VzdGluZyB0aGF0IHRoZSBIRUxEIHNlcnZlciB0aGF0IGlzIHJldHVybmlu
ZyB0aGUgcm91dGluZyBpbmZvcm1hdGlvbiBzaG91bGQgYmUgYWJsZSB0byByZXR1cm4gZXZlcnl0
aGluZyB0aGF0IGEgTG9TVCBzZXJ2ZXIgY291bGQgcmV0dXJuLjwvZGl2Pg0KPGRpdj48YnI+DQo8
L2Rpdj4NCjxkaXY+QnJpYW48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xL
X1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9u
ZTsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgUEFE
RElORy1MRUZUOiAwaW47IEZPTlQtU0laRTogMTFwdDsgUEFERElORy1CT1RUT006IDBpbjsgQk9S
REVSLUxFRlQ6IG1lZGl1bSBub25lOyBDT0xPUjogYmxhY2s7IFBBRERJTkctVE9QOiAzcHQ7IEJP
UkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBGT05ULUZBTUlMWTogQ2FsaWJyaTsgVEVYVC1BTElH
TjogbGVmdCI+DQo8c3BhbiBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPkZyb206IDwvc3Bhbj4m
bHQ7RFJBR0UmZ3Q7LCAmcXVvdDtLZWl0aCAoS2VpdGgpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls
dG86a2VpdGguZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tIj5rZWl0aC5kcmFnZUBhbGNhdGVsLWx1
Y2VudC5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+RGF0
ZTogPC9zcGFuPlR1ZXNkYXksIE1hcmNoIDI0LCAyMDE1IGF0IDQ6NTYgUE08YnI+DQo8c3BhbiBz
dHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPlRvOiA8L3NwYW4+QnJpYW4gUm9zZW4gJmx0OzxhIGhy
ZWY9Im1haWx0bzpicmlhbi5yb3NlbkBuZXVzdGFyLmJpeiI+YnJpYW4ucm9zZW5AbmV1c3Rhci5i
aXo8L2E+Jmd0OywgSmFtZXMgV2ludGVyYm90dG9tICZsdDs8YSBocmVmPSJtYWlsdG86YS5qYW1l
cy53aW50ZXJib3R0b21AZ21haWwuY29tIj5hLmphbWVzLndpbnRlcmJvdHRvbUBnbWFpbC5jb208
L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+Q2M6IDwvc3Bhbj4m
cXVvdDs8YSBocmVmPSJtYWlsdG86ZWNyaXRAaWV0Zi5vcmciPmVjcml0QGlldGYub3JnPC9hPiZx
dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVjcml0QGlldGYub3JnIj5lY3JpdEBpZXRmLm9yZzwv
YT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5TdWJqZWN0OiA8L3Nw
YW4+UkU6IEFsbG93aW5nIGEgZnVsbCBMb1NUIHJlc3BvbnNlIGluIHRoZSBIZWxkIFJvdXRpbmcg
cmVzcG9uc2U8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPG1ldGEgY29u
dGVudD0iTVNIVE1MIDYuMDAuMjkwMC42NTUwIiBuYW1lPSJHRU5FUkFUT1IiPg0KPGRpdiBzdHls
ZT0iRk9OVC1TSVpFOiAxNHB4OyBDT0xPUjogcmdiKDAsMCwwKTsgRk9OVC1GQU1JTFk6IENhbGli
cmksIHNhbnMtc2VyaWY7IFdPUkQtV1JBUDogYnJlYWstd29yZDsgd2Via2l0LW5ic3AtbW9kZTog
c3BhY2U7IHdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZSI+DQo8ZGl2PjxzcGFu
IGNsYXNzPSIzMzk1OTUxMjEtMjQwMzIwMTUiPjxmb250IHNpemU9IjQiPk9uZSBwcm9ibGVtIEkg
YW0gaGF2aW5nIHdpdGggeW91ciBhcmd1bWVudCBpcyB0aGF0IEkgcmVhZCBSRkMgNTk4NSBhcyBw
cm92aWRpbmcgYSBwcm90b2NvbCBiZXR3ZWVuIGEgY2xpZW50IGFuZCBhIHNlcnZpY2Ugd2hpY2gg
aXMgYSBMSVMuIEkgZG8gbm90IHNlZSBhbnl0aGluZyB0aGF0IHNheXMgdGhlIG1ham9yIGFwcGxp
Y2F0aW9uIHN1cHBvcnRlZCBvbg0KIHRoYXQgcHJvdG9jb2wgaXMgTG9zdCwgd2hlcmVhcyB5b3Vy
IGFyZ3VtZW50IHNlZW1zIHRvIGJlIHRoYXQgYWxsIGFwcGxpY2F0aW9ucyBvbiB0aGF0IHByb3Rv
Y29sIG5lZWQgdG8gc3VwcG9ydCBMb3N0LjwvZm9udD48L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFu
IGNsYXNzPSIzMzk1OTUxMjEtMjQwMzIwMTUiPjxmb250IHNpemU9IjQiPjwvZm9udD48L3NwYW4+
Jm5ic3A7PC9kaXY+DQo8ZGl2PjxzcGFuIGNsYXNzPSIzMzk1OTUxMjEtMjQwMzIwMTUiPjxmb250
IHNpemU9IjQiPkNhbiB5b3UgcG9pbnQgbWUgdG8gc29tZXRoaW5nIHRoYXQgc3VwcG9ydHMgeW91
ciB2aWV3cG9pbnQuPC9mb250Pjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gY2xhc3M9IjMzOTU5
NTEyMS0yNDAzMjAxNSI+PGZvbnQgc2l6ZT0iNCI+PC9mb250Pjwvc3Bhbj4mbmJzcDs8L2Rpdj4N
CjxkaXY+PHNwYW4gY2xhc3M9IjMzOTU5NTEyMS0yNDAzMjAxNSI+PGZvbnQgc2l6ZT0iNCI+cmVn
YXJkczwvZm9udD48L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIGNsYXNzPSIzMzk1OTUxMjEtMjQw
MzIwMTUiPjxmb250IHNpemU9IjQiPjwvZm9udD48L3NwYW4+Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxz
cGFuIGNsYXNzPSIzMzk1OTUxMjEtMjQwMzIwMTUiPjxmb250IHNpemU9IjQiPktlaXRoPC9mb250
Pjwvc3Bhbj48L2Rpdj4NCjxicj4NCjxibG9ja3F1b3RlIGRpcj0ibHRyIiBzdHlsZT0iUEFERElO
Ry1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBz
b2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KPGRpdiBjbGFzcz0iT3V0bG9va01lc3NhZ2VIZWFk
ZXIiIGxhbmc9ImVuLXVzIiBkaXI9Imx0ciIgYWxpZ249ImxlZnQiPg0KPGhyIHRhYmluZGV4PSIt
MSI+DQo8Zm9udCBmYWNlPSJUYWhvbWEiIHNpemU9IjIiPjxiPkZyb206PC9iPiBFY3JpdCBbPGEg
aHJlZj0ibWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzplY3JpdC1ib3VuY2Vz
QGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9zZW4sIEJyaWFuPGJyPg0KPGI+
U2VudDo8L2I+IDI0IE1hcmNoIDIwMTUgMjE6Mzk8YnI+DQo8Yj5Ubzo8L2I+IEphbWVzIFdpbnRl
cmJvdHRvbTxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmVjcml0QGlldGYub3JnIj5l
Y3JpdEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0Vjcml0XSBBbGxvd2luZyBh
IGZ1bGwgTG9TVCByZXNwb25zZSBpbiB0aGUgSGVsZCBSb3V0aW5nIHJlc3BvbnNlPGJyPg0KPC9m
b250Pjxicj4NCjwvZGl2Pg0KPGRpdj48L2Rpdj4NCjxkaXY+QXMgSSBzdGF0ZWQgaW4gSUVURiA5
MiwgSSBiZWxpZXZlIHRoZSBJRVRGIHNob3VsZCBhbGxvdyBhbGwgdGhlIHBvc3NpYmxlIHZhbHVl
cyBpbiBhIExvU1QgcmVzcG9uc2UgdG8gYmUgcmV0dXJuZWQgZnJvbSBhIEhFTEQgcmVzcG9uc2Ug
aW4gc2l0dWF0aW9ucyB3aGVyZSBhIHNpbmdsZSBxdWVyeSBpcyBuZWVkZWQgb3IgZGVzaXJhYmxl
LiAmbmJzcDtBcyBhbiBleGFtcGxlLCB0aGUgc2VydmljZSBib3VuZGFyeSBtYXkgYmUgdXNlZnVs
IGZvciBtb2JpbGUNCiBkZXZpY2VzLCB0aGUgc2VydmljZSBudW1iZXIgaXMgdmVyeSB1c2VmdWws
IGFuZCZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBmdXJ0aGVyIHRha2Ug
ZXhjZXB0aW9uIHRvIHRoZSBub3Rpb24gdGhhdCB0aGUgbWFwcGluZyByZXNwb25zZSBpbiBhIHJl
c3RyaWN0ZWQgdXNlIGNhc2Ugd291bGQgbmVjZXNzYXJpbHkgYmUgZGlmZmljdWx0IG9yIGludm9s
dmUgbWlzbGVhZGluZyBkYXRhLiAmbmJzcDtUaGUgZXhhbXBsZSBnaXZlbiBpcyB0aGUg4oCcc291
cmNl4oCdIHBhcmFtZXRlci4gJm5ic3A7SW4gdGhlIGNpdGVkIHVzZSBjYXNlLCB0aGUgSEVMRCBz
ZXJ2ZXIgaXMgdGhlIGF1dGhvcml0YXRpdmUNCiBzb3VyY2Ugb2YgdGhlIHJlc3BvbnNlLCBhbmQg
aXTigJlzIFVSSSBpcyBhIHZlcnkgYXBwcm9wcmlhdGUgdmFsdWUgZm9yIHNvdXJjZS4gJm5ic3A7
SWYgaXQgcmVhbGx5IG9ubHkgaGFzIG9uZSB2YWx1ZSwgdGhlIOKAnHNvdXJjZUlk4oCdIGNvdWxk
IGJlIGEgZml4ZWQsIHNob3J0IHN0cmluZy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2
Pkkgd291bGQgbGlrZSB0byBzdWdnZXN0IHRoYXQgdGhlIHRleHQgYmUgcmV3b3JkZWQgc28gdGhl
IExvU1QgJmx0O21hcHBpbmcmZ3Q7IHJlc3BvbnNlIGlzIHVzZWQgaW5zdGVhZCBvZiAmbHQ7cm91
dGluZ0luZm9ybWF0aW9uJmd0OyBhbmQgdG8gYmUgc29tZXRoaW5nIGxpa2U6PC9kaXY+DQo8ZGl2
Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGlzIGRvY3VtZW50IGltcG9ydHMgdGhlICZsdDttYXBwaW5n
Jmd0OyBzY2hlbWEgZnJvbSBSRkM1MjIyIGFzIHRoZSByZXNwb25zZSBmcm9tIHRoZSBIRUxEIHJv
dXRpbmcgcXVlcnkuICZuYnNwOyBXaGVyZSB0aGUgSEVMRCBzZXJ2ZXIgaXMgbm90IGNvbnN1bHRp
bmcgYW55IG90aGVyIHNlcnZpY2UgZm9yIHRoZSByb3V0aW5nIGRhdGEsIGl0IHdvdWxkIHVzZSBp
dOKAmXMgb3duIFVSSSBmb3IgdGhlIOKAnHNvdXJjZeKAnSBmdW5jdGlvbi4gJm5ic3A7TWFueSBv
ZiB0aGUgJmx0O21hcHBpbmcmZ3Q7DQogZWxlbWVudHMgYXJlIG9wdGlvbmFsIGFuZCB3aGlsZSB0
aGV5IG1heSBub3QgYmUgc2VlbiBpbiBtYW55IGltcGxlbWVudGF0aW9ucyBvZiBIRUxEIHJvdXRp
bmcsIHRoZXkgaGF2ZSBzb21lIHZhbHVlIGluIG90aGVyIGRlcGxveW1lbnRzLjwvZGl2Pg0KPGRp
dj48YnI+DQo8L2Rpdj4NCjxkaXY+QnJpYW48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K
PC9kaXY+DQo8L3NwYW4+PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwv
Ym9keT4NCjwvaHRtbD4NCg==

--_000_D1374B8497691brianrosenneustarbiz_--


From nobody Tue Mar 24 15:19:49 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C67F1AC426 for ; Tue, 24 Mar 2015 15:19:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 OCm_2-r4G-R4 for ; Tue, 24 Mar 2015 15:19:45 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 BB6F51A1B4C for ; Tue, 24 Mar 2015 15:19:45 -0700 (PDT)
Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.14.7/8.14.7) with SMTP id t2OMJhnP004379; Tue, 24 Mar 2015 18:19:43 -0400
Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1tbdawraeg-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Mar 2015 18:19:43 -0400
Received: from STNTEXMB13.cis.neustar.com ([169.254.3.204]) by stntexhc10.cis.neustar.com ([169.254.4.213]) with mapi id 14.03.0158.001; Tue, 24 Mar 2015 18:19:42 -0400
From: "Rosen, Brian" 
To: James Winterbottom , "DRAGE, Keith (Keith)" 
Thread-Topic: Allowing a full LoST response in the Held Routing response
Thread-Index: AQHQZnrm5/Y5NlQVqU2Az0Xn9N4YKJ0sLIzQ///zMgCAAFTogIAAAMqA//+uFAA=
Date: Tue, 24 Mar 2015 22:19:42 +0000
Message-ID: 
References:  <949EF20990823C4C85C18D59AA11AD8B4A11C1B6@FR712WXCHMBA11.zeu.alcatel-lucent.com>  <949EF20990823C4C85C18D59AA11AD8B4A11C21E@FR712WXCHMBA11.zeu.alcatel-lucent.com> <0085A304-7F6E-45FC-B7E3-6594AFD0F54F@gmail.com>
In-Reply-To: <0085A304-7F6E-45FC-B7E3-6594AFD0F54F@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [192.168.132.33]
Content-Type: multipart/alternative; boundary="_000_D1374C6D9769Bbrianrosenneustarbiz_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=nai engine=5700 definitions=7750 signatures=670576
X-Proofpoint-Spam-Reason: safe
Archived-At: 
Cc: "ecrit@ietf.org" 
Subject: Re: [Ecrit] Allowing a full LoST response in the Held Routing response
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Mar 2015 22:19:48 -0000

--_000_D1374C6D9769Bbrianrosenneustarbiz_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QmVjYXVzZSB3ZSBoYXZlIGFscmVhZHkgZGVmaW5lZCBhbiBhcHByb3ByaWF0ZSByZXNwb25zZSB0
byBhIHJlcXVlc3QgZm9yIGVtZXJnZW5jeSBjYWxsIHJvdXRlLCBhbmQgSSB0aGluayByZXF1aXJp
bmcgc29tZW9uZSB0byBjb21lIGJhY2sgbGF0ZXIgYW5kIGFkZCBzdHVmZiB3ZSBhbHJlYWR5IGJl
bGlldmUgaXMgdXNlZnVsIGlzIGJhZCBwcm90b2NvbCBkZXNpZ24uICBEbyBpdCByaWdodCB0aGUg
Zmlyc3QgdGltZS4NCldlIHRob3VnaHQgYWJvdXQgdGhpcyBzdHVmZiwgd2UgZGVjaWRlZCB3aGF0
IHdlIHRob3VnaHQgd2FzIHVzZWZ1bC4gIEkgdGhpbmsgaGF2aW5nIHRoaXMgYWx0ZXJuYXRpdmUg
d2F5IHRvIGdldCBhIHJvdXRlIGRvZXNu4oCZdCBjaGFuZ2Ugd2hhdCBpcyBpbiB0aGUgcmVzcG9u
c2UsIGluIHRoZSBzYW1lIHdheSB0aGF0IHRoZSBmb3JtIG9mIGxvY2F0aW9uIGlzIHRoZSBzYW1l
IHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciB3ZSB1c2UgU0lQIFByZXNlbmNlIG9yIEhFTEQgdG8gZ2V0
IGl0LiAgVGhpcyBpcyBhIGVtZXJnZW5jeSBjYWxsIHJvdXRpbmcgcmVzcG9uc2UsIHdlIGhhdmUg
b25lLCByZS11c2UgaXQuDQoNCkJyaWFuDQoNCkZyb206IEphbWVzIFdpbnRlcmJvdHRvbSA8YS5q
YW1lcy53aW50ZXJib3R0b21AZ21haWwuY29tPG1haWx0bzphLmphbWVzLndpbnRlcmJvdHRvbUBn
bWFpbC5jb20+Pg0KRGF0ZTogVHVlc2RheSwgTWFyY2ggMjQsIDIwMTUgYXQgNToxMiBQTQ0KVG86
ICJEUkFHRSwgS2VpdGggKEtlaXRoKSIgPGtlaXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbTxt
YWlsdG86a2VpdGguZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tPj4NCkNjOiBCcmlhbiBSb3NlbiA8
YnJpYW4ucm9zZW5AbmV1c3Rhci5iaXo8bWFpbHRvOmJyaWFuLnJvc2VuQG5ldXN0YXIuYml6Pj4s
ICJlY3JpdEBpZXRmLm9yZzxtYWlsdG86ZWNyaXRAaWV0Zi5vcmc+IiA8ZWNyaXRAaWV0Zi5vcmc8
bWFpbHRvOmVjcml0QGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBBbGxvd2luZyBhIGZ1bGwgTG9T
VCByZXNwb25zZSBpbiB0aGUgSGVsZCBSb3V0aW5nIHJlc3BvbnNlDQoNCkkgZG9uJ3QgdW5kZXJz
dGFuZCB3aHkgc2ltcGx5IGFkZGluZyBhbiBleHRlbnNpb24gcG9pbnQgdG8gdGhlIHNlcXVlbmNl
IGluIHRoZSBzZXJ2ZXIgZWxlbWVudCB3b24ndCBhZGRyZXNzIHlvdXIgcmVxdWlyZW1lbnQgQnJp
YW4uDQoNClRoZW4gaWYgeW91IHdhbnQgdG8gcmV0dXJuIHRoZSBzdHVmZiB5b3UgY2FuLCBidXQg
YXBwbGljYXRpb25zIHRoYXQgZG9uJ3Qgd2FudCBvciBuZWVkIGl0IGRvbid0IGhhdmUgdG8gYmUg
Y29uY2VybmVkIHdpdGggaXQuDQoNCkNoZWVycw0KSmFtZXMNCg0KU2VudCBmcm9tIG15IGlQaG9u
ZQ0KDQpPbiAyNSBNYXIgMjAxNSwgYXQgOToxMCBhbSwgIkRSQUdFLCBLZWl0aCAoS2VpdGgpIiA8
a2VpdGguZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzprZWl0aC5kcmFnZUBhbGNhdGVs
LWx1Y2VudC5jb20+PiB3cm90ZToNCg0KT0ssIHNvIGxldHMgYXNrIHRoZSBxdWVzdGlvbiBhIGRp
ZmZlcmVudCB3YXkuDQoNCldoeSBzaG91bGQgYW4gZXh0ZW5zaW9uIHRvIGFuIGV4dGVuZGlibGUg
cHJvdG9jb2wgY292ZXIgd2hhdCBzaG91bGQgYmUgYWxsb3dlZCB0byBiZSBzZW50IGluIHJlbGF0
aW9uIHRvIG90aGVyIGV4dGVuc2lvbnMuIFN1cmVseSBhbnl0aGluZyB0aGF0IHRoZSBJRVRGIHdh
bnRlZCBpbiB0aGF0IHJlc3BlY3Qgc2hvdWxkIGhhdmUgYmVlbiBjb3ZlcmVkIGluIFJGQyA1OTg1
IGl0c2VsZi4NCg0KS2VpdGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZy
b206IFJvc2VuLCBCcmlhbiBbbWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6XQ0KU2VudDog
MjQgTWFyY2ggMjAxNSAyMjowNg0KVG86IERSQUdFLCBLZWl0aCAoS2VpdGgpOyBKYW1lcyBXaW50
ZXJib3R0b20NCkNjOiBlY3JpdEBpZXRmLm9yZzxtYWlsdG86ZWNyaXRAaWV0Zi5vcmc+DQpTdWJq
ZWN0OiBSZTogQWxsb3dpbmcgYSBmdWxsIExvU1QgcmVzcG9uc2UgaW4gdGhlIEhlbGQgUm91dGlu
ZyByZXNwb25zZQ0KDQpJ4oCZbSBub3Qgc3VnZ2VzdGluZyB0aGF0IHRoZXJlIGlzIGEgTG9TVCBz
ZXJ2ZXIgaW4gdGhpcyBhcmNoaXRlY3R1cmUuICBJ4oCZbSBzdWdnZXN0aW5nIHRoYXQgdGhlIEhF
TEQgc2VydmVyIHRoYXQgaXMgcmV0dXJuaW5nIHRoZSByb3V0aW5nIGluZm9ybWF0aW9uIHNob3Vs
ZCBiZSBhYmxlIHRvIHJldHVybiBldmVyeXRoaW5nIHRoYXQgYSBMb1NUIHNlcnZlciBjb3VsZCBy
ZXR1cm4uDQoNCkJyaWFuDQoNCkZyb206IDxEUkFHRT4sICJLZWl0aCAoS2VpdGgpIiA8a2VpdGgu
ZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzprZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2Vu
dC5jb20+Pg0KRGF0ZTogVHVlc2RheSwgTWFyY2ggMjQsIDIwMTUgYXQgNDo1NiBQTQ0KVG86IEJy
aWFuIFJvc2VuIDxicmlhbi5yb3NlbkBuZXVzdGFyLmJpejxtYWlsdG86YnJpYW4ucm9zZW5AbmV1
c3Rhci5iaXo+PiwgSmFtZXMgV2ludGVyYm90dG9tIDxhLmphbWVzLndpbnRlcmJvdHRvbUBnbWFp
bC5jb208bWFpbHRvOmEuamFtZXMud2ludGVyYm90dG9tQGdtYWlsLmNvbT4+DQpDYzogImVjcml0
QGlldGYub3JnPG1haWx0bzplY3JpdEBpZXRmLm9yZz4iIDxlY3JpdEBpZXRmLm9yZzxtYWlsdG86
ZWNyaXRAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUkU6IEFsbG93aW5nIGEgZnVsbCBMb1NUIHJlc3Bv
bnNlIGluIHRoZSBIZWxkIFJvdXRpbmcgcmVzcG9uc2UNCg0KT25lIHByb2JsZW0gSSBhbSBoYXZp
bmcgd2l0aCB5b3VyIGFyZ3VtZW50IGlzIHRoYXQgSSByZWFkIFJGQyA1OTg1IGFzIHByb3ZpZGlu
ZyBhIHByb3RvY29sIGJldHdlZW4gYSBjbGllbnQgYW5kIGEgc2VydmljZSB3aGljaCBpcyBhIExJ
Uy4gSSBkbyBub3Qgc2VlIGFueXRoaW5nIHRoYXQgc2F5cyB0aGUgbWFqb3IgYXBwbGljYXRpb24g
c3VwcG9ydGVkIG9uIHRoYXQgcHJvdG9jb2wgaXMgTG9zdCwgd2hlcmVhcyB5b3VyIGFyZ3VtZW50
IHNlZW1zIHRvIGJlIHRoYXQgYWxsIGFwcGxpY2F0aW9ucyBvbiB0aGF0IHByb3RvY29sIG5lZWQg
dG8gc3VwcG9ydCBMb3N0Lg0KDQpDYW4geW91IHBvaW50IG1lIHRvIHNvbWV0aGluZyB0aGF0IHN1
cHBvcnRzIHlvdXIgdmlld3BvaW50Lg0KDQpyZWdhcmRzDQoNCktlaXRoDQoNCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBFY3JpdCBbbWFpbHRvOmVjcml0LWJvdW5jZXNA
aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb3NlbiwgQnJpYW4NClNlbnQ6IDI0IE1hcmNoIDIwMTUg
MjE6MzkNClRvOiBKYW1lcyBXaW50ZXJib3R0b20NCkNjOiBlY3JpdEBpZXRmLm9yZzxtYWlsdG86
ZWNyaXRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbRWNyaXRdIEFsbG93aW5nIGEgZnVsbCBMb1NUIHJl
c3BvbnNlIGluIHRoZSBIZWxkIFJvdXRpbmcgcmVzcG9uc2UNCg0KQXMgSSBzdGF0ZWQgaW4gSUVU
RiA5MiwgSSBiZWxpZXZlIHRoZSBJRVRGIHNob3VsZCBhbGxvdyBhbGwgdGhlIHBvc3NpYmxlIHZh
bHVlcyBpbiBhIExvU1QgcmVzcG9uc2UgdG8gYmUgcmV0dXJuZWQgZnJvbSBhIEhFTEQgcmVzcG9u
c2UgaW4gc2l0dWF0aW9ucyB3aGVyZSBhIHNpbmdsZSBxdWVyeSBpcyBuZWVkZWQgb3IgZGVzaXJh
YmxlLiAgQXMgYW4gZXhhbXBsZSwgdGhlIHNlcnZpY2UgYm91bmRhcnkgbWF5IGJlIHVzZWZ1bCBm
b3IgbW9iaWxlIGRldmljZXMsIHRoZSBzZXJ2aWNlIG51bWJlciBpcyB2ZXJ5IHVzZWZ1bCwgYW5k
DQoNCkkgZnVydGhlciB0YWtlIGV4Y2VwdGlvbiB0byB0aGUgbm90aW9uIHRoYXQgdGhlIG1hcHBp
bmcgcmVzcG9uc2UgaW4gYSByZXN0cmljdGVkIHVzZSBjYXNlIHdvdWxkIG5lY2Vzc2FyaWx5IGJl
IGRpZmZpY3VsdCBvciBpbnZvbHZlIG1pc2xlYWRpbmcgZGF0YS4gIFRoZSBleGFtcGxlIGdpdmVu
IGlzIHRoZSDigJxzb3VyY2XigJ0gcGFyYW1ldGVyLiAgSW4gdGhlIGNpdGVkIHVzZSBjYXNlLCB0
aGUgSEVMRCBzZXJ2ZXIgaXMgdGhlIGF1dGhvcml0YXRpdmUgc291cmNlIG9mIHRoZSByZXNwb25z
ZSwgYW5kIGl04oCZcyBVUkkgaXMgYSB2ZXJ5IGFwcHJvcHJpYXRlIHZhbHVlIGZvciBzb3VyY2Uu
ICBJZiBpdCByZWFsbHkgb25seSBoYXMgb25lIHZhbHVlLCB0aGUg4oCcc291cmNlSWTigJ0gY291
bGQgYmUgYSBmaXhlZCwgc2hvcnQgc3RyaW5nLg0KDQpJIHdvdWxkIGxpa2UgdG8gc3VnZ2VzdCB0
aGF0IHRoZSB0ZXh0IGJlIHJld29yZGVkIHNvIHRoZSBMb1NUIDxtYXBwaW5nPiByZXNwb25zZSBp
cyB1c2VkIGluc3RlYWQgb2YgPHJvdXRpbmdJbmZvcm1hdGlvbj4gYW5kIHRvIGJlIHNvbWV0aGlu
ZyBsaWtlOg0KDQpUaGlzIGRvY3VtZW50IGltcG9ydHMgdGhlIDxtYXBwaW5nPiBzY2hlbWEgZnJv
bSBSRkM1MjIyIGFzIHRoZSByZXNwb25zZSBmcm9tIHRoZSBIRUxEIHJvdXRpbmcgcXVlcnkuICAg
V2hlcmUgdGhlIEhFTEQgc2VydmVyIGlzIG5vdCBjb25zdWx0aW5nIGFueSBvdGhlciBzZXJ2aWNl
IGZvciB0aGUgcm91dGluZyBkYXRhLCBpdCB3b3VsZCB1c2UgaXTigJlzIG93biBVUkkgZm9yIHRo
ZSDigJxzb3VyY2XigJ0gZnVuY3Rpb24uICBNYW55IG9mIHRoZSA8bWFwcGluZz4gZWxlbWVudHMg
YXJlIG9wdGlvbmFsIGFuZCB3aGlsZSB0aGV5IG1heSBub3QgYmUgc2VlbiBpbiBtYW55IGltcGxl
bWVudGF0aW9ucyBvZiBIRUxEIHJvdXRpbmcsIHRoZXkgaGF2ZSBzb21lIHZhbHVlIGluIG90aGVy
IGRlcGxveW1lbnRzLg0KDQpCcmlhbg0K

--_000_D1374C6D9769Bbrianrosenneustarbiz_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5CZWNhdXNlIHdl
IGhhdmUgYWxyZWFkeSBkZWZpbmVkIGFuIGFwcHJvcHJpYXRlIHJlc3BvbnNlIHRvIGEgcmVxdWVz
dCBmb3IgZW1lcmdlbmN5IGNhbGwgcm91dGUsIGFuZCBJIHRoaW5rIHJlcXVpcmluZyBzb21lb25l
IHRvIGNvbWUgYmFjayBsYXRlciBhbmQgYWRkIHN0dWZmIHdlIGFscmVhZHkgYmVsaWV2ZSBpcyB1
c2VmdWwgaXMgYmFkIHByb3RvY29sIGRlc2lnbi4gJm5ic3A7RG8gaXQgcmlnaHQgdGhlIGZpcnN0
IHRpbWUuPC9kaXY+DQo8ZGl2PldlIHRob3VnaHQgYWJvdXQgdGhpcyBzdHVmZiwgd2UgZGVjaWRl
ZCB3aGF0IHdlIHRob3VnaHQgd2FzIHVzZWZ1bC4gJm5ic3A7SSB0aGluayBoYXZpbmcgdGhpcyBh
bHRlcm5hdGl2ZSB3YXkgdG8gZ2V0IGEgcm91dGUgZG9lc27igJl0IGNoYW5nZSB3aGF0IGlzIGlu
IHRoZSByZXNwb25zZSwgaW4gdGhlIHNhbWUgd2F5IHRoYXQgdGhlIGZvcm0gb2YgbG9jYXRpb24g
aXMgdGhlIHNhbWUgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHdlIHVzZSBTSVAgUHJlc2VuY2UNCiBv
ciBIRUxEIHRvIGdldCBpdC4gJm5ic3A7VGhpcyBpcyBhIGVtZXJnZW5jeSBjYWxsIHJvdXRpbmcg
cmVzcG9uc2UsIHdlIGhhdmUgb25lLCByZS11c2UgaXQuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2
Pg0KPGRpdj5CcmlhbjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JD
X0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNp
emU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVk
aXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsg
UEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRk
ZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQi
Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5KYW1lcyBXaW50
ZXJib3R0b20gJmx0OzxhIGhyZWY9Im1haWx0bzphLmphbWVzLndpbnRlcmJvdHRvbUBnbWFpbC5j
b20iPmEuamFtZXMud2ludGVyYm90dG9tQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5
bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UdWVzZGF5LCBNYXJjaCAyNCwgMjAx
NSBhdCA1OjEyIFBNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3Nw
YW4+JnF1b3Q7RFJBR0UsIEtlaXRoIChLZWl0aCkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpr
ZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb20iPmtlaXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50
LmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3Nw
YW4+QnJpYW4gUm9zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpicmlhbi5yb3NlbkBuZXVzdGFyLmJp
eiI+YnJpYW4ucm9zZW5AbmV1c3Rhci5iaXo8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRv
OmVjcml0QGlldGYub3JnIj5lY3JpdEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1h
aWx0bzplY3JpdEBpZXRmLm9yZyI+ZWNyaXRAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0
eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IEFsbG93aW5nIGEgZnVs
bCBMb1NUIHJlc3BvbnNlIGluIHRoZSBIZWxkIFJvdXRpbmcgcmVzcG9uc2U8YnI+DQo8L2Rpdj4N
CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPg0KPGRpdj5JIGRvbid0
IHVuZGVyc3RhbmQgd2h5IHNpbXBseSBhZGRpbmcgYW4gZXh0ZW5zaW9uIHBvaW50IHRvIHRoZSBz
ZXF1ZW5jZSBpbiB0aGUgc2VydmVyIGVsZW1lbnQgd29uJ3QgYWRkcmVzcyB5b3VyIHJlcXVpcmVt
ZW50IEJyaWFuLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlbiBpZiB5b3Ugd2Fu
dCB0byByZXR1cm4gdGhlIHN0dWZmIHlvdSBjYW4sIGJ1dCBhcHBsaWNhdGlvbnMgdGhhdCBkb24n
dCB3YW50IG9yIG5lZWQgaXQgZG9uJ3QgaGF2ZSB0byBiZSBjb25jZXJuZWQgd2l0aCBpdC48L2Rp
dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkNoZWVyczwvZGl2Pg0KPGRpdj5KYW1lczxicj4N
Cjxicj4NClNlbnQgZnJvbSBteSBpUGhvbmU8L2Rpdj4NCjxkaXY+PGJyPg0KT24gMjUgTWFyIDIw
MTUsIGF0IDk6MTAgYW0sICZxdW90O0RSQUdFLCBLZWl0aCAoS2VpdGgpJnF1b3Q7ICZsdDs8YSBo
cmVmPSJtYWlsdG86a2VpdGguZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tIj5rZWl0aC5kcmFnZUBh
bGNhdGVsLWx1Y2VudC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9j
a3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj4NCjxtZXRhIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI5
MDAuNjU1MCIgbmFtZT0iR0VORVJBVE9SIj4NCjxkaXY+PHNwYW4gY2xhc3M9IjkwNTI5MDgyMi0y
NDAzMjAxNSI+PGZvbnQgc2l6ZT0iNCI+T0ssIHNvIGxldHMgYXNrIHRoZSBxdWVzdGlvbiBhIGRp
ZmZlcmVudCB3YXkuPC9mb250Pjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gY2xhc3M9IjkwNTI5
MDgyMi0yNDAzMjAxNSI+PGZvbnQgc2l6ZT0iNCI+PC9mb250Pjwvc3Bhbj4mbmJzcDs8L2Rpdj4N
CjxkaXY+PHNwYW4gY2xhc3M9IjkwNTI5MDgyMi0yNDAzMjAxNSI+PGZvbnQgc2l6ZT0iNCI+V2h5
IHNob3VsZCBhbiBleHRlbnNpb24gdG8gYW4gZXh0ZW5kaWJsZSBwcm90b2NvbCBjb3ZlciB3aGF0
IHNob3VsZCBiZSBhbGxvd2VkIHRvIGJlIHNlbnQgaW4gcmVsYXRpb24gdG8gb3RoZXIgZXh0ZW5z
aW9ucy4gU3VyZWx5IGFueXRoaW5nIHRoYXQgdGhlIElFVEYgd2FudGVkIGluIHRoYXQgcmVzcGVj
dCBzaG91bGQgaGF2ZSBiZWVuIGNvdmVyZWQgaW4NCiBSRkMgNTk4NSBpdHNlbGYuPC9mb250Pjwv
c3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gY2xhc3M9IjkwNTI5MDgyMi0yNDAzMjAxNSI+PGZvbnQg
c2l6ZT0iNCI+PC9mb250Pjwvc3Bhbj4mbmJzcDs8L2Rpdj4NCjxkaXY+PHNwYW4gY2xhc3M9Ijkw
NTI5MDgyMi0yNDAzMjAxNSI+PGZvbnQgc2l6ZT0iNCI+S2VpdGg8L2ZvbnQ+PC9zcGFuPjwvZGl2
Pg0KPGJyPg0KPGJsb2NrcXVvdGUgZGlyPSJsdHIiIHN0eWxlPSJQQURESU5HLUxFRlQ6IDVweDsg
TUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4t
UklHSFQ6IDBweCI+DQo8ZGl2IGNsYXNzPSJPdXRsb29rTWVzc2FnZUhlYWRlciIgbGFuZz0iZW4t
dXMiIGRpcj0ibHRyIiBhbGlnbj0ibGVmdCI+DQo8aHIgdGFiaW5kZXg9Ii0xIj4NCjxmb250IGZh
Y2U9IlRhaG9tYSIgc2l6ZT0iMiI+PGI+RnJvbTo8L2I+IFJvc2VuLCBCcmlhbiBbPGEgaHJlZj0i
bWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6Ij5tYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rh
ci5iaXo8L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IDI0IE1hcmNoIDIwMTUgMjI6MDY8YnI+DQo8
Yj5Ubzo8L2I+IERSQUdFLCBLZWl0aCAoS2VpdGgpOyBKYW1lcyBXaW50ZXJib3R0b208YnI+DQo8
Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzplY3JpdEBpZXRmLm9yZyI+ZWNyaXRAaWV0Zi5vcmc8
L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBBbGxvd2luZyBhIGZ1bGwgTG9TVCByZXNwb25z
ZSBpbiB0aGUgSGVsZCBSb3V0aW5nIHJlc3BvbnNlPGJyPg0KPC9mb250Pjxicj4NCjwvZGl2Pg0K
PGRpdj48L2Rpdj4NCjxkaXY+SeKAmW0gbm90IHN1Z2dlc3RpbmcgdGhhdCB0aGVyZSBpcyBhIExv
U1Qgc2VydmVyIGluIHRoaXMgYXJjaGl0ZWN0dXJlLiAmbmJzcDtJ4oCZbSBzdWdnZXN0aW5nIHRo
YXQgdGhlIEhFTEQgc2VydmVyIHRoYXQgaXMgcmV0dXJuaW5nIHRoZSByb3V0aW5nIGluZm9ybWF0
aW9uIHNob3VsZCBiZSBhYmxlIHRvIHJldHVybiBldmVyeXRoaW5nIHRoYXQgYSBMb1NUIHNlcnZl
ciBjb3VsZCByZXR1cm4uPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5CcmlhbjwvZGl2
Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8
ZGl2IHN0eWxlPSJCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVJJR0hUOiAwaW47
IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBQQURESU5HLUxFRlQ6IDBpbjsgRk9OVC1T
SVpFOiAxMXB0OyBQQURESU5HLUJPVFRPTTogMGluOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7
IENPTE9SOiBibGFjazsgUEFERElORy1UT1A6IDNwdDsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5v
bmU7IEZPTlQtRkFNSUxZOiBDYWxpYnJpOyBURVhULUFMSUdOOiBsZWZ0Ij4NCjxzcGFuIHN0eWxl
PSJGT05ULVdFSUdIVDogYm9sZCI+RnJvbTogPC9zcGFuPiZsdDtEUkFHRSZndDssICZxdW90O0tl
aXRoIChLZWl0aCkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzprZWl0aC5kcmFnZUBhbGNhdGVs
LWx1Y2VudC5jb20iPmtlaXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbTwvYT4mZ3Q7PGJyPg0K
PHNwYW4gc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5EYXRlOiA8L3NwYW4+VHVlc2RheSwgTWFy
Y2ggMjQsIDIwMTUgYXQgNDo1NiBQTTxicj4NCjxzcGFuIHN0eWxlPSJGT05ULVdFSUdIVDogYm9s
ZCI+VG86IDwvc3Bhbj5CcmlhbiBSb3NlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJyaWFuLnJvc2Vu
QG5ldXN0YXIuYml6Ij5icmlhbi5yb3NlbkBuZXVzdGFyLmJpejwvYT4mZ3Q7LCBKYW1lcyBXaW50
ZXJib3R0b20gJmx0OzxhIGhyZWY9Im1haWx0bzphLmphbWVzLndpbnRlcmJvdHRvbUBnbWFpbC5j
b20iPmEuamFtZXMud2ludGVyYm90dG9tQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5
bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5DYzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpl
Y3JpdEBpZXRmLm9yZyI+ZWNyaXRAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls
dG86ZWNyaXRAaWV0Zi5vcmciPmVjcml0QGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls
ZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SRTogQWxsb3dpbmcgYSBmdWxs
IExvU1QgcmVzcG9uc2UgaW4gdGhlIEhlbGQgUm91dGluZyByZXNwb25zZTxicj4NCjwvZGl2Pg0K
PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8bWV0YSBjb250ZW50PSJNU0hUTUwgNi4wMC4yOTAw
LjY1NTAiIG5hbWU9IkdFTkVSQVRPUiI+DQo8ZGl2IHN0eWxlPSJGT05ULVNJWkU6IDE0cHg7IENP
TE9SOiByZ2IoMCwwLDApOyBGT05ULUZBTUlMWTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgV09SRC1X
UkFQOiBicmVhay13b3JkOyB3ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgd2Via2l0LWxpbmUtYnJl
YWs6IGFmdGVyLXdoaXRlLXNwYWNlIj4NCjxkaXY+PHNwYW4gY2xhc3M9IjMzOTU5NTEyMS0yNDAz
MjAxNSI+PGZvbnQgc2l6ZT0iNCI+T25lIHByb2JsZW0gSSBhbSBoYXZpbmcgd2l0aCB5b3VyIGFy
Z3VtZW50IGlzIHRoYXQgSSByZWFkIFJGQyA1OTg1IGFzIHByb3ZpZGluZyBhIHByb3RvY29sIGJl
dHdlZW4gYSBjbGllbnQgYW5kIGEgc2VydmljZSB3aGljaCBpcyBhIExJUy4gSSBkbyBub3Qgc2Vl
IGFueXRoaW5nIHRoYXQgc2F5cyB0aGUgbWFqb3IgYXBwbGljYXRpb24gc3VwcG9ydGVkIG9uDQog
dGhhdCBwcm90b2NvbCBpcyBMb3N0LCB3aGVyZWFzIHlvdXIgYXJndW1lbnQgc2VlbXMgdG8gYmUg
dGhhdCBhbGwgYXBwbGljYXRpb25zIG9uIHRoYXQgcHJvdG9jb2wgbmVlZCB0byBzdXBwb3J0IExv
c3QuPC9mb250Pjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gY2xhc3M9IjMzOTU5NTEyMS0yNDAz
MjAxNSI+PGZvbnQgc2l6ZT0iNCI+PC9mb250Pjwvc3Bhbj4mbmJzcDs8L2Rpdj4NCjxkaXY+PHNw
YW4gY2xhc3M9IjMzOTU5NTEyMS0yNDAzMjAxNSI+PGZvbnQgc2l6ZT0iNCI+Q2FuIHlvdSBwb2lu
dCBtZSB0byBzb21ldGhpbmcgdGhhdCBzdXBwb3J0cyB5b3VyIHZpZXdwb2ludC48L2ZvbnQ+PC9z
cGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBjbGFzcz0iMzM5NTk1MTIxLTI0MDMyMDE1Ij48Zm9udCBz
aXplPSI0Ij48L2ZvbnQ+PC9zcGFuPiZuYnNwOzwvZGl2Pg0KPGRpdj48c3BhbiBjbGFzcz0iMzM5
NTk1MTIxLTI0MDMyMDE1Ij48Zm9udCBzaXplPSI0Ij5yZWdhcmRzPC9mb250Pjwvc3Bhbj48L2Rp
dj4NCjxkaXY+PHNwYW4gY2xhc3M9IjMzOTU5NTEyMS0yNDAzMjAxNSI+PGZvbnQgc2l6ZT0iNCI+
PC9mb250Pjwvc3Bhbj4mbmJzcDs8L2Rpdj4NCjxkaXY+PHNwYW4gY2xhc3M9IjMzOTU5NTEyMS0y
NDAzMjAxNSI+PGZvbnQgc2l6ZT0iNCI+S2VpdGg8L2ZvbnQ+PC9zcGFuPjwvZGl2Pg0KPGJyPg0K
PGJsb2NrcXVvdGUgZGlyPSJsdHIiIHN0eWxlPSJQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxF
RlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBw
eCI+DQo8ZGl2IGNsYXNzPSJPdXRsb29rTWVzc2FnZUhlYWRlciIgbGFuZz0iZW4tdXMiIGRpcj0i
bHRyIiBhbGlnbj0ibGVmdCI+DQo8aHIgdGFiaW5kZXg9Ii0xIj4NCjxmb250IGZhY2U9IlRhaG9t
YSIgc2l6ZT0iMiI+PGI+RnJvbTo8L2I+IEVjcml0IFs8YSBocmVmPSJtYWlsdG86ZWNyaXQtYm91
bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24g
QmVoYWxmIE9mIDwvYj5Sb3NlbiwgQnJpYW48YnI+DQo8Yj5TZW50OjwvYj4gMjQgTWFyY2ggMjAx
NSAyMTozOTxicj4NCjxiPlRvOjwvYj4gSmFtZXMgV2ludGVyYm90dG9tPGJyPg0KPGI+Q2M6PC9i
PiA8YSBocmVmPSJtYWlsdG86ZWNyaXRAaWV0Zi5vcmciPmVjcml0QGlldGYub3JnPC9hPjxicj4N
CjxiPlN1YmplY3Q6PC9iPiBbRWNyaXRdIEFsbG93aW5nIGEgZnVsbCBMb1NUIHJlc3BvbnNlIGlu
IHRoZSBIZWxkIFJvdXRpbmcgcmVzcG9uc2U8YnI+DQo8L2ZvbnQ+PGJyPg0KPC9kaXY+DQo8ZGl2
PjwvZGl2Pg0KPGRpdj5BcyBJIHN0YXRlZCBpbiBJRVRGIDkyLCBJIGJlbGlldmUgdGhlIElFVEYg
c2hvdWxkIGFsbG93IGFsbCB0aGUgcG9zc2libGUgdmFsdWVzIGluIGEgTG9TVCByZXNwb25zZSB0
byBiZSByZXR1cm5lZCBmcm9tIGEgSEVMRCByZXNwb25zZSBpbiBzaXR1YXRpb25zIHdoZXJlIGEg
c2luZ2xlIHF1ZXJ5IGlzIG5lZWRlZCBvciBkZXNpcmFibGUuICZuYnNwO0FzIGFuIGV4YW1wbGUs
IHRoZSBzZXJ2aWNlIGJvdW5kYXJ5IG1heSBiZSB1c2VmdWwgZm9yIG1vYmlsZQ0KIGRldmljZXMs
IHRoZSBzZXJ2aWNlIG51bWJlciBpcyB2ZXJ5IHVzZWZ1bCwgYW5kJm5ic3A7PC9kaXY+DQo8ZGl2
Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGZ1cnRoZXIgdGFrZSBleGNlcHRpb24gdG8gdGhlIG5vdGlv
biB0aGF0IHRoZSBtYXBwaW5nIHJlc3BvbnNlIGluIGEgcmVzdHJpY3RlZCB1c2UgY2FzZSB3b3Vs
ZCBuZWNlc3NhcmlseSBiZSBkaWZmaWN1bHQgb3IgaW52b2x2ZSBtaXNsZWFkaW5nIGRhdGEuICZu
YnNwO1RoZSBleGFtcGxlIGdpdmVuIGlzIHRoZSDigJxzb3VyY2XigJ0gcGFyYW1ldGVyLiAmbmJz
cDtJbiB0aGUgY2l0ZWQgdXNlIGNhc2UsIHRoZSBIRUxEIHNlcnZlciBpcyB0aGUgYXV0aG9yaXRh
dGl2ZQ0KIHNvdXJjZSBvZiB0aGUgcmVzcG9uc2UsIGFuZCBpdOKAmXMgVVJJIGlzIGEgdmVyeSBh
cHByb3ByaWF0ZSB2YWx1ZSBmb3Igc291cmNlLiAmbmJzcDtJZiBpdCByZWFsbHkgb25seSBoYXMg
b25lIHZhbHVlLCB0aGUg4oCcc291cmNlSWTigJ0gY291bGQgYmUgYSBmaXhlZCwgc2hvcnQgc3Ry
aW5nLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSB3b3VsZCBsaWtlIHRvIHN1Z2dl
c3QgdGhhdCB0aGUgdGV4dCBiZSByZXdvcmRlZCBzbyB0aGUgTG9TVCAmbHQ7bWFwcGluZyZndDsg
cmVzcG9uc2UgaXMgdXNlZCBpbnN0ZWFkIG9mICZsdDtyb3V0aW5nSW5mb3JtYXRpb24mZ3Q7IGFu
ZCB0byBiZSBzb21ldGhpbmcgbGlrZTo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRo
aXMgZG9jdW1lbnQgaW1wb3J0cyB0aGUgJmx0O21hcHBpbmcmZ3Q7IHNjaGVtYSBmcm9tIFJGQzUy
MjIgYXMgdGhlIHJlc3BvbnNlIGZyb20gdGhlIEhFTEQgcm91dGluZyBxdWVyeS4gJm5ic3A7IFdo
ZXJlIHRoZSBIRUxEIHNlcnZlciBpcyBub3QgY29uc3VsdGluZyBhbnkgb3RoZXIgc2VydmljZSBm
b3IgdGhlIHJvdXRpbmcgZGF0YSwgaXQgd291bGQgdXNlIGl04oCZcyBvd24gVVJJIGZvciB0aGUg
4oCcc291cmNl4oCdIGZ1bmN0aW9uLiAmbmJzcDtNYW55IG9mIHRoZSAmbHQ7bWFwcGluZyZndDsN
CiBlbGVtZW50cyBhcmUgb3B0aW9uYWwgYW5kIHdoaWxlIHRoZXkgbWF5IG5vdCBiZSBzZWVuIGlu
IG1hbnkgaW1wbGVtZW50YXRpb25zIG9mIEhFTEQgcm91dGluZywgdGhleSBoYXZlIHNvbWUgdmFs
dWUgaW4gb3RoZXIgZGVwbG95bWVudHMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5C
cmlhbjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj48L2Jsb2Nr
cXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8
L2JvZHk+DQo8L2h0bWw+DQo=

--_000_D1374C6D9769Bbrianrosenneustarbiz_--


From nobody Tue Mar 24 16:54:03 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD04E1A1A81 for ; Tue, 24 Mar 2015 16:54:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham
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 vTtvYABptlgQ for ; Tue, 24 Mar 2015 16:53:59 -0700 (PDT)
Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (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 2EBBD1A1A65 for ; Tue, 24 Mar 2015 16:53:59 -0700 (PDT)
Received: by pdbni2 with SMTP id ni2so9042412pdb.1 for ; Tue, 24 Mar 2015 16:53:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=p7A/NopKJoCweTlhz8yKt2gOgO2RMDbWC+v7lcr4jGM=; b=pJtz/bM0g7uPmiDqMUKRZa8hC4iNkPzB+/VUCgcFTqwPGcXkcW8BSlQB5qdwOrVmpB FfeuG+Pjdl/8Q/FZoh8hyqhs5FNLnq5Rz2HOvKIDpCDMHFjsMgOQfPtkxoxAbHSmPSvT HRN2OJqIeTVrFE/4N90Hrmb47zH+N/lVHjDZw3ZwteMS8gAPeO/rNM3C7LeYAs6DCuD/ 98w0W1nYs9XXRqh9uwHxB+5BMVpJ9kJINHsWZGat01xWMw7bqbdNeMDfIAQAKiF/ajX1 /NU+wt7w5HXnMiUI7CS+fnq/EZ/lG/z3laXX8V6DCBuMnUIRMxRfCHVzg/X7L3+/MMh+ MVFQ==
X-Received: by 10.68.135.199 with SMTP id pu7mr11521838pbb.153.1427241238807;  Tue, 24 Mar 2015 16:53:58 -0700 (PDT)
Received: from [10.166.114.205] ([120.158.139.128]) by mx.google.com with ESMTPSA id ds4sm407096pbc.59.2015.03.24.16.53.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Mar 2015 16:53:58 -0700 (PDT)
References:  <949EF20990823C4C85C18D59AA11AD8B4A11C1B6@FR712WXCHMBA11.zeu.alcatel-lucent.com>  <949EF20990823C4C85C18D59AA11AD8B4A11C21E@FR712WXCHMBA11.zeu.alcatel-lucent.com> <0085A304-7F6E-45FC-B7E3-6594AFD0F54F@gmail.com> 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: multipart/alternative; boundary=Apple-Mail-628B5BE8-DF85-4747-A106-0C244938F6F8
Content-Transfer-Encoding: 7bit
Message-Id: <1FC5D1D4-1E6D-4B58-86C1-A05600BC3B08@gmail.com>
X-Mailer: iPhone Mail (11D201)
From: James Winterbottom 
Date: Wed, 25 Mar 2015 10:53:31 +1100
To: "Rosen, Brian" 
Archived-At: 
Cc: "ecrit@ietf.org" 
Subject: Re: [Ecrit] Allowing a full LoST response in the Held Routing response
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Mar 2015 23:54:02 -0000

--Apple-Mail-628B5BE8-DF85-4747-A106-0C244938F6F8
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I don't think that the use case in question has that requirement as the data=
 is not likely to be sourced in the manner that LoST assumes. This makes the=
 LoST data the exception not the rule. In XML we handle this kind of excepti=
on via extensions that come later as the need arises.

Cheers
James

Sent from my iPhone

> On 25 Mar 2015, at 9:19 am, "Rosen, Brian"  wrote=
:
>=20
> Because we have already defined an appropriate response to a request for e=
mergency call route, and I think requiring someone to come back later and ad=
d stuff we already believe is useful is bad protocol design.  Do it right th=
e first time.
> We thought about this stuff, we decided what we thought was useful.  I thi=
nk having this alternative way to get a route doesn=E2=80=99t change what is=
 in the response, in the same way that the form of location is the same rega=
rdless of whether we use SIP Presence or HELD to get it.  This is a emergenc=
y call routing response, we have one, re-use it.
>=20
> Brian
>=20
> From: James Winterbottom 
> Date: Tuesday, March 24, 2015 at 5:12 PM
> To: "DRAGE, Keith (Keith)" 
> Cc: Brian Rosen , "ecrit@ietf.org" 
> Subject: Re: Allowing a full LoST response in the Held Routing response
>=20
> I don't understand why simply adding an extension point to the sequence in=
 the server element won't address your requirement Brian.
>=20
> Then if you want to return the stuff you can, but applications that don't w=
ant or need it don't have to be concerned with it.
>=20
> Cheers
> James
>=20
> Sent from my iPhone
>=20
> On 25 Mar 2015, at 9:10 am, "DRAGE, Keith (Keith)"  wrote:
>=20
>> OK, so lets ask the question a different way.
>> =20
>> Why should an extension to an extendible protocol cover what should be al=
lowed to be sent in relation to other extensions. Surely anything that the I=
ETF wanted in that respect should have been covered in RFC 5985 itself.
>> =20
>> Keith
>>=20
>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20
>> Sent: 24 March 2015 22:06
>> To: DRAGE, Keith (Keith); James Winterbottom
>> Cc: ecrit@ietf.org
>> Subject: Re: Allowing a full LoST response in the Held Routing response
>>=20
>> I=E2=80=99m not suggesting that there is a LoST server in this architectu=
re.  I=E2=80=99m suggesting that the HELD server that is returning the routi=
ng information should be able to return everything that a LoST server could r=
eturn.
>>=20
>> Brian
>>=20
>> From: , "Keith (Keith)" 
>> Date: Tuesday, March 24, 2015 at 4:56 PM
>> To: Brian Rosen , James Winterbottom 
>> Cc: "ecrit@ietf.org" 
>> Subject: RE: Allowing a full LoST response in the Held Routing response
>>=20
>> One problem I am having with your argument is that I read RFC 5985 as pro=
viding a protocol between a client and a service which is a LIS. I do not se=
e anything that says the major application supported on that protocol is Los=
t, whereas your argument seems to be that all applications on that protocol n=
eed to support Lost.
>> =20
>> Can you point me to something that supports your viewpoint.
>> =20
>> regards
>> =20
>> Keith
>>=20
>> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of Rosen, Brian
>> Sent: 24 March 2015 21:39
>> To: James Winterbottom
>> Cc: ecrit@ietf.org
>> Subject: [Ecrit] Allowing a full LoST response in the Held Routing respon=
se
>>=20
>> As I stated in IETF 92, I believe the IETF should allow all the possible v=
alues in a LoST response to be returned from a HELD response in situations w=
here a single query is needed or desirable.  As an example, the service boun=
dary may be useful for mobile devices, the service number is very useful, an=
d=20
>>=20
>> I further take exception to the notion that the mapping response in a res=
tricted use case would necessarily be difficult or involve misleading data. =
 The example given is the =E2=80=9Csource=E2=80=9D parameter.  In the cited u=
se case, the HELD server is the authoritative source of the response, and it=
=E2=80=99s URI is a very appropriate value for source.  If it really only ha=
s one value, the =E2=80=9CsourceId=E2=80=9D could be a fixed, short string.
>>=20
>> I would like to suggest that the text be reworded so the LoST  r=
esponse is used instead of  and to be something like:
>>=20
>> This document imports the  schema from RFC5222 as the response f=
rom the HELD routing query.   Where the HELD server is not consulting any ot=
her service for the routing data, it would use it=E2=80=99s own URI for the =E2=
=80=9Csource=E2=80=9D function.  Many of the  elements are optional=
 and while they may not be seen in many implementations of HELD routing, the=
y have some value in other deployments.
>>=20
>> Brian

--Apple-Mail-628B5BE8-DF85-4747-A106-0C244938F6F8
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


I don't think that the use case in que=
stion has that requirement as the data is not likely to be sourced in the ma=
nner that LoST assumes. This makes the LoST data the exception not the rule.=
 In XML we handle this kind of exception via extensions that come later as t=
he need arises.

Cheers
James

Sent f=
rom my iPhone

On 25 Mar 2015, at 9:19 am, "Rosen, Brian" <<=
a href=3D"mailto:Brian.Rosen@neustar.biz">Brian.Rosen@neustar.biz> wr=
ote:







Because we have already defined an appropriate response to a request fo=
r emergency call route, and I think requiring someone to come back later and=
 add stuff we already believe is useful is bad protocol design.  Do it r=
ight the first time.


We thought about this stuff, we decided what we thought was useful. &nb=
sp;I think having this alternative way to get a route doesn=E2=80=99t change=
 what is in the response, in the same way that the form of location is the s=
ame regardless of whether we use SIP Presence
 or HELD to get it.  This is a emergency call routing response, we have=
 one, re-use it.







Brian


















I don't understand why simply adding an extension point to the sequence=
 in the server element won't address your requirement Brian.







Then if you want to return the stuff you can, but applications that don=
't want or need it don't have to be concerned with it.







Cheers


James



Sent from my iPhone




On 25 Mar 2015, at 9:10 am, "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> wrote:










OK, so lets ask the=
 question a different way.


 =
;


Why should an exten=
sion to an extendible protocol cover what should be allowed to be sent in re=
lation to other extensions. Surely anything that the IETF wanted in that res=
pect should have been covered in
 RFC 5985 itself.


 =
;


Keith=










From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]


Sent: 24 March 2015 22:06

To: DRAGE, Keith (Keith); James Winterbottom

Cc: ecrit@ietf.org

Subject: Re: Allowing a full LoST response in the Held Routing respon=
se








I=E2=80=99m not suggesting that there is a LoST server in this architec=
ture.  I=E2=80=99m suggesting that the HELD server that is returning th=
e routing information should be able to return everything that a LoST server=
 could return.







Brian









From: <DRAGE>, "Keith (Keith)=
" <keith.drage@alcatel-=
lucent.com>

Date: Tuesday, March 24, 2015 at 4:=
56 PM

To: Brian Rosen <brian.rosen@neustar.biz>, James Winterbot=
tom <a.james.winterbott=
om@gmail.com>

Cc: "ecrit@ietf.org" <ecrit@ietf.org=
>

Subject: RE: Allowing a full LoST r=
esponse in the Held Routing response














One problem I am ha=
ving with your argument is that I read RFC 5985 as providing a protocol betw=
een a client and a service which is a LIS. I do not see anything that says t=
he major application supported on
 that protocol is Lost, whereas your argument seems to be that all applicati=
ons on that protocol need to support Lost.


 =
;


Can you point me to=
 something that supports your viewpoint.


 =
;


regards


 =
;


Keith=










From: Ecrit [mailto:ecrit-bounces@ietf.org]
On Behalf Of Rosen, Brian

Sent: 24 March 2015 21:39

To: James Winterbottom

Cc: ecrit@ietf.org

Subject: [Ecrit] Allowing a full LoST response in the Held Routing re=
sponse








As I stated in IETF 92, I believe the IETF should allow all the possibl=
e values in a LoST response to be returned from a HELD response in situation=
s where a single query is needed or desirable.  As an example, the serv=
ice boundary may be useful for mobile
 devices, the service number is very useful, and 







I further take exception to the notion that the mapping response in a r=
estricted use case would necessarily be difficult or involve misleading data=
.  The example given is the =E2=80=9Csource=E2=80=9D parameter.  I=
n the cited use case, the HELD server is the authoritative
 source of the response, and it=E2=80=99s URI is a very appropriate value fo=
r source.  If it really only has one value, the =E2=80=9CsourceId=E2=80=
=9D could be a fixed, short string.







I would like to suggest that the text be reworded so the LoST <mappi=
ng> response is used instead of <routingInformation> and to be some=
thing like:







This document imports the <mapping> schema from RFC5222 as the re=
sponse from the HELD routing query.   Where the HELD server is not cons=
ulting any other service for the routing data, it would use it=E2=80=99s own=
 URI for the =E2=80=9Csource=E2=80=9D function.  Many of the <mappin=
g>
 elements are optional and while they may not be seen in many implementation=
s of HELD routing, they have some value in other deployments.







Brian





















=

--Apple-Mail-628B5BE8-DF85-4747-A106-0C244938F6F8--


From nobody Tue Mar 24 20:28:10 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9111ACD66 for ; Tue, 24 Mar 2015 20:28:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level: 
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 H3xvucNnHy-r for ; Tue, 24 Mar 2015 20:28:07 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90DF01ACD69 for ; Tue, 24 Mar 2015 20:28:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1427254086; x=1458790086; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=LGT81krSGPBrdpbcRMYQHzPTdwCaBHjz4xRkFhfi0DQ=; b=F/7dDDsmPf4/zEeKDn4przFm6DfuoEyju9BUf3d4yvzPQSJH/Ndmil4x 74e2B5SWImI3rlI4ZG5+3UClV2gUicGowJOyqNOI5ESVHSaTS6oaGg+6d DgMGOAJimaFDGUMdH7ewYobGT+3QF5JIN0eUdtBKf8DgEWl4Log/cHQyS w=;
X-IronPort-AV: E=McAfee;i="5600,1067,7750"; a="86570018"
Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Mar 2015 20:28:05 -0700
X-IronPort-AV: E=Sophos;i="5.11,462,1422950400"; d="scan'208";a="879356383"
Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 24 Mar 2015 20:28:05 -0700
Received: from dhcp-93ce.meeting.ietf.org (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 24 Mar 2015 20:28:04 -0700
Message-ID: 
In-Reply-To: 
References: 
X-Mailer: Eudora for Mac OS X
Date: Tue, 24 Mar 2015 20:28:02 -0700
To: "Rosen, Brian" , Randall Gellens 
From: Randall Gellens 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.85.0.31) To nasanexm02f.na.qualcomm.com (10.85.0.87)
Archived-At: 
Cc: "ecrit@ietf.org" 
Subject: Re: [Ecrit] Justification for Data-only (and MSRP only) car-crash
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Mar 2015 03:28:09 -0000

Hi Brian,

At 8:58 PM +0000 3/24/15, Brian Rosen wrote:

>  Although current car telematics systems always have an audio path, 
> there are scenarios where a data-only call is desired.  There are, 
> for example, truck telematics systems that only send data.

To clarify, we're talking about systems that exchange data between 
the vehicle and a service provider/dispatch center; we're not talking 
about emergency calls, right?

>    There are failure scenarios where an audio path can't be created.

I think in these cases an audio path was attempted but failed, so 
there is still a SIP session and there was an intent to have a voice 
path.  So, I consider these failure modes of the primary emergency 
mechanism, not a data-only call (where there was never any intent to 
have interactive media nor a SIP session).

>    There are newer, lower cost systems that don't involve a call center.

If we're talking about the same thing, these are described in the 
draft, and these do establish a voice path to the PSAP, either direct 
from the vehicle to the PSAP (NG9-1-1 call from the IVS) or via a 
previously-paired handset that places a 911 call.

>    In addition, there could be text-only calls, rather than audio.

Probably these would still have an audio path so the PSAP call taker 
can hear what is going on, but I don't think the details of the media 
matter.  What matters is that these are still NG9-1-1 calls that 
create a SIP session and establish interactive media.  In 3GPP, this 
is Multimedia Emergency Services (MMES).

>  I would like to see these allowed in -car-crash.  Due to 
> limitations and design decisions in 3GPP, this capability is not 
> possible in ecall, and thus this text would have to be specific to 
> -car-crash.

The only one of these that I think isn't currently permitted is the 
telematics case where no emergency call is placed.  I'd be happy to 
add this, but in Additional-Data we said that the mechanism is only 
to be used in emergency calls.  We could change that to include 
emergency calls and private/limited use between pre-established 
endpoints or some such.

>



-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The old believe everything; the middle-aged suspect everything;
the young know everything.


From nobody Wed Mar 25 01:03:06 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E0E1ACE0B for ; Wed, 25 Mar 2015 01:03:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 SSJn9Ji0er8B for ; Wed, 25 Mar 2015 01:03:01 -0700 (PDT)
Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (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 9817F1ACE06 for ; Wed, 25 Mar 2015 01:02:59 -0700 (PDT)
Received: by pdbni2 with SMTP id ni2so20647686pdb.1 for ; Wed, 25 Mar 2015 01:02:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=EGyGH+EEXk0KzT/WLaAS+ruRdHZ45i36lzgNa8RVKcU=; b=YJrTkpT5yRJox/Za2Bmbw73zuiPSYiWsqekov/sPyjavfwqtatrkBWB4Y5bjHdJGl6 oPiKAz+73aX6rCvM9UUAwGfw67LHBfNByxV04EzIVW5mmxdc6briWDgYDJYsoRJSO32B wi3rFJRgzUj9wdTuzuF8tC98rGVp/WpNWDrsq0A1OEBKxMnOj4AuKZ1mJ0YNmMSlc+Oo KhUkQj5O8e9INwoxU73ATd3szdYvyVmT7sm90f1+SqFF4GcDGgY1Mel6IT6OhzIalnCW pxHmRCHgipMLG6pLhs6Y8wp5Eq9LSngbdWgJy23L2AuqlVqDJAIFaeyb2GwintmhtF75 wdbw==
X-Received: by 10.68.100.161 with SMTP id ez1mr14430754pbb.81.1427270579326; Wed, 25 Mar 2015 01:02:59 -0700 (PDT)
Received: from [192.168.1.18] (124-149-62-12.dyn.iinet.net.au. [124.149.62.12]) by mx.google.com with ESMTPSA id ae7sm1560836pac.19.2015.03.25.01.02.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Mar 2015 01:02:58 -0700 (PDT)
From: James Winterbottom 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Wed, 25 Mar 2015 19:02:57 +1100
Message-Id: <5F3DEAC5-1A13-45A3-B9C8-51579BAC22F9@gmail.com>
To: "ecrit_ietf.org" 
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Subject: [Ecrit] HELD Routing summary
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Mar 2015 08:03:05 -0000

Hi All,

As I see it there is one open discussion point and three positions on =
this point.
The discussion point is whether or not all of the ancillary data that is =
returned by a LoST findService request should be included in the HELD =
routing response or not.

The three positions that have been stated are (in no particular order):
1) The definition for this information should be included in the base =
specification but is optional to send or be acted on.
2) Isn=E2=80=99t required at all, let the current draft stand
3) Add an extension point to the schema in the draft so that the extra =
can be specified in a different draft and added by something requiring =
it.

This email makes no claims to preference, but just presents the opinions =
that have been expressed.

Cheers
James


From nobody Wed Mar 25 05:54:33 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05431A1A0B for ; Wed, 25 Mar 2015 05:54:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.267
X-Spam-Level: 
X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 oe0DP4HvZMBF for ; Wed, 25 Mar 2015 05:54:29 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 69C5E1ACE8D for ; Wed, 25 Mar 2015 05:54:29 -0700 (PDT)
Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.14.7/8.14.7) with SMTP id t2PCsTKS029772; Wed, 25 Mar 2015 08:54:29 -0400
Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1tbdax18pb-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Mar 2015 08:54:29 -0400
Received: from STNTEXMB13.cis.neustar.com ([169.254.3.204]) by stntexhc10.cis.neustar.com ([169.254.4.213]) with mapi id 14.03.0158.001; Wed, 25 Mar 2015 08:54:27 -0400
From: "Rosen, Brian" 
To: Randall Gellens , Randall Gellens 
Thread-Topic: Justification for Data-only (and MSRP only) car-crash
Thread-Index: AQHQZnVQvCbx497qpEq09eE2XE6XH50szYkAgABKbAA=
Date: Wed, 25 Mar 2015 12:54:26 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [192.168.132.33]
Content-Type: text/plain; charset="utf-8"
Content-ID: <3D01F0B493180E449288AD40FDA4FB5B@neustar.biz>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=nai engine=5700 definitions=7750 signatures=670576
X-Proofpoint-Spam-Reason: safe
Archived-At: 
Cc: "ecrit@ietf.org" 
Subject: Re: [Ecrit] Justification for Data-only (and MSRP only) car-crash
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Mar 2015 12:54:32 -0000

DQoNCk9uIDMvMjQvMTUsIDEwOjI4IFBNLCAiUmFuZGFsbCBHZWxsZW5zIiA8cmFuZHlAcXRpLnF1
YWxjb21tLmNvbT4gd3JvdGU6DQoNCj5IaSBCcmlhbiwNCj4NCj5BdCA4OjU4IFBNICswMDAwIDMv
MjQvMTUsIEJyaWFuIFJvc2VuIHdyb3RlOg0KPg0KPj4gIEFsdGhvdWdoIGN1cnJlbnQgY2FyIHRl
bGVtYXRpY3Mgc3lzdGVtcyBhbHdheXMgaGF2ZSBhbiBhdWRpbyBwYXRoLA0KPj4gdGhlcmUgYXJl
IHNjZW5hcmlvcyB3aGVyZSBhIGRhdGEtb25seSBjYWxsIGlzIGRlc2lyZWQuICBUaGVyZSBhcmUs
DQo+PiBmb3IgZXhhbXBsZSwgdHJ1Y2sgdGVsZW1hdGljcyBzeXN0ZW1zIHRoYXQgb25seSBzZW5k
IGRhdGEuDQo+DQo+VG8gY2xhcmlmeSwgd2UncmUgdGFsa2luZyBhYm91dCBzeXN0ZW1zIHRoYXQg
ZXhjaGFuZ2UgZGF0YSBiZXR3ZWVuDQo+dGhlIHZlaGljbGUgYW5kIGEgc2VydmljZSBwcm92aWRl
ci9kaXNwYXRjaCBjZW50ZXI7IHdlJ3JlIG5vdCB0YWxraW5nDQo+YWJvdXQgZW1lcmdlbmN5IGNh
bGxzLCByaWdodD8NCk5vLCB0aGVzZSBhcmUgcm9sbG92ZXIgYW5kIG90aGVyIHNlbnNvcnMgdGhh
dCBjdXJyZW50bHkganVzdCByZXBvcnQgdG8gdGhlDQpvd25lciBvZiB0aGUgdHJ1Y2tpbmcgY29t
cGFueSBidXQgc2hvdWxkIHNlbmQgbm9uLWh1bWFuLWluaXRpYXRlZA0KZW1lcmdlbmN5IGNhbGxz
Lg0KDQo+DQo+PiAgICBUaGVyZSBhcmUgZmFpbHVyZSBzY2VuYXJpb3Mgd2hlcmUgYW4gYXVkaW8g
cGF0aCBjYW4ndCBiZSBjcmVhdGVkLg0KPg0KPkkgdGhpbmsgaW4gdGhlc2UgY2FzZXMgYW4gYXVk
aW8gcGF0aCB3YXMgYXR0ZW1wdGVkIGJ1dCBmYWlsZWQsIHNvDQo+dGhlcmUgaXMgc3RpbGwgYSBT
SVAgc2Vzc2lvbiBhbmQgdGhlcmUgd2FzIGFuIGludGVudCB0byBoYXZlIGEgdm9pY2UNCj5wYXRo
LiAgU28sIEkgY29uc2lkZXIgdGhlc2UgZmFpbHVyZSBtb2RlcyBvZiB0aGUgcHJpbWFyeSBlbWVy
Z2VuY3kNCj5tZWNoYW5pc20sIG5vdCBhIGRhdGEtb25seSBjYWxsICh3aGVyZSB0aGVyZSB3YXMg
bmV2ZXIgYW55IGludGVudCB0bw0KPmhhdmUgaW50ZXJhY3RpdmUgbWVkaWEgbm9yIGEgU0lQIHNl
c3Npb24pLg0KTm8sIEkgd2FzIHRoaW5raW5nIG9mIGNhc2VzIHdoZXJlIGFuIGF1ZGlvIGNhbGwg
d291bGQgZmFpbCwgYnV0IGEgZGF0YQ0Kb25seSBjYWxsIHdvdWxkIHN1Y2NlZWQuDQoNCj4NCj4+
ICAgIFRoZXJlIGFyZSBuZXdlciwgbG93ZXIgY29zdCBzeXN0ZW1zIHRoYXQgZG9uJ3QgaW52b2x2
ZSBhIGNhbGwgY2VudGVyLg0KPg0KPklmIHdlJ3JlIHRhbGtpbmcgYWJvdXQgdGhlIHNhbWUgdGhp
bmcsIHRoZXNlIGFyZSBkZXNjcmliZWQgaW4gdGhlDQo+ZHJhZnQsIGFuZCB0aGVzZSBkbyBlc3Rh
Ymxpc2ggYSB2b2ljZSBwYXRoIHRvIHRoZSBQU0FQLCBlaXRoZXIgZGlyZWN0DQo+ZnJvbSB0aGUg
dmVoaWNsZSB0byB0aGUgUFNBUCAoTkc5LTEtMSBjYWxsIGZyb20gdGhlIElWUykgb3IgdmlhIGEN
Cj5wcmV2aW91c2x5LXBhaXJlZCBoYW5kc2V0IHRoYXQgcGxhY2VzIGEgOTExIGNhbGwuDQpObywg
dGhlIGRldmljZSBjb25uZWN0ZWQgdG8gdGhlIHZlaGljbGUgaXMgbm90IGEgaGFuZHNldC4gIFRo
ZXkgYXJlDQpwbHVnZ2luZyBpbiB0byB0aGUgY2FyIGRpYWdub3N0aWMgY29ubmVjdG9yLiBTb21l
IHVzZSBhIGhhbmRzZXQgdG8gc2VuZA0KZGF0YSwgb3RoZXJzIGhhdmUgYSB3aXJlbGVzcyBtb2Rl
bS4gIEluIGVpdGhlciBjYXNlLCB0aGUgb25seSBjb25uZWN0aW9uDQppcyBkYXRhLg0KDQpJIGRv
buKAmXQgdGhpbmsgYW4gYXBwIGNhbiwgb3Igc2hvdWxkIGJlIGFibGUgdG8gaW5kdWNlIGEgaGFu
ZHNldCB0byBjcmVhdGUNCmEgOS0xLTEgY2FsbC4gIEFwcHMgY2FuIHJlcXVlc3QgdGhlIGRpYWxl
ciB0byBwbGFjZSBhIGNhbGwsIGJ1dCBpdA0KcmVxdWlyZXMgY29uZmlybWF0aW9uLiAgSW4gdGhp
cyBjYXNlLCB0aGF0IHdvdWxkIG5vdCBiZSB0aGUgZGVzaXJlZA0KcmVzcG9uc2UuDQoNCg0KPg0K
Pj4gICAgSW4gYWRkaXRpb24sIHRoZXJlIGNvdWxkIGJlIHRleHQtb25seSBjYWxscywgcmF0aGVy
IHRoYW4gYXVkaW8uDQo+DQo+UHJvYmFibHkgdGhlc2Ugd291bGQgc3RpbGwgaGF2ZSBhbiBhdWRp
byBwYXRoIHNvIHRoZSBQU0FQIGNhbGwgdGFrZXINCj5jYW4gaGVhciB3aGF0IGlzIGdvaW5nIG9u
LCBidXQgSSBkb24ndCB0aGluayB0aGUgZGV0YWlscyBvZiB0aGUgbWVkaWENCj5tYXR0ZXIuICBX
aGF0IG1hdHRlcnMgaXMgdGhhdCB0aGVzZSBhcmUgc3RpbGwgTkc5LTEtMSBjYWxscyB0aGF0DQo+
Y3JlYXRlIGEgU0lQIHNlc3Npb24gYW5kIGVzdGFibGlzaCBpbnRlcmFjdGl2ZSBtZWRpYS4gIElu
IDNHUFAsIHRoaXMNCj5pcyBNdWx0aW1lZGlhIEVtZXJnZW5jeSBTZXJ2aWNlcyAoTU1FUykuDQpS
ZW1lbWJlciB0aGF0IHRoZXJlIGFyZSBkb2N1bWVudGVkIGNhc2VzIHdoZXJlIG5vIGF1ZGlvIHBh
dGggaXMgcmVxdWlyZWQuDQpUZXh0IGVtZXJnZW5jeSBjYWxscyB0b2RheSBETyBOT1QgY3JlYXRl
IGF1ZGlvIHBhdGhzLCBhbmQgdGhleSBzaG91bGQgbm90Lg0KIEl0IHNob3VsZCBiZSBwb3NzaWJs
ZSB0byBjcmVhdGUgYSBtdWx0aW1lZGlhIGVtZXJnZW5jeSBjYWxsLCBidXQgaXQgaXMNCm5vdCwg
YW5kIHNob3VsZCBub3QsIGJlIHJlcXVpcmVkLg0KDQoNCj4NCj4+ICBJIHdvdWxkIGxpa2UgdG8g
c2VlIHRoZXNlIGFsbG93ZWQgaW4gLWNhci1jcmFzaC4gIER1ZSB0bw0KPj4gbGltaXRhdGlvbnMg
YW5kIGRlc2lnbiBkZWNpc2lvbnMgaW4gM0dQUCwgdGhpcyBjYXBhYmlsaXR5IGlzIG5vdA0KPj4g
cG9zc2libGUgaW4gZWNhbGwsIGFuZCB0aHVzIHRoaXMgdGV4dCB3b3VsZCBoYXZlIHRvIGJlIHNw
ZWNpZmljIHRvDQo+PiAtY2FyLWNyYXNoLg0KPg0KPlRoZSBvbmx5IG9uZSBvZiB0aGVzZSB0aGF0
IEkgdGhpbmsgaXNuJ3QgY3VycmVudGx5IHBlcm1pdHRlZCBpcyB0aGUNCj50ZWxlbWF0aWNzIGNh
c2Ugd2hlcmUgbm8gZW1lcmdlbmN5IGNhbGwgaXMgcGxhY2VkLiAgSSdkIGJlIGhhcHB5IHRvDQo+
YWRkIHRoaXMsIGJ1dCBpbiBBZGRpdGlvbmFsLURhdGEgd2Ugc2FpZCB0aGF0IHRoZSBtZWNoYW5p
c20gaXMgb25seQ0KPnRvIGJlIHVzZWQgaW4gZW1lcmdlbmN5IGNhbGxzLiAgV2UgY291bGQgY2hh
bmdlIHRoYXQgdG8gaW5jbHVkZQ0KPmVtZXJnZW5jeSBjYWxscyBhbmQgcHJpdmF0ZS9saW1pdGVk
IHVzZSBiZXR3ZWVuIHByZS1lc3RhYmxpc2hlZA0KPmVuZHBvaW50cyBvciBzb21lIHN1Y2guDQpO
b3QgYXNraW5nIGZvciB0aGF0LiAgRW1lcmdlbmN5IGNhbGxzIG9ubHkNCg0KDQo+DQo+Pg0KPg0K
Pg0KPg0KPi0tIA0KPlJhbmRhbGwgR2VsbGVucw0KPk9waW5pb25zIGFyZSBwZXJzb25hbDsgICAg
ZmFjdHMgYXJlIHN1c3BlY3Q7ICAgIEkgc3BlYWsgZm9yIG15c2VsZiBvbmx5DQo+LS0tLS0tLS0t
LS0tLS0gUmFuZG9tbHkgc2VsZWN0ZWQgdGFnOiAtLS0tLS0tLS0tLS0tLS0NCj5UaGUgb2xkIGJl
bGlldmUgZXZlcnl0aGluZzsgdGhlIG1pZGRsZS1hZ2VkIHN1c3BlY3QgZXZlcnl0aGluZzsNCj50
aGUgeW91bmcga25vdyBldmVyeXRoaW5nLg0KDQo=


From nobody Wed Mar 25 07:50:01 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F321A1A5A for ; Wed, 25 Mar 2015 07:50:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 ZkjTgE8MLZ2J for ; Wed, 25 Mar 2015 07:49:58 -0700 (PDT)
Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A845E1A1B6A for ; Wed, 25 Mar 2015 07:49:54 -0700 (PDT)
Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail11.telekom.de with ESMTP; 25 Mar 2015 15:49:47 +0100
X-IronPort-AV: E=Sophos;i="5.11,465,1422918000"; d="scan'208";a="642325131"
Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 25 Mar 2015 15:49:47 +0100
Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 25 Mar 2015 15:49:46 +0100
From: 
To: , 
Date: Wed, 25 Mar 2015 15:49:35 +0100
Thread-Topic: [Ecrit] HELD Routing summary
Thread-Index: AdBm0iM53YxyirDIRnO5goDsq0cLHgAOFiLA
Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01E9E52D80B6@HE113667.emea1.cds.t-internal.com>
References: <5F3DEAC5-1A13-45A3-B9C8-51579BAC22F9@gmail.com>
In-Reply-To: <5F3DEAC5-1A13-45A3-B9C8-51579BAC22F9@gmail.com>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [Ecrit] HELD Routing summary
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Mar 2015 14:50:00 -0000

SGkgSmFtZXMsDQogdGhhbmsgeW91IGZvciB0aGUgc3VtbWFyeS4NCk15IHBvc2l0aW9uIGlzIHJl
ZmxlY3RlZCBpbiBwb2ludCAyLg0KDQpJZiBwZW9wbGUgd2FudCB0byBhZGQgc29tZXRoaW5nIHRv
IGEgbWVjaGFuaXNtIGNhbiBpdCBub3QgYmUgZG9uZSBvbmx5IGluIHdyaXRpbmcgYSBmdXJ0aGVy
IGRyYWZ0Pw0KVGhpcyBtZWFucyBhbHNvIGluY2x1ZGluZyBpbiBzdWNoIGEgZHJhZnQgYWxzbyBh
IGV4dGVuc2lvbiBtZWNoYW5pc20uDQoNCkkgdGhpbmsgdGhhdCB3b3VsZCBiZSBhIGNsZWFyIGxp
bmUgdG8gc2F0aXNmeSBldmVyeWJvZHkuDQoNCg0KQmVzdCBSZWdhcmRzDQoNClJvbGFuZCANCg0K
LS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KVm9uOiBFY3JpdCBbbWFpbHRvOmVj
cml0LWJvdW5jZXNAaWV0Zi5vcmddIEltIEF1ZnRyYWcgdm9uIEphbWVzIFdpbnRlcmJvdHRvbQ0K
R2VzZW5kZXQ6IE1pdHR3b2NoLCAyNS4gTcOkcnogMjAxNSAwOTowMw0KQW46IGVjcml0X2lldGYu
b3JnDQpCZXRyZWZmOiBbRWNyaXRdIEhFTEQgUm91dGluZyBzdW1tYXJ5DQoNCkhpIEFsbCwNCg0K
QXMgSSBzZWUgaXQgdGhlcmUgaXMgb25lIG9wZW4gZGlzY3Vzc2lvbiBwb2ludCBhbmQgdGhyZWUg
cG9zaXRpb25zIG9uIHRoaXMgcG9pbnQuDQpUaGUgZGlzY3Vzc2lvbiBwb2ludCBpcyB3aGV0aGVy
IG9yIG5vdCBhbGwgb2YgdGhlIGFuY2lsbGFyeSBkYXRhIHRoYXQgaXMgcmV0dXJuZWQgYnkgYSBM
b1NUIGZpbmRTZXJ2aWNlIHJlcXVlc3Qgc2hvdWxkIGJlIGluY2x1ZGVkIGluIHRoZSBIRUxEIHJv
dXRpbmcgcmVzcG9uc2Ugb3Igbm90Lg0KDQpUaGUgdGhyZWUgcG9zaXRpb25zIHRoYXQgaGF2ZSBi
ZWVuIHN0YXRlZCBhcmUgKGluIG5vIHBhcnRpY3VsYXIgb3JkZXIpOg0KMSkgVGhlIGRlZmluaXRp
b24gZm9yIHRoaXMgaW5mb3JtYXRpb24gc2hvdWxkIGJlIGluY2x1ZGVkIGluIHRoZSBiYXNlIHNw
ZWNpZmljYXRpb24gYnV0IGlzIG9wdGlvbmFsIHRvIHNlbmQgb3IgYmUgYWN0ZWQgb24uDQoyKSBJ
c27igJl0IHJlcXVpcmVkIGF0IGFsbCwgbGV0IHRoZSBjdXJyZW50IGRyYWZ0IHN0YW5kDQozKSBB
ZGQgYW4gZXh0ZW5zaW9uIHBvaW50IHRvIHRoZSBzY2hlbWEgaW4gdGhlIGRyYWZ0IHNvIHRoYXQg
dGhlIGV4dHJhIGNhbiBiZSBzcGVjaWZpZWQgaW4gYSBkaWZmZXJlbnQgZHJhZnQgYW5kIGFkZGVk
IGJ5IHNvbWV0aGluZyByZXF1aXJpbmcgaXQuDQoNClRoaXMgZW1haWwgbWFrZXMgbm8gY2xhaW1z
IHRvIHByZWZlcmVuY2UsIGJ1dCBqdXN0IHByZXNlbnRzIHRoZSBvcGluaW9ucyB0aGF0IGhhdmUg
YmVlbiBleHByZXNzZWQuDQoNCkNoZWVycw0KSmFtZXMNCg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCkVjcml0IG1haWxpbmcgbGlzdA0KRWNyaXRAaWV0
Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCg==


From nobody Wed Mar 25 08:52:22 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3681A87A9 for ; Wed, 25 Mar 2015 08:52:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.267
X-Spam-Level: 
X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 HHaDZtF1dkAo for ; Wed, 25 Mar 2015 08:52:20 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 04EBC1A877A for ; Wed, 25 Mar 2015 08:52:19 -0700 (PDT)
Received: from pps.filterd (m0078664.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.14.7/8.14.7) with SMTP id t2PFnrlJ030668; Wed, 25 Mar 2015 11:52:19 -0400
Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1tbdax1hs5-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Mar 2015 11:52:19 -0400
Received: from STNTEXMB13.cis.neustar.com ([169.254.3.204]) by stntexhc10.cis.neustar.com ([169.254.4.213]) with mapi id 14.03.0158.001; Wed, 25 Mar 2015 11:52:17 -0400
From: "Rosen, Brian" 
To: "R.Jesske@telekom.de" 
Thread-Topic: [Ecrit] HELD Routing summary
Thread-Index: AQHQZxOrLUztZJ1aYEW07NjBnVfm7w==
Date: Wed, 25 Mar 2015 15:52:17 +0000
Message-ID: <14546D76-AEF5-4C23-9BA0-00B6FA4C1E96@neustar.biz>
References: <5F3DEAC5-1A13-45A3-B9C8-51579BAC22F9@gmail.com> <058CE00BD4D6B94FAD033A2439EA1E4B01E9E52D80B6@HE113667.emea1.cds.t-internal.com>
In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01E9E52D80B6@HE113667.emea1.cds.t-internal.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.132.33]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=nai engine=5700 definitions=7750 signatures=670576
X-Proofpoint-Spam-Reason: safe
Archived-At: 
Cc: "ecrit@ietf.org" 
Subject: Re: [Ecrit] HELD Routing summary
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Mar 2015 15:52:21 -0000

TGV04oCZcyBzYXkgdGhhdCBzb21lb25lIGNvbWVzIGFsb25nIGFuZCBzaG93cyBhIGRlY2VudCB1
c2UgY2FzZSBmb3IgaW5jbHVkaW5nIGEgc2VydmljZSBib3VuZGFyeS4NCg0KU28gdGhleSBkZWZp
bmUgYW4gZXh0ZW5zaW9uIGZvciBpdC4NCg0KVGhhdCBleHRlbnNpb24gbWF5IG9yIG1heSBub3Qg
YmUgdGhlIHNhbWUgYXMgdGhlIHNlcnZpY2UgYm91bmRhcnkgdGhhdCBMb1NUIHJldHVybnMuICBB
biBpbXBsZW1lbnRhdGlvbiBkZXNpZ25lZCB0byBwcm92aWRlIHdvcmxkLXdpZGUgc2VydmljZSB3
b3VsZCBoYXZlIHRvIGNoYW5nZS4NCg0KUmV0dXJuaW5nIHRoZSBib3VuZGFyeSBpcyBhbHJlYWR5
IG9wdGlvbmFsIGluIHRoZSBMb1NUIHNjaGVtYS4NCg0KSWYgd2UgdXNlZCB0aGUgZXhpc3Rpbmcg
ZGVmaW5pdGlvbjoNCjEuIE5vIG5ldyBkb2N1bWVudCBpcyByZXF1aXJlZA0KMi4gQ29tcGF0aWJp
bGl0eSBiZXR3ZWVuIHRoaXMgSEVMRCBleHRlbnNpb24gYW5kIExvU1QgaXMgbWFpbnRhaW5lZA0K
My4gU3lzdGVtcyBidWlsdCB0byBzdXBwb3J0IGJvdGggbW9kZWxzIGRvbuKAmXQgaGF2ZSB0byBj
aGFuZ2UNCg0KVGhlcmUgaXMsIGFzIGZhciBhcyBJIGNhbiBzZWUsIG5vIGRvd25zaWRlIHRvIHVz
aW5nIHRoZSBleGlzdGluZyBzY2hlbWEgb3RoZXIgdGhhbiBtYWtpbmcgdGhlIHNtYWxsZXN0IHBv
c3NpYmxlIHJlc3BvbnNlIGEgYml0IGJpZ2dlci4gICBPbmUgY2FuIGFsd2F5cyBpZ25vcmUgYW55
IHJldHVybmVkIGl0ZW1zIG5vdCBuZWVkZWQvd2FudGVkLCBhbmQgc2luY2UgdGhleSBhcmUgb3B0
aW9uYWwgdGhleSBjYW7igJl0IGJlIGFzc3VtZWQgdG8gYmUgdGhlcmUuDQoNCk9wdGlvbiAyIChk
b27igJl0IGFsbG93IGFuIGV4dGVuc2lvbiBwb2ludCBvbiB0aGUgcmV0dXJuKSBtYWtlcyBubyBz
ZW5zZSB0byBtZS4gIEkgY2Fu4oCZdCBpbWFnaW5lIHRoZSBJRVRGIGRvaW5nIHRoYXQuICBBbnkg
ZXh0ZW5zaW9uIHdvdWxkIHRoZW4gcmVxdWlyZSBhbGwgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25z
IHRvIGJlIGNoYW5nZWQuDQoNCkJyaWFuDQoNCj4gT24gTWFyIDI1LCAyMDE1LCBhdCA5OjQ5IEFN
LCBSLkplc3NrZUB0ZWxla29tLmRlIHdyb3RlOg0KPiANCj4gSGkgSmFtZXMsDQo+IHRoYW5rIHlv
dSBmb3IgdGhlIHN1bW1hcnkuDQo+IE15IHBvc2l0aW9uIGlzIHJlZmxlY3RlZCBpbiBwb2ludCAy
Lg0KPiANCj4gSWYgcGVvcGxlIHdhbnQgdG8gYWRkIHNvbWV0aGluZyB0byBhIG1lY2hhbmlzbSBj
YW4gaXQgbm90IGJlIGRvbmUgb25seSBpbiB3cml0aW5nIGEgZnVydGhlciBkcmFmdD8NCj4gVGhp
cyBtZWFucyBhbHNvIGluY2x1ZGluZyBpbiBzdWNoIGEgZHJhZnQgYWxzbyBhIGV4dGVuc2lvbiBt
ZWNoYW5pc20uDQo+IA0KPiBJIHRoaW5rIHRoYXQgd291bGQgYmUgYSBjbGVhciBsaW5lIHRvIHNh
dGlzZnkgZXZlcnlib2R5Lg0KPiANCj4gDQo+IEJlc3QgUmVnYXJkcw0KPiANCj4gUm9sYW5kIA0K
PiANCj4gLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KPiBWb246IEVjcml0IFtt
YWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZ10gSW0gQXVmdHJhZyB2b24gSmFtZXMgV2ludGVy
Ym90dG9tDQo+IEdlc2VuZGV0OiBNaXR0d29jaCwgMjUuIE3DpHJ6IDIwMTUgMDk6MDMNCj4gQW46
IGVjcml0X2lldGYub3JnDQo+IEJldHJlZmY6IFtFY3JpdF0gSEVMRCBSb3V0aW5nIHN1bW1hcnkN
Cj4gDQo+IEhpIEFsbCwNCj4gDQo+IEFzIEkgc2VlIGl0IHRoZXJlIGlzIG9uZSBvcGVuIGRpc2N1
c3Npb24gcG9pbnQgYW5kIHRocmVlIHBvc2l0aW9ucyBvbiB0aGlzIHBvaW50Lg0KPiBUaGUgZGlz
Y3Vzc2lvbiBwb2ludCBpcyB3aGV0aGVyIG9yIG5vdCBhbGwgb2YgdGhlIGFuY2lsbGFyeSBkYXRh
IHRoYXQgaXMgcmV0dXJuZWQgYnkgYSBMb1NUIGZpbmRTZXJ2aWNlIHJlcXVlc3Qgc2hvdWxkIGJl
IGluY2x1ZGVkIGluIHRoZSBIRUxEIHJvdXRpbmcgcmVzcG9uc2Ugb3Igbm90Lg0KPiANCj4gVGhl
IHRocmVlIHBvc2l0aW9ucyB0aGF0IGhhdmUgYmVlbiBzdGF0ZWQgYXJlIChpbiBubyBwYXJ0aWN1
bGFyIG9yZGVyKToNCj4gMSkgVGhlIGRlZmluaXRpb24gZm9yIHRoaXMgaW5mb3JtYXRpb24gc2hv
dWxkIGJlIGluY2x1ZGVkIGluIHRoZSBiYXNlIHNwZWNpZmljYXRpb24gYnV0IGlzIG9wdGlvbmFs
IHRvIHNlbmQgb3IgYmUgYWN0ZWQgb24uDQo+IDIpIElzbuKAmXQgcmVxdWlyZWQgYXQgYWxsLCBs
ZXQgdGhlIGN1cnJlbnQgZHJhZnQgc3RhbmQNCj4gMykgQWRkIGFuIGV4dGVuc2lvbiBwb2ludCB0
byB0aGUgc2NoZW1hIGluIHRoZSBkcmFmdCBzbyB0aGF0IHRoZSBleHRyYSBjYW4gYmUgc3BlY2lm
aWVkIGluIGEgZGlmZmVyZW50IGRyYWZ0IGFuZCBhZGRlZCBieSBzb21ldGhpbmcgcmVxdWlyaW5n
IGl0Lg0KPiANCj4gVGhpcyBlbWFpbCBtYWtlcyBubyBjbGFpbXMgdG8gcHJlZmVyZW5jZSwgYnV0
IGp1c3QgcHJlc2VudHMgdGhlIG9waW5pb25zIHRoYXQgaGF2ZSBiZWVuIGV4cHJlc3NlZC4NCj4g
DQo+IENoZWVycw0KPiBKYW1lcw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+IEVjcml0QGlldGYub3Jn
DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRWNyaXQgbWFpbGlu
ZyBsaXN0DQo+IEVjcml0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vZWNyaXQNCg0K


From nobody Wed Mar 25 12:08:40 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351F31A8999 for ; Wed, 25 Mar 2015 12:08:39 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level: 
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 sJYUycvabcgw for ; Wed, 25 Mar 2015 12:08:37 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 597241B2B7A for ; Wed, 25 Mar 2015 12:08:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1427310513; x=1458846513; h=message-id:in-reply-to:references:date:to:from:subject: cc; bh=nsFOUK8niPjKgBKKW9kjWaMgFyKfFIpx2weJSlJH6V0=; b=kC9EDWCs+MGuxo8hsnASqZrRPubw6R1qX0sFhUiodD20L0FtvtBPAb/3 wwv7a036YzGNxl0YACBJ6/JSK9riIgrMRhmyWRqz69wrfAzb5deKT6ZTu 0GH01P3g4cI3BxNTblgXYyz8kFCEfQ5lwqAw4vXK79h10ispzrL+hMgW4 o=;
X-IronPort-AV: E=McAfee;i="5700,7163,7751"; a="110245828"
Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Mar 2015 12:08:32 -0700
X-IronPort-AV: E=Sophos;i="5.11,466,1422950400"; d="scan'208";a="933384864"
Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Mar 2015 12:08:33 -0700
Received: from Ironmsg03-R.qualcomm.com (ironmsg03-R.qualcomm.com [172.30.46.17]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t2PJ8Voh012891; Wed, 25 Mar 2015 12:08:32 -0700
X-IronPort-AV: E=Sophos;i="5.11,466,1422950400"; d="scan'208";a="879913674"
X-ojodefuego: yes
Received: from unknown (HELO dhcp-93ce.meeting.ietf.org) ([10.64.229.92]) by Ironmsg03-R.qualcomm.com with ESMTP; 25 Mar 2015 12:08:30 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: 
References:   
X-Mailer: Eudora for Mac OS X
Date: Wed, 25 Mar 2015 12:08:29 -0700
To: "Rosen, Brian" 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Cc: "ecrit@ietf.org" 
Subject: Re: [Ecrit] Justification for Data-only (and MSRP only) car-crash
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Mar 2015 19:08:39 -0000

Hi Brian,

At 12:54 PM +0000 3/25/15, Brian Rosen wrote:

>  On 3/24/15, 10:28 PM, "Randall Gellens"  wrote:
>
>>Hi Brian,
>>
>>At 8:58 PM +0000 3/24/15, Brian Rosen wrote:
>>
>>>   Although current car telematics systems always have an audio path,
>>>  there are scenarios where a data-only call is desired.  There are,
>>>  for example, truck telematics systems that only send data.
>>
>>To clarify, we're talking about systems that exchange data between
>>the vehicle and a service provider/dispatch center; we're not talking
>>about emergency calls, right?
>  No, these are rollover and other sensors that currently just report to the
>  owner of the trucking company but should send non-human-initiated
>  emergency calls.

This is a call between the vehicle and the data center, right?  The 
vehicle is not placing an emergency call to a PSAP?  That's what 
"just report to the owner of the trucking company" means, right?  If 
so, I think we're talking about the same thing, which is use of the 
specification for communication between a vehicle and a data center 
or TSP or whatever.  We can add support for this, but I think we'd 
have to tweak the wording in additional-data to do so to relax the 
"for emergency call use only" to include something like "cooperating 
service between cooperating endpoints" or some such.

>
>>
>>>     There are failure scenarios where an audio path can't be created.
>>
>>I think in these cases an audio path was attempted but failed, so
>>there is still a SIP session and there was an intent to have a voice
>>path.  So, I consider these failure modes of the primary emergency
>>mechanism, not a data-only call (where there was never any intent to
>>have interactive media nor a SIP session).
>  No, I was thinking of cases where an audio call would fail, but a data
>  only call would succeed.

Does the vehicle attempt an audio call?  If so, does the SIP session 
get established but the audio media path fails?  If not, what are we 
talking about?

>
>>
>>>     There are newer, lower cost systems that don't involve a call center.
>>
>>If we're talking about the same thing, these are described in the
>>draft, and these do establish a voice path to the PSAP, either direct
>>from the vehicle to the PSAP (NG9-1-1 call from the IVS) or via a
>>previously-paired handset that places a 911 call.
>  No, the device connected to the vehicle is not a handset.  They are
>  plugging in to the car diagnostic connector. Some use a handset to send
>  data, others have a wireless modem.  In either case, the only connection
>  is data.

Are we talking about systems that place an emergency call to the 
PSAP?  Or are we talking about systems that exchange data with an 
entity that isn't a PSAP?

>  I don't think an app can, or should be able to induce a handset to create
>  a 9-1-1 call.  Apps can request the dialer to place a call, but it
>  requires confirmation.  In this case, that would not be the desired
>  response.

There are currently deployed systems that use a paired handset to 
place a 9-1-1 call.  There are other currently deployed systems that 
use an in-built system containing a cell modem to place a 9-1-1 call. 
Are you talking about these, or something else?


>   >
>>>     In addition, there could be text-only calls, rather than audio.
>>
>>Probably these would still have an audio path so the PSAP call taker
>>can hear what is going on, but I don't think the details of the media
>>matter.  What matters is that these are still NG9-1-1 calls that
>>create a SIP session and establish interactive media.  In 3GPP, this
>>is Multimedia Emergency Services (MMES).
>  Remember that there are documented cases where no audio path is required.
>  Text emergency calls today DO NOT create audio paths, and they should not.
>   It should be possible to create a multimedia emergency call, but it is
>  not, and should not, be required.

We're talking about situations where the desired outcome is an 
emergency call with interactive text (either character at a time or 
message at a time)?  If so, then we're talking about the same thing: 
an emergency call with a SIP session and some form(s) of interactive 
media.

>
>>
>>>   I would like to see these allowed in -car-crash.  Due to
>>>  limitations and design decisions in 3GPP, this capability is not
>>>  possible in ecall, and thus this text would have to be specific to
>>>  -car-crash.
>>
>>The only one of these that I think isn't currently permitted is the
>>telematics case where no emergency call is placed.  I'd be happy to
>>add this, but in Additional-Data we said that the mechanism is only
>>to be used in emergency calls.  We could change that to include
>>emergency calls and private/limited use between pre-established
>>endpoints or some such.
>  Not asking for that.  Emergency calls only

How is it an emergency call if the vehicle is exchanging data with 
the trucking company or a dispatch center or some other entity?


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Never Withhold Herpes Infection from Loved One
--Newspaper headline


From nobody Wed Mar 25 12:17:28 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C918F1B2AB1 for ; Wed, 25 Mar 2015 12:17:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 GJvWRS1DO_Pl for ; Wed, 25 Mar 2015 12:17:20 -0700 (PDT)
Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (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 D68241B2ADF for ; Wed, 25 Mar 2015 12:17:19 -0700 (PDT)
Received: by pacwe9 with SMTP id we9so38238122pac.1 for ; Wed, 25 Mar 2015 12:17:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=MRaTND4IVfKs3UttH1IrGrTtM8dHi8Ay3fcXtzHjISo=; b=WQAJwAsnvJf/h68KOjjpiZh3L85uXsZM9l97v9NoTM2CXHFu6ZNb8u5LGMtZ8ExF5x tSHT2mRJrxrTURecITY6yI63qUa+0LB8WKpBIzKTSv4eGa975fEWZluOltJDCKKFH1Ph uWX9DKEsk23vjK5Hn9yJyQlB+thSAX15Gqf24rrXN7EOf0927Qe0jO0gq0FuHmD6xmDw hFXjik9OH/KCnIyHsrcRUbXEFjB8jI/7glC3p0mgEGvF+k6R75tCs6EiHIIBVA/ThbVk 3WjBUR1h9JzgnFVcGaSQbT3hTG+yG0/3zUv+3wY4xAkfhclguhp50zfMmI6eDJBBrDXJ mnMA==
X-Received: by 10.66.234.2 with SMTP id ua2mr19696447pac.137.1427311039620; Wed, 25 Mar 2015 12:17:19 -0700 (PDT)
Received: from [192.168.1.18] (124-149-62-12.dyn.iinet.net.au. [124.149.62.12]) by mx.google.com with ESMTPSA id y15sm3210130pbt.36.2015.03.25.12.17.17 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Mar 2015 12:17:19 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: James Winterbottom 
In-Reply-To: <5F3DEAC5-1A13-45A3-B9C8-51579BAC22F9@gmail.com>
Date: Thu, 26 Mar 2015 06:17:16 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <07AAEC1A-6B87-4CA8-BBE5-E07E2B72E004@gmail.com>
References: <5F3DEAC5-1A13-45A3-B9C8-51579BAC22F9@gmail.com>
To: "ecrit_ietf.org" 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Subject: Re: [Ecrit] HELD Routing summary
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Mar 2015 19:17:25 -0000

I support option 3.
This allows people to add extra stuff if they want but it doesn=E2=80=99t =
require implementers of this draft to understand LoST information, which =
is what option 1 would do.


Cheers
James

> On 25 Mar 2015, at 7:02 pm, James Winterbottom =
 wrote:
>=20
> Hi All,
>=20
> As I see it there is one open discussion point and three positions on =
this point.
> The discussion point is whether or not all of the ancillary data that =
is returned by a LoST findService request should be included in the HELD =
routing response or not.
>=20
> The three positions that have been stated are (in no particular =
order):
> 1) The definition for this information should be included in the base =
specification but is optional to send or be acted on.
> 2) Isn=E2=80=99t required at all, let the current draft stand
> 3) Add an extension point to the schema in the draft so that the extra =
can be specified in a different draft and added by something requiring =
it.
>=20
> This email makes no claims to preference, but just presents the =
opinions that have been expressed.
>=20
> Cheers
> James
>=20


From nobody Wed Mar 25 12:21:12 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784A51B29F2 for ; Wed, 25 Mar 2015 12:21:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 BiHjK6Nl-ZtB for ; Wed, 25 Mar 2015 12:21:09 -0700 (PDT)
Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (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 C61F21A8A9B for ; Wed, 25 Mar 2015 12:21:09 -0700 (PDT)
Received: by pdnc3 with SMTP id c3so37897736pdn.0 for ; Wed, 25 Mar 2015 12:21:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NssN35BUxfXu+ZG/bIecBPQRW5MvSoBHisq9Q3j56yk=; b=tb3EgRyFA4wJa2nP35FKiNnM+M9fIiYVuHP5JsYxHS2Q2Aje0/KTRm5V+TjcVzPVRY Mbv2Pva+DV/3gzJmApTthIZZ/HsASDmLzx8m7ht4Rp9dd12Rk4iFZYIxAZuFfU1ly302 mY3SsqEUNEBe54i0vMLO4PM8sQR/UvTgpapIoSqISu6SeUtq75tg6x8lX8CsOo6yEv2z q6T3M53J+VLJ3NBwXd/uQChVk+o6GBWygE37DV1x959qq43EjLDywy0KRsNrE2feFeuM n7PEm3fF2TX3HrxyMBot+iAJ9D/zqBT65bvHpAJQPegeEgMOlAk2rCelKNzkLd687Dx5 eidg==
X-Received: by 10.68.113.161 with SMTP id iz1mr20064101pbb.30.1427311268392; Wed, 25 Mar 2015 12:21:08 -0700 (PDT)
Received: from [192.168.1.18] (124-149-62-12.dyn.iinet.net.au. [124.149.62.12]) by mx.google.com with ESMTPSA id hr5sm3210899pbb.44.2015.03.25.12.21.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Mar 2015 12:21:07 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: James Winterbottom 
In-Reply-To: <14546D76-AEF5-4C23-9BA0-00B6FA4C1E96@neustar.biz>
Date: Thu, 26 Mar 2015 06:21:04 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5F3DEAC5-1A13-45A3-B9C8-51579BAC22F9@gmail.com> <058CE00BD4D6B94FAD033A2439EA1E4B01E9E52D80B6@HE113667.emea1.cds.t-internal.com> <14546D76-AEF5-4C23-9BA0-00B6FA4C1E96@neustar.biz>
To: "Rosen, Brian" 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: "ecrit@ietf.org" 
Subject: Re: [Ecrit] HELD Routing summary
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Mar 2015 19:21:11 -0000

There is downside to using the existing schema Brian, this is spelt out =
clearly in the draft. In order to include the fields you want a new =
element would need to be defined in this draft to support it. I think =
that that is the wrong way to do it as there has been no expression of =
need. If a need arrises after this draft is done, then it can be added =
later. Right now it isn=E2=80=99t needed.

As I said in my preference for option 3, I think that the extension =
point should be added then anything can be added later if required.

Cheers
James


> On 26 Mar 2015, at 2:52 am, Rosen, Brian  =
wrote:
>=20
> Let=E2=80=99s say that someone comes along and shows a decent use case =
for including a service boundary.
>=20
> So they define an extension for it.
>=20
> That extension may or may not be the same as the service boundary that =
LoST returns.  An implementation designed to provide world-wide service =
would have to change.
>=20
> Returning the boundary is already optional in the LoST schema.
>=20
> If we used the existing definition:
> 1. No new document is required
> 2. Compatibility between this HELD extension and LoST is maintained
> 3. Systems built to support both models don=E2=80=99t have to change
>=20
> There is, as far as I can see, no downside to using the existing =
schema other than making the smallest possible response a bit bigger.   =
One can always ignore any returned items not needed/wanted, and since =
they are optional they can=E2=80=99t be assumed to be there.
>=20
> Option 2 (don=E2=80=99t allow an extension point on the return) makes =
no sense to me.  I can=E2=80=99t imagine the IETF doing that.  Any =
extension would then require all existing implementations to be changed.
>=20
> Brian
>=20
>> On Mar 25, 2015, at 9:49 AM, R.Jesske@telekom.de wrote:
>>=20
>> Hi James,
>> thank you for the summary.
>> My position is reflected in point 2.
>>=20
>> If people want to add something to a mechanism can it not be done =
only in writing a further draft?
>> This means also including in such a draft also a extension mechanism.
>>=20
>> I think that would be a clear line to satisfy everybody.
>>=20
>>=20
>> Best Regards
>>=20
>> Roland=20
>>=20
>> -----Urspr=C3=BCngliche Nachricht-----
>> Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von James =
Winterbottom
>> Gesendet: Mittwoch, 25. M=C3=A4rz 2015 09:03
>> An: ecrit_ietf.org
>> Betreff: [Ecrit] HELD Routing summary
>>=20
>> Hi All,
>>=20
>> As I see it there is one open discussion point and three positions on =
this point.
>> The discussion point is whether or not all of the ancillary data that =
is returned by a LoST findService request should be included in the HELD =
routing response or not.
>>=20
>> The three positions that have been stated are (in no particular =
order):
>> 1) The definition for this information should be included in the base =
specification but is optional to send or be acted on.
>> 2) Isn=E2=80=99t required at all, let the current draft stand
>> 3) Add an extension point to the schema in the draft so that the =
extra can be specified in a different draft and added by something =
requiring it.
>>=20
>> This email makes no claims to preference, but just presents the =
opinions that have been expressed.
>>=20
>> Cheers
>> James
>>=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
>=20


From nobody Thu Mar 26 06:22:58 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690DD1B2CC9 for ; Thu, 26 Mar 2015 06:22:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level: 
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 Gm66eou_x-Zr for ; Thu, 26 Mar 2015 06:22:54 -0700 (PDT)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (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 CBFF71A8A58 for ; Thu, 26 Mar 2015 06:22:53 -0700 (PDT)
Received: by ieclw3 with SMTP id lw3so45949506iec.2 for ; Thu, 26 Mar 2015 06:22:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8vK2dF5mrgrzoaRvKWOHQz9pGd2kaN1+wxyGyF01EaE=; b=swMGgVBHF/OhCyNimKB1oSTYAQCcHUohhHLQg6i/1u2oKm5VwP7Z/BFMFH5lYAg047 PXi339pJiTIHYG1FKttAsaqlGIAPYxcr8hjCavKiwJ0gvgAsmqfLeREo3aaT2BkIbc3p BhJdfk6TMnnffacXEi5OGz9RKJZgZQmpYeJeFqt1yMuc4usG/DocsenmDTKkT/HzIXH/ UWlb7HjU+rvOGHG+ivH9T6UvHMRj3+ICJs2F9JDLaJm/M4rjJEJwJ7IaVLSDxgP7aqFh ujS7YNZMOe3woKgVX9505h5IffCXPmarUVDC6VK6ilExrpwuEfjzsYzBVdiiDpoWVSbc gfkg==
MIME-Version: 1.0
X-Received: by 10.107.155.13 with SMTP id d13mr20804108ioe.29.1427376173228; Thu, 26 Mar 2015 06:22:53 -0700 (PDT)
Received: by 10.36.192.84 with HTTP; Thu, 26 Mar 2015 06:22:53 -0700 (PDT)
In-Reply-To: 
References: <5F3DEAC5-1A13-45A3-B9C8-51579BAC22F9@gmail.com> <058CE00BD4D6B94FAD033A2439EA1E4B01E9E52D80B6@HE113667.emea1.cds.t-internal.com> <14546D76-AEF5-4C23-9BA0-00B6FA4C1E96@neustar.biz> 
Date: Thu, 26 Mar 2015 14:22:53 +0100
Message-ID: 
From: Laura Liess 
To: James Winterbottom ,  "Rosen, Brian" 
Content-Type: multipart/alternative; boundary=001a1141bd00c427cb051230e9fa
Archived-At: 
Cc: "ecrit@ietf.org" 
Subject: Re: [Ecrit] HELD Routing summary
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 13:22:57 -0000

--001a1141bd00c427cb051230e9fa
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I would prefer 3) and I can live with 2).

I am oposed to 1) because it would delay the draft progress, just to add
features about we don't know if anyone will need them andif so,  what
exactly will be needed. For the work in ETSI on the EC M493 this is clearly
not needed. ETSI needs the draft finished very soon, if we want the final
ETSI specification, targeted for the end of this year, to refer an RFC and
not a draft and the implementations which will come then soon, to be based
an RFC and not on some intermediary version of the draft.

I think 3) is a good solution, flexible enough that everyone could live
with it.

Thank you
Laura

2015-03-25 20:21 GMT+01:00 James Winterbottom <
a.james.winterbottom@gmail.com>:

> There is downside to using the existing schema Brian, this is spelt out
> clearly in the draft. In order to include the fields you want a new eleme=
nt
> would need to be defined in this draft to support it. I think that that i=
s
> the wrong way to do it as there has been no expression of need. If a need
> arrises after this draft is done, then it can be added later. Right now i=
t
> isn't needed.
>
> As I said in my preference for option 3, I think that the extension point
> should be added then anything can be added later if required.
>
> Cheers
> James
>
>
> > On 26 Mar 2015, at 2:52 am, Rosen, Brian 
> wrote:
> >
> > Let's say that someone comes along and shows a decent use case for
> including a service boundary.
> >
> > So they define an extension for it.
> >
> > That extension may or may not be the same as the service boundary that
> LoST returns.  An implementation designed to provide world-wide service
> would have to change.
> >
> > Returning the boundary is already optional in the LoST schema.
> >
> > If we used the existing definition:
> > 1. No new document is required
> > 2. Compatibility between this HELD extension and LoST is maintained
> > 3. Systems built to support both models don't have to change
> >
> > There is, as far as I can see, no downside to using the existing schema
> other than making the smallest possible response a bit bigger.   One can
> always ignore any returned items not needed/wanted, and since they are
> optional they can't be assumed to be there.
> >
> > Option 2 (don't allow an extension point on the return) makes no sense
> to me.  I can't imagine the IETF doing that.  Any extension would then
> require all existing implementations to be changed.
> >
> > Brian
> >
> >> On Mar 25, 2015, at 9:49 AM, R.Jesske@telekom.de wrote:
> >>
> >> Hi James,
> >> thank you for the summary.
> >> My position is reflected in point 2.
> >>
> >> If people want to add something to a mechanism can it not be done only
> in writing a further draft?
> >> This means also including in such a draft also a extension mechanism.
> >>
> >> I think that would be a clear line to satisfy everybody.
> >>
> >>
> >> Best Regards
> >>
> >> Roland
> >>
> >> -----Urspr=FCngliche Nachricht-----
> >> Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von James
> Winterbottom
> >> Gesendet: Mittwoch, 25. M=E4rz 2015 09:03
> >> An: ecrit_ietf.org
> >> Betreff: [Ecrit] HELD Routing summary
> >>
> >> Hi All,
> >>
> >> As I see it there is one open discussion point and three positions on
> this point.
> >> The discussion point is whether or not all of the ancillary data that
> is returned by a LoST findService request should be included in the HELD
> routing response or not.
> >>
> >> The three positions that have been stated are (in no particular order)=
:
> >> 1) The definition for this information should be included in the base
> specification but is optional to send or be acted on.
> >> 2) Isn't required at all, let the current draft stand
> >> 3) Add an extension point to the schema in the draft so that the extra
> can be specified in a different draft and added by something requiring it=
.
> >>
> >> This email makes no claims to preference, but just presents the
> opinions that have been expressed.
> >>
> >> Cheers
> >> James
> >>
> >> _______________________________________________
> >> 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
> >
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>

--001a1141bd00c427cb051230e9fa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I would prefer 3) and I can live with 2). 

I a=
m oposed to 1)=20
because it would delay the draft progress, just to add features about we
 don't know if anyone will need them andif so,  what exactly will =
be=20
needed. For the work in ETSI on the EC M493=20
this is clearly not needed. ETSI needs the draft finished very soon, if=20
we want the final ETSI specification, targeted for the end of this year,
 to refer an RFC and not a draft and the implementations which will come
 then soon, to be based an RFC and not on some intermediary version of=20
the draft.  

I think 3) is a good solution, flexible=
 enough that everyone could live with it. 

Thank you
Laura
=


2015-03-25 20:21 =
GMT+01:00 James Winterbottom <a.james.winterbottom@gmail.com<=
/a>>:
There is downside to usin=
g the existing schema Brian, this is spelt out clearly in the draft. In ord=
er to include the fields you want a new element would need to be defined in=
 this draft to support it. I think that that is the wrong way to do it as t=
here has been no expression of need. If a need arrises after this draft is =
done, then it can be added later. Right now it isn’t needed.



As I said in my preference for option 3, I think that the extension point s=
hould be added then anything can be added later if required.



Cheers

James






> On 26 Mar 2015, at 2:52 am, Rosen, Brian <Brian.Rosen@neustar.biz> wrote:

>

> Let’s say that someone comes along and shows a decent use case f=
or including a service boundary.

>

> So they define an extension for it.

>

> That extension may or may not be the same as the service boundary that=
 LoST returns.  An implementation designed to provide world-wide servi=
ce would have to change.

>

> Returning the boundary is already optional in the LoST schema.

>

> If we used the existing definition:

> 1. No new document is required

> 2. Compatibility between this HELD extension and LoST is maintained
> 3. Systems built to support both models don’t have to change

>

> There is, as far as I can see, no downside to using the existing schem=
a other than making the smallest possible response a bit bigger.  &nbs=
p;One can always ignore any returned items not needed/wanted, and since the=
y are optional they can’t be assumed to be there.

>

> Option 2 (don’t allow an extension point on the return) makes no=
 sense to me.  I can’t imagine the IETF doing that.  Any ex=
tension would then require all existing implementations to be changed.

>

> Brian

>

>> On Mar 25, 2015, at 9:49 AM, R.Jesske@telekom.de wrote:

>>

>> Hi James,

>> thank you for the summary.

>> My position is reflected in point 2.

>>

>> If people want to add something to a mechanism can it not be done =
only in writing a further draft?

>> This means also including in such a draft also a extension mechani=
sm.

>>

>> I think that would be a clear line to satisfy everybody.

>>

>>

>> Best Regards

>>

>> Roland

>>

>> -----Urspr=FCngliche Nachricht-----

>> Von: Ecrit [mailto:ecrit=
-bounces@ietf.org] Im Auftrag von James Winterbottom

>> Gesendet: Mittwoch, 25. M=E4rz 2015 09:03

>> An: ecrit_ietf=
.org

>> Betreff: [Ecrit] HELD Routing summary

>>

>> Hi All,

>>

>> As I see it there is one open discussion point and three positions=
 on this point.

>> The discussion point is whether or not all of the ancillary data t=
hat is returned by a LoST findService request should be included in the HEL=
D routing response or not.

>>

>> The three positions that have been stated are (in no particular or=
der):

>> 1) The definition for this information should be included in the b=
ase specification but is optional to send or be acted on.

>> 2) Isn’t required at all, let the current draft stand

>> 3) Add an extension point to the schema in the draft so that the e=
xtra can be specified in a different draft and added by something requiring=
 it.

>>

>> This email makes no claims to preference, but just presents the op=
inions that have been expressed.

>>

>> Cheers

>> James

>>

>> _______________________________________________

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

>



_______________________________________________

Ecrit mailing list

Ecrit@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/ecrit





--001a1141bd00c427cb051230e9fa--


From nobody Thu Mar 26 07:32:05 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8E51A0252 for ; Thu, 26 Mar 2015 07:32:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 7UdmsTglF6BN for ; Thu, 26 Mar 2015 07:32:00 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 666B81A039D for ; Thu, 26 Mar 2015 07:31:13 -0700 (PDT)
Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.14.7/8.14.7) with SMTP id t2QEPWVf020493; Thu, 26 Mar 2015 10:31:11 -0400
Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1tcknf8126-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Mar 2015 10:31:11 -0400
Received: from STNTEXMB13.cis.neustar.com ([169.254.3.129]) by stntexhc10.cis.neustar.com ([169.254.4.32]) with mapi id 14.03.0158.001; Thu, 26 Mar 2015 10:31:09 -0400
From: "Rosen, Brian" 
To: Laura Liess 
Thread-Topic: [Ecrit] HELD Routing summary
Thread-Index: AQHQZxOrLUztZJ1aYEW07NjBnVfm7w==
Date: Thu, 26 Mar 2015 14:31:09 +0000
Message-ID: 
References: <5F3DEAC5-1A13-45A3-B9C8-51579BAC22F9@gmail.com> <058CE00BD4D6B94FAD033A2439EA1E4B01E9E52D80B6@HE113667.emea1.cds.t-internal.com> <14546D76-AEF5-4C23-9BA0-00B6FA4C1E96@neustar.biz>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.132.33]
Content-Type: multipart/alternative; boundary="_000_F231A13C452A4DC68602B9837BD785D5neustarbiz_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=nai engine=5700 definitions=7751 signatures=670576
X-Proofpoint-Spam-Reason: safe
Archived-At: 
Cc: "ecrit@ietf.org" 
Subject: Re: [Ecrit] HELD Routing summary
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 14:32:04 -0000

--_000_F231A13C452A4DC68602B9837BD785D5neustarbiz_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

I don=92t understand any of this logic.

You import the definition from RFC5222 and refer to it for the meaning of t=
he elements.  Done.  No time delay.  10 minutes of editing.

I want to be able to build systems that work world-wide.  The more commonal=
ity of data structures, the better.

You have not shown any harm to re-use of a data structure that was designed=
 for the purpose you have, has had extensive IETF review, implementation, a=
nd consensus.  You want to invent something new.  It=92s clearly a subset, =
but it=92s not precisely a subset.  That is not a good idea in my opinion. =
 As the majority of elements in  are optional, an implementation c=
an choose never to send them (server) or ignore them if received (client). =
 If you use the extension point (3), and we later decide that most of  is in fact useful, we would end up different data structures, because =
the base structure is different.

Brian

On Mar 26, 2015, at 8:22 AM, Laura Liess > wrote:

I would prefer 3) and I can live with 2).

I am oposed to 1) because it would delay the draft progress, just to add fe=
atures about we don't know if anyone will need them andif so,  what exactly=
 will be needed. For the work in ETSI on the EC M493 this is clearly not ne=
eded. ETSI needs the draft finished very soon, if we want the final ETSI sp=
ecification, targeted for the end of this year, to refer an RFC and not a d=
raft and the implementations which will come then soon, to be based an RFC =
and not on some intermediary version of the draft.

I think 3) is a good solution, flexible enough that everyone could live wit=
h it.

Thank you
[https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]Laura

2015-03-25 20:21 GMT+01:00 James Winterbottom >:
There is downside to using the existing schema Brian, this is spelt out cle=
arly in the draft. In order to include the fields you want a new element wo=
uld need to be defined in this draft to support it. I think that that is th=
e wrong way to do it as there has been no expression of need. If a need arr=
ises after this draft is done, then it can be added later. Right now it isn=
=92t needed.

As I said in my preference for option 3, I think that the extension point s=
hould be added then anything can be added later if required.

Cheers
James


> On 26 Mar 2015, at 2:52 am, Rosen, Brian > wrote:
>
> Let=92s say that someone comes along and shows a decent use case for incl=
uding a service boundary.
>
> So they define an extension for it.
>
> That extension may or may not be the same as the service boundary that Lo=
ST returns.  An implementation designed to provide world-wide service would=
 have to change.
>
> Returning the boundary is already optional in the LoST schema.
>
> If we used the existing definition:
> 1. No new document is required
> 2. Compatibility between this HELD extension and LoST is maintained
> 3. Systems built to support both models don=92t have to change
>
> There is, as far as I can see, no downside to using the existing schema o=
ther than making the smallest possible response a bit bigger.   One can alw=
ays ignore any returned items not needed/wanted, and since they are optiona=
l they can=92t be assumed to be there.
>
> Option 2 (don=92t allow an extension point on the return) makes no sense =
to me.  I can=92t imagine the IETF doing that.  Any extension would then re=
quire all existing implementations to be changed.
>
> Brian
>
>> On Mar 25, 2015, at 9:49 AM, R.Jesske@telekom.de wrote:
>>
>> Hi James,
>> thank you for the summary.
>> My position is reflected in point 2.
>>
>> If people want to add something to a mechanism can it not be done only i=
n writing a further draft?
>> This means also including in such a draft also a extension mechanism.
>>
>> I think that would be a clear line to satisfy everybody.
>>
>>
>> Best Regards
>>
>> Roland
>>
>> -----Urspr=FCngliche Nachricht-----
>> Von: Ecrit [mailto:ecrit-bounces@ietf.org=
] Im Auftrag von James Winterbottom
>> Gesendet: Mittwoch, 25. M=E4rz 2015 09:03
>> An: ecrit_ietf.org
>> Betreff: [Ecrit] HELD Routing summary
>>
>> Hi All,
>>
>> As I see it there is one open discussion point and three positions on th=
is point.
>> The discussion point is whether or not all of the ancillary data that is=
 returned by a LoST findService request should be included in the HELD rout=
ing response or not.
>>
>> The three positions that have been stated are (in no particular order):
>> 1) The definition for this information should be included in the base sp=
ecification but is optional to send or be acted on.
>> 2) Isn=92t required at all, let the current draft stand
>> 3) Add an extension point to the schema in the draft so that the extra c=
an be specified in a different draft and added by something requiring it.
>>
>> This email makes no claims to preference, but just presents the opinions=
 that have been expressed.
>>
>> Cheers
>> James
>>
>> _______________________________________________
>> 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
>

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



--_000_F231A13C452A4DC68602B9837BD785D5neustarbiz_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <070059705BB3194C8D3A356919C4E021@neustar.biz>
Content-Transfer-Encoding: quoted-printable






I don=92t understand any of this logic.






You import the definition from RFC5222 and refer to it for =
the meaning of the elements.  Done.  No time delay.  10 minu=
tes of editing.







I want to be able to build systems that work world-wide. &n=
bsp;The more commonality of data structures, the better.







You have not shown any harm to re-use of a data structure t=
hat was designed for the purpose you have, has had extensive IETF review, i=
mplementation, and consensus.  You want to invent something new.  =
;It=92s clearly a subset, but it=92s not precisely
 a subset.  That is not a good idea in my opinion.  As the majori=
ty of elements in <mapping> are optional, an implementation can choos=
e never to send them (server) or ignore them if received (client).  If=
 you use the extension point (3), and we later decide
 that most of <mapping> is in fact useful, we would end up different =
data structures, because the base structure is different.







Brian









On Mar 26, 2015, at 8:22 AM, Laura Liess <laura.liess.dt@googlemail.com=
> wrote:








I would prefer 3) and I can live with 2). 



I am oposed to 1) because it would delay the draft progress, just to add fe=
atures about we don't know if anyone will need them andif so,  what ex=
actly will be needed. For the work in ETSI on the EC M493 this is clearly n=
ot needed. ETSI needs the draft finished
 very soon, if we want the final ETSI specification, targeted for the end o=
f this year, to refer an RFC and not a draft and the implementations which =
will come then soon, to be based an RFC and not on some intermediary versio=
n of the draft. 







I think 3) is a good solution, flexible enough that everyon=
e could live with it.






Thank you



Laura







2015-03-25 20:21 GMT+01:00 James Winterbotto=
m 
<a.james.winterbottom@gmail.com>:



There is downside to using the existing schema Brian, this is spelt out cle=
arly in the draft. In order to include the fields you want a new element wo=
uld need to be defined in this draft to support it. I think that that is th=
e wrong way to do it as there has
 been no expression of need. If a need arrises after this draft is done, th=
en it can be added later. Right now it isn=92t needed.



As I said in my preference for option 3, I think that the extension point s=
hould be added then anything can be added later if required.



Cheers

James









> On 26 Mar 2015, at 2:52 am, Rosen, Brian <Brian.Rosen@neustar.biz> wrote:

>

> Let=92s say that someone comes along and shows a decent use case for i=
ncluding a service boundary.

>

> So they define an extension for it.

>

> That extension may or may not be the same as the service boundary that=
 LoST returns.  An implementation designed to provide world-wide servi=
ce would have to change.

>

> Returning the boundary is already optional in the LoST schema.

>

> If we used the existing definition:

> 1. No new document is required

> 2. Compatibility between this HELD extension and LoST is maintained
> 3. Systems built to support both models don=92t have to change

>

> There is, as far as I can see, no downside to using the existing schem=
a other than making the smallest possible response a bit bigger.  &nbs=
p;One can always ignore any returned items not needed/wanted, and since the=
y are optional they can=92t be assumed to be there.

>

> Option 2 (don=92t allow an extension point on the return) makes no sen=
se to me.  I can=92t imagine the IETF doing that.  Any extension =
would then require all existing implementations to be changed.

>

> Brian

>

>> On Mar 25, 2015, at 9:49 AM, R.Jesske@telekom.de wrote:

>>

>> Hi James,

>> thank you for the summary.

>> My position is reflected in point 2.

>>

>> If people want to add something to a mechanism can it not be done =
only in writing a further draft?

>> This means also including in such a draft also a extension mechani=
sm.

>>

>> I think that would be a clear line to satisfy everybody.

>>

>>

>> Best Regards

>>

>> Roland

>>

>> -----Urspr=FCngliche Nachricht-----

>> Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von James Winterbottom

>> Gesendet: Mittwoch, 25. M=E4rz 2015 09:03

>> An: ecrit_ietf.org

>> Betreff: [Ecrit] HELD Routing summary

>>

>> Hi All,

>>

>> As I see it there is one open discussion point and three positions=
 on this point.

>> The discussion point is whether or not all of the ancillary data t=
hat is returned by a LoST findService request should be included in the HEL=
D routing response or not.

>>

>> The three positions that have been stated are (in no particular or=
der):

>> 1) The definition for this information should be included in the b=
ase specification but is optional to send or be acted on.

>> 2) Isn=92t required at all, let the current draft stand

>> 3) Add an extension point to the schema in the draft so that the e=
xtra can be specified in a different draft and added by something requiring=
 it.

>>

>> This email makes no claims to preference, but just presents the op=
inions that have been expressed.

>>

>> Cheers

>> James

>>

>> _______________________________________________

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

>



_______________________________________________

Ecrit mailing list

Ecrit@ietf.org

https://www.ietf.org/mailman/listinfo/ecrit




























--_000_F231A13C452A4DC68602B9837BD785D5neustarbiz_--


From nobody Thu Mar 26 07:36:11 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83541A039D for ; Thu, 26 Mar 2015 07:36:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 DtZdlU3HVRXX for ; Thu, 26 Mar 2015 07:36:05 -0700 (PDT)
Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (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 850EF1A0007 for ; Thu, 26 Mar 2015 07:36:05 -0700 (PDT)
Received: by pabxg6 with SMTP id xg6so64835750pab.0 for ; Thu, 26 Mar 2015 07:36:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=iga6iCxN28Ldx5bJA8c3NxcVDoamZsZyyB+jeKdlXGU=; b=w3gj2fKJDIT0thkeSOEKesImhuZyBbt4T/GaIOjAbh/5TbSxyCQRPiQZmTGw8fQ+2l 0jz6SV51S25ymLr/a8jnn+zYwCBfqqkdKUnpzaBf799HXfaejKPUHe+rllwQZm34ew7H wmSLN3sK2B6c3miFXAziwdx1c7Ajg6iaeC8/0csMdoe0LJNZKLIJ2O5M+eWZZyPkyqHU OFS9A/RJZVIqXJTaxv+wnoP5nOqLvyP3InM7uZPlMZbY9nEx6me2eXa7EHpJdHOosl/p kwezWh1Wt5vGtFDWeLThWiVkIhwMu8cD/mafO93JRioAmECUt6/ZqrOX44C6kFdF5IjP Jpqg==
X-Received: by 10.70.0.41 with SMTP id 9mr6015263pdb.123.1427380565033; Thu, 26 Mar 2015 07:36:05 -0700 (PDT)
Received: from [192.168.1.18] (124-149-62-12.dyn.iinet.net.au. [124.149.62.12]) by mx.google.com with ESMTPSA id nj5sm5830197pdb.35.2015.03.26.07.36.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Mar 2015 07:36:04 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_FB6FAEBA-1D43-430A-B47B-3EC7A7771BA0"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: James Winterbottom 
In-Reply-To: 
Date: Fri, 27 Mar 2015 01:35:59 +1100
Message-Id: <75BAB4CE-E408-472D-80DD-569ADD918A8B@gmail.com>
References: <5F3DEAC5-1A13-45A3-B9C8-51579BAC22F9@gmail.com> <058CE00BD4D6B94FAD033A2439EA1E4B01E9E52D80B6@HE113667.emea1.cds.t-internal.com> <14546D76-AEF5-4C23-9BA0-00B6FA4C1E96@neustar.biz>   
To: "Rosen, Brian" 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: "ecrit@ietf.org" 
Subject: Re: [Ecrit] HELD Routing summary
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 14:36:09 -0000

--Apple-Mail=_FB6FAEBA-1D43-430A-B47B-3EC7A7771BA0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

HUH????

As I have said before and as the draft states, at least of the mandatory =
mapping elements is not applicable where you don=92t LoST, so simply =
resuming mapping doesn=92t work.

If we put the extension point in, and you want to reuse mapping elements =
in your implementation you can simply reference them in the extension =
point, no specification required and things that choose not to =
understand the extension can ignore  them. No extra specification =
required, no extra work at all required in this specification, not even =
10 minutes editing and 4 years of haggling.

Cheers
James


> On 27 Mar 2015, at 1:31 am, Rosen, Brian  =
wrote:
>=20
> I don=92t understand any of this logic.
>=20
> You import the definition from RFC5222 and refer to it for the meaning =
of the elements.  Done.  No time delay.  10 minutes of editing.
>=20
> I want to be able to build systems that work world-wide.  The more =
commonality of data structures, the better.
>=20
> You have not shown any harm to re-use of a data structure that was =
designed for the purpose you have, has had extensive IETF review, =
implementation, and consensus.  You want to invent something new.  It=92s =
clearly a subset, but it=92s not precisely a subset.  That is not a good =
idea in my opinion.  As the majority of elements in  are =
optional, an implementation can choose never to send them (server) or =
ignore them if received (client).  If you use the extension point (3), =
and we later decide that most of  is in fact useful, we would =
end up different data structures, because the base structure is =
different.
>=20
> Brian
>=20
>> On Mar 26, 2015, at 8:22 AM, Laura Liess =
> =
wrote:
>>=20
>> I would prefer 3) and I can live with 2).=20
>>=20
>> I am oposed to 1) because it would delay the draft progress, just to =
add features about we don't know if anyone will need them andif so,  =
what exactly will be needed. For the work in ETSI on the EC M493 this is =
clearly not needed. ETSI needs the draft finished very soon, if we want =
the final ETSI specification, targeted for the end of this year, to =
refer an RFC and not a draft and the implementations which will come =
then soon, to be based an RFC and not on some intermediary version of =
the draft. =20
>>=20
>> I think 3) is a good solution, flexible enough that everyone could =
live with it.=20
>>=20
>> Thank you
>> Laura
>>=20
>> 2015-03-25 20:21 GMT+01:00 James Winterbottom =
>:
>> There is downside to using the existing schema Brian, this is spelt =
out clearly in the draft. In order to include the fields you want a new =
element would need to be defined in this draft to support it. I think =
that that is the wrong way to do it as there has been no expression of =
need. If a need arrises after this draft is done, then it can be added =
later. Right now it isn=92t needed.
>>=20
>> As I said in my preference for option 3, I think that the extension =
point should be added then anything can be added later if required.
>>=20
>> Cheers
>> James
>>=20
>>=20
>> > On 26 Mar 2015, at 2:52 am, Rosen, Brian > wrote:
>> >
>> > Let=92s say that someone comes along and shows a decent use case =
for including a service boundary.
>> >
>> > So they define an extension for it.
>> >
>> > That extension may or may not be the same as the service boundary =
that LoST returns.  An implementation designed to provide world-wide =
service would have to change.
>> >
>> > Returning the boundary is already optional in the LoST schema.
>> >
>> > If we used the existing definition:
>> > 1. No new document is required
>> > 2. Compatibility between this HELD extension and LoST is maintained
>> > 3. Systems built to support both models don=92t have to change
>> >
>> > There is, as far as I can see, no downside to using the existing =
schema other than making the smallest possible response a bit bigger.   =
One can always ignore any returned items not needed/wanted, and since =
they are optional they can=92t be assumed to be there.
>> >
>> > Option 2 (don=92t allow an extension point on the return) makes no =
sense to me.  I can=92t imagine the IETF doing that.  Any extension =
would then require all existing implementations to be changed.
>> >
>> > Brian
>> >
>> >> On Mar 25, 2015, at 9:49 AM, R.Jesske@telekom.de =
 wrote:
>> >>
>> >> Hi James,
>> >> thank you for the summary.
>> >> My position is reflected in point 2.
>> >>
>> >> If people want to add something to a mechanism can it not be done =
only in writing a further draft?
>> >> This means also including in such a draft also a extension =
mechanism.
>> >>
>> >> I think that would be a clear line to satisfy everybody.
>> >>
>> >>
>> >> Best Regards
>> >>
>> >> Roland
>> >>
>> >> -----Urspr=FCngliche Nachricht-----
>> >> Von: Ecrit [mailto:ecrit-bounces@ietf.org =
] Im Auftrag von James Winterbottom
>> >> Gesendet: Mittwoch, 25. M=E4rz 2015 09:03
>> >> An: ecrit_ietf.org 
>> >> Betreff: [Ecrit] HELD Routing summary
>> >>
>> >> Hi All,
>> >>
>> >> As I see it there is one open discussion point and three positions =
on this point.
>> >> The discussion point is whether or not all of the ancillary data =
that is returned by a LoST findService request should be included in the =
HELD routing response or not.
>> >>
>> >> The three positions that have been stated are (in no particular =
order):
>> >> 1) The definition for this information should be included in the =
base specification but is optional to send or be acted on.
>> >> 2) Isn=92t required at all, let the current draft stand
>> >> 3) Add an extension point to the schema in the draft so that the =
extra can be specified in a different draft and added by something =
requiring it.
>> >>
>> >> This email makes no claims to preference, but just presents the =
opinions that have been expressed.
>> >>
>> >> Cheers
>> >> James
>> >>
>> >> _______________________________________________
>> >> 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 =

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

>>=20
>=20


--Apple-Mail=_FB6FAEBA-1D43-430A-B47B-3EC7A7771BA0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

HUH????

As =
I have said before and as the draft states, at least of the mandatory =
mapping elements is not applicable where you don=92t LoST, so simply =
resuming mapping doesn=92t work.

If we put the extension point in, and =
you want to reuse mapping elements in your implementation you can simply =
reference them in the extension point, no specification required and =
things that choose not to understand the extension can ignore =
 them. No extra specification required, no extra work at all =
required in this specification, not even 10 minutes editing and 4 years =
of haggling.

Cheers
James


On 27 Mar 2015, at 1:31 am, =
Rosen, Brian <Brian.Rosen@neustar.biz> wrote:







I don=92t understand any of this logic.






You import the definition from RFC5222 and refer to it =
for the meaning of the elements.  Done.  No time delay. =
 10 minutes of editing.







I want to be able to build systems that work world-wide. =
 The more commonality of data structures, the better.







You have not shown any harm to re-use of a data =
structure that was designed for the purpose you have, has had extensive =
IETF review, implementation, and consensus.  You want to invent =
something new.  It=92s clearly a subset, but it=92s not precisely
 a subset.  That is not a good idea in my opinion.  As the =
majority of elements in <mapping> are optional, an implementation =
can choose never to send them (server) or ignore them if received =
(client).  If you use the extension point (3), and we later decide
 that most of <mapping> is in fact useful, we would end up =
different data structures, because the base structure is =
different.







Brian









On Mar 26, 2015, at 8:22 AM, Laura Liess <laura.liess.dt@googlemail.com> wrote:








I would prefer 3) and I can live with 2). 



I am oposed to 1) because it would delay the draft progress, just to add =
features about we don't know if anyone will need them andif so,  =
what exactly will be needed. For the work in ETSI on the EC M493 this is =
clearly not needed. ETSI needs the draft finished
 very soon, if we want the final ETSI specification, targeted for the =
end of this year, to refer an RFC and not a draft and the =
implementations which will come then soon, to be based an RFC and not on =
some intermediary version of the draft. 







I think 3) is a good solution, flexible enough that =
everyone could live with it.






Thank you



Laura=








2015-03-25 20:21 GMT+01:00 James Winterbottom =

<a.james.winterbottom@gmail.com>:



There is downside to using the existing schema Brian, this is spelt out =
clearly in the draft. In order to include the fields you want a new =
element would need to be defined in this draft to support it. I think =
that that is the wrong way to do it as there has
 been no expression of need. If a need arrises after this draft is done, =
then it can be added later. Right now it isn=92t needed.



As I said in my preference for option 3, I think that the extension =
point should be added then anything can be added later if required.



Cheers

James









> On 26 Mar 2015, at 2:52 am, Rosen, Brian <Brian.Rosen@neustar.biz> wrote:

>

> Let=92s say that someone comes along and shows a decent use case =
for including a service boundary.

>

> So they define an extension for it.

>

> That extension may or may not be the same as the service boundary =
that LoST returns.  An implementation designed to provide =
world-wide service would have to change.

>

> Returning the boundary is already optional in the LoST schema.

>

> If we used the existing definition:

> 1. No new document is required

> 2. Compatibility between this HELD extension and LoST is =
maintained

> 3. Systems built to support both models don=92t have to change

>

> There is, as far as I can see, no downside to using the existing =
schema other than making the smallest possible response a bit =
bigger.   One can always ignore any returned items not =
needed/wanted, and since they are optional they can=92t be assumed to be =
there.

>

> Option 2 (don=92t allow an extension point on the return) makes no =
sense to me.  I can=92t imagine the IETF doing that.  Any =
extension would then require all existing implementations to be =
changed.

>

> Brian

>

>> On Mar 25, 2015, at 9:49 AM, R.Jesske@telekom.de =
wrote:

>>

>> Hi James,

>> thank you for the summary.

>> My position is reflected in point 2.

>>

>> If people want to add something to a mechanism can it not be =
done only in writing a further draft?

>> This means also including in such a draft also a extension =
mechanism.

>>

>> I think that would be a clear line to satisfy everybody.

>>

>>

>> Best Regards

>>

>> Roland

>>

>> -----Urspr=FCngliche Nachricht-----

>> Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von James =
Winterbottom

>> Gesendet: Mittwoch, 25. M=E4rz 2015 09:03

>> An: ecrit_ietf.org

>> Betreff: [Ecrit] HELD Routing summary

>>

>> Hi All,

>>

>> As I see it there is one open discussion point and three =
positions on this point.

>> The discussion point is whether or not all of the ancillary =
data that is returned by a LoST findService request should be included =
in the HELD routing response or not.

>>

>> The three positions that have been stated are (in no particular =
order):

>> 1) The definition for this information should be included in =
the base specification but is optional to send or be acted on.

>> 2) Isn=92t required at all, let the current draft stand

>> 3) Add an extension point to the schema in the draft so that =
the extra can be specified in a different draft and added by something =
requiring it.

>>

>> This email makes no claims to preference, but just presents the =
opinions that have been expressed.

>>

>> Cheers

>> James

>>

>> _______________________________________________

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

>



_______________________________________________

Ecrit mailing list

Ecrit@ietf.org

https://www.ietf.org/mailman/listinfo/ecrit






























=

--Apple-Mail=_FB6FAEBA-1D43-430A-B47B-3EC7A7771BA0--


From nobody Thu Mar 26 08:20:10 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760871AD071 for ; Thu, 26 Mar 2015 08:20:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 NJRtqULJ4m4E for ; Thu, 26 Mar 2015 08:19:55 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 746461ACEFD for ; Thu, 26 Mar 2015 08:19:45 -0700 (PDT)
Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.14.7/8.14.7) with SMTP id t2QFDssa016081; Thu, 26 Mar 2015 11:19:44 -0400
Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1tcknf84d1-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Mar 2015 11:19:44 -0400
Received: from STNTEXMB13.cis.neustar.com ([169.254.3.129]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Thu, 26 Mar 2015 11:19:37 -0400
From: "Rosen, Brian" 
To: James Winterbottom 
Thread-Topic: [Ecrit] HELD Routing summary
Thread-Index: AQHQZxOrLUztZJ1aYEW07NjBnVfm7w==
Date: Thu, 26 Mar 2015 15:19:37 +0000
Message-ID: 
References: <5F3DEAC5-1A13-45A3-B9C8-51579BAC22F9@gmail.com> <058CE00BD4D6B94FAD033A2439EA1E4B01E9E52D80B6@HE113667.emea1.cds.t-internal.com> <14546D76-AEF5-4C23-9BA0-00B6FA4C1E96@neustar.biz>    <75BAB4CE-E408-472D-80DD-569ADD918A8B@gmail.com>
In-Reply-To: <75BAB4CE-E408-472D-80DD-569ADD918A8B@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.132.33]
Content-Type: multipart/alternative; boundary="_000_EA49CD4BEE854F1F9D4EAB2C13C691CFneustarbiz_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=nai engine=5700 definitions=7751 signatures=670576
X-Proofpoint-Spam-Reason: safe
Archived-At: 
Cc: "ecrit@ietf.org" 
Subject: Re: [Ecrit] HELD Routing summary
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 15:20:01 -0000

--_000_EA49CD4BEE854F1F9D4EAB2C13C691CFneustarbiz_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Come on, the mandatory elements are the source, lastUpdated and expires.  T=
he source might be the HELD server, but it might be something else.  If it=
=92s the HELD server, say so.
It is a trivial ask that you include source, lastUpdated and expires in the=
 response, identical to LoST.  It provides a level of compatibility that is=
 useful, and non-intrusive for implementations to accommodate.  It COULD be=
 a fixed string.

You think of implementations as the server has, internally, all the routing=
 information.  That=92s one way to do it.  Another way to do it is to have =
the HELD server consult a LoST server.  Yes, I know you don=92t think anyon=
e will implement a LoST server.  I think you are wrong.

I understand that I can incrementally add the mapping components as extensi=
ons in a way that is transformable to a =93real=94  structure, but=
 the bits on the wire are different.
If you persist, and consensus is to have an extension point and no more, I=
=92ll submit the draft that does it right away.   Does that REALLY make any=
 sense?

Brian

On Mar 26, 2015, at 9:35 AM, James Winterbottom > wrote:

HUH????

As I have said before and as the draft states, at least of the mandatory ma=
pping elements is not applicable where you don=92t LoST, so simply resuming=
 mapping doesn=92t work.

If we put the extension point in, and you want to reuse mapping elements in=
 your implementation you can simply reference them in the extension point, =
no specification required and things that choose not to understand the exte=
nsion can ignore  them. No extra specification required, no extra work at a=
ll required in this specification, not even 10 minutes editing and 4 years =
of haggling.

Cheers
James


On 27 Mar 2015, at 1:31 am, Rosen, Brian > wrote:

I don=92t understand any of this logic.

You import the definition from RFC5222 and refer to it for the meaning of t=
he elements.  Done.  No time delay.  10 minutes of editing.

I want to be able to build systems that work world-wide.  The more commonal=
ity of data structures, the better.

You have not shown any harm to re-use of a data structure that was designed=
 for the purpose you have, has had extensive IETF review, implementation, a=
nd consensus.  You want to invent something new.  It=92s clearly a subset, =
but it=92s not precisely a subset.  That is not a good idea in my opinion. =
 As the majority of elements in  are optional, an implementation c=
an choose never to send them (server) or ignore them if received (client). =
 If you use the extension point (3), and we later decide that most of  is in fact useful, we would end up different data structures, because =
the base structure is different.

Brian

On Mar 26, 2015, at 8:22 AM, Laura Liess > wrote:

I would prefer 3) and I can live with 2).

I am oposed to 1) because it would delay the draft progress, just to add fe=
atures about we don't know if anyone will need them andif so,  what exactly=
 will be needed. For the work in ETSI on the EC M493 this is clearly not ne=
eded. ETSI needs the draft finished very soon, if we want the final ETSI sp=
ecification, targeted for the end of this year, to refer an RFC and not a d=
raft and the implementations which will come then soon, to be based an RFC =
and not on some intermediary version of the draft.

I think 3) is a good solution, flexible enough that everyone could live wit=
h it.

Thank you
[https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]Laura

2015-03-25 20:21 GMT+01:00 James Winterbottom >:
There is downside to using the existing schema Brian, this is spelt out cle=
arly in the draft. In order to include the fields you want a new element wo=
uld need to be defined in this draft to support it. I think that that is th=
e wrong way to do it as there has been no expression of need. If a need arr=
ises after this draft is done, then it can be added later. Right now it isn=
=92t needed.

As I said in my preference for option 3, I think that the extension point s=
hould be added then anything can be added later if required.

Cheers
James


> On 26 Mar 2015, at 2:52 am, Rosen, Brian > wrote:
>
> Let=92s say that someone comes along and shows a decent use case for incl=
uding a service boundary.
>
> So they define an extension for it.
>
> That extension may or may not be the same as the service boundary that Lo=
ST returns.  An implementation designed to provide world-wide service would=
 have to change.
>
> Returning the boundary is already optional in the LoST schema.
>
> If we used the existing definition:
> 1. No new document is required
> 2. Compatibility between this HELD extension and LoST is maintained
> 3. Systems built to support both models don=92t have to change
>
> There is, as far as I can see, no downside to using the existing schema o=
ther than making the smallest possible response a bit bigger.   One can alw=
ays ignore any returned items not needed/wanted, and since they are optiona=
l they can=92t be assumed to be there.
>
> Option 2 (don=92t allow an extension point on the return) makes no sense =
to me.  I can=92t imagine the IETF doing that.  Any extension would then re=
quire all existing implementations to be changed.
>
> Brian
>
>> On Mar 25, 2015, at 9:49 AM, R.Jesske@telekom.de wrote:
>>
>> Hi James,
>> thank you for the summary.
>> My position is reflected in point 2.
>>
>> If people want to add something to a mechanism can it not be done only i=
n writing a further draft?
>> This means also including in such a draft also a extension mechanism.
>>
>> I think that would be a clear line to satisfy everybody.
>>
>>
>> Best Regards
>>
>> Roland
>>
>> -----Urspr=FCngliche Nachricht-----
>> Von: Ecrit [mailto:ecrit-bounces@ietf.org=
] Im Auftrag von James Winterbottom
>> Gesendet: Mittwoch, 25. M=E4rz 2015 09:03
>> An: ecrit_ietf.org
>> Betreff: [Ecrit] HELD Routing summary
>>
>> Hi All,
>>
>> As I see it there is one open discussion point and three positions on th=
is point.
>> The discussion point is whether or not all of the ancillary data that is=
 returned by a LoST findService request should be included in the HELD rout=
ing response or not.
>>
>> The three positions that have been stated are (in no particular order):
>> 1) The definition for this information should be included in the base sp=
ecification but is optional to send or be acted on.
>> 2) Isn=92t required at all, let the current draft stand
>> 3) Add an extension point to the schema in the draft so that the extra c=
an be specified in a different draft and added by something requiring it.
>>
>> This email makes no claims to preference, but just presents the opinions=
 that have been expressed.
>>
>> Cheers
>> James
>>
>> _______________________________________________
>> 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
>

_______________________________________________
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


--_000_EA49CD4BEE854F1F9D4EAB2C13C691CFneustarbiz_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <38B8A9357FBF62419D836E3A624B0A79@neustar.biz>
Content-Transfer-Encoding: quoted-printable






Come on, the mandatory elements are the source, lastUpdated and expires. &n=
bsp;The source might be the HELD server, but it might be something else. &n=
bsp;If it=92s the HELD server, say so.

It is a trivial ask that you include source, lastUpdated an=
d expires in the response, identical to LoST.  It provides a level of =
compatibility that is useful, and non-intrusive for implementations to acco=
mmodate.  It COULD be a fixed string. 







You think of implementations as the server has, internally,=
 all the routing information.  That=92s one way to do it.  Anothe=
r way to do it is to have the HELD server consult a LoST server.  Yes,=
 I know you don=92t think anyone will implement a LoST
 server.  I think you are wrong.







I understand that I can incrementally add the mapping compo=
nents as extensions in a way that is transformable to a =93real=94 <mapp=
ing> structure, but the bits on the wire are different.  


If you persist, and consensus is to have an extension point=
 and no more, I=92ll submit the draft that does it right away.   Does =
that REALLY make any sense?







Brian









On Mar 26, 2015, at 9:35 AM, James Winterbottom <a.james.winterbottom@=
gmail.com> wrote:







HUH????






As I have said before and as the draft states, at least of =
the mandatory mapping elements is not applicable where you don=92t LoST, so=
 simply resuming mapping doesn=92t work.







If we put the extension point in, and you want to reuse map=
ping elements in your implementation you can simply reference them in the e=
xtension point, no specification required and things that choose not to und=
erstand the extension can ignore  them.
 No extra specification required, no extra work at all required in this spe=
cification, not even 10 minutes editing and 4 years of haggling.







Cheers


James














On 27 Mar 2015, at 1:31 am, Rosen, Brian <Brian.Rosen@neustar.biz> wro=
te:







I don=92t understand any of this logic.






You import the definition from RFC5222 and refer to it for =
the meaning of the elements.  Done.  No time delay.  10 minu=
tes of editing.







I want to be able to build systems that work world-wide. &n=
bsp;The more commonality of data structures, the better.







You have not shown any harm to re-use of a data structure t=
hat was designed for the purpose you have, has had extensive IETF review, i=
mplementation, and consensus.  You want to invent something new.  =
;It=92s clearly a subset, but it=92s not precisely
 a subset.  That is not a good idea in my opinion.  As the majori=
ty of elements in <mapping> are optional, an implementation can choos=
e never to send them (server) or ignore them if received (client).  If=
 you use the extension point (3), and we later decide
 that most of <mapping> is in fact useful, we would end up different =
data structures, because the base structure is different.







Brian









On Mar 26, 2015, at 8:22 AM, Laura Liess <laura.liess.dt@googlemail.com=
> wrote:








I would prefer 3) and I can live with 2). 



I am oposed to 1) because it would delay the draft progress, just to add fe=
atures about we don't know if anyone will need them andif so,  what ex=
actly will be needed. For the work in ETSI on the EC M493 this is clearly n=
ot needed. ETSI needs the draft finished
 very soon, if we want the final ETSI specification, targeted for the end o=
f this year, to refer an RFC and not a draft and the implementations which =
will come then soon, to be based an RFC and not on some intermediary versio=
n of the draft. 







I think 3) is a good solution, flexible enough that everyon=
e could live with it.






Thank you



Laura







2015-03-25 20:21 GMT+01:00 James Winterbotto=
m 
<a.james.winterbottom@gmail.com>:



There is downside to using the existing schema Brian, this is spelt out cle=
arly in the draft. In order to include the fields you want a new element wo=
uld need to be defined in this draft to support it. I think that that is th=
e wrong way to do it as there has
 been no expression of need. If a need arrises after this draft is done, th=
en it can be added later. Right now it isn=92t needed.



As I said in my preference for option 3, I think that the extension point s=
hould be added then anything can be added later if required.



Cheers

James









> On 26 Mar 2015, at 2:52 am, Rosen, Brian <Brian.Rosen@neustar.biz> wrote:

>

> Let=92s say that someone comes along and shows a decent use case for i=
ncluding a service boundary.

>

> So they define an extension for it.

>

> That extension may or may not be the same as the service boundary that=
 LoST returns.  An implementation designed to provide world-wide servi=
ce would have to change.

>

> Returning the boundary is already optional in the LoST schema.

>

> If we used the existing definition:

> 1. No new document is required

> 2. Compatibility between this HELD extension and LoST is maintained
> 3. Systems built to support both models don=92t have to change

>

> There is, as far as I can see, no downside to using the existing schem=
a other than making the smallest possible response a bit bigger.  &nbs=
p;One can always ignore any returned items not needed/wanted, and since the=
y are optional they can=92t be assumed to be there.

>

> Option 2 (don=92t allow an extension point on the return) makes no sen=
se to me.  I can=92t imagine the IETF doing that.  Any extension =
would then require all existing implementations to be changed.

>

> Brian

>

>> On Mar 25, 2015, at 9:49 AM, R.Jesske@telekom.de wrote:

>>

>> Hi James,

>> thank you for the summary.

>> My position is reflected in point 2.

>>

>> If people want to add something to a mechanism can it not be done =
only in writing a further draft?

>> This means also including in such a draft also a extension mechani=
sm.

>>

>> I think that would be a clear line to satisfy everybody.

>>

>>

>> Best Regards

>>

>> Roland

>>

>> -----Urspr=FCngliche Nachricht-----

>> Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von James Winterbottom

>> Gesendet: Mittwoch, 25. M=E4rz 2015 09:03

>> An: ecrit_ietf.org

>> Betreff: [Ecrit] HELD Routing summary

>>

>> Hi All,

>>

>> As I see it there is one open discussion point and three positions=
 on this point.

>> The discussion point is whether or not all of the ancillary data t=
hat is returned by a LoST findService request should be included in the HEL=
D routing response or not.

>>

>> The three positions that have been stated are (in no particular or=
der):

>> 1) The definition for this information should be included in the b=
ase specification but is optional to send or be acted on.

>> 2) Isn=92t required at all, let the current draft stand

>> 3) Add an extension point to the schema in the draft so that the e=
xtra can be specified in a different draft and added by something requiring=
 it.

>>

>> This email makes no claims to preference, but just presents the op=
inions that have been expressed.

>>

>> Cheers

>> James

>>

>> _______________________________________________

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

>



_______________________________________________

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














--_000_EA49CD4BEE854F1F9D4EAB2C13C691CFneustarbiz_--


From nobody Thu Mar 26 10:10:32 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B0B1A87B0 for ; Thu, 26 Mar 2015 10:10:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level: 
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 WOmARjEecHHL for ; Thu, 26 Mar 2015 10:10:24 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34C6A1A884E for ; Thu, 26 Mar 2015 10:10:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1427389822; x=1458925822; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=yJMNGgV+lW9lUSmOogNuLde2kNyBeQz8wAZJUcAl5zs=; b=fyod6YeO2dAc3DUsoLYy5A1/wUGozZb4UgqOJG7vVdLdGE1kxhjbsbeQ Z5nDKjOzP/YV4iJt86OWbdTz7802zI28TlKf/usJQEnkEfvznMeJ2tCm6 ChWPm8ZVPWTBymwv/x3olkKz1bAugk63VleokRPynYqkkQdQ8Z9Ws85Bd s=;
X-IronPort-AV: E=McAfee;i="5700,7163,7751"; a="86683749"
Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 26 Mar 2015 10:10:21 -0700
X-IronPort-AV: E=Sophos;i="5.11,473,1422950400"; d="scan'208";a="32103067"
Received: from nasanexm02b.na.qualcomm.com ([10.85.0.42]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 26 Mar 2015 10:10:20 -0700
Received: from dhcp-93ce.meeting.ietf.org (10.80.80.8) by nasanexm02b.na.qualcomm.com (10.85.0.42) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 26 Mar 2015 10:10:19 -0700
Message-ID: 
In-Reply-To: 
References: <5F3DEAC5-1A13-45A3-B9C8-51579BAC22F9@gmail.com> <058CE00BD4D6B94FAD033A2439EA1E4B01E9E52D80B6@HE113667.emea1.cds.t-int ernal.com> <14546D76-AEF5-4C23-9BA0-00B6FA4C1E96@neustar.biz>    <75BAB4CE-E408-472D-80DD-569ADD918A8B@gmail.com> 
X-Mailer: Eudora for Mac OS X
Date: Thu, 26 Mar 2015 10:10:13 -0700
To: "Rosen, Brian" , James Winterbottom 
From: Randall Gellens 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To nasanexm02b.na.qualcomm.com (10.85.0.42)
Archived-At: 
Cc: "ecrit@ietf.org" 
Subject: Re: [Ecrit] HELD Routing summary
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 17:10:30 -0000

Brian,

If it's only 10 minutes of editing, then maybe=20
you can revise either the XML (and update the=20
TXT) or the TXT and show what it would look like=20
in the document?  I think perhaps two examples=20
would also help: one where the source is a local=20
database and the other where the source is a LoST=20
server.  We'd then have a concrete proposal in=20
front of us and we could ask if we have consensus=20
to adopt it and move forward.

James, if Brian does this, can you then look at=20
the revisions and see if you still object or if=20
you can accept them?

At 3:19 PM +0000 3/26/15, Brian Rosen wrote:

>  Come on, the mandatory elements are the source,=20
> lastUpdated and expires.  The source might be=20
> the HELD server, but it might be something=20
> else.  If it's the HELD server, say so.
>  It is a trivial ask that you include source,=20
> lastUpdated and expires in the response,=20
> identical to LoST.  It provides a level of=20
> compatibility that is useful, and non-intrusive=20
> for implementations to accommodate.  It COULD=20
> be a fixed string.
>
>  You think of implementations as the server has,=20
> internally, all the routing information.=20
>  That's one way to do it.  Another way to do it=20
> is to have the HELD server consult a LoST=20
> server.  Yes, I know you don't think anyone=20
> will implement a LoST server.  I think you are=20
> wrong.
>
>  I understand that I can incrementally add the=20
> mapping components as extensions in a way that=20
> is transformable to a "real" =20
> structure, but the bits on the wire are=20
> different.
>  If you persist, and consensus is to have an=20
> extension point and no more, I'll submit the=20
> draft that does it right away.   Does that=20
> REALLY make any sense?
>
>  Brian
>
>>  On Mar 26, 2015, at 9:35 AM, James=20
>> Winterbottom=20
>> <a.james.winterbottom@gmail.com>=
=20
>> wrote:
>>
>>  HUH????
>>
>>  As I have said before and as the draft states,=20
>> at least of the mandatory mapping elements is=20
>> not applicable where you don't LoST, so simply=20
>> resuming mapping doesn't work.
>>
>>  If we put the extension point in, and you want=20
>> to reuse mapping elements in your=20
>> implementation you can simply reference them=20
>> in the extension point, no specification=20
>> required and things that choose not to=20
>> understand the extension can ignore  them. No=20
>> extra specification required, no extra work at=20
>> all required in this specification, not even=20
>> 10 minutes editing and 4 years of haggling.
>>
>>  Cheers
>>  James
>>
>>
>>>  On 27 Mar 2015, at 1:31 am, Rosen, Brian=20
>>> <Brian.Rosen@neustar.biz>=20
>>> wrote:
>>>
>>>  I don't understand any of this logic.
>>>
>>>  You import the definition from RFC5222 and=20
>>> refer to it for the meaning of the elements.=20
>>>  Done.  No time delay.  10 minutes of editing.
>>>
>>>  I want to be able to build systems that work=20
>>> world-wide.  The more commonality of data=20
>>> structures, the better.
>>>
>>>  You have not shown any harm to re-use of a=20
>>> data structure that was designed for the=20
>>> purpose you have, has had extensive IETF=20
>>> review, implementation, and consensus.  You=20
>>> want to invent something new.  It's clearly a=20
>>> subset, but it's not precisely a subset.=20
>>>  That is not a good idea in my opinion.  As=20
>>> the majority of elements in  are=20
>>> optional, an implementation can choose never=20
>>> to send them (server) or ignore them if=20
>>> received (client).  If you use the extension=20
>>> point (3), and we later decide that most of=20
>>>  is in fact useful, we would end up=20
>>> different data structures, because the base=20
>>> structure is different.
>>>
>>>  Brian
>>>
>>>>  On Mar 26, 2015, at 8:22 AM, Laura Liess=20
>>>> <laura.liess.dt@googlemail.com>=
=20
>>>> wrote:
>>>>
>>>>  I would prefer 3) and I can live with 2).
>>>>
>>>>  I am oposed to 1) because it would delay the=20
>>>> draft progress, just to add features about=20
>>>> we don't know if anyone will need them andif=20
>>>> so,  what exactly will be needed. For the=20
>>>> work in ETSI on the EC M493 this is clearly=20
>>>> not needed. ETSI needs the draft finished=20
>>>> very soon, if we want the final ETSI=20
>>>> specification, targeted for the end of this=20
>>>> year, to refer an RFC and not a draft and=20
>>>> the implementations which will come then=20
>>>> soon, to be based an RFC and not on some=20
>>>> intermediary version of the draft. 
>>>>
>>>>  I think 3) is a good solution, flexible=20
>>>> enough that everyone could live with it.
>>>>
>>>>  Thank you
>>>>   Laura
>>>>
>>>>  2015-03-25 20:21 GMT+01:00 James=20
>>>> Winterbottom=20
>>>> <a.james.winterbottom@gmail.com>=
:
>>>>
>>>>  There is downside to using the existing=20
>>>> schema Brian, this is spelt out clearly in=20
>>>> the draft. In order to include the fields=20
>>>> you want a new element would need to be=20
>>>> defined in this draft to support it. I think=20
>>>> that that is the wrong way to do it as there=20
>>>> has been no expression of need. If a need=20
>>>> arrises after this draft is done, then it=20
>>>> can be added later. Right now it isn't=20
>>>> needed.
>>>>
>>>>  As I said in my preference for option 3, I=20
>>>> think that the extension point should be=20
>>>> added then anything can be added later if=20
>>>> required.
>>>>
>>>>  Cheers
>>>>  James
>>>>
>>>>
>>>>
>>>>>  On 26 Mar 2015, at 2:52 am, Rosen, Brian=20
>>>>> <Brian.Rosen@neustar.biz>=20
>>>>> wrote:
>>>>>
>>>>>  Let's say that someone comes along and=20
>>>>> shows a decent use case for including a=20
>>>>> service boundary.
>>>>>
>>>>>  So they define an extension for it.
>>>>>
>>>>>  That extension may or may not be the same=20
>>>>> as the service boundary that LoST returns.=20
>>>>> An implementation designed to provide=20
>>>>> world-wide service would have to change.
>>>>>
>>>>>  Returning the boundary is already optional in the LoST schema.
>>>>>
>>>>>  If we used the existing definition:
>>>>>  1. No new document is required
>>>>>  2. Compatibility between this HELD extension and LoST is maintained
>>>>>  3. Systems built to support both models don't have to change
>>>>>
>>>>>  There is, as far as I can see, no downside=20
>>>>> to using the existing schema other than=20
>>>>> making the smallest possible response a bit=20
>>>>> bigger.   One can always ignore any=20
>>>>> returned items not needed/wanted, and since=20
>>>>> they are optional they can't be assumed to=20
>>>>> be there.
>>>>>
>>>>>  Option 2 (don't allow an extension point on=20
>>>>> the return) makes no sense to me.  I can't=20
>>>>> imagine the IETF doing that.  Any extension=20
>>>>> would then require all existing=20
>>>>> implementations to be changed.
>>>>>
>>>>>  Brian
>>>>>
>>>>>>  On Mar 25, 2015, at 9:49 AM,=20
>>>>>> R.Jesske@telekom.de=20
>>>>>> wrote:
>>>>>>
>>>>>>  Hi James,
>>>>>>  thank you for the summary.
>>>>>>  My position is reflected in point 2.
>>>>>>
>>>>>>  If people want to add something to a=20
>>>>>> mechanism can it not be done only in=20
>>>>>> writing a further draft?
>>>>>>  This means also including in such a draft also a extension mechanism=
=2E
>>>>>>
>>>>>>  I think that would be a clear line to satisfy everybody.
>>>>>>
>>>>>>
>>>>>>  Best Regards
>>>>>>
>>>>>>  Roland
>>>>>>
>>>>>>  -----Urspr=FCngliche Nachricht-----
>>>>>>  Von: Ecrit=20
>>>>>> [mailto:ecrit-bounces@ietf.org]=20
>>>>>> Im Auftrag von James Winterbottom
>>>>>>  Gesendet: Mittwoch, 25. M=E4rz 2015 09:03
>>>>>>  An: ecrit_ietf.org
>>>>>>  Betreff: [Ecrit] HELD Routing summary
>>>>>>
>>>>>>  Hi All,
>>>>>>
>>>>>>  As I see it there is one open discussion=20
>>>>>> point and three positions on this point.
>>>>>>  The discussion point is whether or not all=20
>>>>>> of the ancillary data that is returned by=20
>>>>>> a LoST findService request should be=20
>>>>>> included in the HELD routing response or=20
>>>>>> not.
>>>>>>
>>>>>>  The three positions that have been stated are (in no particular orde=
r):
>>>>>>  1) The definition for this information=20
>>>>>> should be included in the base=20
>>>>>> specification but is optional to send or=20
>>>>>> be acted on.
>>>>>>  2) Isn't required at all, let the current draft stand
>>>>>>  3) Add an extension point to the schema in=20
>>>>>> the draft so that the extra can be=20
>>>>>> specified in a different draft and added=20
>>>>>> by something requiring it.
>>>>>>
>>>>>>  This email makes no claims to preference,=20
>>>>>> but just presents the opinions that have=20
>>>>>> been expressed.
>>>>>>
>>>>>>  Cheers
>>>>>>  James
>>>>>>
>>>>>>  _______________________________________________
>>>>>>  Ecrit mailing list
>>>>>>  Ecrit@ietf.org
>>>>>>=20
>>>>>> =20
>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>>  _______________________________________________
>>>>>>  Ecrit mailing list
>>>>>>  Ecrit@ietf.org
>>>>>>=20
>>>>>> =20
>>>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>>
>>>>
>>>>  _______________________________________________
>>>>  Ecrit mailing list
>>>>  Ecrit@ietf.org
>>>>=20
>>>> https://www.ietf.org/mailm=
an/listinfo/ecrit
>>>>
>>>>
>>>
>>
>>  _______________________________________________
>>  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



-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Spotted on the back of a t-shirt worn by LAPD Bomb Squad:
"If you see me running, try to keep up."


From nobody Thu Mar 26 12:07:30 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4E01A9248 for ; Thu, 26 Mar 2015 12:07:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 DTq7EqMv3sWb for ; Thu, 26 Mar 2015 12:07:24 -0700 (PDT)
Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (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 83AF41A901D for ; Thu, 26 Mar 2015 12:07:24 -0700 (PDT)
Received: by pdbni2 with SMTP id ni2so71489866pdb.1 for ; Thu, 26 Mar 2015 12:07:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=TVau7nSKyAAXBJjDFEW0QXsFOqxrNH6XRBR1Tmu5oyM=; b=DQRSeXA8Wf2w2qeD31So4wULPBna6DNHSEEZUClo73j0+Kem0BXXySdbpUVnCCYSyK HE91qftRMw2Cg22JAplXZxMVYh3l0nQHAcvZ/qjQ4yJmLUrggfnZbe8/PiiVjklPt1gh +DGjyRzKFEPSQVyde2FO1SBMC69B6CzQ5R3TMzjiZbk5NjkMdpo2TxeN6GI3g3tYDwck +kFRooiMatLytab2+Rmm7NfqdIKJ1Ld02vIHSwkdlaIEOE5qXxrXgG+PrxuJ+rYqmtIJ ZFemjC9j+rP1nNBwfjhx+pe+q+q5jJu5cZS23s7ZT+WezXo9KiwYS2QDn3TA7i14BeJA o2Wg==
X-Received: by 10.68.132.169 with SMTP id ov9mr28669375pbb.109.1427396844089;  Thu, 26 Mar 2015 12:07:24 -0700 (PDT)
Received: from [192.168.1.18] (124-149-62-12.dyn.iinet.net.au. [124.149.62.12]) by mx.google.com with ESMTPSA id ft11sm6362235pdb.65.2015.03.26.12.07.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Mar 2015 12:07:23 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_827E1B88-B258-4F63-B5AA-D209E1F01C82"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: James Winterbottom 
In-Reply-To: 
Date: Fri, 27 Mar 2015 06:07:17 +1100
Message-Id: <204B769A-295F-476E-8B36-8F428FD4EE67@gmail.com>
References: <5F3DEAC5-1A13-45A3-B9C8-51579BAC22F9@gmail.com> <058CE00BD4D6B94FAD033A2439EA1E4B01E9E52D80B6@HE113667.emea1.cds.t-int ernal.com> <14546D76-AEF5-4C23-9BA0-00B6FA4C1E96@neustar.biz>    <75BAB4CE-E408-472D-80DD-569ADD918A8B@gmail.com>  
To: Randall Gellens 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: "Rosen, Brian" , "ecrit@ietf.org" 
Subject: Re: [Ecrit] HELD Routing summary
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 19:07:28 -0000

--Apple-Mail=_827E1B88-B258-4F63-B5AA-D209E1F01C82
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Randall,

I don=92t agree with Brian=92s position on the Source, my reading of =
LoST is that this can=92t be the HELD server because it doesn=92t =
satisfy the description and requirements for the use of that field.

But further to that, the three people in this group that requested this =
functionality don=92t see a need for this stuff. Indeed the only person =
arguing for it is Brian and he hasn=92t provided or demonstrated any =
need for it. Option 3 on that table allows it be added when needed which =
is the fastest and easiest approach.


Cheers
James

> On 27 Mar 2015, at 4:10 am, Randall Gellens  =
wrote:
>=20
> Brian,
>=20
> If it's only 10 minutes of editing, then maybe you can revise either =
the XML (and update the TXT) or the TXT and show what it would look like =
in the document?  I think perhaps two examples would also help: one =
where the source is a local database and the other where the source is a =
LoST server.  We'd then have a concrete proposal in front of us and we =
could ask if we have consensus to adopt it and move forward.
>=20
> James, if Brian does this, can you then look at the revisions and see =
if you still object or if you can accept them?
>=20
> At 3:19 PM +0000 3/26/15, Brian Rosen wrote:
>=20
>> Come on, the mandatory elements are the source, lastUpdated and =
expires.  The source might be the HELD server, but it might be something =
else.  If it's the HELD server, say so.
>> It is a trivial ask that you include source, lastUpdated and expires =
in the response, identical to LoST.  It provides a level of =
compatibility that is useful, and non-intrusive for implementations to =
accommodate.  It COULD be a fixed string.
>>=20
>> You think of implementations as the server has, internally, all the =
routing information.  That's one way to do it.  Another way to do it is =
to have the HELD server consult a LoST server.  Yes, I know you don't =
think anyone will implement a LoST server.  I think you are wrong.
>>=20
>> I understand that I can incrementally add the mapping components as =
extensions in a way that is transformable to a "real"  =
structure, but the bits on the wire are different.
>> If you persist, and consensus is to have an extension point and no =
more, I'll submit the draft that does it right away.   Does that REALLY =
make any sense?
>>=20
>> Brian
>>=20
>>> On Mar 26, 2015, at 9:35 AM, James Winterbottom =
<>a.james.winterbottom@gmail.com =
> wrote:
>>>=20
>>> HUH????
>>>=20
>>> As I have said before and as the draft states, at least of the =
mandatory mapping elements is not applicable where you don't LoST, so =
simply resuming mapping doesn't work.
>>>=20
>>> If we put the extension point in, and you want to reuse mapping =
elements in your implementation you can simply reference them in the =
extension point, no specification required and things that choose not to =
understand the extension can ignore  them. No extra specification =
required, no extra work at all required in this specification, not even =
10 minutes editing and 4 years of haggling.
>>>=20
>>> Cheers
>>> James
>>>=20
>>>=20
>>>> On 27 Mar 2015, at 1:31 am, Rosen, Brian =
<>Brian.Rosen@neustar.biz =
> wrote:
>>>>=20
>>>> I don't understand any of this logic.
>>>>=20
>>>> You import the definition from RFC5222 and refer to it for the =
meaning of the elements.  Done.  No time delay.  10 minutes of editing.
>>>>=20
>>>> I want to be able to build systems that work world-wide.  The more =
commonality of data structures, the better.
>>>>=20
>>>> You have not shown any harm to re-use of a data structure that was =
designed for the purpose you have, has had extensive IETF review, =
implementation, and consensus.  You want to invent something new.  It's =
clearly a subset, but it's not precisely a subset.  That is not a good =
idea in my opinion.  As the majority of elements in  are =
optional, an implementation can choose never to send them (server) or =
ignore them if received (client).  If you use the extension point (3), =
and we later decide that most of  is in fact useful, we would =
end up different data structures, because the base structure is =
different.
>>>>=20
>>>> Brian
>>>>=20
>>>>> On Mar 26, 2015, at 8:22 AM, Laura Liess =
<>laura.liess.dt@googlemail.com =
> wrote:
>>>>>=20
>>>>> I would prefer 3) and I can live with 2).
>>>>>=20
>>>>> I am oposed to 1) because it would delay the draft progress, just =
to add features about we don't know if anyone will need them andif so,  =
what exactly will be needed. For the work in ETSI on the EC M493 this is =
clearly not needed. ETSI needs the draft finished very soon, if we want =
the final ETSI specification, targeted for the end of this year, to =
refer an RFC and not a draft and the implementations which will come =
then soon, to be based an RFC and not on some intermediary version of =
the draft.
>>>>>=20
>>>>> I think 3) is a good solution, flexible enough that everyone could =
live with it.
>>>>>=20
>>>>> Thank you
>>>>>  Laura
>>>>>=20
>>>>> 2015-03-25 20:21 GMT+01:00 James Winterbottom =
<>a.james.winterbottom@gmail.com =
>:
>>>>>=20
>>>>> There is downside to using the existing schema Brian, this is =
spelt out clearly in the draft. In order to include the fields you want =
a new element would need to be defined in this draft to support it. I =
think that that is the wrong way to do it as there has been no =
expression of need. If a need arrises after this draft is done, then it =
can be added later. Right now it isn't needed.
>>>>>=20
>>>>> As I said in my preference for option 3, I think that the =
extension point should be added then anything can be added later if =
required.
>>>>>=20
>>>>> Cheers
>>>>> James
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>> On 26 Mar 2015, at 2:52 am, Rosen, Brian =
<>Brian.Rosen@neustar.biz =
> wrote:
>>>>>>=20
>>>>>> Let's say that someone comes along and shows a decent use case =
for including a service boundary.
>>>>>>=20
>>>>>> So they define an extension for it.
>>>>>>=20
>>>>>> That extension may or may not be the same as the service boundary =
that LoST returns. An implementation designed to provide world-wide =
service would have to change.
>>>>>>=20
>>>>>> Returning the boundary is already optional in the LoST schema.
>>>>>>=20
>>>>>> If we used the existing definition:
>>>>>> 1. No new document is required
>>>>>> 2. Compatibility between this HELD extension and LoST is =
maintained
>>>>>> 3. Systems built to support both models don't have to change
>>>>>>=20
>>>>>> There is, as far as I can see, no downside to using the existing =
schema other than making the smallest possible response a bit bigger.   =
One can always ignore any returned items not needed/wanted, and since =
they are optional they can't be assumed to be there.
>>>>>>=20
>>>>>> Option 2 (don't allow an extension point on the return) makes no =
sense to me.  I can't imagine the IETF doing that. Any extension would =
then require all existing implementations to be changed.
>>>>>>=20
>>>>>> Brian
>>>>>>=20
>>>>>>> On Mar 25, 2015, at 9:49 AM, >R.Jesske@telekom.de =
 wrote:
>>>>>>>=20
>>>>>>> Hi James,
>>>>>>> thank you for the summary.
>>>>>>> My position is reflected in point 2.
>>>>>>>=20
>>>>>>> If people want to add something to a mechanism can it not be =
done only in writing a further draft?
>>>>>>> This means also including in such a draft also a extension =
mechanism.
>>>>>>>=20
>>>>>>> I think that would be a clear line to satisfy everybody.
>>>>>>>=20
>>>>>>>=20
>>>>>>> Best Regards
>>>>>>>=20
>>>>>>> Roland
>>>>>>>=20
>>>>>>> -----Urspr=FCngliche Nachricht-----
>>>>>>> Von: Ecrit [mailto:>ecrit-bounces@ietf.org =
] Im Auftrag von James Winterbottom
>>>>>>> Gesendet: Mittwoch, 25. M=E4rz 2015 09:03
>>>>>>> An: >ecrit_ietf.org
>>>>>>> Betreff: [Ecrit] HELD Routing summary
>>>>>>>=20
>>>>>>> Hi All,
>>>>>>>=20
>>>>>>> As I see it there is one open discussion point and three =
positions on this point.
>>>>>>> The discussion point is whether or not all of the ancillary data =
that is returned by a LoST findService request should be included in the =
HELD routing response or not.
>>>>>>>=20
>>>>>>> The three positions that have been stated are (in no particular =
order):
>>>>>>> 1) The definition for this information should be included in the =
base specification but is optional to send or be acted on.
>>>>>>> 2) Isn't required at all, let the current draft stand
>>>>>>> 3) Add an extension point to the schema in the draft so that the =
extra can be specified in a different draft and added by something =
requiring it.
>>>>>>>=20
>>>>>>> This email makes no claims to preference, but just presents the =
opinions that have been expressed.
>>>>>>>=20
>>>>>>> Cheers
>>>>>>> James
>>>>>>>=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 =

>>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> Ecrit mailing list
>>>>> >Ecrit@ietf.org =

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

>>> https://www.ietf.org/mailman/listinfo/ecrit =

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

>=20
>=20
>=20
> --
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself =
only
> -------------- Randomly selected tag: ---------------
> Spotted on the back of a t-shirt worn by LAPD Bomb Squad:
> "If you see me running, try to keep up."


--Apple-Mail=_827E1B88-B258-4F63-B5AA-D209E1F01C82
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Randall,

I =
don=92t agree with Brian=92s position on the Source, my reading of LoST =
is that this can=92t be the HELD server because it doesn=92t satisfy the =
description and requirements for the use of that field.

But further to that, the =
three people in this group that requested this functionality don=92t see =
a need for this stuff. Indeed the only person arguing for it is Brian =
and he hasn=92t provided or demonstrated any need for it. Option 3 on =
that table allows it be added when needed which is the fastest and =
easiest approach.


Cheers
James

On =
27 Mar 2015, at 4:10 am, Randall Gellens <randy@qti.qualcomm.com> wrote:

Brian,

If it's only 10 minutes of editing, then maybe =
you can revise either the XML (and update the TXT) or the TXT and show =
what it would look like in the document?  I think perhaps two =
examples would also help: one where the source is a local database and =
the other where the source is a LoST server.  We'd then have a =
concrete proposal in front of us and we could ask if we have consensus =
to adopt it and move forward.

James, if Brian does this, =
can you then look at the revisions and see if you still object or if you =
can accept them?

At 3:19 PM +0000 3/26/15, =
Brian Rosen wrote:

Come on, the mandatory elements are the source, =
lastUpdated and expires.  The source might be the HELD server, but =
it might be something else.  If it's the HELD server, say so.
It is a trivial ask that you include source, lastUpdated and =
expires in the response, identical to LoST.  It provides a level of =
compatibility that is useful, and non-intrusive for implementations to =
accommodate.  It COULD be a fixed string.

You think of implementations as the server has, internally, =
all the routing information.  That's one way to do it. =
 Another way to do it is to have the HELD server consult a LoST =
server.  Yes, I know you don't think anyone will implement a LoST =
server.  I think you are wrong.

I =
understand that I can incrementally add the mapping components as =
extensions in a way that is transformable to a "real" <mapping> =
structure, but the bits on the wire are different.
If you =
persist, and consensus is to have an extension point and no more, I'll =
submit the draft that does it right away.   Does that REALLY =
make any sense?

Brian

On Mar 26, 2015, at 9:35 =
AM, James Winterbottom <<mailto:a.james.winterbottom@gmail.com>a.james.winterbottom@gmail.com> wrote:
HUH????

As I have said before =
and as the draft states, at least of the mandatory mapping elements is =
not applicable where you don't LoST, so simply resuming mapping doesn't =
work.

If we put the extension point in, and =
you want to reuse mapping elements in your implementation you can simply =
reference them in the extension point, no specification required and =
things that choose not to understand the extension can ignore =
 them. No extra specification required, no extra work at all =
required in this specification, not even 10 minutes editing and 4 years =
of haggling.

Cheers
James


On 27 Mar 2015, at 1:31 am, Rosen, Brian <<mailto:Brian.Rosen@neustar.biz>Brian.Rosen@neustar.biz> wrote:

I don't understand any of this logic.

You import the definition from RFC5222 and refer to it for =
the meaning of the elements.  Done.  No time delay.  10 =
minutes of editing.

I want to be able to =
build systems that work world-wide.  The more commonality of data =
structures, the better.

You have not shown =
any harm to re-use of a data structure that was designed for the purpose =
you have, has had extensive IETF review, implementation, and consensus. =
 You want to invent something new.  It's clearly a subset, but =
it's not precisely a subset.  That is not a good idea in my =
opinion.  As the majority of elements in <mapping> are =
optional, an implementation can choose never to send them (server) or =
ignore them if received (client).  If you use the extension point =
(3), and we later decide that most of <mapping> is in fact useful, =
we would end up different data structures, because the base structure is =
different.

Brian

On Mar 26, 2015, at 8:22 =
AM, Laura Liess <<mailto:laura.liess.dt@googlemail.com>laura.liess.dt@googlemail.com> wrote:

I would prefer 3) and I can live with 2).

I am oposed to 1) because it would delay the draft progress, =
just to add features about we don't know if anyone will need them andif =
so,  what exactly will be needed. For the work in ETSI on the EC =
M493 this is clearly not needed. ETSI needs the draft finished very =
soon, if we want the final ETSI specification, targeted for the end of =
this year, to refer an RFC and not a draft and the implementations which =
will come then soon, to be based an RFC and not on some intermediary =
version of the draft.

I think 3) is a good =
solution, flexible enough that everyone could live with it.

Thank you
 Laura

2015-03-25 20:21 GMT+01:00 James Winterbottom =
<<mailto:a.james.winterbottom@gmail.com>a.james.winterbottom@gmail.com>:

There is downside to using the existing schema Brian, this is =
spelt out clearly in the draft. In order to include the fields you want =
a new element would need to be defined in this draft to support it. I =
think that that is the wrong way to do it as there has been no =
expression of need. If a need arrises after this draft is done, then it =
can be added later. Right now it isn't needed.

As I said in my preference for option 3, I think that the =
extension point should be added then anything can be added later if =
required.

Cheers
James



On 26 Mar 2015, at 2:52 am, Rosen, Brian =
<<mailto:Brian.Rosen@neustar.biz>Brian.Rosen@neustar.biz> wrote:

Let's say that someone comes along and shows a decent use =
case for including a service boundary.

So =
they define an extension for it.

That =
extension may or may not be the same as the service boundary that LoST =
returns. An implementation designed to provide world-wide service would =
have to change.

Returning the boundary is =
already optional in the LoST schema.

If we =
used the existing definition:
1. No new document is =
required
2. Compatibility between this HELD extension and =
LoST is maintained
3. Systems built to support both models =
don't have to change

There is, as far as I =
can see, no downside to using the existing schema other than making the =
smallest possible response a bit bigger.   One can always =
ignore any returned items not needed/wanted, and since they are optional =
they can't be assumed to be there.

Option 2 =
(don't allow an extension point on the return) makes no sense to me. =
 I can't imagine the IETF doing that. Any extension would then =
require all existing implementations to be changed.

Brian

On Mar 25, 2015, at 9:49 AM, <mailto:R.Jesske@telekom.de>R.Jesske@telekom.de wrote:

Hi James,
thank you for the summary.
My position is reflected in point 2.

If people want to add something to a mechanism can it not be =
done only in writing a further draft?
This means also =
including in such a draft also a extension mechanism.

I think that would be a clear line to satisfy everybody.


Best Regards

Roland

-----Urspr=FCngliche =
Nachricht-----
Von: Ecrit [mailto:<mailto:ecrit-bounces@ietf.org>ecrit-bounces@ietf.org] Im Auftrag von James =
Winterbottom
Gesendet: Mittwoch, 25. M=E4rz 2015 09:03
An: <http://ecrit_ietf.org/>ecrit_ietf.org
Betreff: [Ecrit] HELD Routing summary

Hi All,

As I see it there is one =
open discussion point and three positions on this point.
The=
 discussion point is whether or not all of the ancillary data that is =
returned by a LoST findService request should be included in the HELD =
routing response or not.

The three =
positions that have been stated are (in no particular order):
1) The definition for this information should be included in =
the base specification but is optional to send or be acted on.
2) Isn't required at all, let the current draft stand
3) Add an extension point to the schema in the draft so that =
the extra can be specified in a different draft and added by something =
requiring it.

This email makes no claims to =
preference, but just presents the opinions that have been expressed.

Cheers
James

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


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




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



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



--
Randall Gellens
Opinions are personal;    facts =
are suspect;    I speak for myself only
-------------- Randomly selected tag: =
---------------
Spotted on the back of a =
t-shirt worn by LAPD Bomb Squad:
"If you see me running, try to keep =
up."

=

--Apple-Mail=_827E1B88-B258-4F63-B5AA-D209E1F01C82--


From nobody Thu Mar 26 12:17:36 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029C31A9162 for ; Thu, 26 Mar 2015 12:17:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 y-gGgy06iWxg for ; Thu, 26 Mar 2015 12:17:31 -0700 (PDT)
Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (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 5C6071B2A97 for ; Thu, 26 Mar 2015 12:17:30 -0700 (PDT)
Received: by pdbcz9 with SMTP id cz9so71644731pdb.3 for ; Thu, 26 Mar 2015 12:17:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=mJfR355sln5A7FUlaKviwpZ7Ow+jAMy6XnoHLhuutHk=; b=XwPusAm+aitiEVQtffQ7/RMZR4DFBahoODgQC88LJooPvEJbbw9Poifpr5+ONcs86M zE1m8bRPM/xkqCIF4y56Du1Rw7guESYEf8thmsHsKumKuhhJnK1CmaxM0CDw6Y8ZLTNp MExiLQAmFpLC4hY54AYNMz9Wy8sSReyaShEyTNNRR3nV+Ak1cR+/cnE7psv7KJ3uHl3s GA/u/NDAON3BZYzoUtiT84RXusAxRH6UmGCs1Z5MK7vXUfV5D3hW/43XRqR0/zKeIm4q iiDaVBZkuRDWJJyvPViV4Sr10b8XMbUiffclRbH9XAdtn7HkNZBtZo0uq/n/xNnOUfNt p2Pg==
X-Received: by 10.68.248.8 with SMTP id yi8mr29520491pbc.56.1427397449983; Thu, 26 Mar 2015 12:17:29 -0700 (PDT)
Received: from [192.168.1.18] (124-149-62-12.dyn.iinet.net.au. [124.149.62.12]) by mx.google.com with ESMTPSA id np6sm6372135pdb.80.2015.03.26.12.17.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Mar 2015 12:17:29 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_654055F9-B80B-41A0-865C-088D9222C4B8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: James Winterbottom 
In-Reply-To: 
Date: Fri, 27 Mar 2015 06:17:24 +1100
Message-Id: 
References: <5F3DEAC5-1A13-45A3-B9C8-51579BAC22F9@gmail.com> <058CE00BD4D6B94FAD033A2439EA1E4B01E9E52D80B6@HE113667.emea1.cds.t-internal.com> <14546D76-AEF5-4C23-9BA0-00B6FA4C1E96@neustar.biz>    <75BAB4CE-E408-472D-80DD-569ADD918A8B@gmail.com> 
To: "Rosen, Brian" 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: "ecrit@ietf.org" 
Subject: Re: [Ecrit] HELD Routing summary
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 19:17:35 -0000

--Apple-Mail=_654055F9-B80B-41A0-865C-088D9222C4B8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Brian,

Please read the draft, look at RFC5222 and tell me source can ever be =
the HELD server with putting  LoST interface on to the HELD server?

I don=92t see a need for the information you are requesting.
If you were to provide a draft to add the extension you request then I =
think you would have to demonstrate a very strong use case for it.  =
Further, I don=92t think it would be unreasonable to request a liaison =
statement from an SDO indicating that they required it to progress their =
work.

Cheers
James



> On 27 Mar 2015, at 2:19 am, Rosen, Brian  =
wrote:
>=20
> Come on, the mandatory elements are the source, lastUpdated and =
expires.  The source might be the HELD server, but it might be something =
else.  If it=92s the HELD server, say so.
> It is a trivial ask that you include source, lastUpdated and expires =
in the response, identical to LoST.  It provides a level of =
compatibility that is useful, and non-intrusive for implementations to =
accommodate.  It COULD be a fixed string.=20
>=20
> You think of implementations as the server has, internally, all the =
routing information.  That=92s one way to do it.  Another way to do it =
is to have the HELD server consult a LoST server.  Yes, I know you don=92t=
 think anyone will implement a LoST server.  I think you are wrong.
>=20
> I understand that I can incrementally add the mapping components as =
extensions in a way that is transformable to a =93real=94  =
structure, but the bits on the wire are different. =20
> If you persist, and consensus is to have an extension point and no =
more, I=92ll submit the draft that does it right away.   Does that =
REALLY make any sense?
>=20
> Brian
>=20
>> On Mar 26, 2015, at 9:35 AM, James Winterbottom =
> =
wrote:
>>=20
>> HUH????
>>=20
>> As I have said before and as the draft states, at least of the =
mandatory mapping elements is not applicable where you don=92t LoST, so =
simply resuming mapping doesn=92t work.
>>=20
>> If we put the extension point in, and you want to reuse mapping =
elements in your implementation you can simply reference them in the =
extension point, no specification required and things that choose not to =
understand the extension can ignore  them. No extra specification =
required, no extra work at all required in this specification, not even =
10 minutes editing and 4 years of haggling.
>>=20
>> Cheers
>> James
>>=20
>>=20
>>> On 27 Mar 2015, at 1:31 am, Rosen, Brian > wrote:
>>>=20
>>> I don=92t understand any of this logic.
>>>=20
>>> You import the definition from RFC5222 and refer to it for the =
meaning of the elements.  Done.  No time delay.  10 minutes of editing.
>>>=20
>>> I want to be able to build systems that work world-wide.  The more =
commonality of data structures, the better.
>>>=20
>>> You have not shown any harm to re-use of a data structure that was =
designed for the purpose you have, has had extensive IETF review, =
implementation, and consensus.  You want to invent something new.  It=92s =
clearly a subset, but it=92s not precisely a subset.  That is not a good =
idea in my opinion.  As the majority of elements in  are =
optional, an implementation can choose never to send them (server) or =
ignore them if received (client).  If you use the extension point (3), =
and we later decide that most of  is in fact useful, we would =
end up different data structures, because the base structure is =
different.
>>>=20
>>> Brian
>>>=20
>>>> On Mar 26, 2015, at 8:22 AM, Laura Liess =
> =
wrote:
>>>>=20
>>>> I would prefer 3) and I can live with 2).=20
>>>>=20
>>>> I am oposed to 1) because it would delay the draft progress, just =
to add features about we don't know if anyone will need them andif so,  =
what exactly will be needed. For the work in ETSI on the EC M493 this is =
clearly not needed. ETSI needs the draft finished very soon, if we want =
the final ETSI specification, targeted for the end of this year, to =
refer an RFC and not a draft and the implementations which will come =
then soon, to be based an RFC and not on some intermediary version of =
the draft. =20
>>>>=20
>>>> I think 3) is a good solution, flexible enough that everyone could =
live with it.=20
>>>>=20
>>>> Thank you
>>>> Laura
>>>>=20
>>>> 2015-03-25 20:21 GMT+01:00 James Winterbottom =
>:
>>>> There is downside to using the existing schema Brian, this is spelt =
out clearly in the draft. In order to include the fields you want a new =
element would need to be defined in this draft to support it. I think =
that that is the wrong way to do it as there has been no expression of =
need. If a need arrises after this draft is done, then it can be added =
later. Right now it isn=92t needed.
>>>>=20
>>>> As I said in my preference for option 3, I think that the extension =
point should be added then anything can be added later if required.
>>>>=20
>>>> Cheers
>>>> James
>>>>=20
>>>>=20
>>>> > On 26 Mar 2015, at 2:52 am, Rosen, Brian > wrote:
>>>> >
>>>> > Let=92s say that someone comes along and shows a decent use case =
for including a service boundary.
>>>> >
>>>> > So they define an extension for it.
>>>> >
>>>> > That extension may or may not be the same as the service boundary =
that LoST returns.  An implementation designed to provide world-wide =
service would have to change.
>>>> >
>>>> > Returning the boundary is already optional in the LoST schema.
>>>> >
>>>> > If we used the existing definition:
>>>> > 1. No new document is required
>>>> > 2. Compatibility between this HELD extension and LoST is =
maintained
>>>> > 3. Systems built to support both models don=92t have to change
>>>> >
>>>> > There is, as far as I can see, no downside to using the existing =
schema other than making the smallest possible response a bit bigger.   =
One can always ignore any returned items not needed/wanted, and since =
they are optional they can=92t be assumed to be there.
>>>> >
>>>> > Option 2 (don=92t allow an extension point on the return) makes =
no sense to me.  I can=92t imagine the IETF doing that.  Any extension =
would then require all existing implementations to be changed.
>>>> >
>>>> > Brian
>>>> >
>>>> >> On Mar 25, 2015, at 9:49 AM, R.Jesske@telekom.de =
 wrote:
>>>> >>
>>>> >> Hi James,
>>>> >> thank you for the summary.
>>>> >> My position is reflected in point 2.
>>>> >>
>>>> >> If people want to add something to a mechanism can it not be =
done only in writing a further draft?
>>>> >> This means also including in such a draft also a extension =
mechanism.
>>>> >>
>>>> >> I think that would be a clear line to satisfy everybody.
>>>> >>
>>>> >>
>>>> >> Best Regards
>>>> >>
>>>> >> Roland
>>>> >>
>>>> >> -----Urspr=FCngliche Nachricht-----
>>>> >> Von: Ecrit [mailto:ecrit-bounces@ietf.org =
] Im Auftrag von James Winterbottom
>>>> >> Gesendet: Mittwoch, 25. M=E4rz 2015 09:03
>>>> >> An: ecrit_ietf.org 
>>>> >> Betreff: [Ecrit] HELD Routing summary
>>>> >>
>>>> >> Hi All,
>>>> >>
>>>> >> As I see it there is one open discussion point and three =
positions on this point.
>>>> >> The discussion point is whether or not all of the ancillary data =
that is returned by a LoST findService request should be included in the =
HELD routing response or not.
>>>> >>
>>>> >> The three positions that have been stated are (in no particular =
order):
>>>> >> 1) The definition for this information should be included in the =
base specification but is optional to send or be acted on.
>>>> >> 2) Isn=92t required at all, let the current draft stand
>>>> >> 3) Add an extension point to the schema in the draft so that the =
extra can be specified in a different draft and added by something =
requiring it.
>>>> >>
>>>> >> This email makes no claims to preference, but just presents the =
opinions that have been expressed.
>>>> >>
>>>> >> Cheers
>>>> >> James
>>>> >>
>>>> >> _______________________________________________
>>>> >> 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 =

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

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


--Apple-Mail=_654055F9-B80B-41A0-865C-088D9222C4B8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Brian,

Please read the draft, look at RFC5222 and tell me source can =
ever be the HELD server with putting  LoST interface on to the HELD =
server?

I =
don=92t see a need for the information you are requesting.
If you were to provide a draft to add the extension you =
request then I think you would have to demonstrate a very strong use =
case for it.  Further, I don=92t think it would be unreasonable to =
request a liaison statement from an SDO indicating that they required it =
to progress their work.

Cheers
James



On =
27 Mar 2015, at 2:19 am, Rosen, Brian <Brian.Rosen@neustar.biz> wrote:







Come on, the mandatory elements are the source, lastUpdated and expires. =
 The source might be the HELD server, but it might be something =
else.  If it=92s the HELD server, say so.

It is a trivial ask that you include source, lastUpdated =
and expires in the response, identical to LoST.  It provides a =
level of compatibility that is useful, and non-intrusive for =
implementations to accommodate.  It COULD be a fixed =
string. 







You think of implementations as the server has, =
internally, all the routing information.  That=92s one way to do =
it.  Another way to do it is to have the HELD server consult a LoST =
server.  Yes, I know you don=92t think anyone will implement a LoST
 server.  I think you are wrong.







I understand that I can incrementally add the mapping =
components as extensions in a way that is transformable to a =93real=94 =
<mapping> structure, but the bits on the wire are different. =
 


If you persist, and consensus is to have an extension =
point and no more, I=92ll submit the draft that does it right away. =
  Does that REALLY make any sense?







Brian









On Mar 26, 2015, at 9:35 AM, James Winterbottom <a.james.winterbottom@gmail.com> wrote:







HUH????






As I have said before and as the draft states, at least =
of the mandatory mapping elements is not applicable where you don=92t =
LoST, so simply resuming mapping doesn=92t work.







If we put the extension point in, and you want to reuse =
mapping elements in your implementation you can simply reference them in =
the extension point, no specification required and things that choose =
not to understand the extension can ignore  them.
 No extra specification required, no extra work at all required in this =
specification, not even 10 minutes editing and 4 years of =
haggling.







Cheers


James














On 27 Mar 2015, at 1:31 am, Rosen, Brian <Brian.Rosen@neustar.biz> wrote:







I don=92t understand any of this logic.






You import the definition from RFC5222 and refer to it =
for the meaning of the elements.  Done.  No time delay. =
 10 minutes of editing.







I want to be able to build systems that work world-wide. =
 The more commonality of data structures, the better.







You have not shown any harm to re-use of a data =
structure that was designed for the purpose you have, has had extensive =
IETF review, implementation, and consensus.  You want to invent =
something new.  It=92s clearly a subset, but it=92s not precisely
 a subset.  That is not a good idea in my opinion.  As the =
majority of elements in <mapping> are optional, an implementation =
can choose never to send them (server) or ignore them if received =
(client).  If you use the extension point (3), and we later decide
 that most of <mapping> is in fact useful, we would end up =
different data structures, because the base structure is =
different.







Brian









On Mar 26, 2015, at 8:22 AM, Laura Liess <laura.liess.dt@googlemail.com> wrote:








I would prefer 3) and I can live with 2). 



I am oposed to 1) because it would delay the draft progress, just to add =
features about we don't know if anyone will need them andif so,  =
what exactly will be needed. For the work in ETSI on the EC M493 this is =
clearly not needed. ETSI needs the draft finished
 very soon, if we want the final ETSI specification, targeted for the =
end of this year, to refer an RFC and not a draft and the =
implementations which will come then soon, to be based an RFC and not on =
some intermediary version of the draft. 







I think 3) is a good solution, flexible enough that =
everyone could live with it.






Thank you



Laura=








2015-03-25 20:21 GMT+01:00 James Winterbottom =

<a.james.winterbottom@gmail.com>:



There is downside to using the existing schema Brian, this is spelt out =
clearly in the draft. In order to include the fields you want a new =
element would need to be defined in this draft to support it. I think =
that that is the wrong way to do it as there has
 been no expression of need. If a need arrises after this draft is done, =
then it can be added later. Right now it isn=92t needed.



As I said in my preference for option 3, I think that the extension =
point should be added then anything can be added later if required.



Cheers

James









> On 26 Mar 2015, at 2:52 am, Rosen, Brian <Brian.Rosen@neustar.biz> wrote:

>

> Let=92s say that someone comes along and shows a decent use case =
for including a service boundary.

>

> So they define an extension for it.

>

> That extension may or may not be the same as the service boundary =
that LoST returns.  An implementation designed to provide =
world-wide service would have to change.

>

> Returning the boundary is already optional in the LoST schema.

>

> If we used the existing definition:

> 1. No new document is required

> 2. Compatibility between this HELD extension and LoST is =
maintained

> 3. Systems built to support both models don=92t have to change

>

> There is, as far as I can see, no downside to using the existing =
schema other than making the smallest possible response a bit =
bigger.   One can always ignore any returned items not =
needed/wanted, and since they are optional they can=92t be assumed to be =
there.

>

> Option 2 (don=92t allow an extension point on the return) makes no =
sense to me.  I can=92t imagine the IETF doing that.  Any =
extension would then require all existing implementations to be =
changed.

>

> Brian

>

>> On Mar 25, 2015, at 9:49 AM, R.Jesske@telekom.de =
wrote:

>>

>> Hi James,

>> thank you for the summary.

>> My position is reflected in point 2.

>>

>> If people want to add something to a mechanism can it not be =
done only in writing a further draft?

>> This means also including in such a draft also a extension =
mechanism.

>>

>> I think that would be a clear line to satisfy everybody.

>>

>>

>> Best Regards

>>

>> Roland

>>

>> -----Urspr=FCngliche Nachricht-----

>> Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von James =
Winterbottom

>> Gesendet: Mittwoch, 25. M=E4rz 2015 09:03

>> An: ecrit_ietf.org

>> Betreff: [Ecrit] HELD Routing summary

>>

>> Hi All,

>>

>> As I see it there is one open discussion point and three =
positions on this point.

>> The discussion point is whether or not all of the ancillary =
data that is returned by a LoST findService request should be included =
in the HELD routing response or not.

>>

>> The three positions that have been stated are (in no particular =
order):

>> 1) The definition for this information should be included in =
the base specification but is optional to send or be acted on.

>> 2) Isn=92t required at all, let the current draft stand

>> 3) Add an extension point to the schema in the draft so that =
the extra can be specified in a different draft and added by something =
requiring it.

>>

>> This email makes no claims to preference, but just presents the =
opinions that have been expressed.

>>

>> Cheers

>> James

>>

>> _______________________________________________

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

>



_______________________________________________

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=_654055F9-B80B-41A0-865C-088D9222C4B8--


From nobody Thu Mar 26 12:26:29 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B651B2DAD for ; Thu, 26 Mar 2015 12:26:28 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level: 
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 zdFTxKKJ3GVe for ; Thu, 26 Mar 2015 12:26:24 -0700 (PDT)
Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 393491B2D86 for ; Thu, 26 Mar 2015 12:26:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1427397984; x=1458933984; h=message-id:in-reply-to:references:date:to:from:subject: cc:content-transfer-encoding; bh=RayBW9tBpiozH00VOjyL6a8OnxKj/x4hsGrz57V6uh0=; b=ELAHSYViR2ZU5BiG2so5Fi51XTlt0bpejyR+fq95zfXKX4h7j6h4uvL5 DcOYrPid/Or1bbWk3VoWs4uc5BhDxFZKRIJXWqDQjLPLXMlkQS1yUmlLN s8zciMgFHkYlSfe7G5vo2iiAbJbrG0EkSIO4IRUayIFs88KixJMqP1q1y Q=;
X-IronPort-AV: E=McAfee;i="5700,7163,7752"; a="86692463"
Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Mar 2015 12:26:23 -0700
X-IronPort-AV: E=Sophos;i="5.11,474,1422950400"; d="scan'208";a="880800614"
Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Mar 2015 12:26:23 -0700
Received: from Ironmsg03-R.qualcomm.com (ironmsg03-R.qualcomm.com [172.30.46.17]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t2QJQLGn019101; Thu, 26 Mar 2015 12:26:23 -0700
X-IronPort-AV: E=Sophos;i="5.11,474,1422950400"; d="scan'208";a="880800488"
X-ojodefuego: yes
Received: from unknown (HELO dhcp-93ce.meeting.ietf.org) ([10.64.194.32]) by Ironmsg03-R.qualcomm.com with ESMTP; 26 Mar 2015 12:26:20 -0700
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <204B769A-295F-476E-8B36-8F428FD4EE67@gmail.com>
References: <5F3DEAC5-1A13-45A3-B9C8-51579BAC22F9@gmail.com> <058CE00BD4D6B94FAD033A2439EA1E4B01E9E52D80B6@HE113667.emea1.cds.t-int ernal.com> <14546D76-AEF5-4C23-9BA0-00B6FA4C1E96@neustar.biz>    <75BAB4CE-E408-472D-80DD-569ADD918A8B@gmail.com>   <204B769A-295F-476E-8B36-8F428FD4EE67@gmail.com>
X-Mailer: Eudora for Mac OS X
Date: Thu, 26 Mar 2015 12:26:17 -0700
To: James Winterbottom 
From: Randall Gellens 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: 
Cc: "Rosen, Brian" , "ecrit@ietf.org" 
Subject: Re: [Ecrit] HELD Routing summary
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 19:26:28 -0000

My impression is that people are talking past=20
each other, which is why I thought seeing the=20
proposal in the document would help clarify it.

At 6:07 AM +1100 3/27/15, James Winterbottom wrote:

>  Randall,
>
>  I don't agree with Brian's position on the=20
> Source, my reading of LoST is that this can't=20
> be the HELD server because it doesn't satisfy=20
> the description and requirements for the use of=20
> that field.
>
>  But further to that, the three people in this=20
> group that requested this functionality don't=20
> see a need for this stuff. Indeed the only=20
> person arguing for it is Brian and he hasn't=20
> provided or demonstrated any need for it.=20
> Option 3 on that table allows it be added when=20
> needed which is the fastest and easiest=20
> approach.
>
>
>  Cheers
>  James
>
>>  On 27 Mar 2015, at 4:10 am, Randall Gellens=20
>> <randy@qti.qualcomm.com>=20
>> wrote:
>>
>>  Brian,
>>
>>  If it's only 10 minutes of editing, then maybe=20
>> you can revise either the XML (and update the=20
>> TXT) or the TXT and show what it would look=20
>> like in the document?  I think perhaps two=20
>> examples would also help: one where the source=20
>> is a local database and the other where the=20
>> source is a LoST server.  We'd then have a=20
>> concrete proposal in front of us and we could=20
>> ask if we have consensus to adopt it and move=20
>> forward.
>>
>>  James, if Brian does this, can you then look=20
>> at the revisions and see if you still object=20
>> or if you can accept them?
>>
>>  At 3:19 PM +0000 3/26/15, Brian Rosen wrote:
>>
>>>  Come on, the mandatory elements are the=20
>>> source, lastUpdated and expires.  The source=20
>>> might be the HELD server, but it might be=20
>>> something else.  If it's the HELD server, say=20
>>> so.
>>>  It is a trivial ask that you include source,=20
>>> lastUpdated and expires in the response,=20
>>> identical to LoST.  It provides a level of=20
>>> compatibility that is useful, and=20
>>> non-intrusive for implementations to=20
>>> accommodate.  It COULD be a fixed string.
>>>
>>>  You think of implementations as the server=20
>>> has, internally, all the routing information.=20
>>>  That's one way to do it.  Another way to do=20
>>> it is to have the HELD server consult a LoST=20
>>> server.  Yes, I know you don't think anyone=20
>>> will implement a LoST server.  I think you=20
>>> are wrong.
>>>
>>>  I understand that I can incrementally add the=20
>>> mapping components as extensions in a way=20
>>> that is transformable to a "real" =20
>>> structure, but the bits on the wire are=20
>>> different.
>>>  If you persist, and consensus is to have an=20
>>> extension point and no more, I'll submit the=20
>>> draft that does it right away.   Does that=20
>>> REALLY make any sense?
>>>
>>>  Brian
>>>
>>>>  On Mar 26, 2015, at 9:35 AM, James=20
>>>> Winterbottom=20
>>>> <<mailto:a.james.winterbottom@gm=
ail.com>a.james.winterbottom@gmail.co=
m>=20
>>>> wrote:
>>>>
>>>>  HUH????
>>>>
>>>>  As I have said before and as the draft=20
>>>> states, at least of the mandatory mapping=20
>>>> elements is not applicable where you don't=20
>>>> LoST, so simply resuming mapping doesn't=20
>>>> work.
>>>>
>>>>  If we put the extension point in, and you=20
>>>> want to reuse mapping elements in your=20
>>>> implementation you can simply reference them=20
>>>> in the extension point, no specification=20
>>>> required and things that choose not to=20
>>>> understand the extension can ignore  them.=20
>>>> No extra specification required, no extra=20
>>>> work at all required in this specification,=20
>>>> not even 10 minutes editing and 4 years of=20
>>>> haggling.
>>>>
>>>>  Cheers
>>>>  James
>>>>
>>>>>  On 27 Mar 2015, at 1:31 am, Rosen, Brian=20
>>>>> <<mailto:Brian.Rosen@neustar.biz>Brian.Rosen@neustar.biz>=20
>>>>> wrote:
>>>>>
>>>>>  I don't understand any of this logic.
>>>>>
>>>>>  You import the definition from RFC5222 and=20
>>>>> refer to it for the meaning of the=20
>>>>> elements.  Done.  No time delay.  10=20
>>>>> minutes of editing.
>>>>>
>>>>>  I want to be able to build systems that=20
>>>>> work world-wide.  The more commonality of=20
>>>>> data structures, the better.
>>>>>
>>>>>  You have not shown any harm to re-use of a=20
>>>>> data structure that was designed for the=20
>>>>> purpose you have, has had extensive IETF=20
>>>>> review, implementation, and consensus.  You=20
>>>>> want to invent something new.  It's clearly=20
>>>>> a subset, but it's not precisely a subset.=20
>>>>>  That is not a good idea in my opinion.  As=20
>>>>> the majority of elements in  are=20
>>>>> optional, an implementation can choose=20
>>>>> never to send them (server) or ignore them=20
>>>>> if received (client).  If you use the=20
>>>>> extension point (3), and we later decide=20
>>>>> that most of  is in fact useful,=20
>>>>> we would end up different data structures,=20
>>>>> because the base structure is different.
>>>>>
>>>>>  Brian
>>>>>
>>>>>>  On Mar 26, 2015, at 8:22 AM, Laura Liess=20
>>>>>> <<mailto:laura.liess.dt@googlem=
ail.com>laura.liess.dt@googlemail.com>=
=20
>>>>>> wrote:
>>>>>>
>>>>>>  I would prefer 3) and I can live with 2).
>>>>>>
>>>>>>  I am oposed to 1) because it would delay=20
>>>>>> the draft progress, just to add features=20
>>>>>> about we don't know if anyone will need=20
>>>>>> them andif so,  what exactly will be=20
>>>>>> needed. For the work in ETSI on the EC=20
>>>>>> M493 this is clearly not needed. ETSI=20
>>>>>> needs the draft finished very soon, if we=20
>>>>>> want the final ETSI specification,=20
>>>>>> targeted for the end of this year, to=20
>>>>>> refer an RFC and not a draft and the=20
>>>>>> implementations which will come then soon,=20
>>>>>> to be based an RFC and not on some=20
>>>>>> intermediary version of the draft.
>>>>>>
>>>>>>  I think 3) is a good solution, flexible=20
>>>>>> enough that everyone could live with it.
>>>>>>
>>>>>>  Thank you
>>>>>>   Laura
>>>>>>
>>>>>>  2015-03-25 20:21 GMT+01:00 James=20
>>>>>> Winterbottom=20
>>>>>> <<mailto:a.james.winterbottom@=
gmail.com>a.james.winterbottom@gmail.=
com>:
>>>>>>
>>>>>>  There is downside to using the existing=20
>>>>>> schema Brian, this is spelt out clearly in=20
>>>>>> the draft. In order to include the fields=20
>>>>>> you want a new element would need to be=20
>>>>>> defined in this draft to support it. I=20
>>>>>> think that that is the wrong way to do it=20
>>>>>> as there has been no expression of need.=20
>>>>>> If a need arrises after this draft is=20
>>>>>> done, then it can be added later. Right=20
>>>>>> now it isn't needed.
>>>>>>
>>>>>>  As I said in my preference for option 3, I=20
>>>>>> think that the extension point should be=20
>>>>>> added then anything can be added later if=20
>>>>>> required.
>>>>>>
>>>>>>  Cheers
>>>>>>  James
>>>>>>
>>>>>>
>>>>>>>  On 26 Mar 2015, at 2:52 am, Rosen, Brian=20
>>>>>>> <<mailto:Brian.Rosen@neustar.biz>Brian.Rosen@neustar.biz>=20
>>>>>>> wrote:
>>>>>>>
>>>>>>>  Let's say that someone comes along and=20
>>>>>>> shows a decent use case for including a=20
>>>>>>> service boundary.
>>>>>>>
>>>>>>>  So they define an extension for it.
>>>>>>>
>>>>>>>  That extension may or may not be the same=20
>>>>>>> as the service boundary that LoST=20
>>>>>>> returns. An implementation designed to=20
>>>>>>> provide world-wide service would have to=20
>>>>>>> change.
>>>>>>>
>>>>>>>  Returning the boundary is already optional in the LoST schema.
>>>>>>>
>>>>>>>  If we used the existing definition:
>>>>>>>  1. No new document is required
>>>>>>>  2. Compatibility between this HELD extension and LoST is maintained
>>>>>>>  3. Systems built to support both models don't have to change
>>>>>>>
>>>>>>>  There is, as far as I can see, no=20
>>>>>>> downside to using the existing schema=20
>>>>>>> other than making the smallest possible=20
>>>>>>> response a bit bigger.   One can always=20
>>>>>>> ignore any returned items not=20
>>>>>>> needed/wanted, and since they are=20
>>>>>>> optional they can't be assumed to be=20
>>>>>>> there.
>>>>>>>
>>>>>>>  Option 2 (don't allow an extension point=20
>>>>>>> on the return) makes no sense to me.  I=20
>>>>>>> can't imagine the IETF doing that. Any=20
>>>>>>> extension would then require all existing=20
>>>>>>> implementations to be changed.
>>>>>>>
>>>>>>>  Brian
>>>>>>>
>>>>>>>>  On Mar 25, 2015, at 9:49 AM,=20
>>>>>>>> <mailto:R.Jesske@telekom.de>R.Jesske@telekom.de wrote:
>>>>>>>>
>>>>>>>>  Hi James,
>>>>>>>>  thank you for the summary.
>>>>>>>>  My position is reflected in point 2.
>>>>>>>>
>>>>>>>>  If people want to add something to a=20
>>>>>>>> mechanism can it not be done only in=20
>>>>>>>> writing a further draft?
>>>>>>>>  This means also including in such a draft also a extension mechani=
sm.
>>>>>>>>
>>>>>>>>  I think that would be a clear line to satisfy everybody.
>>>>>>>>
>>>>>>>>
>>>>>>>>  Best Regards
>>>>>>>>
>>>>>>>>  Roland
>>>>>>>>
>>>>>>>>  -----Urspr=FCngliche Nachricht-----
>>>>>>>>  Von: Ecrit=20
>>>>>>>> [mailto:<mailto:ecrit-bounces@ietf.o=
rg>ecrit-bounces@ietf.org]=20
>>>>>>>> Im Auftrag von James Winterbottom
>>>>>>>>  Gesendet: Mittwoch, 25. M=E4rz 2015 09:03
>>>>>>>>  An: <http://ecrit_ietf.org/>ecrit_ietf.org
>>>>>>>>  Betreff: [Ecrit] HELD Routing summary
>>>>>>>>
>>>>>>>>  Hi All,
>>>>>>>>
>>>>>>>>  As I see it there is one open discussion=20
>>>>>>>> point and three positions on this point.
>>>>>>>>  The discussion point is whether or not=20
>>>>>>>> all of the ancillary data that is=20
>>>>>>>> returned by a LoST findService request=20
>>>>>>>> should be included in the HELD routing=20
>>>>>>>> response or not.
>>>>>>>>
>>>>>>>>  The three positions that have been=20
>>>>>>>> stated are (in no particular order):
>>>>>>>>  1) The definition for this information=20
>>>>>>>> should be included in the base=20
>>>>>>>> specification but is optional to send or=20
>>>>>>>> be acted on.
>>>>>>>>  2) Isn't required at all, let the current draft stand
>>>>>>>>  3) Add an extension point to the schema=20
>>>>>>>> in the draft so that the extra can be=20
>>>>>>>> specified in a different draft and added=20
>>>>>>>> by something requiring it.
>>>>>>>>
>>>>>>>>  This email makes no claims to=20
>>>>>>>> preference, but just presents the=20
>>>>>>>> opinions that have been expressed.
>>>>>>>>
>>>>>>>>  Cheers
>>>>>>>>  James
>>>>>>>>
>>>>>>>>  _______________________________________________
>>>>>>>>  Ecrit mailing list
>>>>>>>>=20
>>>>>>>> <mailto:Ecrit@ietf.org>Ecrit@ietf.org
>>>>>>>>=20
>>>>>>>> <https://www.ietf.org/=
mailman/listinfo/ecrit> https:/=
/www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>  _______________________________________________
>>>>>>>>  Ecrit mailing list
>>>>>>>>=20
>>>>>>>> <mailto:Ecrit@ietf.org>Ecrit@ietf.org
>>>>>>>>=20
>>>>>>>> <https://www.ietf.org/=
mailman/listinfo/ecrit> https:/=
/www.ietf.org/mailman/listinfo/ecrit
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>  _______________________________________________
>>>>>>  Ecrit mailing list
>>>>>>=20
>>>>>> <mailto:Ecrit@ietf.org>=
Ecrit@ietf.org
>>>>>>=20
>>>>>> <https://www.ietf.org/ma=
ilman/listinfo/ecrit>https://ww=
w.ietf.org/mailman/listinfo/ecrit
>>>>>>
>>>>>
>>>>
>>>>  _______________________________________________
>>>>  Ecrit mailing list
>>>>=20
>>>> <mailto:Ecrit@ietf.org>Ec=
rit@ietf.org
>>>>=20
>>>> https://www.ietf.org/mailm=
an/listinfo/ecrit
>>>>
>>>
>>>
>>>  _______________________________________________
>>>  Ecrit mailing list
>>>  Ecrit@ietf.org
>>>=20
>>> https://www.ietf.org/mailma=
n/listinfo/ecrit
>>>
>>
>>
>>
>>  --
>>  Randall Gellens
>>  Opinions are personal;    facts are suspect;    I speak for myself only
>>  -------------- Randomly selected tag: ---------------
>>  Spotted on the back of a t-shirt worn by LAPD Bomb Squad:
>>  "If you see me running, try to keep up."
>>
>
>
>  _______________________________________________
>  Ecrit mailing list
>  Ecrit@ietf.org
>  https://www.ietf.org/mailman/listinfo/ecrit



-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Skipper:   Mr. Howell, You don't know what it's like out there in
           the ocean, you may be bitten by a shark!
Thurston:  A shark bite a Howell, ha ha he wouldn't dare.
Skipper:   Besides we don't have room enough for your luggage.
Thurston:  Well that's different. If I can't go first class I won't
           go at all.


From nobody Thu Mar 26 12:27:56 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8391D1A914A for ; Thu, 26 Mar 2015 12:27:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.799
X-Spam-Level: 
X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, J_CHICKENPOX_65=0.6, SPF_PASS=-0.001] autolearn=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 mU3Ig2IE_Qvz for ; Thu, 26 Mar 2015 12:27:50 -0700 (PDT)
Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (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 E27361A8A9B for ; Thu, 26 Mar 2015 12:27:49 -0700 (PDT)
Received: by pacwz10 with SMTP id wz10so20917459pac.2 for ; Thu, 26 Mar 2015 12:27:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=4Y+87RMKmvaKYShOugmnjbSKcJq77nbw0PoLg6HyBQk=; b=EVTO7KRfkLGQedreS8mGjQsjSiO9i1/s36bdPL6TnhlDA8NqffrQR3ftn5v3YITrWb HTsUZ2C+fxnoZfg7Cs8Ho57dK18HrZgU9JAaHpbxJkDBjLVgsTEQEtS3ADSmKRQKmDIM 7rRNDQZn1w/44qZLjAxz5TX+Gx76j7FS9rcSdGoZE9Am71lFW1b6balI0qSOrWmST2KS 78P6DiK5BvZGxWW2kEZO8TbQkMCoqYR7ZlhIa7NDGM7pBHdOhvaJwSYkZHZib7+Z0xb+ J+LlNip4yVuDundfEhRw9OEI6Ji5HCviktbcAzTEf5gThbpwMN9lS0/UnZ8gzU9TXcbF nVYA==
X-Received: by 10.68.76.98 with SMTP id j2mr28594736pbw.75.1427398069570; Thu, 26 Mar 2015 12:27:49 -0700 (PDT)
Received: from [192.168.1.18] (124-149-62-12.dyn.iinet.net.au. [124.149.62.12]) by mx.google.com with ESMTPSA id d12sm6377895pbu.4.2015.03.26.12.27.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Mar 2015 12:27:48 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_2F20A1C7-A7FA-43BA-8371-EFA00F1ED02E"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: James Winterbottom 
In-Reply-To: 
Date: Fri, 27 Mar 2015 06:27:43 +1100
Message-Id: 
References: <5F3DEAC5-1A13-45A3-B9C8-51579BAC22F9@gmail.com> <058CE00BD4D6B94FAD033A2439EA1E4B01E9E52D80B6@HE113667.emea1.cds.t-int ernal.com> <14546D76-AEF5-4C23-9BA0-00B6FA4C1E96@neustar.biz>    <75BAB4CE-E408-472D-80DD-569ADD918A8B@gmail.com>   <204B769A-295F-476E-8B36-8F428FD4EE67@gmail.com> 
To: Randall Gellens 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: "Rosen, Brian" , "ecrit@ietf.org" 
Subject: Re: [Ecrit] HELD Routing summary
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 19:27:54 -0000

--Apple-Mail=_2F20A1C7-A7FA-43BA-8371-EFA00F1ED02E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Thanks for talking the position as conciliator Randall.



> On 27 Mar 2015, at 6:26 am, Randall Gellens  =
wrote:
>=20
> My impression is that people are talking past=20
> each other, which is why I thought seeing the=20
> proposal in the document would help clarify it.
>=20
> At 6:07 AM +1100 3/27/15, James Winterbottom wrote:
>=20
>> Randall,
>>=20
>> I don't agree with Brian's position on the=20
>> Source, my reading of LoST is that this can't=20
>> be the HELD server because it doesn't satisfy=20
>> the description and requirements for the use of=20
>> that field.
>>=20
>> But further to that, the three people in this=20
>> group that requested this functionality don't=20
>> see a need for this stuff. Indeed the only=20
>> person arguing for it is Brian and he hasn't=20
>> provided or demonstrated any need for it.=20
>> Option 3 on that table allows it be added when=20
>> needed which is the fastest and easiest=20
>> approach.
>>=20
>>=20
>> Cheers
>> James
>>=20
>>> On 27 Mar 2015, at 4:10 am, Randall Gellens=20
>>> <>randy@qti.qualcomm.com =
>=20
>>> wrote:
>>>=20
>>> Brian,
>>>=20
>>> If it's only 10 minutes of editing, then maybe=20
>>> you can revise either the XML (and update the=20
>>> TXT) or the TXT and show what it would look=20
>>> like in the document?  I think perhaps two=20
>>> examples would also help: one where the source=20
>>> is a local database and the other where the=20
>>> source is a LoST server.  We'd then have a=20
>>> concrete proposal in front of us and we could=20
>>> ask if we have consensus to adopt it and move=20
>>> forward.
>>>=20
>>> James, if Brian does this, can you then look=20
>>> at the revisions and see if you still object=20
>>> or if you can accept them?
>>>=20
>>> At 3:19 PM +0000 3/26/15, Brian Rosen wrote:
>>>=20
>>>> Come on, the mandatory elements are the=20
>>>> source, lastUpdated and expires.  The source=20
>>>> might be the HELD server, but it might be=20
>>>> something else.  If it's the HELD server, say=20
>>>> so.
>>>> It is a trivial ask that you include source,=20
>>>> lastUpdated and expires in the response,=20
>>>> identical to LoST.  It provides a level of=20
>>>> compatibility that is useful, and=20
>>>> non-intrusive for implementations to=20
>>>> accommodate.  It COULD be a fixed string.
>>>>=20
>>>> You think of implementations as the server=20
>>>> has, internally, all the routing information.=20
>>>> That's one way to do it.  Another way to do=20
>>>> it is to have the HELD server consult a LoST=20
>>>> server.  Yes, I know you don't think anyone=20
>>>> will implement a LoST server.  I think you=20
>>>> are wrong.
>>>>=20
>>>> I understand that I can incrementally add the=20
>>>> mapping components as extensions in a way=20
>>>> that is transformable to a "real" =20
>>>> structure, but the bits on the wire are=20
>>>> different.
>>>> If you persist, and consensus is to have an=20
>>>> extension point and no more, I'll submit the=20
>>>> draft that does it right away.   Does that=20
>>>> REALLY make any sense?
>>>>=20
>>>> Brian
>>>>=20
>>>>> On Mar 26, 2015, at 9:35 AM, James=20
>>>>> Winterbottom=20
>>>>> <<>mailto:a.james.winterbottom@gmail.=
com =
>>a.james.winterbottom@gmail.com =
>=20
>>>>> wrote:
>>>>>=20
>>>>> HUH????
>>>>>=20
>>>>> As I have said before and as the draft=20
>>>>> states, at least of the mandatory mapping=20
>>>>> elements is not applicable where you don't=20
>>>>> LoST, so simply resuming mapping doesn't=20
>>>>> work.
>>>>>=20
>>>>> If we put the extension point in, and you=20
>>>>> want to reuse mapping elements in your=20
>>>>> implementation you can simply reference them=20
>>>>> in the extension point, no specification=20
>>>>> required and things that choose not to=20
>>>>> understand the extension can ignore  them.=20
>>>>> No extra specification required, no extra=20
>>>>> work at all required in this specification,=20
>>>>> not even 10 minutes editing and 4 years of=20
>>>>> haggling.
>>>>>=20
>>>>> Cheers
>>>>> James
>>>>>=20
>>>>>> On 27 Mar 2015, at 1:31 am, Rosen, Brian=20
>>>>>> <<>mailto:Brian.Rosen@neustar.biz =
>>Brian.Rosen@neustar.biz =
>=20
>>>>>> wrote:
>>>>>>=20
>>>>>> I don't understand any of this logic.
>>>>>>=20
>>>>>> You import the definition from RFC5222 and=20
>>>>>> refer to it for the meaning of the=20
>>>>>> elements.  Done.  No time delay.  10=20
>>>>>> minutes of editing.
>>>>>>=20
>>>>>> I want to be able to build systems that=20
>>>>>> work world-wide.  The more commonality of=20
>>>>>> data structures, the better.
>>>>>>=20
>>>>>> You have not shown any harm to re-use of a=20
>>>>>> data structure that was designed for the=20
>>>>>> purpose you have, has had extensive IETF=20
>>>>>> review, implementation, and consensus.  You=20
>>>>>> want to invent something new.  It's clearly=20
>>>>>> a subset, but it's not precisely a subset.=20
>>>>>> That is not a good idea in my opinion.  As=20
>>>>>> the majority of elements in  are=20
>>>>>> optional, an implementation can choose=20
>>>>>> never to send them (server) or ignore them=20
>>>>>> if received (client).  If you use the=20
>>>>>> extension point (3), and we later decide=20
>>>>>> that most of  is in fact useful,=20
>>>>>> we would end up different data structures,=20
>>>>>> because the base structure is different.
>>>>>>=20
>>>>>> Brian
>>>>>>=20
>>>>>>> On Mar 26, 2015, at 8:22 AM, Laura Liess=20
>>>>>>> <<>mailto:laura.liess.dt@googlemail.co=
m =
>>laura.liess.dt@googlemail.com =
>=20
>>>>>>> wrote:
>>>>>>>=20
>>>>>>> I would prefer 3) and I can live with 2).
>>>>>>>=20
>>>>>>> I am oposed to 1) because it would delay=20
>>>>>>> the draft progress, just to add features=20
>>>>>>> about we don't know if anyone will need=20
>>>>>>> them andif so,  what exactly will be=20
>>>>>>> needed. For the work in ETSI on the EC=20
>>>>>>> M493 this is clearly not needed. ETSI=20
>>>>>>> needs the draft finished very soon, if we=20
>>>>>>> want the final ETSI specification,=20
>>>>>>> targeted for the end of this year, to=20
>>>>>>> refer an RFC and not a draft and the=20
>>>>>>> implementations which will come then soon,=20
>>>>>>> to be based an RFC and not on some=20
>>>>>>> intermediary version of the draft.
>>>>>>>=20
>>>>>>> I think 3) is a good solution, flexible=20
>>>>>>> enough that everyone could live with it.
>>>>>>>=20
>>>>>>> Thank you
>>>>>>>  Laura
>>>>>>>=20
>>>>>>> 2015-03-25 20:21 GMT+01:00 James=20
>>>>>>> Winterbottom=20
>>>>>>> <<>mailto:a.james.winterbottom@gmail.=
com =
>>a.james.winterbottom@gmail.com =
>:
>>>>>>>=20
>>>>>>> There is downside to using the existing=20
>>>>>>> schema Brian, this is spelt out clearly in=20
>>>>>>> the draft. In order to include the fields=20
>>>>>>> you want a new element would need to be=20
>>>>>>> defined in this draft to support it. I=20
>>>>>>> think that that is the wrong way to do it=20
>>>>>>> as there has been no expression of need.=20
>>>>>>> If a need arrises after this draft is=20
>>>>>>> done, then it can be added later. Right=20
>>>>>>> now it isn't needed.
>>>>>>>=20
>>>>>>> As I said in my preference for option 3, I=20
>>>>>>> think that the extension point should be=20
>>>>>>> added then anything can be added later if=20
>>>>>>> required.
>>>>>>>=20
>>>>>>> Cheers
>>>>>>> James
>>>>>>>=20
>>>>>>>=20
>>>>>>>> On 26 Mar 2015, at 2:52 am, Rosen, Brian=20
>>>>>>>> <<>mailto:Brian.Rosen@neustar.biz =
>>Brian.Rosen@neustar.biz =
>=20
>>>>>>>> wrote:
>>>>>>>>=20
>>>>>>>> Let's say that someone comes along and=20
>>>>>>>> shows a decent use case for including a=20
>>>>>>>> service boundary.
>>>>>>>>=20
>>>>>>>> So they define an extension for it.
>>>>>>>>=20
>>>>>>>> That extension may or may not be the same=20
>>>>>>>> as the service boundary that LoST=20
>>>>>>>> returns. An implementation designed to=20
>>>>>>>> provide world-wide service would have to=20
>>>>>>>> change.
>>>>>>>>=20
>>>>>>>> Returning the boundary is already optional in the LoST schema.
>>>>>>>>=20
>>>>>>>> If we used the existing definition:
>>>>>>>> 1. No new document is required
>>>>>>>> 2. Compatibility between this HELD extension and LoST is =
maintained
>>>>>>>> 3. Systems built to support both models don't have to change
>>>>>>>>=20
>>>>>>>> There is, as far as I can see, no=20
>>>>>>>> downside to using the existing schema=20
>>>>>>>> other than making the smallest possible=20
>>>>>>>> response a bit bigger.   One can always=20
>>>>>>>> ignore any returned items not=20
>>>>>>>> needed/wanted, and since they are=20
>>>>>>>> optional they can't be assumed to be=20
>>>>>>>> there.
>>>>>>>>=20
>>>>>>>> Option 2 (don't allow an extension point=20
>>>>>>>> on the return) makes no sense to me.  I=20
>>>>>>>> can't imagine the IETF doing that. Any=20
>>>>>>>> extension would then require all existing=20
>>>>>>>> implementations to be changed.
>>>>>>>>=20
>>>>>>>> Brian
>>>>>>>>=20
>>>>>>>>> On Mar 25, 2015, at 9:49 AM,=20
>>>>>>>>> <>mailto:R.Jesske@telekom.de =
>>R.Jesske@telekom.de =
 wrote:
>>>>>>>>>=20
>>>>>>>>> Hi James,
>>>>>>>>> thank you for the summary.
>>>>>>>>> My position is reflected in point 2.
>>>>>>>>>=20
>>>>>>>>> If people want to add something to a=20
>>>>>>>>> mechanism can it not be done only in=20
>>>>>>>>> writing a further draft?
>>>>>>>>> This means also including in such a draft also a extension =
mechanism.
>>>>>>>>>=20
>>>>>>>>> I think that would be a clear line to satisfy everybody.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Best Regards
>>>>>>>>>=20
>>>>>>>>> Roland
>>>>>>>>>=20
>>>>>>>>> -----Urspr=FCngliche Nachricht-----
>>>>>>>>> Von: Ecrit=20
>>>>>>>>> [mailto:<>mailto:ecrit-bounces@ietf.org =
>>ecrit-bounces@ietf.org =
]=20
>>>>>>>>> Im Auftrag von James Winterbottom
>>>>>>>>> Gesendet: Mittwoch, 25. M=E4rz 2015 09:03
>>>>>>>>> An: <>http://ecrit_ietf.org/ =
>ecrit_ietf.org
>>>>>>>>> Betreff: [Ecrit] HELD Routing summary
>>>>>>>>>=20
>>>>>>>>> Hi All,
>>>>>>>>>=20
>>>>>>>>> As I see it there is one open discussion=20
>>>>>>>>> point and three positions on this point.
>>>>>>>>> The discussion point is whether or not=20
>>>>>>>>> all of the ancillary data that is=20
>>>>>>>>> returned by a LoST findService request=20
>>>>>>>>> should be included in the HELD routing=20
>>>>>>>>> response or not.
>>>>>>>>>=20
>>>>>>>>> The three positions that have been=20
>>>>>>>>> stated are (in no particular order):
>>>>>>>>> 1) The definition for this information=20
>>>>>>>>> should be included in the base=20
>>>>>>>>> specification but is optional to send or=20
>>>>>>>>> be acted on.
>>>>>>>>> 2) Isn't required at all, let the current draft stand
>>>>>>>>> 3) Add an extension point to the schema=20
>>>>>>>>> in the draft so that the extra can be=20
>>>>>>>>> specified in a different draft and added=20
>>>>>>>>> by something requiring it.
>>>>>>>>>=20
>>>>>>>>> This email makes no claims to=20
>>>>>>>>> preference, but just presents the=20
>>>>>>>>> opinions that have been expressed.
>>>>>>>>>=20
>>>>>>>>> Cheers
>>>>>>>>> James
>>>>>>>>>=20
>>>>>>>>> _______________________________________________
>>>>>>>>> Ecrit mailing list
>>>>>>>>>=20
>>>>>>>>> <>mailto:Ecrit@ietf.org =
>>Ecrit@ietf.org 
>>>>>>>>>=20
>>>>>>>>> <>https://www.ietf.org/mailman=
/listinfo/ecrit > =
>https://www.ietf.org/mailman=
/listinfo/ecrit 
>>>>>>>>> _______________________________________________
>>>>>>>>> Ecrit mailing list
>>>>>>>>>=20
>>>>>>>>> <>mailto:Ecrit@ietf.org =
>>Ecrit@ietf.org 
>>>>>>>>>=20
>>>>>>>>> <>https://www.ietf.org/mailman=
/listinfo/ecrit > =
>https://www.ietf.org/mailman=
/listinfo/ecrit 
>>>>>>>>>=20
>>>>>>>>=20
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> Ecrit mailing list
>>>>>>>=20
>>>>>>> <>mailto:Ecrit@ietf.org =
>>Ecrit@ietf.org 
>>>>>>>=20
>>>>>>> <>https://www.ietf.org/mailman=
/listinfo/ecrit =
>>https://www.ietf.org/mailman=
/listinfo/ecrit 
>>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> Ecrit mailing list
>>>>>=20
>>>>> <>mailto:Ecrit@ietf.org =
>>Ecrit@ietf.org 
>>>>>=20
>>>>> >https://www.ietf.org/mailman=
/listinfo/ecrit 
>>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> >Ecrit@ietf.org =

>>>>=20
>>>> >https://www.ietf.org/mailman=
/listinfo/ecrit 
>>>>=20
>>>=20
>>>=20
>>>=20
>>> --
>>> Randall Gellens
>>> Opinions are personal;    facts are suspect;    I speak for myself =
only
>>> -------------- Randomly selected tag: ---------------
>>> Spotted on the back of a t-shirt worn by LAPD Bomb Squad:
>>> "If you see me running, try to keep up."
>>>=20
>>=20
>>=20
>> _______________________________________________
>> Ecrit mailing list
>> Ecrit@ietf.org 
>> https://www.ietf.org/mailman/listinfo/ecrit =

>=20
>=20
>=20
> --
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself =
only
> -------------- Randomly selected tag: ---------------
> Skipper:   Mr. Howell, You don't know what it's like out there in
>           the ocean, you may be bitten by a shark!
> Thurston:  A shark bite a Howell, ha ha he wouldn't dare.
> Skipper:   Besides we don't have room enough for your luggage.
> Thurston:  Well that's different. If I can't go first class I won't
>           go at all.


--Apple-Mail=_2F20A1C7-A7FA-43BA-8371-EFA00F1ED02E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

Thanks for talking the position as conciliator Randall.



On 27 Mar 2015, at 6:26 am, Randall Gellens <rg+ietf@qti.qualcomm.com> wrote:

My impression is that people are talking =
past 
each other, which is why I thought seeing =
the 
proposal in the document would help clarify =
it.

At 6:07 AM +1100 3/27/15, =
James Winterbottom wrote:

Randall,

I don't agree =
with Brian's position on the 
Source, my =
reading of LoST is that this can't 
be the HELD =
server because it doesn't satisfy 
the =
description and requirements for the use of 
that =
field.

But further to that, the three =
people in this 
group that requested this functionality don't 
see a need =
for this stuff. Indeed the only 
person =
arguing for it is Brian and he hasn't 
provided or =
demonstrated any need for it. 
Option 3 on =
that table allows it be added when 
needed which =
is the fastest and easiest 
approach.


Cheers
James

On 27 Mar =
2015, at 4:10 am, Randall Gellens 
<<mailto:randy@qti.qualcomm.com>randy@qti.qualcomm.com> 
wrote:

Brian,

If it's =
only 10 minutes of editing, then maybe 
you can =
revise either the XML (and update the 
TXT) or the =
TXT and show what it would look 
like in the =
document?  I think perhaps two 
examples =
would also help: one where the source 
is a local =
database and the other where the 
source is a =
LoST server.  We'd then have a 
concrete =
proposal in front of us and we could 
ask if we =
have consensus to adopt it and move 
forward.

James, if Brian does this, can you then =
look 
at =
the revisions and see if you still object 
or if you =
can accept them?

At 3:19 PM +0000 3/26/15, =
Brian Rosen wrote:

Come on, the mandatory elements are the 
source, =
lastUpdated and expires.  The source 
might be the =
HELD server, but it might be 
something =
else.  If it's the HELD server, say 
so.
It is a trivial ask that you include source, 
lastUpdated =
and expires in the response, 
identical to =
LoST.  It provides a level of 
compatibility =
that is useful, and 
non-intrusive for implementations to 
accommodate. =
 It COULD be a fixed string.

You think =
of implementations as the server 
has, =
internally, all the routing information. 
That's one =
way to do it.  Another way to do 
it is to =
have the HELD server consult a LoST 
server. =
 Yes, I know you don't think anyone 
will =
implement a LoST server.  I think you 
are =
wrong.

I understand that I can =
incrementally add the 
mapping =
components as extensions in a way 
that is =
transformable to a "real" <mapping> 
structure, =
but the bits on the wire are 
different.
If you persist, and consensus is to have an 
extension =
point and no more, I'll submit the 
draft that =
does it right away.   Does that 
REALLY make =
any sense?

Brian

On Mar 26, 2015, at 9:35 =
AM, James 
Winterbottom 
<<<mailto:a.james.winterbottom@gmail.com>mailto:a.james.winterbottom@gmail.com><mailto:a.james.winterbottom@gmail.com>a.james.winterbottom@gmail.com> 
wrote:

HUH????

As I have =
said before and as the draft 
states, at =
least of the mandatory mapping 
elements is =
not applicable where you don't 
LoST, so =
simply resuming mapping doesn't 
work.

If we put the extension point in, and you 
want to =
reuse mapping elements in your 
implementation=
 you can simply reference them 
in the =
extension point, no specification 
required and =
things that choose not to 
understand =
the extension can ignore  them. 
No extra =
specification required, no extra 
work at all =
required in this specification, 
not even 10 =
minutes editing and 4 years of 
haggling.

Cheers
James

On 27 Mar 2015, at 1:31 =
am, Rosen, Brian 
<<<mailto:Brian.Rosen@neustar.biz>mailto:Brian.Rosen@neustar.biz><mailto:Brian.Rosen@neustar.biz>Brian.Rosen@neustar.biz> 
wrote:

I don't understand any of this logic.

You import the definition from RFC5222 =
and 
refer=
 to it for the meaning of the 
elements. =
 Done.  No time delay.  10 
minutes of =
editing.

I want to be able to build systems =
that 
work=
 world-wide.  The more commonality of 
data =
structures, the better.

You have not shown =
any harm to re-use of a 
data =
structure that was designed for the 
purpose you =
have, has had extensive IETF 
review, =
implementation, and consensus.  You 
want to =
invent something new.  It's clearly 
a subset, =
but it's not precisely a subset. 
That is not =
a good idea in my opinion.  As 
the majority =
of elements in <mapping> are 
optional, an =
implementation can choose 
never to =
send them (server) or ignore them 
if received =
(client).  If you use the 
extension =
point (3), and we later decide 
that most of =
<mapping> is in fact useful, 
we would end =
up different data structures, 
because the =
base structure is different.

Brian

On Mar =
26, 2015, at 8:22 AM, Laura Liess 
<<<mailto:laura.liess.dt@googlemail.com>mailto:laura.liess.dt@googlemail.com><mailto:laura.liess.dt@googlemail.com>laura.liess.dt@googlemail.com> 
wrote:

I would prefer 3) and I can live with 2).

I am oposed to 1) because it would delay 
the draft =
progress, just to add features 
about we =
don't know if anyone will need 
them andif =
so,  what exactly will be 
needed. For =
the work in ETSI on the EC 
M493 this is =
clearly not needed. ETSI 
needs the =
draft finished very soon, if we 
want the =
final ETSI specification, 
targeted for =
the end of this year, to 
refer an RFC =
and not a draft and the 
implementations which will come then soon, 
to be based =
an RFC and not on some 
intermediary =
version of the draft.

I think 3) is a good =
solution, flexible 
enough that everyone could live with it.

Thank you
 Laura

2015-03-25 20:21 GMT+01:00 James 
Winterbottom 
<<<mailto:a.james.winterbottom@gmail.com>mailto:a.james.winterbottom@gmail.com><mailto:a.james.winterbottom@gmail.com>a.james.winterbottom@gmail.com>:

There is downside to using the existing 
schema =
Brian, this is spelt out clearly in 
the draft. =
In order to include the fields 
you want a =
new element would need to be 
defined in =
this draft to support it. I 
think that =
that is the wrong way to do it 
as there has =
been no expression of need. 
If a need =
arrises after this draft is 
done, then =
it can be added later. Right 
now it isn't =
needed.

As I said in my preference for =
option 3, I 
think that the extension point should be 
added then =
anything can be added later if 
required.

Cheers
James


On 26 Mar =
2015, at 2:52 am, Rosen, Brian 
<<<mailto:Brian.Rosen@neustar.biz>mailto:Brian.Rosen@neustar.biz><mailto:Brian.Rosen@neustar.biz>Brian.Rosen@neustar.biz> 
wrote:

Let's say that someone comes along and 
shows a =
decent use case for including a 
service =
boundary.

So they define an extension for =
it.

That extension may or may not be the =
same 
as =
the service boundary that LoST 
returns. An =
implementation designed to 
provide =
world-wide service would have to 
change.

Returning the boundary is already optional in =
the LoST schema.

If we used the existing =
definition:
1. No new document is required
2. =
Compatibility between this HELD extension and LoST is maintained
3. Systems built to support both models don't have to =
change

There is, as far as I can see, =
no 
downside to using the existing schema 
other than =
making the smallest possible 
response a =
bit bigger.   One can always 
ignore any =
returned items not 
needed/wanted, and since they are 
optional =
they can't be assumed to be 
there.

Option 2 (don't allow an extension point 
on the =
return) makes no sense to me.  I 
can't =
imagine the IETF doing that. Any 
extension =
would then require all existing 
implementations to be changed.

Brian

On Mar 25, 2015, at 9:49 AM, 
<<mailto:R.Jesske@telekom.de>mailto:R.Jesske@telekom.de><mailto:R.Jesske@telekom.de>R.Jesske@telekom.de wrote:

Hi James,
thank you for the summary.
My position is reflected in point 2.

If people want to add something to a 
mechanism =
can it not be done only in 
writing a =
further draft?
This means also including in such a draft =
also a extension mechanism.

I think that =
would be a clear line to satisfy everybody.


Best Regards

Roland

-----Urspr=FCngliche =
Nachricht-----
Von: Ecrit 
[mailto:<<mailto:ecrit-bounces@ietf.org>mailto:ecrit-bounces@ietf.org><mailto:ecrit-bounces@ietf.org>ecrit-bounces@ietf.org] 
Im Auftrag =
von James Winterbottom
Gesendet: Mittwoch, 25. M=E4rz 2015 =
09:03
An: <<http://ecrit_ietf.org/>http://ecrit_ietf.org/>ecrit_ietf.org
Betreff: [Ecrit] HELD Routing summary

Hi All,

As I see it there is one =
open discussion 
point and three positions on this point.
The =
discussion point is whether or not 
all of the =
ancillary data that is 
returned by =
a LoST findService request 
should be =
included in the HELD routing 
response or =
not.

The three positions that have =
been 
stated are (in no particular order):
1) The =
definition for this information 
should be =
included in the base specification but is optional to send or 
be acted =
on.
2) Isn't required at all, let the current draft =
stand
3) Add an extension point to the schema 
in the draft =
so that the extra can be 
specified in =
a different draft and added 
by something =
requiring it.

This email makes no claims =
to 
preference, but just presents the 
opinions =
that have been expressed.

Cheers
James

_______________________________________________
Ecrit mailing list

<<mailto:Ecrit@ietf.org>mailto:Ecrit@ietf.org><mailto:Ecrit@ietf.org>Ecrit@ietf.org

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

<<mailto:Ecrit@ietf.org>mailto:Ecrit@ietf.org><mailto:Ecrit@ietf.org>Ecrit@ietf.org

<<https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit> <https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit



_______________________________________________
Ecrit mailing list

<<mailto:Ecrit@ietf.org>mailto:Ecrit@ietf.org><mailto:Ecrit@ietf.org>Ecrit@ietf.org

<<https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit><https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit



_______________________________________________
Ecrit mailing list

<<mailto:Ecrit@ietf.org>mailto:Ecrit@ietf.org><mailto:Ecrit@ietf.org>Ecrit@ietf.org

<https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit



_______________________________________________
Ecrit mailing list
<mailto:Ecrit@ietf.org>Ecrit@ietf.org

<https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit




--
Randall Gellens
Opinions are =
personal;    facts are suspect;    I speak =
for myself only
-------------- Randomly selected tag: =
---------------
Spotted on the back of a t-shirt worn by =
LAPD Bomb Squad:
"If you see me running, try to keep =
up."



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



--
Randall Gellens
Opinions are personal;    facts =
are suspect;    I speak for myself only
-------------- Randomly selected tag: =
---------------
Skipper:   Mr. =
Howell, You don't know what it's like out there in
          the=
 ocean, you may be bitten by a shark!
Thurston:  A shark bite a Howell, ha ha he =
wouldn't dare.
Skipper: =
  Besides we don't have room enough for your =
luggage.
Thurston:  Well =
that's different. If I can't go first class I won't
          go =
at all.

=

--Apple-Mail=_2F20A1C7-A7FA-43BA-8371-EFA00F1ED02E--


From nobody Thu Mar 26 12:45:18 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9A41B2B4D for ; Thu, 26 Mar 2015 12:45:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level: 
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 xeMyrRn9hX9t for ; Thu, 26 Mar 2015 12:45:05 -0700 (PDT)
Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 843C11AC3D3 for ; Thu, 26 Mar 2015 12:44:40 -0700 (PDT)
Received: from pps.filterd (m0049401.ppops.net [127.0.0.1]) by m0049401.ppops.net-0018ba01. (8.14.7/8.14.7) with SMTP id t2QJhM0x016659; Thu, 26 Mar 2015 15:44:37 -0400
Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by m0049401.ppops.net-0018ba01. with ESMTP id 1tcr5c00y6-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Mar 2015 15:44:36 -0400
Received: from STNTEXMB13.cis.neustar.com ([169.254.3.129]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Thu, 26 Mar 2015 15:44:35 -0400
From: "Rosen, Brian" 
To: James Winterbottom , Randall Gellens 
Thread-Topic: [Ecrit] HELD Routing summary
Thread-Index: AQHQZxOrLUztZJ1aYEW07NjBnVfm750vJ1qHgABDaYD//7DggA==
Date: Thu, 26 Mar 2015 19:44:34 +0000
Message-ID: 
References: <5F3DEAC5-1A13-45A3-B9C8-51579BAC22F9@gmail.com> <14546D76-AEF5-4C23-9BA0-00B6FA4C1E96@neustar.biz>    <75BAB4CE-E408-472D-80DD-569ADD918A8B@gmail.com>   <204B769A-295F-476E-8B36-8F428FD4EE67@gmail.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [192.168.132.33]
Content-Type: multipart/alternative; boundary="_000_D139C8D79789Fbrianrosenneustarbiz_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=nai engine=5700 definitions=7752 signatures=670576
X-Proofpoint-Spam-Reason: safe
Archived-At: 
Cc: "ecrit@ietf.org" 
Subject: Re: [Ecrit] HELD Routing summary
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 19:45:16 -0000

--_000_D139C8D79789Fbrianrosenneustarbiz_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

UmVwbGFjZSB0aGUgbGFzdCB0d28gcGFyYWdyYXBocyBvZiBTZWN0aW9uIDQgd2l0aDoNCg0KVGhl
IGxvY2F0aW9uIHJlc3BvbnNlIHdoZW4gdGhlIEhFTEQgc2V2ZXIgc3VwcG9ydHMgdGhpcyBzcGVj
aWZpY2F0aW9uIGFuZCByb3V0aW5nIGlzIHJlcXVlc3RlZCBjb25zaXN0cyBvZiB0aGUgPG1hcHBp
bmc+IGVsZW1lbnQgZnJvbSBSRkM1MjIyLiAgVGhlIOKAnHNvdXJjZeKAnSBlbGVtZW50IHNoYWxs
IGJlIHRoZSBVUkkgb2YgdGhlIGF1dGhvcml0YXRpdmUgZ2VuZXJhdG9yIG9mIHRoZSBtYXBwaW5n
IGRhdGEsIHdoaWNoIG1heSBiZSB0aGUgSEVMRCBzZXJ2ZXLigJlzIFVSSS4gICBBbGwgb3RoZXIg
ZWxlbWVudHMgb2YgdGhlIDxtYXBwaW5nPiBlbGVtZW50IGFyZSBhcyB0aGV5IGFyZSBkZXNjcmli
ZWQgaW4gUkZDNTIyMi4NCg0KDQoNCg0KSWYgdGhpcyBsYW5ndWFnZSBpcyBhY2NlcHRhYmxlLCBJ
4oCZbGwgZml4IHRoZSBzY2hlbWEgaW4gU2VjdGlvbiA1IGFuZCB0aGUgZXhhbXBsZXMuDQoNCkJy
aWFuDQoNCkZyb206IEphbWVzIFdpbnRlcmJvdHRvbSA8YS5qYW1lcy53aW50ZXJib3R0b21AZ21h
aWwuY29tPG1haWx0bzphLmphbWVzLndpbnRlcmJvdHRvbUBnbWFpbC5jb20+Pg0KRGF0ZTogVGh1
cnNkYXksIE1hcmNoIDI2LCAyMDE1IGF0IDI6MjcgUE0NClRvOiBSYW5kYWxsIEdlbGxlbnMgPHJn
K2lldGZAcXRpLnF1YWxjb21tLmNvbTxtYWlsdG86cmcraWV0ZkBxdGkucXVhbGNvbW0uY29tPj4N
CkNjOiBCcmlhbiBSb3NlbiA8YnJpYW4ucm9zZW5AbmV1c3Rhci5iaXo8bWFpbHRvOmJyaWFuLnJv
c2VuQG5ldXN0YXIuYml6Pj4sICJlY3JpdEBpZXRmLm9yZzxtYWlsdG86ZWNyaXRAaWV0Zi5vcmc+
IiA8ZWNyaXRAaWV0Zi5vcmc8bWFpbHRvOmVjcml0QGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBb
RWNyaXRdIEhFTEQgUm91dGluZyBzdW1tYXJ5DQoNClRoYW5rcyBmb3IgdGFsa2luZyB0aGUgcG9z
aXRpb24gYXMgY29uY2lsaWF0b3IgUmFuZGFsbC4NCg0KDQoNCk9uIDI3IE1hciAyMDE1LCBhdCA2
OjI2IGFtLCBSYW5kYWxsIEdlbGxlbnMgPHJnK2lldGZAcXRpLnF1YWxjb21tLmNvbTxtYWlsdG86
cmcraWV0ZkBxdGkucXVhbGNvbW0uY29tPj4gd3JvdGU6DQoNCk15IGltcHJlc3Npb24gaXMgdGhh
dCBwZW9wbGUgYXJlIHRhbGtpbmcgcGFzdA0KZWFjaCBvdGhlciwgd2hpY2ggaXMgd2h5IEkgdGhv
dWdodCBzZWVpbmcgdGhlDQpwcm9wb3NhbCBpbiB0aGUgZG9jdW1lbnQgd291bGQgaGVscCBjbGFy
aWZ5IGl0Lg0KDQpBdCA2OjA3IEFNICsxMTAwIDMvMjcvMTUsIEphbWVzIFdpbnRlcmJvdHRvbSB3
cm90ZToNCg0KUmFuZGFsbCwNCg0KSSBkb24ndCBhZ3JlZSB3aXRoIEJyaWFuJ3MgcG9zaXRpb24g
b24gdGhlDQpTb3VyY2UsIG15IHJlYWRpbmcgb2YgTG9TVCBpcyB0aGF0IHRoaXMgY2FuJ3QNCmJl
IHRoZSBIRUxEIHNlcnZlciBiZWNhdXNlIGl0IGRvZXNuJ3Qgc2F0aXNmeQ0KdGhlIGRlc2NyaXB0
aW9uIGFuZCByZXF1aXJlbWVudHMgZm9yIHRoZSB1c2Ugb2YNCnRoYXQgZmllbGQuDQoNCkJ1dCBm
dXJ0aGVyIHRvIHRoYXQsIHRoZSB0aHJlZSBwZW9wbGUgaW4gdGhpcw0KZ3JvdXAgdGhhdCByZXF1
ZXN0ZWQgdGhpcyBmdW5jdGlvbmFsaXR5IGRvbid0DQpzZWUgYSBuZWVkIGZvciB0aGlzIHN0dWZm
LiBJbmRlZWQgdGhlIG9ubHkNCnBlcnNvbiBhcmd1aW5nIGZvciBpdCBpcyBCcmlhbiBhbmQgaGUg
aGFzbid0DQpwcm92aWRlZCBvciBkZW1vbnN0cmF0ZWQgYW55IG5lZWQgZm9yIGl0Lg0KT3B0aW9u
IDMgb24gdGhhdCB0YWJsZSBhbGxvd3MgaXQgYmUgYWRkZWQgd2hlbg0KbmVlZGVkIHdoaWNoIGlz
IHRoZSBmYXN0ZXN0IGFuZCBlYXNpZXN0DQphcHByb2FjaC4NCg0KDQpDaGVlcnMNCkphbWVzDQoN
Ck9uIDI3IE1hciAyMDE1LCBhdCA0OjEwIGFtLCBSYW5kYWxsIEdlbGxlbnMNCjw8bWFpbHRvOnJh
bmR5QHF0aS5xdWFsY29tbS5jb20+cmFuZHlAcXRpLnF1YWxjb21tLmNvbTxtYWlsdG86cmFuZHlA
cXRpLnF1YWxjb21tLmNvbT4+DQp3cm90ZToNCg0KQnJpYW4sDQoNCklmIGl0J3Mgb25seSAxMCBt
aW51dGVzIG9mIGVkaXRpbmcsIHRoZW4gbWF5YmUNCnlvdSBjYW4gcmV2aXNlIGVpdGhlciB0aGUg
WE1MIChhbmQgdXBkYXRlIHRoZQ0KVFhUKSBvciB0aGUgVFhUIGFuZCBzaG93IHdoYXQgaXQgd291
bGQgbG9vaw0KbGlrZSBpbiB0aGUgZG9jdW1lbnQ/ICBJIHRoaW5rIHBlcmhhcHMgdHdvDQpleGFt
cGxlcyB3b3VsZCBhbHNvIGhlbHA6IG9uZSB3aGVyZSB0aGUgc291cmNlDQppcyBhIGxvY2FsIGRh
dGFiYXNlIGFuZCB0aGUgb3RoZXIgd2hlcmUgdGhlDQpzb3VyY2UgaXMgYSBMb1NUIHNlcnZlci4g
IFdlJ2QgdGhlbiBoYXZlIGENCmNvbmNyZXRlIHByb3Bvc2FsIGluIGZyb250IG9mIHVzIGFuZCB3
ZSBjb3VsZA0KYXNrIGlmIHdlIGhhdmUgY29uc2Vuc3VzIHRvIGFkb3B0IGl0IGFuZCBtb3ZlDQpm
b3J3YXJkLg0KDQpKYW1lcywgaWYgQnJpYW4gZG9lcyB0aGlzLCBjYW4geW91IHRoZW4gbG9vaw0K
YXQgdGhlIHJldmlzaW9ucyBhbmQgc2VlIGlmIHlvdSBzdGlsbCBvYmplY3QNCm9yIGlmIHlvdSBj
YW4gYWNjZXB0IHRoZW0/DQoNCkF0IDM6MTkgUE0gKzAwMDAgMy8yNi8xNSwgQnJpYW4gUm9zZW4g
d3JvdGU6DQoNCkNvbWUgb24sIHRoZSBtYW5kYXRvcnkgZWxlbWVudHMgYXJlIHRoZQ0Kc291cmNl
LCBsYXN0VXBkYXRlZCBhbmQgZXhwaXJlcy4gIFRoZSBzb3VyY2UNCm1pZ2h0IGJlIHRoZSBIRUxE
IHNlcnZlciwgYnV0IGl0IG1pZ2h0IGJlDQpzb21ldGhpbmcgZWxzZS4gIElmIGl0J3MgdGhlIEhF
TEQgc2VydmVyLCBzYXkNCnNvLg0KSXQgaXMgYSB0cml2aWFsIGFzayB0aGF0IHlvdSBpbmNsdWRl
IHNvdXJjZSwNCmxhc3RVcGRhdGVkIGFuZCBleHBpcmVzIGluIHRoZSByZXNwb25zZSwNCmlkZW50
aWNhbCB0byBMb1NULiAgSXQgcHJvdmlkZXMgYSBsZXZlbCBvZg0KY29tcGF0aWJpbGl0eSB0aGF0
IGlzIHVzZWZ1bCwgYW5kDQpub24taW50cnVzaXZlIGZvciBpbXBsZW1lbnRhdGlvbnMgdG8NCmFj
Y29tbW9kYXRlLiAgSXQgQ09VTEQgYmUgYSBmaXhlZCBzdHJpbmcuDQoNCllvdSB0aGluayBvZiBp
bXBsZW1lbnRhdGlvbnMgYXMgdGhlIHNlcnZlcg0KaGFzLCBpbnRlcm5hbGx5LCBhbGwgdGhlIHJv
dXRpbmcgaW5mb3JtYXRpb24uDQpUaGF0J3Mgb25lIHdheSB0byBkbyBpdC4gIEFub3RoZXIgd2F5
IHRvIGRvDQppdCBpcyB0byBoYXZlIHRoZSBIRUxEIHNlcnZlciBjb25zdWx0IGEgTG9TVA0Kc2Vy
dmVyLiAgWWVzLCBJIGtub3cgeW91IGRvbid0IHRoaW5rIGFueW9uZQ0Kd2lsbCBpbXBsZW1lbnQg
YSBMb1NUIHNlcnZlci4gIEkgdGhpbmsgeW91DQphcmUgd3JvbmcuDQoNCkkgdW5kZXJzdGFuZCB0
aGF0IEkgY2FuIGluY3JlbWVudGFsbHkgYWRkIHRoZQ0KbWFwcGluZyBjb21wb25lbnRzIGFzIGV4
dGVuc2lvbnMgaW4gYSB3YXkNCnRoYXQgaXMgdHJhbnNmb3JtYWJsZSB0byBhICJyZWFsIiA8bWFw
cGluZz4NCnN0cnVjdHVyZSwgYnV0IHRoZSBiaXRzIG9uIHRoZSB3aXJlIGFyZQ0KZGlmZmVyZW50
Lg0KSWYgeW91IHBlcnNpc3QsIGFuZCBjb25zZW5zdXMgaXMgdG8gaGF2ZSBhbg0KZXh0ZW5zaW9u
IHBvaW50IGFuZCBubyBtb3JlLCBJJ2xsIHN1Ym1pdCB0aGUNCmRyYWZ0IHRoYXQgZG9lcyBpdCBy
aWdodCBhd2F5LiAgIERvZXMgdGhhdA0KUkVBTExZIG1ha2UgYW55IHNlbnNlPw0KDQpCcmlhbg0K
DQpPbiBNYXIgMjYsIDIwMTUsIGF0IDk6MzUgQU0sIEphbWVzDQpXaW50ZXJib3R0b20NCjw8PG1h
aWx0bzphLmphbWVzLndpbnRlcmJvdHRvbUBnbWFpbC5jb20+bWFpbHRvOmEuamFtZXMud2ludGVy
Ym90dG9tQGdtYWlsLmNvbT48bWFpbHRvOmEuamFtZXMud2ludGVyYm90dG9tQGdtYWlsLmNvbT5h
LmphbWVzLndpbnRlcmJvdHRvbUBnbWFpbC5jb208bWFpbHRvOmEuamFtZXMud2ludGVyYm90dG9t
QGdtYWlsLmNvbT4+DQp3cm90ZToNCg0KSFVIPz8/Pw0KDQpBcyBJIGhhdmUgc2FpZCBiZWZvcmUg
YW5kIGFzIHRoZSBkcmFmdA0Kc3RhdGVzLCBhdCBsZWFzdCBvZiB0aGUgbWFuZGF0b3J5IG1hcHBp
bmcNCmVsZW1lbnRzIGlzIG5vdCBhcHBsaWNhYmxlIHdoZXJlIHlvdSBkb24ndA0KTG9TVCwgc28g
c2ltcGx5IHJlc3VtaW5nIG1hcHBpbmcgZG9lc24ndA0Kd29yay4NCg0KSWYgd2UgcHV0IHRoZSBl
eHRlbnNpb24gcG9pbnQgaW4sIGFuZCB5b3UNCndhbnQgdG8gcmV1c2UgbWFwcGluZyBlbGVtZW50
cyBpbiB5b3VyDQppbXBsZW1lbnRhdGlvbiB5b3UgY2FuIHNpbXBseSByZWZlcmVuY2UgdGhlbQ0K
aW4gdGhlIGV4dGVuc2lvbiBwb2ludCwgbm8gc3BlY2lmaWNhdGlvbg0KcmVxdWlyZWQgYW5kIHRo
aW5ncyB0aGF0IGNob29zZSBub3QgdG8NCnVuZGVyc3RhbmQgdGhlIGV4dGVuc2lvbiBjYW4gaWdu
b3JlICB0aGVtLg0KTm8gZXh0cmEgc3BlY2lmaWNhdGlvbiByZXF1aXJlZCwgbm8gZXh0cmENCndv
cmsgYXQgYWxsIHJlcXVpcmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbiwNCm5vdCBldmVuIDEwIG1p
bnV0ZXMgZWRpdGluZyBhbmQgNCB5ZWFycyBvZg0KaGFnZ2xpbmcuDQoNCkNoZWVycw0KSmFtZXMN
Cg0KT24gMjcgTWFyIDIwMTUsIGF0IDE6MzEgYW0sIFJvc2VuLCBCcmlhbg0KPDw8bWFpbHRvOkJy
aWFuLlJvc2VuQG5ldXN0YXIuYml6Pm1haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpej48bWFp
bHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6PkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6PG1haWx0
bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpej4+DQp3cm90ZToNCg0KSSBkb24ndCB1bmRlcnN0YW5k
IGFueSBvZiB0aGlzIGxvZ2ljLg0KDQpZb3UgaW1wb3J0IHRoZSBkZWZpbml0aW9uIGZyb20gUkZD
NTIyMiBhbmQNCnJlZmVyIHRvIGl0IGZvciB0aGUgbWVhbmluZyBvZiB0aGUNCmVsZW1lbnRzLiAg
RG9uZS4gIE5vIHRpbWUgZGVsYXkuICAxMA0KbWludXRlcyBvZiBlZGl0aW5nLg0KDQpJIHdhbnQg
dG8gYmUgYWJsZSB0byBidWlsZCBzeXN0ZW1zIHRoYXQNCndvcmsgd29ybGQtd2lkZS4gIFRoZSBt
b3JlIGNvbW1vbmFsaXR5IG9mDQpkYXRhIHN0cnVjdHVyZXMsIHRoZSBiZXR0ZXIuDQoNCllvdSBo
YXZlIG5vdCBzaG93biBhbnkgaGFybSB0byByZS11c2Ugb2YgYQ0KZGF0YSBzdHJ1Y3R1cmUgdGhh
dCB3YXMgZGVzaWduZWQgZm9yIHRoZQ0KcHVycG9zZSB5b3UgaGF2ZSwgaGFzIGhhZCBleHRlbnNp
dmUgSUVURg0KcmV2aWV3LCBpbXBsZW1lbnRhdGlvbiwgYW5kIGNvbnNlbnN1cy4gIFlvdQ0Kd2Fu
dCB0byBpbnZlbnQgc29tZXRoaW5nIG5ldy4gIEl0J3MgY2xlYXJseQ0KYSBzdWJzZXQsIGJ1dCBp
dCdzIG5vdCBwcmVjaXNlbHkgYSBzdWJzZXQuDQpUaGF0IGlzIG5vdCBhIGdvb2QgaWRlYSBpbiBt
eSBvcGluaW9uLiAgQXMNCnRoZSBtYWpvcml0eSBvZiBlbGVtZW50cyBpbiA8bWFwcGluZz4gYXJl
DQpvcHRpb25hbCwgYW4gaW1wbGVtZW50YXRpb24gY2FuIGNob29zZQ0KbmV2ZXIgdG8gc2VuZCB0
aGVtIChzZXJ2ZXIpIG9yIGlnbm9yZSB0aGVtDQppZiByZWNlaXZlZCAoY2xpZW50KS4gIElmIHlv
dSB1c2UgdGhlDQpleHRlbnNpb24gcG9pbnQgKDMpLCBhbmQgd2UgbGF0ZXIgZGVjaWRlDQp0aGF0
IG1vc3Qgb2YgPG1hcHBpbmc+IGlzIGluIGZhY3QgdXNlZnVsLA0Kd2Ugd291bGQgZW5kIHVwIGRp
ZmZlcmVudCBkYXRhIHN0cnVjdHVyZXMsDQpiZWNhdXNlIHRoZSBiYXNlIHN0cnVjdHVyZSBpcyBk
aWZmZXJlbnQuDQoNCkJyaWFuDQoNCk9uIE1hciAyNiwgMjAxNSwgYXQgODoyMiBBTSwgTGF1cmEg
TGllc3MNCjw8PG1haWx0bzpsYXVyYS5saWVzcy5kdEBnb29nbGVtYWlsLmNvbT5tYWlsdG86bGF1
cmEubGllc3MuZHRAZ29vZ2xlbWFpbC5jb20+PG1haWx0bzpsYXVyYS5saWVzcy5kdEBnb29nbGVt
YWlsLmNvbT5sYXVyYS5saWVzcy5kdEBnb29nbGVtYWlsLmNvbTxtYWlsdG86bGF1cmEubGllc3Mu
ZHRAZ29vZ2xlbWFpbC5jb20+Pg0Kd3JvdGU6DQoNCkkgd291bGQgcHJlZmVyIDMpIGFuZCBJIGNh
biBsaXZlIHdpdGggMikuDQoNCkkgYW0gb3Bvc2VkIHRvIDEpIGJlY2F1c2UgaXQgd291bGQgZGVs
YXkNCnRoZSBkcmFmdCBwcm9ncmVzcywganVzdCB0byBhZGQgZmVhdHVyZXMNCmFib3V0IHdlIGRv
bid0IGtub3cgaWYgYW55b25lIHdpbGwgbmVlZA0KdGhlbSBhbmRpZiBzbywgIHdoYXQgZXhhY3Rs
eSB3aWxsIGJlDQpuZWVkZWQuIEZvciB0aGUgd29yayBpbiBFVFNJIG9uIHRoZSBFQw0KTTQ5MyB0
aGlzIGlzIGNsZWFybHkgbm90IG5lZWRlZC4gRVRTSQ0KbmVlZHMgdGhlIGRyYWZ0IGZpbmlzaGVk
IHZlcnkgc29vbiwgaWYgd2UNCndhbnQgdGhlIGZpbmFsIEVUU0kgc3BlY2lmaWNhdGlvbiwNCnRh
cmdldGVkIGZvciB0aGUgZW5kIG9mIHRoaXMgeWVhciwgdG8NCnJlZmVyIGFuIFJGQyBhbmQgbm90
IGEgZHJhZnQgYW5kIHRoZQ0KaW1wbGVtZW50YXRpb25zIHdoaWNoIHdpbGwgY29tZSB0aGVuIHNv
b24sDQp0byBiZSBiYXNlZCBhbiBSRkMgYW5kIG5vdCBvbiBzb21lDQppbnRlcm1lZGlhcnkgdmVy
c2lvbiBvZiB0aGUgZHJhZnQuDQoNCkkgdGhpbmsgMykgaXMgYSBnb29kIHNvbHV0aW9uLCBmbGV4
aWJsZQ0KZW5vdWdoIHRoYXQgZXZlcnlvbmUgY291bGQgbGl2ZSB3aXRoIGl0Lg0KDQpUaGFuayB5
b3UNCiBMYXVyYQ0KDQoyMDE1LTAzLTI1IDIwOjIxIEdNVCswMTowMCBKYW1lcw0KV2ludGVyYm90
dG9tDQo8PDxtYWlsdG86YS5qYW1lcy53aW50ZXJib3R0b21AZ21haWwuY29tPm1haWx0bzphLmph
bWVzLndpbnRlcmJvdHRvbUBnbWFpbC5jb20+PG1haWx0bzphLmphbWVzLndpbnRlcmJvdHRvbUBn
bWFpbC5jb20+YS5qYW1lcy53aW50ZXJib3R0b21AZ21haWwuY29tPG1haWx0bzphLmphbWVzLndp
bnRlcmJvdHRvbUBnbWFpbC5jb20+PjoNCg0KVGhlcmUgaXMgZG93bnNpZGUgdG8gdXNpbmcgdGhl
IGV4aXN0aW5nDQpzY2hlbWEgQnJpYW4sIHRoaXMgaXMgc3BlbHQgb3V0IGNsZWFybHkgaW4NCnRo
ZSBkcmFmdC4gSW4gb3JkZXIgdG8gaW5jbHVkZSB0aGUgZmllbGRzDQp5b3Ugd2FudCBhIG5ldyBl
bGVtZW50IHdvdWxkIG5lZWQgdG8gYmUNCmRlZmluZWQgaW4gdGhpcyBkcmFmdCB0byBzdXBwb3J0
IGl0LiBJDQp0aGluayB0aGF0IHRoYXQgaXMgdGhlIHdyb25nIHdheSB0byBkbyBpdA0KYXMgdGhl
cmUgaGFzIGJlZW4gbm8gZXhwcmVzc2lvbiBvZiBuZWVkLg0KSWYgYSBuZWVkIGFycmlzZXMgYWZ0
ZXIgdGhpcyBkcmFmdCBpcw0KZG9uZSwgdGhlbiBpdCBjYW4gYmUgYWRkZWQgbGF0ZXIuIFJpZ2h0
DQpub3cgaXQgaXNuJ3QgbmVlZGVkLg0KDQpBcyBJIHNhaWQgaW4gbXkgcHJlZmVyZW5jZSBmb3Ig
b3B0aW9uIDMsIEkNCnRoaW5rIHRoYXQgdGhlIGV4dGVuc2lvbiBwb2ludCBzaG91bGQgYmUNCmFk
ZGVkIHRoZW4gYW55dGhpbmcgY2FuIGJlIGFkZGVkIGxhdGVyIGlmDQpyZXF1aXJlZC4NCg0KQ2hl
ZXJzDQpKYW1lcw0KDQoNCk9uIDI2IE1hciAyMDE1LCBhdCAyOjUyIGFtLCBSb3NlbiwgQnJpYW4N
Cjw8PG1haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpej5tYWlsdG86QnJpYW4uUm9zZW5AbmV1
c3Rhci5iaXo+PG1haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpej5Ccmlhbi5Sb3NlbkBuZXVz
dGFyLmJpejxtYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo+Pg0Kd3JvdGU6DQoNCkxldCdz
IHNheSB0aGF0IHNvbWVvbmUgY29tZXMgYWxvbmcgYW5kDQpzaG93cyBhIGRlY2VudCB1c2UgY2Fz
ZSBmb3IgaW5jbHVkaW5nIGENCnNlcnZpY2UgYm91bmRhcnkuDQoNClNvIHRoZXkgZGVmaW5lIGFu
IGV4dGVuc2lvbiBmb3IgaXQuDQoNClRoYXQgZXh0ZW5zaW9uIG1heSBvciBtYXkgbm90IGJlIHRo
ZSBzYW1lDQphcyB0aGUgc2VydmljZSBib3VuZGFyeSB0aGF0IExvU1QNCnJldHVybnMuIEFuIGlt
cGxlbWVudGF0aW9uIGRlc2lnbmVkIHRvDQpwcm92aWRlIHdvcmxkLXdpZGUgc2VydmljZSB3b3Vs
ZCBoYXZlIHRvDQpjaGFuZ2UuDQoNClJldHVybmluZyB0aGUgYm91bmRhcnkgaXMgYWxyZWFkeSBv
cHRpb25hbCBpbiB0aGUgTG9TVCBzY2hlbWEuDQoNCklmIHdlIHVzZWQgdGhlIGV4aXN0aW5nIGRl
ZmluaXRpb246DQoxLiBObyBuZXcgZG9jdW1lbnQgaXMgcmVxdWlyZWQNCjIuIENvbXBhdGliaWxp
dHkgYmV0d2VlbiB0aGlzIEhFTEQgZXh0ZW5zaW9uIGFuZCBMb1NUIGlzIG1haW50YWluZWQNCjMu
IFN5c3RlbXMgYnVpbHQgdG8gc3VwcG9ydCBib3RoIG1vZGVscyBkb24ndCBoYXZlIHRvIGNoYW5n
ZQ0KDQpUaGVyZSBpcywgYXMgZmFyIGFzIEkgY2FuIHNlZSwgbm8NCmRvd25zaWRlIHRvIHVzaW5n
IHRoZSBleGlzdGluZyBzY2hlbWENCm90aGVyIHRoYW4gbWFraW5nIHRoZSBzbWFsbGVzdCBwb3Nz
aWJsZQ0KcmVzcG9uc2UgYSBiaXQgYmlnZ2VyLiAgIE9uZSBjYW4gYWx3YXlzDQppZ25vcmUgYW55
IHJldHVybmVkIGl0ZW1zIG5vdA0KbmVlZGVkL3dhbnRlZCwgYW5kIHNpbmNlIHRoZXkgYXJlDQpv
cHRpb25hbCB0aGV5IGNhbid0IGJlIGFzc3VtZWQgdG8gYmUNCnRoZXJlLg0KDQpPcHRpb24gMiAo
ZG9uJ3QgYWxsb3cgYW4gZXh0ZW5zaW9uIHBvaW50DQpvbiB0aGUgcmV0dXJuKSBtYWtlcyBubyBz
ZW5zZSB0byBtZS4gIEkNCmNhbid0IGltYWdpbmUgdGhlIElFVEYgZG9pbmcgdGhhdC4gQW55DQpl
eHRlbnNpb24gd291bGQgdGhlbiByZXF1aXJlIGFsbCBleGlzdGluZw0KaW1wbGVtZW50YXRpb25z
IHRvIGJlIGNoYW5nZWQuDQoNCkJyaWFuDQoNCk9uIE1hciAyNSwgMjAxNSwgYXQgOTo0OSBBTSwN
Cjw8bWFpbHRvOlIuSmVzc2tlQHRlbGVrb20uZGU+bWFpbHRvOlIuSmVzc2tlQHRlbGVrb20uZGU+
PG1haWx0bzpSLkplc3NrZUB0ZWxla29tLmRlPlIuSmVzc2tlQHRlbGVrb20uZGU8bWFpbHRvOlIu
SmVzc2tlQHRlbGVrb20uZGU+IHdyb3RlOg0KDQpIaSBKYW1lcywNCnRoYW5rIHlvdSBmb3IgdGhl
IHN1bW1hcnkuDQpNeSBwb3NpdGlvbiBpcyByZWZsZWN0ZWQgaW4gcG9pbnQgMi4NCg0KSWYgcGVv
cGxlIHdhbnQgdG8gYWRkIHNvbWV0aGluZyB0byBhDQptZWNoYW5pc20gY2FuIGl0IG5vdCBiZSBk
b25lIG9ubHkgaW4NCndyaXRpbmcgYSBmdXJ0aGVyIGRyYWZ0Pw0KVGhpcyBtZWFucyBhbHNvIGlu
Y2x1ZGluZyBpbiBzdWNoIGEgZHJhZnQgYWxzbyBhIGV4dGVuc2lvbiBtZWNoYW5pc20uDQoNCkkg
dGhpbmsgdGhhdCB3b3VsZCBiZSBhIGNsZWFyIGxpbmUgdG8gc2F0aXNmeSBldmVyeWJvZHkuDQoN
Cg0KQmVzdCBSZWdhcmRzDQoNClJvbGFuZA0KDQotLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNo
dC0tLS0tDQpWb246IEVjcml0DQpbbWFpbHRvOjw8bWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5v
cmc+bWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmc+PG1haWx0bzplY3JpdC1ib3VuY2VzQGll
dGYub3JnPmVjcml0LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5v
cmc+XQ0KSW0gQXVmdHJhZyB2b24gSmFtZXMgV2ludGVyYm90dG9tDQpHZXNlbmRldDogTWl0dHdv
Y2gsIDI1LiBNw6RyeiAyMDE1IDA5OjAzDQpBbjogPDxodHRwOi8vZWNyaXRfaWV0Zi5vcmcvPmh0
dHA6Ly9lY3JpdF9pZXRmLm9yZy8+ZWNyaXRfaWV0Zi5vcmcNCkJldHJlZmY6IFtFY3JpdF0gSEVM
RCBSb3V0aW5nIHN1bW1hcnkNCg0KSGkgQWxsLA0KDQpBcyBJIHNlZSBpdCB0aGVyZSBpcyBvbmUg
b3BlbiBkaXNjdXNzaW9uDQpwb2ludCBhbmQgdGhyZWUgcG9zaXRpb25zIG9uIHRoaXMgcG9pbnQu
DQpUaGUgZGlzY3Vzc2lvbiBwb2ludCBpcyB3aGV0aGVyIG9yIG5vdA0KYWxsIG9mIHRoZSBhbmNp
bGxhcnkgZGF0YSB0aGF0IGlzDQpyZXR1cm5lZCBieSBhIExvU1QgZmluZFNlcnZpY2UgcmVxdWVz
dA0Kc2hvdWxkIGJlIGluY2x1ZGVkIGluIHRoZSBIRUxEIHJvdXRpbmcNCnJlc3BvbnNlIG9yIG5v
dC4NCg0KVGhlIHRocmVlIHBvc2l0aW9ucyB0aGF0IGhhdmUgYmVlbg0Kc3RhdGVkIGFyZSAoaW4g
bm8gcGFydGljdWxhciBvcmRlcik6DQoxKSBUaGUgZGVmaW5pdGlvbiBmb3IgdGhpcyBpbmZvcm1h
dGlvbg0Kc2hvdWxkIGJlIGluY2x1ZGVkIGluIHRoZSBiYXNlDQpzcGVjaWZpY2F0aW9uIGJ1dCBp
cyBvcHRpb25hbCB0byBzZW5kIG9yDQpiZSBhY3RlZCBvbi4NCjIpIElzbid0IHJlcXVpcmVkIGF0
IGFsbCwgbGV0IHRoZSBjdXJyZW50IGRyYWZ0IHN0YW5kDQozKSBBZGQgYW4gZXh0ZW5zaW9uIHBv
aW50IHRvIHRoZSBzY2hlbWENCmluIHRoZSBkcmFmdCBzbyB0aGF0IHRoZSBleHRyYSBjYW4gYmUN
CnNwZWNpZmllZCBpbiBhIGRpZmZlcmVudCBkcmFmdCBhbmQgYWRkZWQNCmJ5IHNvbWV0aGluZyBy
ZXF1aXJpbmcgaXQuDQoNClRoaXMgZW1haWwgbWFrZXMgbm8gY2xhaW1zIHRvDQpwcmVmZXJlbmNl
LCBidXQganVzdCBwcmVzZW50cyB0aGUNCm9waW5pb25zIHRoYXQgaGF2ZSBiZWVuIGV4cHJlc3Nl
ZC4NCg0KQ2hlZXJzDQpKYW1lcw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KRWNyaXQgbWFpbGluZyBsaXN0DQoNCjw8bWFpbHRvOkVjcml0QGlldGYu
b3JnPm1haWx0bzpFY3JpdEBpZXRmLm9yZz48bWFpbHRvOkVjcml0QGlldGYub3JnPkVjcml0QGll
dGYub3JnPG1haWx0bzpFY3JpdEBpZXRmLm9yZz4NCg0KPDxodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL2Vjcml0Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vZWNyaXQ+IDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0Pmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpFY3JpdCBtYWlsaW5nIGxpc3QNCg0K
PDxtYWlsdG86RWNyaXRAaWV0Zi5vcmc+bWFpbHRvOkVjcml0QGlldGYub3JnPjxtYWlsdG86RWNy
aXRAaWV0Zi5vcmc+RWNyaXRAaWV0Zi5vcmc8bWFpbHRvOkVjcml0QGlldGYub3JnPg0KDQo8PGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQ+aHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdD4gPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vZWNyaXQ+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9l
Y3JpdA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCkVjcml0IG1haWxpbmcgbGlzdA0KDQo8PG1haWx0bzpFY3JpdEBpZXRmLm9yZz5tYWlsdG86
RWNyaXRAaWV0Zi5vcmc+PG1haWx0bzpFY3JpdEBpZXRmLm9yZz5FY3JpdEBpZXRmLm9yZzxtYWls
dG86RWNyaXRAaWV0Zi5vcmc+DQoNCjw8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9lY3JpdD5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0Pjxo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0Pmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpFY3JpdCBtYWlsaW5nIGxpc3QNCg0KPDxtYWls
dG86RWNyaXRAaWV0Zi5vcmc+bWFpbHRvOkVjcml0QGlldGYub3JnPjxtYWlsdG86RWNyaXRAaWV0
Zi5vcmc+RWNyaXRAaWV0Zi5vcmc8bWFpbHRvOkVjcml0QGlldGYub3JnPg0KDQo8aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdD5odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL2Vjcml0DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KRWNyaXQgbWFpbGluZyBsaXN0DQo8bWFpbHRvOkVjcml0QGll
dGYub3JnPkVjcml0QGlldGYub3JnPG1haWx0bzpFY3JpdEBpZXRmLm9yZz4NCg0KPGh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQ+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQoNCg0KDQotLQ0KUmFuZGFsbCBHZWxsZW5zDQpPcGlu
aW9ucyBhcmUgcGVyc29uYWw7ICAgIGZhY3RzIGFyZSBzdXNwZWN0OyAgICBJIHNwZWFrIGZvciBt
eXNlbGYgb25seQ0KLS0tLS0tLS0tLS0tLS0gUmFuZG9tbHkgc2VsZWN0ZWQgdGFnOiAtLS0tLS0t
LS0tLS0tLS0NClNwb3R0ZWQgb24gdGhlIGJhY2sgb2YgYSB0LXNoaXJ0IHdvcm4gYnkgTEFQRCBC
b21iIFNxdWFkOg0KIklmIHlvdSBzZWUgbWUgcnVubmluZywgdHJ5IHRvIGtlZXAgdXAuIg0KDQoN
Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkVjcml0
IG1haWxpbmcgbGlzdA0KRWNyaXRAaWV0Zi5vcmc8bWFpbHRvOkVjcml0QGlldGYub3JnPg0KaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQoNCg0KLS0NClJhbmRh
bGwgR2VsbGVucw0KT3BpbmlvbnMgYXJlIHBlcnNvbmFsOyAgICBmYWN0cyBhcmUgc3VzcGVjdDsg
ICAgSSBzcGVhayBmb3IgbXlzZWxmIG9ubHkNCi0tLS0tLS0tLS0tLS0tIFJhbmRvbWx5IHNlbGVj
dGVkIHRhZzogLS0tLS0tLS0tLS0tLS0tDQpTa2lwcGVyOiAgIE1yLiBIb3dlbGwsIFlvdSBkb24n
dCBrbm93IHdoYXQgaXQncyBsaWtlIG91dCB0aGVyZSBpbg0KICAgICAgICAgIHRoZSBvY2Vhbiwg
eW91IG1heSBiZSBiaXR0ZW4gYnkgYSBzaGFyayENClRodXJzdG9uOiAgQSBzaGFyayBiaXRlIGEg
SG93ZWxsLCBoYSBoYSBoZSB3b3VsZG4ndCBkYXJlLg0KU2tpcHBlcjogICBCZXNpZGVzIHdlIGRv
bid0IGhhdmUgcm9vbSBlbm91Z2ggZm9yIHlvdXIgbHVnZ2FnZS4NClRodXJzdG9uOiAgV2VsbCB0
aGF0J3MgZGlmZmVyZW50LiBJZiBJIGNhbid0IGdvIGZpcnN0IGNsYXNzIEkgd29uJ3QNCiAgICAg
ICAgICBnbyBhdCBhbGwuDQoNCg==

--_000_D139C8D79789Fbrianrosenneustarbiz_
Content-Type: text/html; charset="utf-8"
Content-ID: <70AB6985D893454F85A398B5D3B0A37C@neustar.biz>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5SZXBsYWNlIHRo
ZSBsYXN0IHR3byBwYXJhZ3JhcGhzIG9mIFNlY3Rpb24gNCB3aXRoOjwvZGl2Pg0KPGRpdj48YnI+
DQo8L2Rpdj4NCjxkaXY+VGhlIGxvY2F0aW9uIHJlc3BvbnNlIHdoZW4gdGhlIEhFTEQgc2V2ZXIg
c3VwcG9ydHMgdGhpcyBzcGVjaWZpY2F0aW9uIGFuZCByb3V0aW5nIGlzIHJlcXVlc3RlZCBjb25z
aXN0cyBvZiB0aGUgJmx0O21hcHBpbmcmZ3Q7IGVsZW1lbnQgZnJvbSBSRkM1MjIyLiAmbmJzcDtU
aGUg4oCcc291cmNl4oCdIGVsZW1lbnQgc2hhbGwgYmUgdGhlIFVSSSBvZiB0aGUgYXV0aG9yaXRh
dGl2ZSBnZW5lcmF0b3Igb2YgdGhlIG1hcHBpbmcgZGF0YSwgd2hpY2ggbWF5IGJlIHRoZSBIRUxE
DQogc2VydmVy4oCZcyBVUkkuICZuYnNwOyBBbGwgb3RoZXIgZWxlbWVudHMgb2YgdGhlICZsdDtt
YXBwaW5nJmd0OyBlbGVtZW50IGFyZSBhcyB0aGV5IGFyZSBkZXNjcmliZWQgaW4gUkZDNTIyMi4g
Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+
PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JZiB0aGlzIGxhbmd1YWdlIGlz
IGFjY2VwdGFibGUsIEnigJlsbCBmaXggdGhlIHNjaGVtYSBpbiBTZWN0aW9uIDUgYW5kIHRoZSBl
eGFtcGxlcy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkJyaWFuPC9kaXY+DQo8ZGl2
Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5
bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7
IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1l
ZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElO
Ry1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hU
OiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln
aHQ6Ym9sZCI+RnJvbTogPC9zcGFuPkphbWVzIFdpbnRlcmJvdHRvbSAmbHQ7PGEgaHJlZj0ibWFp
bHRvOmEuamFtZXMud2ludGVyYm90dG9tQGdtYWlsLmNvbSI+YS5qYW1lcy53aW50ZXJib3R0b21A
Z21haWwuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0
ZTogPC9zcGFuPlRodXJzZGF5LCBNYXJjaCAyNiwgMjAxNSBhdCAyOjI3IFBNPGJyPg0KPHNwYW4g
c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+UmFuZGFsbCBHZWxsZW5zICZsdDs8
YSBocmVmPSJtYWlsdG86cmcmIzQzO2lldGZAcXRpLnF1YWxjb21tLmNvbSI+cmcmIzQzO2lldGZA
cXRpLnF1YWxjb21tLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv
bGQiPkNjOiA8L3NwYW4+QnJpYW4gUm9zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpicmlhbi5yb3Nl
bkBuZXVzdGFyLmJpeiI+YnJpYW4ucm9zZW5AbmV1c3Rhci5iaXo8L2E+Jmd0OywgJnF1b3Q7PGEg
aHJlZj0ibWFpbHRvOmVjcml0QGlldGYub3JnIj5lY3JpdEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0
OzxhIGhyZWY9Im1haWx0bzplY3JpdEBpZXRmLm9yZyI+ZWNyaXRAaWV0Zi5vcmc8L2E+Jmd0Ozxi
cj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtF
Y3JpdF0gSEVMRCBSb3V0aW5nIHN1bW1hcnk8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+
DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3At
bW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFz
cz0iIj4NClRoYW5rcyBmb3IgdGFsa2luZyB0aGUgcG9zaXRpb24gYXMgY29uY2lsaWF0b3IgUmFu
ZGFsbC4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi
PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2
Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDI3
IE1hciAyMDE1LCBhdCA2OjI2IGFtLCBSYW5kYWxsIEdlbGxlbnMgJmx0OzxhIGhyZWY9Im1haWx0
bzpyZyYjNDM7aWV0ZkBxdGkucXVhbGNvbW0uY29tIiBjbGFzcz0iIj5yZyYjNDM7aWV0ZkBxdGku
cXVhbGNvbW0uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVy
Y2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy
aWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs
OyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg
dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt
YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut
d2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xh
c3M9IiI+TXkNCiBpbXByZXNzaW9uIGlzIHRoYXQgcGVvcGxlIGFyZSB0YWxraW5nIHBhc3Q8c3Bh
biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxiciBz
dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl
OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0
ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0
ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7
IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13
ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs
OyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp
bmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGln
bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z
cGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl
eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9y
dGFudDsiIGNsYXNzPSIiPmVhY2gNCiBvdGhlciwgd2hpY2ggaXMgd2h5IEkgdGhvdWdodCBzZWVp
bmcgdGhlPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwv
c3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg
Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v
cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFu
czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm
b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu
ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5
bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl
dHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87
IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u
ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsg
LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5s
aW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5wcm9wb3NhbA0KIGluIHRoZSBkb2N1bWVudCB3b3Vs
ZCBoZWxwIGNsYXJpZnkgaXQuPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGlj
YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9y
bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhl
aWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl
bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93
czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw
eDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp
emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQt
d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3Jt
YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0
ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3
b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9
IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4
OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDog
bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBo
YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu
c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj
aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRp
c3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+QXQNCiA2OjA3IEFNICYjNDM7MTEw
MCAzLzI3LzE1LCBKYW1lcyBXaW50ZXJib3R0b20gd3JvdGU6PC9zcGFuPjxiciBzdHlsZT0iZm9u
dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7
IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu
Zzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu
OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw
YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4
dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTog
SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp
YW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7
IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0
ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h
bDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13
aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iZm9u
dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7
IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu
Zzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu
OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw
YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4
dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KUmFuZGFsbCw8YnIgY2xhc3M9IiI+DQo8
YnIgY2xhc3M9IiI+DQpJIGRvbid0IGFncmVlIHdpdGggQnJpYW4ncyBwb3NpdGlvbiBvbiB0aGU8
c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNz
PSIiPg0KU291cmNlLCBteSByZWFkaW5nIG9mIExvU1QgaXMgdGhhdCB0aGlzIGNhbid0PHNwYW4g
Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4N
CmJlIHRoZSBIRUxEIHNlcnZlciBiZWNhdXNlIGl0IGRvZXNuJ3Qgc2F0aXNmeTxzcGFuIGNsYXNz
PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQp0aGUg
ZGVzY3JpcHRpb24gYW5kIHJlcXVpcmVtZW50cyBmb3IgdGhlIHVzZSBvZjxzcGFuIGNsYXNzPSJB
cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQp0aGF0IGZp
ZWxkLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkJ1dCBmdXJ0aGVyIHRvIHRoYXQsIHRo
ZSB0aHJlZSBwZW9wbGUgaW4gdGhpczxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui
PiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpncm91cCB0aGF0IHJlcXVlc3RlZCB0aGlzIGZ1
bmN0aW9uYWxpdHkgZG9uJ3Q8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz
cDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0Kc2VlIGEgbmVlZCBmb3IgdGhpcyBzdHVmZi4gSW5kZWVk
IHRoZSBvbmx5PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu
PjxiciBjbGFzcz0iIj4NCnBlcnNvbiBhcmd1aW5nIGZvciBpdCBpcyBCcmlhbiBhbmQgaGUgaGFz
bid0PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBj
bGFzcz0iIj4NCnByb3ZpZGVkIG9yIGRlbW9uc3RyYXRlZCBhbnkgbmVlZCBmb3IgaXQuPHNwYW4g
Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4N
Ck9wdGlvbiAzIG9uIHRoYXQgdGFibGUgYWxsb3dzIGl0IGJlIGFkZGVkIHdoZW48c3BhbiBjbGFz
cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KbmVl
ZGVkIHdoaWNoIGlzIHRoZSBmYXN0ZXN0IGFuZCBlYXNpZXN0PHNwYW4gY2xhc3M9IkFwcGxlLWNv
bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCmFwcHJvYWNoLjxiciBj
bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkNoZWVyczxiciBjbGFzcz0i
Ij4NCkphbWVzPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i
Y2l0ZSIgY2xhc3M9IiI+T24gMjcgTWFyIDIwMTUsIGF0IDQ6MTAgYW0sIFJhbmRhbGwgR2VsbGVu
czxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xh
c3M9IiI+DQombHQ7Jmx0OzxhIGhyZWY9Im1haWx0bzpyYW5keUBxdGkucXVhbGNvbW0uY29tIiBj
bGFzcz0iIj5tYWlsdG86cmFuZHlAcXRpLnF1YWxjb21tLmNvbTwvYT4mZ3Q7PGEgaHJlZj0ibWFp
bHRvOnJhbmR5QHF0aS5xdWFsY29tbS5jb20iIGNsYXNzPSIiPnJhbmR5QHF0aS5xdWFsY29tbS5j
b208L2E+Jmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh
bj48YnIgY2xhc3M9IiI+DQp3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpCcmlh
biw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJZiBpdCdzIG9ubHkgMTAgbWludXRlcyBv
ZiBlZGl0aW5nLCB0aGVuIG1heWJlPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+
Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCnlvdSBjYW4gcmV2aXNlIGVpdGhlciB0aGUgWE1M
IChhbmQgdXBkYXRlIHRoZTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw
Ozwvc3Bhbj48YnIgY2xhc3M9IiI+DQpUWFQpIG9yIHRoZSBUWFQgYW5kIHNob3cgd2hhdCBpdCB3
b3VsZCBsb29rPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu
PjxiciBjbGFzcz0iIj4NCmxpa2UgaW4gdGhlIGRvY3VtZW50PyAmbmJzcDtJIHRoaW5rIHBlcmhh
cHMgdHdvPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxi
ciBjbGFzcz0iIj4NCmV4YW1wbGVzIHdvdWxkIGFsc28gaGVscDogb25lIHdoZXJlIHRoZSBzb3Vy
Y2U8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNs
YXNzPSIiPg0KaXMgYSBsb2NhbCBkYXRhYmFzZSBhbmQgdGhlIG90aGVyIHdoZXJlIHRoZTxzcGFu
IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+
DQpzb3VyY2UgaXMgYSBMb1NUIHNlcnZlci4gJm5ic3A7V2UnZCB0aGVuIGhhdmUgYTxzcGFuIGNs
YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpj
b25jcmV0ZSBwcm9wb3NhbCBpbiBmcm9udCBvZiB1cyBhbmQgd2UgY291bGQ8c3BhbiBjbGFzcz0i
QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KYXNrIGlm
IHdlIGhhdmUgY29uc2Vuc3VzIHRvIGFkb3B0IGl0IGFuZCBtb3ZlPHNwYW4gY2xhc3M9IkFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCmZvcndhcmQuPGJy
IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSmFtZXMsIGlmIEJyaWFuIGRvZXMgdGhpcywgY2Fu
IHlvdSB0aGVuIGxvb2s8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8
L3NwYW4+PGJyIGNsYXNzPSIiPg0KYXQgdGhlIHJldmlzaW9ucyBhbmQgc2VlIGlmIHlvdSBzdGls
bCBvYmplY3Q8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+
PGJyIGNsYXNzPSIiPg0Kb3IgaWYgeW91IGNhbiBhY2NlcHQgdGhlbT88YnIgY2xhc3M9IiI+DQo8
YnIgY2xhc3M9IiI+DQpBdCAzOjE5IFBNICYjNDM7MDAwMCAzLzI2LzE1LCBCcmlhbiBSb3NlbiB3
cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl
IiBjbGFzcz0iIj5Db21lIG9uLCB0aGUgbWFuZGF0b3J5IGVsZW1lbnRzIGFyZSB0aGU8c3BhbiBj
bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0K
c291cmNlLCBsYXN0VXBkYXRlZCBhbmQgZXhwaXJlcy4gJm5ic3A7VGhlIHNvdXJjZTxzcGFuIGNs
YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpt
aWdodCBiZSB0aGUgSEVMRCBzZXJ2ZXIsIGJ1dCBpdCBtaWdodCBiZTxzcGFuIGNsYXNzPSJBcHBs
ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpzb21ldGhpbmcg
ZWxzZS4gJm5ic3A7SWYgaXQncyB0aGUgSEVMRCBzZXJ2ZXIsIHNheTxzcGFuIGNsYXNzPSJBcHBs
ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpzby48YnIgY2xh
c3M9IiI+DQpJdCBpcyBhIHRyaXZpYWwgYXNrIHRoYXQgeW91IGluY2x1ZGUgc291cmNlLDxzcGFu
IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+
DQpsYXN0VXBkYXRlZCBhbmQgZXhwaXJlcyBpbiB0aGUgcmVzcG9uc2UsPHNwYW4gY2xhc3M9IkFw
cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCmlkZW50aWNh
bCB0byBMb1NULiAmbmJzcDtJdCBwcm92aWRlcyBhIGxldmVsIG9mPHNwYW4gY2xhc3M9IkFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCmNvbXBhdGliaWxp
dHkgdGhhdCBpcyB1c2VmdWwsIGFuZDxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui
PiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpub24taW50cnVzaXZlIGZvciBpbXBsZW1lbnRh
dGlvbnMgdG88c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+
PGJyIGNsYXNzPSIiPg0KYWNjb21tb2RhdGUuICZuYnNwO0l0IENPVUxEIGJlIGEgZml4ZWQgc3Ry
aW5nLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCllvdSB0aGluayBvZiBpbXBsZW1lbnRh
dGlvbnMgYXMgdGhlIHNlcnZlcjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu
YnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpoYXMsIGludGVybmFsbHksIGFsbCB0aGUgcm91dGlu
ZyBpbmZvcm1hdGlvbi48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8
L3NwYW4+PGJyIGNsYXNzPSIiPg0KVGhhdCdzIG9uZSB3YXkgdG8gZG8gaXQuICZuYnNwO0Fub3Ro
ZXIgd2F5IHRvIGRvPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z
cGFuPjxiciBjbGFzcz0iIj4NCml0IGlzIHRvIGhhdmUgdGhlIEhFTEQgc2VydmVyIGNvbnN1bHQg
YSBMb1NUPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxi
ciBjbGFzcz0iIj4NCnNlcnZlci4gJm5ic3A7WWVzLCBJIGtub3cgeW91IGRvbid0IHRoaW5rIGFu
eW9uZTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIg
Y2xhc3M9IiI+DQp3aWxsIGltcGxlbWVudCBhIExvU1Qgc2VydmVyLiAmbmJzcDtJIHRoaW5rIHlv
dTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xh
c3M9IiI+DQphcmUgd3JvbmcuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSB1bmRlcnN0
YW5kIHRoYXQgSSBjYW4gaW5jcmVtZW50YWxseSBhZGQgdGhlPHNwYW4gY2xhc3M9IkFwcGxlLWNv
bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCm1hcHBpbmcgY29tcG9u
ZW50cyBhcyBleHRlbnNpb25zIGluIGEgd2F5PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z
cGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCnRoYXQgaXMgdHJhbnNmb3JtYWJsZSB0
byBhICZxdW90O3JlYWwmcXVvdDsgJmx0O21hcHBpbmcmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNv
bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCnN0cnVjdHVyZSwgYnV0
IHRoZSBiaXRzIG9uIHRoZSB3aXJlIGFyZTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh
Y2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpkaWZmZXJlbnQuPGJyIGNsYXNzPSIiPg0K
SWYgeW91IHBlcnNpc3QsIGFuZCBjb25zZW5zdXMgaXMgdG8gaGF2ZSBhbjxzcGFuIGNsYXNzPSJB
cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpleHRlbnNp
b24gcG9pbnQgYW5kIG5vIG1vcmUsIEknbGwgc3VibWl0IHRoZTxzcGFuIGNsYXNzPSJBcHBsZS1j
b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpkcmFmdCB0aGF0IGRv
ZXMgaXQgcmlnaHQgYXdheS4gJm5ic3A7Jm5ic3A7RG9lcyB0aGF0PHNwYW4gY2xhc3M9IkFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NClJFQUxMWSBtYWtl
IGFueSBzZW5zZT88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpCcmlhbjxiciBjbGFzcz0i
Ij4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPk9uIE1h
ciAyNiwgMjAxNSwgYXQgOTozNSBBTSwgSmFtZXM8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVk
LXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KV2ludGVyYm90dG9tPHNwYW4gY2xh
c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCiZs
dDsmbHQ7Jmx0OzxhIGhyZWY9Im1haWx0bzphLmphbWVzLndpbnRlcmJvdHRvbUBnbWFpbC5jb20i
IGNsYXNzPSIiPm1haWx0bzphLmphbWVzLndpbnRlcmJvdHRvbUBnbWFpbC5jb208L2E+Jmd0Ozxh
IGhyZWY9Im1haWx0bzphLmphbWVzLndpbnRlcmJvdHRvbUBnbWFpbC5jb20iIGNsYXNzPSIiPm1h
aWx0bzphLmphbWVzLndpbnRlcmJvdHRvbUBnbWFpbC5jb208L2E+Jmd0OyZsdDs8YSBocmVmPSJt
YWlsdG86YS5qYW1lcy53aW50ZXJib3R0b21AZ21haWwuY29tIiBjbGFzcz0iIj5tYWlsdG86YS5q
YW1lcy53aW50ZXJib3R0b21AZ21haWwuY29tPC9hPiZndDs8YSBocmVmPSJtYWlsdG86YS5qYW1l
cy53aW50ZXJib3R0b21AZ21haWwuY29tIiBjbGFzcz0iIj5hLmphbWVzLndpbnRlcmJvdHRvbUBn
bWFpbC5jb208L2E+Jmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw
Ozwvc3Bhbj48YnIgY2xhc3M9IiI+DQp3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+
DQpIVUg/Pz8/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQXMgSSBoYXZlIHNhaWQgYmVm
b3JlIGFuZCBhcyB0aGUgZHJhZnQ8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m
bmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0Kc3RhdGVzLCBhdCBsZWFzdCBvZiB0aGUgbWFuZGF0
b3J5IG1hcHBpbmc8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw
YW4+PGJyIGNsYXNzPSIiPg0KZWxlbWVudHMgaXMgbm90IGFwcGxpY2FibGUgd2hlcmUgeW91IGRv
bid0PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBj
bGFzcz0iIj4NCkxvU1QsIHNvIHNpbXBseSByZXN1bWluZyBtYXBwaW5nIGRvZXNuJ3Q8c3BhbiBj
bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0K
d29yay48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJZiB3ZSBwdXQgdGhlIGV4dGVuc2lv
biBwb2ludCBpbiwgYW5kIHlvdTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu
YnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQp3YW50IHRvIHJldXNlIG1hcHBpbmcgZWxlbWVudHMg
aW4geW91cjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48
YnIgY2xhc3M9IiI+DQppbXBsZW1lbnRhdGlvbiB5b3UgY2FuIHNpbXBseSByZWZlcmVuY2UgdGhl
bTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xh
c3M9IiI+DQppbiB0aGUgZXh0ZW5zaW9uIHBvaW50LCBubyBzcGVjaWZpY2F0aW9uPHNwYW4gY2xh
c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCnJl
cXVpcmVkIGFuZCB0aGluZ3MgdGhhdCBjaG9vc2Ugbm90IHRvPHNwYW4gY2xhc3M9IkFwcGxlLWNv
bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCnVuZGVyc3RhbmQgdGhl
IGV4dGVuc2lvbiBjYW4gaWdub3JlICZuYnNwO3RoZW0uPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCk5vIGV4dHJhIHNwZWNpZmlj
YXRpb24gcmVxdWlyZWQsIG5vIGV4dHJhPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFj
ZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCndvcmsgYXQgYWxsIHJlcXVpcmVkIGluIHRo
aXMgc3BlY2lmaWNhdGlvbiw8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz
cDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0Kbm90IGV2ZW4gMTAgbWludXRlcyBlZGl0aW5nIGFuZCA0
IHllYXJzIG9mPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu
PjxiciBjbGFzcz0iIj4NCmhhZ2dsaW5nLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkNo
ZWVyczxiciBjbGFzcz0iIj4NCkphbWVzPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJs
b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+T24gMjcgTWFyIDIwMTUsIGF0IDE6MzEgYW0s
IFJvc2VuLCBCcmlhbjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv
c3Bhbj48YnIgY2xhc3M9IiI+DQombHQ7Jmx0OyZsdDs8YSBocmVmPSJtYWlsdG86QnJpYW4uUm9z
ZW5AbmV1c3Rhci5iaXoiIGNsYXNzPSIiPm1haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpejwv
YT4mZ3Q7PGEgaHJlZj0ibWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6IiBjbGFzcz0iIj5t
YWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo8L2E+Jmd0OyZsdDs8YSBocmVmPSJtYWlsdG86
QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXoiIGNsYXNzPSIiPm1haWx0bzpCcmlhbi5Sb3NlbkBuZXVz
dGFyLmJpejwvYT4mZ3Q7PGEgaHJlZj0ibWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6IiBj
bGFzcz0iIj5Ccmlhbi5Sb3NlbkBuZXVzdGFyLmJpejwvYT4mZ3Q7PHNwYW4gY2xhc3M9IkFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCndyb3RlOjxiciBj
bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgZG9uJ3QgdW5kZXJzdGFuZCBhbnkgb2YgdGhpcyBs
b2dpYy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpZb3UgaW1wb3J0IHRoZSBkZWZpbml0
aW9uIGZyb20gUkZDNTIyMiBhbmQ8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m
bmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KcmVmZXIgdG8gaXQgZm9yIHRoZSBtZWFuaW5nIG9m
IHRoZTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIg
Y2xhc3M9IiI+DQplbGVtZW50cy4gJm5ic3A7RG9uZS4gJm5ic3A7Tm8gdGltZSBkZWxheS4gJm5i
c3A7MTA8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJy
IGNsYXNzPSIiPg0KbWludXRlcyBvZiBlZGl0aW5nLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i
Ij4NCkkgd2FudCB0byBiZSBhYmxlIHRvIGJ1aWxkIHN5c3RlbXMgdGhhdDxzcGFuIGNsYXNzPSJB
cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQp3b3JrIHdv
cmxkLXdpZGUuICZuYnNwO1RoZSBtb3JlIGNvbW1vbmFsaXR5IG9mPHNwYW4gY2xhc3M9IkFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCmRhdGEgc3RydWN0
dXJlcywgdGhlIGJldHRlci48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpZb3UgaGF2ZSBu
b3Qgc2hvd24gYW55IGhhcm0gdG8gcmUtdXNlIG9mIGE8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy
dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KZGF0YSBzdHJ1Y3R1cmUgdGhh
dCB3YXMgZGVzaWduZWQgZm9yIHRoZTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui
PiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpwdXJwb3NlIHlvdSBoYXZlLCBoYXMgaGFkIGV4
dGVuc2l2ZSBJRVRGPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z
cGFuPjxiciBjbGFzcz0iIj4NCnJldmlldywgaW1wbGVtZW50YXRpb24sIGFuZCBjb25zZW5zdXMu
ICZuYnNwO1lvdTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh
bj48YnIgY2xhc3M9IiI+DQp3YW50IHRvIGludmVudCBzb21ldGhpbmcgbmV3LiAmbmJzcDtJdCdz
IGNsZWFybHk8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+
PGJyIGNsYXNzPSIiPg0KYSBzdWJzZXQsIGJ1dCBpdCdzIG5vdCBwcmVjaXNlbHkgYSBzdWJzZXQu
PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFz
cz0iIj4NClRoYXQgaXMgbm90IGEgZ29vZCBpZGVhIGluIG15IG9waW5pb24uICZuYnNwO0FzPHNw
YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0i
Ij4NCnRoZSBtYWpvcml0eSBvZiBlbGVtZW50cyBpbiAmbHQ7bWFwcGluZyZndDsgYXJlPHNwYW4g
Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4N
Cm9wdGlvbmFsLCBhbiBpbXBsZW1lbnRhdGlvbiBjYW4gY2hvb3NlPHNwYW4gY2xhc3M9IkFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCm5ldmVyIHRvIHNl
bmQgdGhlbSAoc2VydmVyKSBvciBpZ25vcmUgdGhlbTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0
ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQppZiByZWNlaXZlZCAoY2xpZW50
KS4gJm5ic3A7SWYgeW91IHVzZSB0aGU8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl
Ij4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KZXh0ZW5zaW9uIHBvaW50ICgzKSwgYW5kIHdl
IGxhdGVyIGRlY2lkZTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv
c3Bhbj48YnIgY2xhc3M9IiI+DQp0aGF0IG1vc3Qgb2YgJmx0O21hcHBpbmcmZ3Q7IGlzIGluIGZh
Y3QgdXNlZnVsLDxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh
bj48YnIgY2xhc3M9IiI+DQp3ZSB3b3VsZCBlbmQgdXAgZGlmZmVyZW50IGRhdGEgc3RydWN0dXJl
cyw8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNs
YXNzPSIiPg0KYmVjYXVzZSB0aGUgYmFzZSBzdHJ1Y3R1cmUgaXMgZGlmZmVyZW50LjxiciBjbGFz
cz0iIj4NCjxiciBjbGFzcz0iIj4NCkJyaWFuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K
PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+T24gTWFyIDI2LCAyMDE1LCBhdCA4OjIy
IEFNLCBMYXVyYSBMaWVzczxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw
Ozwvc3Bhbj48YnIgY2xhc3M9IiI+DQombHQ7Jmx0OyZsdDs8YSBocmVmPSJtYWlsdG86bGF1cmEu
bGllc3MuZHRAZ29vZ2xlbWFpbC5jb20iIGNsYXNzPSIiPm1haWx0bzpsYXVyYS5saWVzcy5kdEBn
b29nbGVtYWlsLmNvbTwvYT4mZ3Q7PGEgaHJlZj0ibWFpbHRvOmxhdXJhLmxpZXNzLmR0QGdvb2ds
ZW1haWwuY29tIiBjbGFzcz0iIj5tYWlsdG86bGF1cmEubGllc3MuZHRAZ29vZ2xlbWFpbC5jb208
L2E+Jmd0OyZsdDs8YSBocmVmPSJtYWlsdG86bGF1cmEubGllc3MuZHRAZ29vZ2xlbWFpbC5jb20i
IGNsYXNzPSIiPm1haWx0bzpsYXVyYS5saWVzcy5kdEBnb29nbGVtYWlsLmNvbTwvYT4mZ3Q7PGEg
aHJlZj0ibWFpbHRvOmxhdXJhLmxpZXNzLmR0QGdvb2dsZW1haWwuY29tIiBjbGFzcz0iIj5sYXVy
YS5saWVzcy5kdEBnb29nbGVtYWlsLmNvbTwvYT4mZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCndyb3RlOjxiciBjbGFzcz0i
Ij4NCjxiciBjbGFzcz0iIj4NCkkgd291bGQgcHJlZmVyIDMpIGFuZCBJIGNhbiBsaXZlIHdpdGgg
MikuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBhbSBvcG9zZWQgdG8gMSkgYmVjYXVz
ZSBpdCB3b3VsZCBkZWxheTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw
Ozwvc3Bhbj48YnIgY2xhc3M9IiI+DQp0aGUgZHJhZnQgcHJvZ3Jlc3MsIGp1c3QgdG8gYWRkIGZl
YXR1cmVzPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxi
ciBjbGFzcz0iIj4NCmFib3V0IHdlIGRvbid0IGtub3cgaWYgYW55b25lIHdpbGwgbmVlZDxzcGFu
IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+
DQp0aGVtIGFuZGlmIHNvLCAmbmJzcDt3aGF0IGV4YWN0bHkgd2lsbCBiZTxzcGFuIGNsYXNzPSJB
cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpuZWVkZWQu
IEZvciB0aGUgd29yayBpbiBFVFNJIG9uIHRoZSBFQzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0
ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpNNDkzIHRoaXMgaXMgY2xlYXJs
eSBub3QgbmVlZGVkLiBFVFNJPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i
c3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCm5lZWRzIHRoZSBkcmFmdCBmaW5pc2hlZCB2ZXJ5IHNv
b24sIGlmIHdlPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu
PjxiciBjbGFzcz0iIj4NCndhbnQgdGhlIGZpbmFsIEVUU0kgc3BlY2lmaWNhdGlvbiw8c3BhbiBj
bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0K
dGFyZ2V0ZWQgZm9yIHRoZSBlbmQgb2YgdGhpcyB5ZWFyLCB0bzxzcGFuIGNsYXNzPSJBcHBsZS1j
b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpyZWZlciBhbiBSRkMg
YW5kIG5vdCBhIGRyYWZ0IGFuZCB0aGU8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl
Ij4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KaW1wbGVtZW50YXRpb25zIHdoaWNoIHdpbGwg
Y29tZSB0aGVuIHNvb24sPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7
PC9zcGFuPjxiciBjbGFzcz0iIj4NCnRvIGJlIGJhc2VkIGFuIFJGQyBhbmQgbm90IG9uIHNvbWU8
c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNz
PSIiPg0KaW50ZXJtZWRpYXJ5IHZlcnNpb24gb2YgdGhlIGRyYWZ0LjxiciBjbGFzcz0iIj4NCjxi
ciBjbGFzcz0iIj4NCkkgdGhpbmsgMykgaXMgYSBnb29kIHNvbHV0aW9uLCBmbGV4aWJsZTxzcGFu
IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+
DQplbm91Z2ggdGhhdCBldmVyeW9uZSBjb3VsZCBsaXZlIHdpdGggaXQuPGJyIGNsYXNzPSIiPg0K
PGJyIGNsYXNzPSIiPg0KVGhhbmsgeW91PGJyIGNsYXNzPSIiPg0KJm5ic3A7TGF1cmE8YnIgY2xh
c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQoyMDE1LTAzLTI1IDIwOjIxIEdNVCYjNDM7MDE6MDAgSmFt
ZXM8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNs
YXNzPSIiPg0KV2ludGVyYm90dG9tPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+
Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCiZsdDsmbHQ7Jmx0OzxhIGhyZWY9Im1haWx0bzph
LmphbWVzLndpbnRlcmJvdHRvbUBnbWFpbC5jb20iIGNsYXNzPSIiPm1haWx0bzphLmphbWVzLndp
bnRlcmJvdHRvbUBnbWFpbC5jb208L2E+Jmd0OzxhIGhyZWY9Im1haWx0bzphLmphbWVzLndpbnRl
cmJvdHRvbUBnbWFpbC5jb20iIGNsYXNzPSIiPm1haWx0bzphLmphbWVzLndpbnRlcmJvdHRvbUBn
bWFpbC5jb208L2E+Jmd0OyZsdDs8YSBocmVmPSJtYWlsdG86YS5qYW1lcy53aW50ZXJib3R0b21A
Z21haWwuY29tIiBjbGFzcz0iIj5tYWlsdG86YS5qYW1lcy53aW50ZXJib3R0b21AZ21haWwuY29t
PC9hPiZndDs8YSBocmVmPSJtYWlsdG86YS5qYW1lcy53aW50ZXJib3R0b21AZ21haWwuY29tIiBj
bGFzcz0iIj5hLmphbWVzLndpbnRlcmJvdHRvbUBnbWFpbC5jb208L2E+Jmd0Ozo8YnIgY2xhc3M9
IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGVyZSBpcyBkb3duc2lkZSB0byB1c2luZyB0aGUgZXhpc3Rp
bmc8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNs
YXNzPSIiPg0Kc2NoZW1hIEJyaWFuLCB0aGlzIGlzIHNwZWx0IG91dCBjbGVhcmx5IGluPHNwYW4g
Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4N
CnRoZSBkcmFmdC4gSW4gb3JkZXIgdG8gaW5jbHVkZSB0aGUgZmllbGRzPHNwYW4gY2xhc3M9IkFw
cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCnlvdSB3YW50
IGEgbmV3IGVsZW1lbnQgd291bGQgbmVlZCB0byBiZTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0
ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpkZWZpbmVkIGluIHRoaXMgZHJh
ZnQgdG8gc3VwcG9ydCBpdC4gSTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu
YnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQp0aGluayB0aGF0IHRoYXQgaXMgdGhlIHdyb25nIHdh
eSB0byBkbyBpdDxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh
bj48YnIgY2xhc3M9IiI+DQphcyB0aGVyZSBoYXMgYmVlbiBubyBleHByZXNzaW9uIG9mIG5lZWQu
PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFz
cz0iIj4NCklmIGEgbmVlZCBhcnJpc2VzIGFmdGVyIHRoaXMgZHJhZnQgaXM8c3BhbiBjbGFzcz0i
QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KZG9uZSwg
dGhlbiBpdCBjYW4gYmUgYWRkZWQgbGF0ZXIuIFJpZ2h0PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCm5vdyBpdCBpc24ndCBuZWVk
ZWQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQXMgSSBzYWlkIGluIG15IHByZWZlcmVu
Y2UgZm9yIG9wdGlvbiAzLCBJPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i
c3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCnRoaW5rIHRoYXQgdGhlIGV4dGVuc2lvbiBwb2ludCBz
aG91bGQgYmU8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+
PGJyIGNsYXNzPSIiPg0KYWRkZWQgdGhlbiBhbnl0aGluZyBjYW4gYmUgYWRkZWQgbGF0ZXIgaWY8
c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNz
PSIiPg0KcmVxdWlyZWQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQ2hlZXJzPGJyIGNs
YXNzPSIiPg0KSmFtZXM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+
DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5PbiAyNiBNYXIgMjAxNSwgYXQgMjo1
MiBhbSwgUm9zZW4sIEJyaWFuPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i
c3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCiZsdDsmbHQ7Jmx0OzxhIGhyZWY9Im1haWx0bzpCcmlh
bi5Sb3NlbkBuZXVzdGFyLmJpeiIgY2xhc3M9IiI+bWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIu
Yml6PC9hPiZndDs8YSBocmVmPSJtYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXoiIGNsYXNz
PSIiPm1haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpejwvYT4mZ3Q7Jmx0OzxhIGhyZWY9Im1h
aWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpeiIgY2xhc3M9IiI+bWFpbHRvOkJyaWFuLlJvc2Vu
QG5ldXN0YXIuYml6PC9hPiZndDs8YSBocmVmPSJtYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5i
aXoiIGNsYXNzPSIiPkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6PC9hPiZndDs8c3BhbiBjbGFzcz0i
QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0Kd3JvdGU6
PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTGV0J3Mgc2F5IHRoYXQgc29tZW9uZSBjb21l
cyBhbG9uZyBhbmQ8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw
YW4+PGJyIGNsYXNzPSIiPg0Kc2hvd3MgYSBkZWNlbnQgdXNlIGNhc2UgZm9yIGluY2x1ZGluZyBh
PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFz
cz0iIj4NCnNlcnZpY2UgYm91bmRhcnkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU28g
dGhleSBkZWZpbmUgYW4gZXh0ZW5zaW9uIGZvciBpdC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9
IiI+DQpUaGF0IGV4dGVuc2lvbiBtYXkgb3IgbWF5IG5vdCBiZSB0aGUgc2FtZTxzcGFuIGNsYXNz
PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQphcyB0
aGUgc2VydmljZSBib3VuZGFyeSB0aGF0IExvU1Q8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVk
LXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KcmV0dXJucy4gQW4gaW1wbGVtZW50
YXRpb24gZGVzaWduZWQgdG88c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz
cDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KcHJvdmlkZSB3b3JsZC13aWRlIHNlcnZpY2Ugd291bGQg
aGF2ZSB0bzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48
YnIgY2xhc3M9IiI+DQpjaGFuZ2UuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUmV0dXJu
aW5nIHRoZSBib3VuZGFyeSBpcyBhbHJlYWR5IG9wdGlvbmFsIGluIHRoZSBMb1NUIHNjaGVtYS48
YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJZiB3ZSB1c2VkIHRoZSBleGlzdGluZyBkZWZp
bml0aW9uOjxiciBjbGFzcz0iIj4NCjEuIE5vIG5ldyBkb2N1bWVudCBpcyByZXF1aXJlZDxiciBj
bGFzcz0iIj4NCjIuIENvbXBhdGliaWxpdHkgYmV0d2VlbiB0aGlzIEhFTEQgZXh0ZW5zaW9uIGFu
ZCBMb1NUIGlzIG1haW50YWluZWQ8YnIgY2xhc3M9IiI+DQozLiBTeXN0ZW1zIGJ1aWx0IHRvIHN1
cHBvcnQgYm90aCBtb2RlbHMgZG9uJ3QgaGF2ZSB0byBjaGFuZ2U8YnIgY2xhc3M9IiI+DQo8YnIg
Y2xhc3M9IiI+DQpUaGVyZSBpcywgYXMgZmFyIGFzIEkgY2FuIHNlZSwgbm88c3BhbiBjbGFzcz0i
QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KZG93bnNp
ZGUgdG8gdXNpbmcgdGhlIGV4aXN0aW5nIHNjaGVtYTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0
ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpvdGhlciB0aGFuIG1ha2luZyB0
aGUgc21hbGxlc3QgcG9zc2libGU8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m
bmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KcmVzcG9uc2UgYSBiaXQgYmlnZ2VyLiAmbmJzcDsm
bmJzcDtPbmUgY2FuIGFsd2F5czxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu
YnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQppZ25vcmUgYW55IHJldHVybmVkIGl0ZW1zIG5vdDxz
cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9
IiI+DQpuZWVkZWQvd2FudGVkLCBhbmQgc2luY2UgdGhleSBhcmU8c3BhbiBjbGFzcz0iQXBwbGUt
Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0Kb3B0aW9uYWwgdGhl
eSBjYW4ndCBiZSBhc3N1bWVkIHRvIGJlPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFj
ZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCnRoZXJlLjxiciBjbGFzcz0iIj4NCjxiciBj
bGFzcz0iIj4NCk9wdGlvbiAyIChkb24ndCBhbGxvdyBhbiBleHRlbnNpb24gcG9pbnQ8c3BhbiBj
bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0K
b24gdGhlIHJldHVybikgbWFrZXMgbm8gc2Vuc2UgdG8gbWUuICZuYnNwO0k8c3BhbiBjbGFzcz0i
QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KY2FuJ3Qg
aW1hZ2luZSB0aGUgSUVURiBkb2luZyB0aGF0LiBBbnk8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy
dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KZXh0ZW5zaW9uIHdvdWxkIHRo
ZW4gcmVxdWlyZSBhbGwgZXhpc3Rpbmc8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl
Ij4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KaW1wbGVtZW50YXRpb25zIHRvIGJlIGNoYW5n
ZWQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQnJpYW48YnIgY2xhc3M9IiI+DQo8YnIg
Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5PbiBNYXIgMjUsIDIw
MTUsIGF0IDk6NDkgQU0sPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7
PC9zcGFuPjxiciBjbGFzcz0iIj4NCiZsdDsmbHQ7PGEgaHJlZj0ibWFpbHRvOlIuSmVzc2tlQHRl
bGVrb20uZGUiIGNsYXNzPSIiPm1haWx0bzpSLkplc3NrZUB0ZWxla29tLmRlPC9hPiZndDs8YSBo
cmVmPSJtYWlsdG86Ui5KZXNza2VAdGVsZWtvbS5kZSIgY2xhc3M9IiI+bWFpbHRvOlIuSmVzc2tl
QHRlbGVrb20uZGU8L2E+Jmd0OyZsdDs8YSBocmVmPSJtYWlsdG86Ui5KZXNza2VAdGVsZWtvbS5k
ZSIgY2xhc3M9IiI+bWFpbHRvOlIuSmVzc2tlQHRlbGVrb20uZGU8L2E+Jmd0OzxhIGhyZWY9Im1h
aWx0bzpSLkplc3NrZUB0ZWxla29tLmRlIiBjbGFzcz0iIj5SLkplc3NrZUB0ZWxla29tLmRlPC9h
PjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj53cm90ZTo8
YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpIaSBKYW1lcyw8YnIgY2xhc3M9IiI+DQp0aGFu
ayB5b3UgZm9yIHRoZSBzdW1tYXJ5LjxiciBjbGFzcz0iIj4NCk15IHBvc2l0aW9uIGlzIHJlZmxl
Y3RlZCBpbiBwb2ludCAyLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCklmIHBlb3BsZSB3
YW50IHRvIGFkZCBzb21ldGhpbmcgdG8gYTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh
Y2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQptZWNoYW5pc20gY2FuIGl0IG5vdCBiZSBk
b25lIG9ubHkgaW48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw
YW4+PGJyIGNsYXNzPSIiPg0Kd3JpdGluZyBhIGZ1cnRoZXIgZHJhZnQ/PGJyIGNsYXNzPSIiPg0K
VGhpcyBtZWFucyBhbHNvIGluY2x1ZGluZyBpbiBzdWNoIGEgZHJhZnQgYWxzbyBhIGV4dGVuc2lv
biBtZWNoYW5pc20uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSB0aGluayB0aGF0IHdv
dWxkIGJlIGEgY2xlYXIgbGluZSB0byBzYXRpc2Z5IGV2ZXJ5Ym9keS48YnIgY2xhc3M9IiI+DQo8
YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpCZXN0IFJlZ2FyZHM8YnIgY2xhc3M9IiI+DQo8
YnIgY2xhc3M9IiI+DQpSb2xhbmQ8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLS0tLVVy
c3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tPGJyIGNsYXNzPSIiPg0KVm9uOiBFY3JpdDxzcGFu
IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+
DQpbPGEgaHJlZj0ibWFpbHRvOiZsdDsiPm1haWx0bzombHQ7PC9hPiZsdDs8YSBocmVmPSJtYWls
dG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZyIgY2xhc3M9IiI+bWFpbHRvOmVjcml0LWJvdW5jZXNA
aWV0Zi5vcmc8L2E+Jmd0OzxhIGhyZWY9Im1haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnIiBj
bGFzcz0iIj5tYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7Jmx0OzxhIGhyZWY9
Im1haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnIiBjbGFzcz0iIj5tYWlsdG86ZWNyaXQtYm91
bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7PGEgaHJlZj0ibWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5v
cmciIGNsYXNzPSIiPmVjcml0LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XTxzcGFuIGNsYXNzPSJBcHBs
ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpJbSBBdWZ0cmFn
IHZvbiBKYW1lcyBXaW50ZXJib3R0b208YnIgY2xhc3M9IiI+DQpHZXNlbmRldDogTWl0dHdvY2gs
IDI1LiBNw6RyeiAyMDE1IDA5OjAzPGJyIGNsYXNzPSIiPg0KQW46ICZsdDsmbHQ7PGEgaHJlZj0i
aHR0cDovL2Vjcml0X2lldGYub3JnLyIgY2xhc3M9IiI+aHR0cDovL2Vjcml0X2lldGYub3JnLzwv
YT4mZ3Q7PGEgaHJlZj0iaHR0cDovL2Vjcml0X2lldGYub3JnLyIgY2xhc3M9IiI+aHR0cDovL2Vj
cml0X2lldGYub3JnLzwvYT4mZ3Q7ZWNyaXRfaWV0Zi5vcmc8YnIgY2xhc3M9IiI+DQpCZXRyZWZm
OiBbRWNyaXRdIEhFTEQgUm91dGluZyBzdW1tYXJ5PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi
Pg0KSGkgQWxsLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkFzIEkgc2VlIGl0IHRoZXJl
IGlzIG9uZSBvcGVuIGRpc2N1c3Npb248c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl
Ij4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KcG9pbnQgYW5kIHRocmVlIHBvc2l0aW9ucyBv
biB0aGlzIHBvaW50LjxiciBjbGFzcz0iIj4NClRoZSBkaXNjdXNzaW9uIHBvaW50IGlzIHdoZXRo
ZXIgb3Igbm90PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu
PjxiciBjbGFzcz0iIj4NCmFsbCBvZiB0aGUgYW5jaWxsYXJ5IGRhdGEgdGhhdCBpczxzcGFuIGNs
YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpy
ZXR1cm5lZCBieSBhIExvU1QgZmluZFNlcnZpY2UgcmVxdWVzdDxzcGFuIGNsYXNzPSJBcHBsZS1j
b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpzaG91bGQgYmUgaW5j
bHVkZWQgaW4gdGhlIEhFTEQgcm91dGluZzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh
Y2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpyZXNwb25zZSBvciBub3QuPGJyIGNsYXNz
PSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIHRocmVlIHBvc2l0aW9ucyB0aGF0IGhhdmUgYmVlbjxz
cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9
IiI+DQpzdGF0ZWQgYXJlIChpbiBubyBwYXJ0aWN1bGFyIG9yZGVyKTo8YnIgY2xhc3M9IiI+DQox
KSBUaGUgZGVmaW5pdGlvbiBmb3IgdGhpcyBpbmZvcm1hdGlvbjxzcGFuIGNsYXNzPSJBcHBsZS1j
b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpzaG91bGQgYmUgaW5j
bHVkZWQgaW4gdGhlIGJhc2U8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz
cDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0Kc3BlY2lmaWNhdGlvbiBidXQgaXMgb3B0aW9uYWwgdG8g
c2VuZCBvcjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48
YnIgY2xhc3M9IiI+DQpiZSBhY3RlZCBvbi48YnIgY2xhc3M9IiI+DQoyKSBJc24ndCByZXF1aXJl
ZCBhdCBhbGwsIGxldCB0aGUgY3VycmVudCBkcmFmdCBzdGFuZDxiciBjbGFzcz0iIj4NCjMpIEFk
ZCBhbiBleHRlbnNpb24gcG9pbnQgdG8gdGhlIHNjaGVtYTxzcGFuIGNsYXNzPSJBcHBsZS1jb252
ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQppbiB0aGUgZHJhZnQgc28g
dGhhdCB0aGUgZXh0cmEgY2FuIGJlPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+
Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCnNwZWNpZmllZCBpbiBhIGRpZmZlcmVudCBkcmFm
dCBhbmQgYWRkZWQ8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw
YW4+PGJyIGNsYXNzPSIiPg0KYnkgc29tZXRoaW5nIHJlcXVpcmluZyBpdC48YnIgY2xhc3M9IiI+
DQo8YnIgY2xhc3M9IiI+DQpUaGlzIGVtYWlsIG1ha2VzIG5vIGNsYWltcyB0bzxzcGFuIGNsYXNz
PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpwcmVm
ZXJlbmNlLCBidXQganVzdCBwcmVzZW50cyB0aGU8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVk
LXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0Kb3BpbmlvbnMgdGhhdCBoYXZlIGJl
ZW4gZXhwcmVzc2VkLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkNoZWVyczxiciBjbGFz
cz0iIj4NCkphbWVzPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpFY3JpdCBtYWls
aW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombHQ7Jmx0OzxhIGhyZWY9Im1h
aWx0bzpFY3JpdEBpZXRmLm9yZyIgY2xhc3M9IiI+bWFpbHRvOkVjcml0QGlldGYub3JnPC9hPiZn
dDs8YSBocmVmPSJtYWlsdG86RWNyaXRAaWV0Zi5vcmciIGNsYXNzPSIiPm1haWx0bzpFY3JpdEBp
ZXRmLm9yZzwvYT4mZ3Q7Jmx0OzxhIGhyZWY9Im1haWx0bzpFY3JpdEBpZXRmLm9yZyIgY2xhc3M9
IiI+bWFpbHRvOkVjcml0QGlldGYub3JnPC9hPiZndDs8YSBocmVmPSJtYWlsdG86RWNyaXRAaWV0
Zi5vcmciIGNsYXNzPSIiPkVjcml0QGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFz
cz0iIj4NCiZsdDsmbHQ7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9lY3JpdCIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9lY3JpdDwvYT4mZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9lY3JpdCIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9lY3JpdDwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL2Vjcml0IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL2Vjcml0PC9hPiZndDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL2Vjcml0IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL2Vjcml0PC9hPjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KRWNyaXQgbWFpbGluZyBsaXN0PGJy
IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJmx0OyZsdDs8YSBocmVmPSJtYWlsdG86RWNyaXRA
aWV0Zi5vcmciIGNsYXNzPSIiPm1haWx0bzpFY3JpdEBpZXRmLm9yZzwvYT4mZ3Q7PGEgaHJlZj0i
bWFpbHRvOkVjcml0QGlldGYub3JnIiBjbGFzcz0iIj5tYWlsdG86RWNyaXRAaWV0Zi5vcmc8L2E+
Jmd0OyZsdDs8YSBocmVmPSJtYWlsdG86RWNyaXRAaWV0Zi5vcmciIGNsYXNzPSIiPm1haWx0bzpF
Y3JpdEBpZXRmLm9yZzwvYT4mZ3Q7PGEgaHJlZj0ibWFpbHRvOkVjcml0QGlldGYub3JnIiBjbGFz
cz0iIj5FY3JpdEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombHQ7
Jmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQi
IGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQ8L2E+
Jmd0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQi
IGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQ8L2E+
Jmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9l
Y3JpdCIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3Jp
dDwvYT4mZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9l
Y3JpdCIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3Jp
dDwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xh
c3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCkVjcml0IG1haWxpbmcg
bGlzdDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZsdDsmbHQ7PGEgaHJlZj0ibWFpbHRv
OkVjcml0QGlldGYub3JnIiBjbGFzcz0iIj5tYWlsdG86RWNyaXRAaWV0Zi5vcmc8L2E+Jmd0Ozxh
IGhyZWY9Im1haWx0bzpFY3JpdEBpZXRmLm9yZyIgY2xhc3M9IiI+bWFpbHRvOkVjcml0QGlldGYu
b3JnPC9hPiZndDsmbHQ7PGEgaHJlZj0ibWFpbHRvOkVjcml0QGlldGYub3JnIiBjbGFzcz0iIj5t
YWlsdG86RWNyaXRAaWV0Zi5vcmc8L2E+Jmd0OzxhIGhyZWY9Im1haWx0bzpFY3JpdEBpZXRmLm9y
ZyIgY2xhc3M9IiI+RWNyaXRAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi
Pg0KJmx0OyZsdDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L2Vjcml0IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vj
cml0PC9hPiZndDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L2Vjcml0IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vj
cml0PC9hPiZndDsmbHQ7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9lY3JpdCIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9lY3JpdDwvYT4mZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9lY3JpdCIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9lY3JpdDwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8
YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCkVjcml0IG1h
aWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZsdDsmbHQ7PGEgaHJlZj0i
bWFpbHRvOkVjcml0QGlldGYub3JnIiBjbGFzcz0iIj5tYWlsdG86RWNyaXRAaWV0Zi5vcmc8L2E+
Jmd0OzxhIGhyZWY9Im1haWx0bzpFY3JpdEBpZXRmLm9yZyIgY2xhc3M9IiI+bWFpbHRvOkVjcml0
QGlldGYub3JnPC9hPiZndDsmbHQ7PGEgaHJlZj0ibWFpbHRvOkVjcml0QGlldGYub3JnIiBjbGFz
cz0iIj5tYWlsdG86RWNyaXRAaWV0Zi5vcmc8L2E+Jmd0OzxhIGhyZWY9Im1haWx0bzpFY3JpdEBp
ZXRmLm9yZyIgY2xhc3M9IiI+RWNyaXRAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNs
YXNzPSIiPg0KJmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vZWNyaXQiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
ZWNyaXQ8L2E+Jmd0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vZWNyaXQiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
ZWNyaXQ8L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJy
IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpFY3JpdCBtYWlsaW5nIGxpc3Q8YnIgY2xh
c3M9IiI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOkVjcml0QGlldGYub3JnIiBjbGFzcz0iIj5tYWls
dG86RWNyaXRAaWV0Zi5vcmc8L2E+Jmd0OzxhIGhyZWY9Im1haWx0bzpFY3JpdEBpZXRmLm9yZyIg
Y2xhc3M9IiI+RWNyaXRAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K
Jmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQi
IGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQ8L2E+
Jmd0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQi
IGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQ8L2E+
PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIi
Pg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS08YnIgY2xhc3M9IiI+DQpSYW5kYWxs
IEdlbGxlbnM8YnIgY2xhc3M9IiI+DQpPcGluaW9ucyBhcmUgcGVyc29uYWw7ICZuYnNwOyZuYnNw
OyZuYnNwO2ZhY3RzIGFyZSBzdXNwZWN0OyAmbmJzcDsmbmJzcDsmbmJzcDtJIHNwZWFrIGZvciBt
eXNlbGYgb25seTxiciBjbGFzcz0iIj4NCi0tLS0tLS0tLS0tLS0tIFJhbmRvbWx5IHNlbGVjdGVk
IHRhZzogLS0tLS0tLS0tLS0tLS0tPGJyIGNsYXNzPSIiPg0KU3BvdHRlZCBvbiB0aGUgYmFjayBv
ZiBhIHQtc2hpcnQgd29ybiBieSBMQVBEIEJvbWIgU3F1YWQ6PGJyIGNsYXNzPSIiPg0KJnF1b3Q7
SWYgeW91IHNlZSBtZSBydW5uaW5nLCB0cnkgdG8ga2VlcCB1cC4mcXVvdDs8YnIgY2xhc3M9IiI+
DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9
IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBj
bGFzcz0iIj4NCkVjcml0IG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0
bzpFY3JpdEBpZXRmLm9yZyIgY2xhc3M9IiI+RWNyaXRAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIi
Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdCIg
Y2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdDwvYT48
YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2
ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6
IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGlu
ZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt
aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3
aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo
OiAwcHg7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u
dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBm
b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDog
bm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw
eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0
bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNs
YXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy
cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0
OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9y
cGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy
YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNw
YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250
LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs
OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBh
dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06
IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw
cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6
IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+LS08L3NwYW4+PGJyIHN0eWxlPSJmb250LWZh
bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u
dC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu
b3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0
YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6
IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0
cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhl
bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu
dDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBs
aW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4
dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7
IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk
dGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9
IiI+UmFuZGFsbA0KIEdlbGxlbnM8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0
aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBu
b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUt
aGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu
ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk
b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog
MHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u
dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBm
b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDog
bm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw
eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0
bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxv
YXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+T3BpbmlvbnMN
CiBhcmUgcGVyc29uYWw7ICZuYnNwOyZuYnNwOyZuYnNwO2ZhY3RzIGFyZSBzdXNwZWN0OyAmbmJz
cDsmbmJzcDsmbmJzcDtJIHNwZWFrIGZvciBteXNlbGYgb25seTwvc3Bhbj48YnIgc3R5bGU9ImZv
bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs
OyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp
bmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGln
bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z
cGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl
eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12
YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt
YWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0
OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v
cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r
ZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBj
bGFzcz0iIj4tLS0tLS0tLS0tLS0tLQ0KIFJhbmRvbWx5IHNlbGVjdGVkIHRhZzogLS0tLS0tLS0t
LS0tLS0tPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl
OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdl
aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFs
OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4
dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y
ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIi
Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg
Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v
cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFu
czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm
b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu
ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNw
bGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPlNraXBwZXI6DQogJm5ic3A7Jm5ic3A7
TXIuIEhvd2VsbCwgWW91IGRvbid0IGtub3cgd2hhdCBpdCdzIGxpa2Ugb3V0IHRoZXJlIGluPC9z
cGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm
b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9y
bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5z
OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv
cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n
OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls
ZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0
dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsg
dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l
OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAt
d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxp
bmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3RoZQ0KIG9jZWFuLCB5b3UgbWF5IGJlIGJpdHRl
biBieSBhIHNoYXJrITwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv
bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsg
Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6
IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw
cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1
dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBj
bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6
IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2Vp
Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7
IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0
LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3Jk
LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9u
ZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5UaHVyc3RvbjoNCiAmbmJz
cDtBIHNoYXJrIGJpdGUgYSBIb3dlbGwsIGhhIGhhIGhlIHdvdWxkbid0IGRhcmUuPC9zcGFuPjxi
ciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0
eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs
ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRv
OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v
bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7
IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y
bWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw
YWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h
bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0
ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0
LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWlt
cG9ydGFudDsiIGNsYXNzPSIiPlNraXBwZXI6DQogJm5ic3A7Jm5ic3A7QmVzaWRlcyB3ZSBkb24n
dCBoYXZlIHJvb20gZW5vdWdoIGZvciB5b3VyIGx1Z2dhZ2UuPC9zcGFuPjxiciBzdHlsZT0iZm9u
dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7
IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu
Zzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu
OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw
YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4
dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh
cmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h
bDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7
IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y
bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl
LXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNs
YXNzPSIiPlRodXJzdG9uOg0KICZuYnNwO1dlbGwgdGhhdCdzIGRpZmZlcmVudC4gSWYgSSBjYW4n
dCBnbyBmaXJzdCBjbGFzcyBJIHdvbid0PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhl
bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu
dDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBs
aW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4
dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7
IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk
dGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7
IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1h
bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWln
aHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50
OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6
IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7
IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2dv
DQogYXQgYWxsLjwvc3Bhbj48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNz
PSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_D139C8D79789Fbrianrosenneustarbiz_--


From nobody Thu Mar 26 13:02:28 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8CC1AC417 for ; Thu, 26 Mar 2015 13:02:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.799
X-Spam-Level: 
X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, J_CHICKENPOX_65=0.6, SPF_PASS=-0.001] autolearn=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 CwtIu20hVfy8 for ; Thu, 26 Mar 2015 13:02:15 -0700 (PDT)
Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (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 94BD41B2E37 for ; Thu, 26 Mar 2015 13:02:06 -0700 (PDT)
Received: by pacwz10 with SMTP id wz10so21708866pac.2 for ; Thu, 26 Mar 2015 13:02:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=nG/t7Yg6lpCTMPCPRIod8F4awRWE3PMzpKT0a7gLxRQ=; b=WGyFh8AOfpQEYqtMAyprNOjAjlIKjXBr8V7e5Tc3m2M3BpzoD11B9VcNNKLsaGsFVe j/WOLV9/e3kAvg5e9gc5yEkBrolrGwlXgDQuCEYWHjtFN987YhdWGw7vl02ue49fi8Ij UiBqu9LT52HokPEo2IGkc2seTEI2JnOHVauQSgGAb7yIMmSd5OBw0fzq+iubcf31rWjn KIKWp9Ir9GtlFyp3fN6WlEEVTSCrY+bPgzf8iYQXhitedX6gQK3NFQ8Q3CpdVPIpt0mB +JMP3Up8r5PIEITP1lnMAc6/vtu0827iznM7IQn2mZvqCi+/TlfGd9Oywp+Kx69EtvSu WGGw==
X-Received: by 10.70.102.101 with SMTP id fn5mr29444027pdb.131.1427400126122;  Thu, 26 Mar 2015 13:02:06 -0700 (PDT)
Received: from [192.168.1.100] ([1.149.84.41]) by mx.google.com with ESMTPSA id su5sm6409090pbc.38.2015.03.26.13.02.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Mar 2015 13:02:05 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_7E2B3114-6D54-46AC-8A74-5EA2A42A179F"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: James Winterbottom 
In-Reply-To: 
Date: Fri, 27 Mar 2015 07:02:00 +1100
Message-Id: <9227FF13-3F48-44E3-A53E-68455DED2DD1@gmail.com>
References: <5F3DEAC5-1A13-45A3-B9C8-51579BAC22F9@gmail.com> <14546D76-AEF5-4C23-9BA0-00B6FA4C1E96@neustar.biz>    <75BAB4CE-E408-472D-80DD-569ADD918A8B@gmail.com>   <204B769A-295F-476E-8B36-8F428FD4EE67@gmail.com>   
To: "Rosen, Brian" 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: "ecrit@ietf.org" , Randall Gellens 
Subject: Re: [Ecrit] HELD Routing summary
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 20:02:21 -0000

--Apple-Mail=_7E2B3114-6D54-46AC-8A74-5EA2A42A179F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I still don=E2=80=99t want the extra stuff as I don=E2=80=99t see a need =
for it.

However, if we were to proceed down this path then:
This document now normatively updates RFC5222 so I don=E2=80=99t think =
that the language below is strong enough or clear enough that we are =
changing the meaning of source from RFC5222. This is because the HELD =
server may not generate the mapping data, it may simply supply it and a =
URI for how it obtained it may not exist.
The source in RFC5222 is not a URI, it is a LoST application unique =
string, I am not sure that making this a HELD application unique string =
makes sense, so this would require more thought, unless this is also =
part of the updating to RFC5222 which would also require schema change =
to support.

These were the problems I look at when I created the specification the =
way it is, which is why I didn=E2=80=99t use the mapping element. I just =
don=E2=80=99t think you can use words to explain away the issues and =
cram the mapping element in, you would need to redefine the mapping =
element and I see no value in that.

Cheers
James

> On 27 Mar 2015, at 6:44 am, Rosen, Brian  =
wrote:
>=20
> Replace the last two paragraphs of Section 4 with:
>=20
> The location response when the HELD sever supports this specification =
and routing is requested consists of the  element from RFC5222. =
 The =E2=80=9Csource=E2=80=9D element shall be the URI of the =
authoritative generator of the mapping data, which may be the HELD =
server=E2=80=99s URI.   All other elements of the  element are =
as they are described in RFC5222. =20
>=20
>=20
>=20
>=20
> If this language is acceptable, I=E2=80=99ll fix the schema in Section =
5 and the examples.
>=20
> Brian
>=20
> From: James Winterbottom >
> Date: Thursday, March 26, 2015 at 2:27 PM
> To: Randall Gellens >
> Cc: Brian Rosen >, "ecrit@ietf.org =
" >
> Subject: Re: [Ecrit] HELD Routing summary
>=20
> Thanks for talking the position as conciliator Randall.
>=20
>=20
>=20
>> On 27 Mar 2015, at 6:26 am, Randall Gellens > wrote:
>>=20
>> My impression is that people are talking past=20
>> each other, which is why I thought seeing the=20
>> proposal in the document would help clarify it.
>>=20
>> At 6:07 AM +1100 3/27/15, James Winterbottom wrote:
>>=20
>>> Randall,
>>>=20
>>> I don't agree with Brian's position on the=20
>>> Source, my reading of LoST is that this can't=20
>>> be the HELD server because it doesn't satisfy=20
>>> the description and requirements for the use of=20
>>> that field.
>>>=20
>>> But further to that, the three people in this=20
>>> group that requested this functionality don't=20
>>> see a need for this stuff. Indeed the only=20
>>> person arguing for it is Brian and he hasn't=20
>>> provided or demonstrated any need for it.=20
>>> Option 3 on that table allows it be added when=20
>>> needed which is the fastest and easiest=20
>>> approach.
>>>=20
>>>=20
>>> Cheers
>>> James
>>>=20
>>>> On 27 Mar 2015, at 4:10 am, Randall Gellens=20
>>>> <>randy@qti.qualcomm.com =
>=20
>>>> wrote:
>>>>=20
>>>> Brian,
>>>>=20
>>>> If it's only 10 minutes of editing, then maybe=20
>>>> you can revise either the XML (and update the=20
>>>> TXT) or the TXT and show what it would look=20
>>>> like in the document?  I think perhaps two=20
>>>> examples would also help: one where the source=20
>>>> is a local database and the other where the=20
>>>> source is a LoST server.  We'd then have a=20
>>>> concrete proposal in front of us and we could=20
>>>> ask if we have consensus to adopt it and move=20
>>>> forward.
>>>>=20
>>>> James, if Brian does this, can you then look=20
>>>> at the revisions and see if you still object=20
>>>> or if you can accept them?
>>>>=20
>>>> At 3:19 PM +0000 3/26/15, Brian Rosen wrote:
>>>>=20
>>>>> Come on, the mandatory elements are the=20
>>>>> source, lastUpdated and expires.  The source=20
>>>>> might be the HELD server, but it might be=20
>>>>> something else.  If it's the HELD server, say=20
>>>>> so.
>>>>> It is a trivial ask that you include source,=20
>>>>> lastUpdated and expires in the response,=20
>>>>> identical to LoST.  It provides a level of=20
>>>>> compatibility that is useful, and=20
>>>>> non-intrusive for implementations to=20
>>>>> accommodate.  It COULD be a fixed string.
>>>>>=20
>>>>> You think of implementations as the server=20
>>>>> has, internally, all the routing information.=20
>>>>> That's one way to do it.  Another way to do=20
>>>>> it is to have the HELD server consult a LoST=20
>>>>> server.  Yes, I know you don't think anyone=20
>>>>> will implement a LoST server.  I think you=20
>>>>> are wrong.
>>>>>=20
>>>>> I understand that I can incrementally add the=20
>>>>> mapping components as extensions in a way=20
>>>>> that is transformable to a "real" =20
>>>>> structure, but the bits on the wire are=20
>>>>> different.
>>>>> If you persist, and consensus is to have an=20
>>>>> extension point and no more, I'll submit the=20
>>>>> draft that does it right away.   Does that=20
>>>>> REALLY make any sense?
>>>>>=20
>>>>> Brian
>>>>>=20
>>>>>> On Mar 26, 2015, at 9:35 AM, James=20
>>>>>> Winterbottom=20
>>>>>> <<>mailto:a.james.winterbottom@gmail.=
com =
>>a.james.winterbottom@gmail.com =
>=20
>>>>>> wrote:
>>>>>>=20
>>>>>> HUH????
>>>>>>=20
>>>>>> As I have said before and as the draft=20
>>>>>> states, at least of the mandatory mapping=20
>>>>>> elements is not applicable where you don't=20
>>>>>> LoST, so simply resuming mapping doesn't=20
>>>>>> work.
>>>>>>=20
>>>>>> If we put the extension point in, and you=20
>>>>>> want to reuse mapping elements in your=20
>>>>>> implementation you can simply reference them=20
>>>>>> in the extension point, no specification=20
>>>>>> required and things that choose not to=20
>>>>>> understand the extension can ignore  them.=20
>>>>>> No extra specification required, no extra=20
>>>>>> work at all required in this specification,=20
>>>>>> not even 10 minutes editing and 4 years of=20
>>>>>> haggling.
>>>>>>=20
>>>>>> Cheers
>>>>>> James
>>>>>>=20
>>>>>>> On 27 Mar 2015, at 1:31 am, Rosen, Brian=20
>>>>>>> <<>mailto:Brian.Rosen@neustar.biz =
>>Brian.Rosen@neustar.biz =
>=20
>>>>>>> wrote:
>>>>>>>=20
>>>>>>> I don't understand any of this logic.
>>>>>>>=20
>>>>>>> You import the definition from RFC5222 and=20
>>>>>>> refer to it for the meaning of the=20
>>>>>>> elements.  Done.  No time delay.  10=20
>>>>>>> minutes of editing.
>>>>>>>=20
>>>>>>> I want to be able to build systems that=20
>>>>>>> work world-wide.  The more commonality of=20
>>>>>>> data structures, the better.
>>>>>>>=20
>>>>>>> You have not shown any harm to re-use of a=20
>>>>>>> data structure that was designed for the=20
>>>>>>> purpose you have, has had extensive IETF=20
>>>>>>> review, implementation, and consensus.  You=20
>>>>>>> want to invent something new.  It's clearly=20
>>>>>>> a subset, but it's not precisely a subset.=20
>>>>>>> That is not a good idea in my opinion.  As=20
>>>>>>> the majority of elements in  are=20
>>>>>>> optional, an implementation can choose=20
>>>>>>> never to send them (server) or ignore them=20
>>>>>>> if received (client).  If you use the=20
>>>>>>> extension point (3), and we later decide=20
>>>>>>> that most of  is in fact useful,=20
>>>>>>> we would end up different data structures,=20
>>>>>>> because the base structure is different.
>>>>>>>=20
>>>>>>> Brian
>>>>>>>=20
>>>>>>>> On Mar 26, 2015, at 8:22 AM, Laura Liess=20
>>>>>>>> <<>mailto:laura.liess.dt@googlemail.co=
m =
>>laura.liess.dt@googlemail.com =
>=20
>>>>>>>> wrote:
>>>>>>>>=20
>>>>>>>> I would prefer 3) and I can live with 2).
>>>>>>>>=20
>>>>>>>> I am oposed to 1) because it would delay=20
>>>>>>>> the draft progress, just to add features=20
>>>>>>>> about we don't know if anyone will need=20
>>>>>>>> them andif so,  what exactly will be=20
>>>>>>>> needed. For the work in ETSI on the EC=20
>>>>>>>> M493 this is clearly not needed. ETSI=20
>>>>>>>> needs the draft finished very soon, if we=20
>>>>>>>> want the final ETSI specification,=20
>>>>>>>> targeted for the end of this year, to=20
>>>>>>>> refer an RFC and not a draft and the=20
>>>>>>>> implementations which will come then soon,=20
>>>>>>>> to be based an RFC and not on some=20
>>>>>>>> intermediary version of the draft.
>>>>>>>>=20
>>>>>>>> I think 3) is a good solution, flexible=20
>>>>>>>> enough that everyone could live with it.
>>>>>>>>=20
>>>>>>>> Thank you
>>>>>>>>  Laura
>>>>>>>>=20
>>>>>>>> 2015-03-25 20:21 GMT+01:00 James=20
>>>>>>>> Winterbottom=20
>>>>>>>> <<>mailto:a.james.winterbottom@gmail.=
com =
>>a.james.winterbottom@gmail.com =
>:
>>>>>>>>=20
>>>>>>>> There is downside to using the existing=20
>>>>>>>> schema Brian, this is spelt out clearly in=20
>>>>>>>> the draft. In order to include the fields=20
>>>>>>>> you want a new element would need to be=20
>>>>>>>> defined in this draft to support it. I=20
>>>>>>>> think that that is the wrong way to do it=20
>>>>>>>> as there has been no expression of need.=20
>>>>>>>> If a need arrises after this draft is=20
>>>>>>>> done, then it can be added later. Right=20
>>>>>>>> now it isn't needed.
>>>>>>>>=20
>>>>>>>> As I said in my preference for option 3, I=20
>>>>>>>> think that the extension point should be=20
>>>>>>>> added then anything can be added later if=20
>>>>>>>> required.
>>>>>>>>=20
>>>>>>>> Cheers
>>>>>>>> James
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>> On 26 Mar 2015, at 2:52 am, Rosen, Brian=20
>>>>>>>>> <<>mailto:Brian.Rosen@neustar.biz =
>>Brian.Rosen@neustar.biz =
>=20
>>>>>>>>> wrote:
>>>>>>>>>=20
>>>>>>>>> Let's say that someone comes along and=20
>>>>>>>>> shows a decent use case for including a=20
>>>>>>>>> service boundary.
>>>>>>>>>=20
>>>>>>>>> So they define an extension for it.
>>>>>>>>>=20
>>>>>>>>> That extension may or may not be the same=20
>>>>>>>>> as the service boundary that LoST=20
>>>>>>>>> returns. An implementation designed to=20
>>>>>>>>> provide world-wide service would have to=20
>>>>>>>>> change.
>>>>>>>>>=20
>>>>>>>>> Returning the boundary is already optional in the LoST schema.
>>>>>>>>>=20
>>>>>>>>> If we used the existing definition:
>>>>>>>>> 1. No new document is required
>>>>>>>>> 2. Compatibility between this HELD extension and LoST is =
maintained
>>>>>>>>> 3. Systems built to support both models don't have to change
>>>>>>>>>=20
>>>>>>>>> There is, as far as I can see, no=20
>>>>>>>>> downside to using the existing schema=20
>>>>>>>>> other than making the smallest possible=20
>>>>>>>>> response a bit bigger.   One can always=20
>>>>>>>>> ignore any returned items not=20
>>>>>>>>> needed/wanted, and since they are=20
>>>>>>>>> optional they can't be assumed to be=20
>>>>>>>>> there.
>>>>>>>>>=20
>>>>>>>>> Option 2 (don't allow an extension point=20
>>>>>>>>> on the return) makes no sense to me.  I=20
>>>>>>>>> can't imagine the IETF doing that. Any=20
>>>>>>>>> extension would then require all existing=20
>>>>>>>>> implementations to be changed.
>>>>>>>>>=20
>>>>>>>>> Brian
>>>>>>>>>=20
>>>>>>>>>> On Mar 25, 2015, at 9:49 AM,=20
>>>>>>>>>> <>mailto:R.Jesske@telekom.de =
>>R.Jesske@telekom.de =
 wrote:
>>>>>>>>>>=20
>>>>>>>>>> Hi James,
>>>>>>>>>> thank you for the summary.
>>>>>>>>>> My position is reflected in point 2.
>>>>>>>>>>=20
>>>>>>>>>> If people want to add something to a=20
>>>>>>>>>> mechanism can it not be done only in=20
>>>>>>>>>> writing a further draft?
>>>>>>>>>> This means also including in such a draft also a extension =
mechanism.
>>>>>>>>>>=20
>>>>>>>>>> I think that would be a clear line to satisfy everybody.
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> Best Regards
>>>>>>>>>>=20
>>>>>>>>>> Roland
>>>>>>>>>>=20
>>>>>>>>>> -----Urspr=C3=BCngliche Nachricht-----
>>>>>>>>>> Von: Ecrit=20
>>>>>>>>>> [mailto:< >mailto:ecrit-bounces@ietf.org =
>>ecrit-bounces@ietf.org =
]=20
>>>>>>>>>> Im Auftrag von James Winterbottom
>>>>>>>>>> Gesendet: Mittwoch, 25. M=C3=A4rz 2015 09:03
>>>>>>>>>> An: <>http://ecrit_ietf.org/ =
>ecrit_ietf.org
>>>>>>>>>> Betreff: [Ecrit] HELD Routing summary
>>>>>>>>>>=20
>>>>>>>>>> Hi All,
>>>>>>>>>>=20
>>>>>>>>>> As I see it there is one open discussion=20
>>>>>>>>>> point and three positions on this point.
>>>>>>>>>> The discussion point is whether or not=20
>>>>>>>>>> all of the ancillary data that is=20
>>>>>>>>>> returned by a LoST findService request=20
>>>>>>>>>> should be included in the HELD routing=20
>>>>>>>>>> response or not.
>>>>>>>>>>=20
>>>>>>>>>> The three positions that have been=20
>>>>>>>>>> stated are (in no particular order):
>>>>>>>>>> 1) The definition for this information=20
>>>>>>>>>> should be included in the base=20
>>>>>>>>>> specification but is optional to send or=20
>>>>>>>>>> be acted on.
>>>>>>>>>> 2) Isn't required at all, let the current draft stand
>>>>>>>>>> 3) Add an extension point to the schema=20
>>>>>>>>>> in the draft so that the extra can be=20
>>>>>>>>>> specified in a different draft and added=20
>>>>>>>>>> by something requiring it.
>>>>>>>>>>=20
>>>>>>>>>> This email makes no claims to=20
>>>>>>>>>> preference, but just presents the=20
>>>>>>>>>> opinions that have been expressed.
>>>>>>>>>>=20
>>>>>>>>>> Cheers
>>>>>>>>>> James
>>>>>>>>>>=20
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Ecrit mailing list
>>>>>>>>>>=20
>>>>>>>>>> <>mailto:Ecrit@ietf.org =
>>Ecrit@ietf.org 
>>>>>>>>>>=20
>>>>>>>>>> <>https://www.ietf.org/mailman=
/listinfo/ecrit > =
>https://www.ietf.org/mailman=
/listinfo/ecrit 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Ecrit mailing list
>>>>>>>>>>=20
>>>>>>>>>> <>mailto:Ecrit@ietf.org =
>>Ecrit@ietf.org 
>>>>>>>>>>=20
>>>>>>>>>> <>https://www.ietf.org/mailman=
/listinfo/ecrit > =
>https://www.ietf.org/mailman=
/listinfo/ecrit 
>>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> Ecrit mailing list
>>>>>>>>=20
>>>>>>>> <>mailto:Ecrit@ietf.org =
>>Ecrit@ietf.org 
>>>>>>>>=20
>>>>>>>> <>https://www.ietf.org/mailman=
/listinfo/ecrit =
>>https://www.ietf.org/mailman=
/listinfo/ecrit 
>>>>>>>>=20
>>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> Ecrit mailing list
>>>>>>=20
>>>>>> <>mailto:Ecrit@ietf.org =
>>Ecrit@ietf.org 
>>>>>>=20
>>>>>> >https://www.ietf.org/mailman=
/listinfo/ecrit 
>>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> Ecrit mailing list
>>>>> >Ecrit@ietf.org =

>>>>>=20
>>>>> >https://www.ietf.org/mailman=
/listinfo/ecrit 
>>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> --
>>>> Randall Gellens
>>>> Opinions are personal;    facts are suspect;    I speak for myself =
only
>>>> -------------- Randomly selected tag: ---------------
>>>> Spotted on the back of a t-shirt worn by LAPD Bomb Squad:
>>>> "If you see me running, try to keep up."
>>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> Ecrit mailing list
>>> Ecrit@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/ecrit =

>>=20
>>=20
>>=20
>> --
>> Randall Gellens
>> Opinions are personal;    facts are suspect;    I speak for myself =
only
>> -------------- Randomly selected tag: ---------------
>> Skipper:   Mr. Howell, You don't know what it's like out there in
>>           the ocean, you may be bitten by a shark!
>> Thurston:  A shark bite a Howell, ha ha he wouldn't dare.
>> Skipper:   Besides we don't have room enough for your luggage.
>> Thurston:  Well that's different. If I can't go first class I won't
>>           go at all.
>=20


--Apple-Mail=_7E2B3114-6D54-46AC-8A74-5EA2A42A179F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


I still don=E2=80=99t want the extra stuff as =
I don=E2=80=99t see a need for it.

However, if we were to proceed down =
this path then:
This document now normatively =
updates RFC5222 so I don=E2=80=99t think that the language below is =
strong enough or clear enough that we are changing the meaning of source =
from RFC5222. This is because the HELD server may not generate the =
mapping data, it may simply supply it and a URI for how it obtained it =
may not exist.
The source in RFC5222 is not a URI, =
it is a LoST application unique string, I am not sure that making this a =
HELD application unique string makes sense, so this would require more =
thought, unless this is also part of the updating to RFC5222 which would =
also require schema change to support.

These were the problems I look at when =
I created the specification the way it is, which is why I didn=E2=80=99t =
use the mapping element. I just don=E2=80=99t think you can use words to =
explain away the issues and cram the mapping element in, you would need =
to redefine the mapping element and I see no value in that.

Cheers
James

On 27 Mar 2015, at 6:44 am, Rosen, Brian =
<Brian.Rosen@neustar.biz> wrote:








Replace the last two paragraphs of Section 4 with:







The location response when the HELD sever supports this =
specification and routing is requested consists of the <mapping> =
element from RFC5222.  The =E2=80=9Csource=E2=80=9D element shall =
be the URI of the authoritative generator of the mapping data, which may =
be the HELD
 server=E2=80=99s URI.   All other elements of the <mapping> =
element are as they are described in RFC5222.  






















If this language is acceptable, I=E2=80=99ll fix the =
schema in Section 5 and the examples.







Brian









From: James =
Winterbottom <a.james.winterbottom@gmail.com>

Date: Thursday, March =
26, 2015 at 2:27 PM

To: Randall Gellens =
<rg+ietf@qti.qualcomm.com>

Cc: Brian Rosen =
<brian.rosen@neustar.biz>, "ecrit@ietf.org" <ecrit@ietf.org>

Subject: Re: [Ecrit] =
HELD Routing summary












Thanks for talking the position as conciliator Randall.


















On 27 Mar 2015, at 6:26 am, Randall Gellens <rg+ietf@qti.qualcomm.com> wrote:




My
 impression is that people are talking past 

each
 other, which is why I thought seeing the 

proposal
 in the document would help clarify it.



At
 6:07 AM +1100 3/27/15, James Winterbottom wrote:





Randall,



I don't agree with Brian's position on the 

Source, my reading of LoST is that this can't 

be the HELD server because it doesn't satisfy 

the description and requirements for the use of 

that field.



But further to that, the three people in this 

group that requested this functionality don't 

see a need for this stuff. Indeed the only 

person arguing for it is Brian and he hasn't 

provided or demonstrated any need for it. 

Option 3 on that table allows it be added when 

needed which is the fastest and easiest 

approach.





Cheers

James




On 27 Mar 2015, at 4:10 am, Randall =
Gellens 

<<mailto:randy@qti.qualcomm.com>randy@qti.qualcomm.com> 

wrote:



Brian,



If it's only 10 minutes of editing, then maybe 

you can revise either the XML (and update the 

TXT) or the TXT and show what it would look 

like in the document?  I think perhaps two 

examples would also help: one where the source 

is a local database and the other where the 

source is a LoST server.  We'd then have a 

concrete proposal in front of us and we could 

ask if we have consensus to adopt it and move 

forward.



James, if Brian does this, can you then look 

at the revisions and see if you still object 

or if you can accept them?



At 3:19 PM +0000 3/26/15, Brian Rosen wrote:




Come on, the mandatory elements are =
the 

source, lastUpdated and expires.  The source 

might be the HELD server, but it might be 

something else.  If it's the HELD server, say 

so.

It is a trivial ask that you include source, 

lastUpdated and expires in the response, 

identical to LoST.  It provides a level of 

compatibility that is useful, and 

non-intrusive for implementations to 

accommodate.  It COULD be a fixed string.



You think of implementations as the server 

has, internally, all the routing information. 

That's one way to do it.  Another way to do 

it is to have the HELD server consult a LoST 

server.  Yes, I know you don't think anyone 

will implement a LoST server.  I think you 

are wrong.



I understand that I can incrementally add the 

mapping components as extensions in a way 

that is transformable to a "real" <mapping> 

structure, but the bits on the wire are 

different.

If you persist, and consensus is to have an 

extension point and no more, I'll submit the 

draft that does it right away.   Does that 

REALLY make any sense?



Brian




On Mar 26, 2015, at 9:35 AM, =
James 

Winterbottom 

<<<mailto:a.james.winterbottom@gmail.com>mailto:a.james.winterbottom@gmail.com><mailto:a.james.winterbottom@gmail.com>a.james.winterbottom@gmail.com> 

wrote:



HUH????



As I have said before and as the draft 

states, at least of the mandatory mapping 

elements is not applicable where you don't 

LoST, so simply resuming mapping doesn't 

work.



If we put the extension point in, and you 

want to reuse mapping elements in your 

implementation you can simply reference them 

in the extension point, no specification 

required and things that choose not to 

understand the extension can ignore  them. 

No extra specification required, no extra 

work at all required in this specification, 

not even 10 minutes editing and 4 years of 

haggling.



Cheers

James




On 27 Mar 2015, at 1:31 am, Rosen, =
Brian 

<<<mailto:Brian.Rosen@neustar.biz>mailto:Brian.Rosen@neustar.biz><mailto:Brian.Rosen@neustar.biz>Brian.Rosen@neustar.biz> 

wrote:



I don't understand any of this logic.



You import the definition from RFC5222 and 

refer to it for the meaning of the 

elements.  Done.  No time delay.  10 

minutes of editing.



I want to be able to build systems that 

work world-wide.  The more commonality of 

data structures, the better.



You have not shown any harm to re-use of a 

data structure that was designed for the 

purpose you have, has had extensive IETF 

review, implementation, and consensus.  You 

want to invent something new.  It's clearly 

a subset, but it's not precisely a subset. 

That is not a good idea in my opinion.  As 

the majority of elements in <mapping> are 

optional, an implementation can choose 

never to send them (server) or ignore them 

if received (client).  If you use the 

extension point (3), and we later decide 

that most of <mapping> is in fact useful, 

we would end up different data structures, 

because the base structure is different.



Brian




On Mar 26, 2015, at 8:22 AM, Laura =
Liess 

<<<mailto:laura.liess.dt@googlemail.com>mailto:laura.liess.dt@googlemail.com><mailto:laura.liess.dt@googlemail.com>laura.liess.dt@googlemail.com> 

wrote:



I would prefer 3) and I can live with 2).



I am oposed to 1) because it would delay 

the draft progress, just to add features 

about we don't know if anyone will need 

them andif so,  what exactly will be 

needed. For the work in ETSI on the EC 

M493 this is clearly not needed. ETSI 

needs the draft finished very soon, if we 

want the final ETSI specification, 

targeted for the end of this year, to 

refer an RFC and not a draft and the 

implementations which will come then soon, 

to be based an RFC and not on some 

intermediary version of the draft.



I think 3) is a good solution, flexible 

enough that everyone could live with it.



Thank you

 Laura



2015-03-25 20:21 GMT+01:00 James 

Winterbottom 

<<<mailto:a.james.winterbottom@gmail.com>mailto:a.james.winterbottom@gmail.com><mailto:a.james.winterbottom@gmail.com>a.james.winterbottom@gmail.com>:



There is downside to using the existing 

schema Brian, this is spelt out clearly in 

the draft. In order to include the fields 

you want a new element would need to be 

defined in this draft to support it. I 

think that that is the wrong way to do it 

as there has been no expression of need. 

If a need arrises after this draft is 

done, then it can be added later. Right 

now it isn't needed.



As I said in my preference for option 3, I 

think that the extension point should be 

added then anything can be added later if 

required.



Cheers

James






On 26 Mar 2015, at 2:52 am, Rosen, =
Brian 

<<<mailto:Brian.Rosen@neustar.biz>mailto:Brian.Rosen@neustar.biz><mailto:Brian.Rosen@neustar.biz>Brian.Rosen@neustar.biz> 

wrote:



Let's say that someone comes along and 

shows a decent use case for including a 

service boundary.



So they define an extension for it.



That extension may or may not be the same 

as the service boundary that LoST 

returns. An implementation designed to 

provide world-wide service would have to 

change.



Returning the boundary is already optional in the LoST schema.



If we used the existing definition:

1. No new document is required

2. Compatibility between this HELD extension and LoST is maintained

3. Systems built to support both models don't have to change



There is, as far as I can see, no 

downside to using the existing schema 

other than making the smallest possible 

response a bit bigger.   One can always 

ignore any returned items not 

needed/wanted, and since they are 

optional they can't be assumed to be 

there.



Option 2 (don't allow an extension point 

on the return) makes no sense to me.  I 

can't imagine the IETF doing that. Any 

extension would then require all existing 

implementations to be changed.



Brian




On Mar 25, 2015, at 9:49 AM, 

<<mailto:R.Jesske@telekom.de>mailto:R.Jesske@telekom.de><mailto:R.Jesske@telekom.de>R.Jesske@telekom.de wrote:



Hi James,

thank you for the summary.

My position is reflected in point 2.



If people want to add something to a 

mechanism can it not be done only in 

writing a further draft?

This means also including in such a draft also a extension mechanism.



I think that would be a clear line to satisfy everybody.





Best Regards



Roland



-----Urspr=C3=BCngliche Nachricht-----

Von: Ecrit 

[mailto:<<mailto:ecrit-bounces@ietf.org>mailto:ecrit-bounces@ietf.org><mailto:ecrit-bounces@ietf.org>ecrit-bounces@ietf.org] 

Im Auftrag von James Winterbottom

Gesendet: Mittwoch, 25. M=C3=A4rz 2015 09:03

An: <<http://ecrit_ietf.org/>http://ecrit_ietf.org/>ecrit_ietf.org

Betreff: [Ecrit] HELD Routing summary



Hi All,



As I see it there is one open discussion 

point and three positions on this point.

The discussion point is whether or not 

all of the ancillary data that is 

returned by a LoST findService request 

should be included in the HELD routing 

response or not.



The three positions that have been 

stated are (in no particular order):

1) The definition for this information 

should be included in the base 

specification but is optional to send or 

be acted on.

2) Isn't required at all, let the current draft stand

3) Add an extension point to the schema 

in the draft so that the extra can be 

specified in a different draft and added 

by something requiring it.



This email makes no claims to 

preference, but just presents the 

opinions that have been expressed.



Cheers

James



_______________________________________________

Ecrit mailing list



<<mailto:Ecrit@ietf.org>mailto:Ecrit@ietf.org><mailto:Ecrit@ietf.org>Ecrit@ietf.org



<<https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit> <https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________

Ecrit mailing list



<<mailto:Ecrit@ietf.org>mailto:Ecrit@ietf.org><mailto:Ecrit@ietf.org>Ecrit@ietf.org



<<https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit> <https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit











_______________________________________________

Ecrit mailing list



<<mailto:Ecrit@ietf.org>mailto:Ecrit@ietf.org><mailto:Ecrit@ietf.org>Ecrit@ietf.org



<<https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit><https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit











_______________________________________________

Ecrit mailing list



<<mailto:Ecrit@ietf.org>mailto:Ecrit@ietf.org><mailto:Ecrit@ietf.org>Ecrit@ietf.org



<https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit









_______________________________________________

Ecrit mailing list

<mailto:Ecrit@ietf.org>Ecrit@ietf.org



<https://www.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit











--

Randall Gellens

Opinions are personal;    facts are suspect; =
   I speak for myself only

-------------- Randomly selected tag: ---------------

Spotted on the back of a t-shirt worn by LAPD Bomb Squad:

"If you see me running, try to keep up."









_______________________________________________

Ecrit mailing list

Ecrit@ietf.org

https://www.ietf.org/mailman/listinfo/ecrit









--

Randall
 Gellens

Opinions
 are personal;    facts are suspect;    I =
speak for myself only

--------------
 Randomly selected tag: ---------------

Skipper:
   Mr. Howell, You don't know what it's like out there =
in

          the=

 ocean, you may be bitten by a shark!

Thurston:
  A shark bite a Howell, ha ha he wouldn't dare.

Skipper:
   Besides we don't have room enough for your =
luggage.

Thurston:
  Well that's different. If I can't go first class I =
won't

          go
 at all.



















=

--Apple-Mail=_7E2B3114-6D54-46AC-8A74-5EA2A42A179F--


From nobody Thu Mar 26 14:44:50 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C511B2F75 for ; Thu, 26 Mar 2015 14:44:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.859
X-Spam-Level: 
X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 gBNlCGeD247Z for ; Thu, 26 Mar 2015 14:44:43 -0700 (PDT)
Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21B5E1B2F63 for ; Thu, 26 Mar 2015 14:44:40 -0700 (PDT)
Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by tcmail41.telekom.de with ESMTP; 26 Mar 2015 22:44:38 +0100
X-IronPort-AV: E=Sophos;i="5.11,475,1422918000";  d="scan'208,217";a="793528297"
Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES128-SHA; 26 Mar 2015 22:44:38 +0100
Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 26 Mar 2015 22:44:37 +0100
From: 
To: , 
Date: Thu, 26 Mar 2015 22:44:29 +0100
Thread-Topic: [Ecrit] HELD Routing summary
Thread-Index: AdBn/81NoPdsvhV5QZGIBdvIzYBCFQADd/0Q
Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01E9E52D8834@HE113667.emea1.cds.t-internal.com>
References: <5F3DEAC5-1A13-45A3-B9C8-51579BAC22F9@gmail.com> <14546D76-AEF5-4C23-9BA0-00B6FA4C1E96@neustar.biz>    <75BAB4CE-E408-472D-80DD-569ADD918A8B@gmail.com>   <204B769A-295F-476E-8B36-8F428FD4EE67@gmail.com>    <9227FF13-3F48-44E3-A53E-68455DED2DD1@gmail.com>
In-Reply-To: <9227FF13-3F48-44E3-A53E-68455DED2DD1@gmail.com>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE
Content-Type: multipart/alternative; boundary="_000_058CE00BD4D6B94FAD033A2439EA1E4B01E9E52D8834HE113667eme_"
MIME-Version: 1.0
Archived-At: 
Cc: ecrit@ietf.org, rg+ietf@qti.qualcomm.com
Subject: Re: [Ecrit] HELD Routing summary
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 21:44:49 -0000

--_000_058CE00BD4D6B94FAD033A2439EA1E4B01E9E52D8834HE113667eme_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQpGb3IgbWUgaXQgbG9va3MgbGlrZSBtb3JlIGNvbmZ1c2luZyB0aGFuIG9ubHkgdG8gYXBwbHkg
dG8gT1BUSU9OIDMuDQpUaHVzIEnigJltIHN0aWxsIGluIGZhdm9yIGZvciBPcHRpb24gMyB3aGlj
aCBuZWVkIG9ubHkgYSBzbWFsbCBjaGFuZ2UuDQpBbmQgSSB0aGluayB0aGUgcmVxdWlyZW1lbnQg
Zm9yIGV4dGVuc2liaWxpdHkgYXMgZGlzY3Vzc2VkIGluIHRoZSBtZWV0aW5nIGlzIGZ1bGZpbGxl
ZC4NCg0KSW4gc2hvcnQgSSBzdXBwb3J0IG5vdyBPUFRJT04gMyBhcyBKYW1lcyBwcm9wb3NlZC4N
Cg0KVGhhbmsgeW91IGFuZCBCZXN0IFJlZ2FyZHMNCg0KUm9sYW5kDQoNClZvbjogRWNyaXQgW21h
aWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXSBJbSBBdWZ0cmFnIHZvbiBKYW1lcyBXaW50ZXJi
b3R0b20NCkdlc2VuZGV0OiBEb25uZXJzdGFnLCAyNi4gTcOkcnogMjAxNSAyMTowMg0KQW46IFJv
c2VuLCBCcmlhbg0KQ2M6IGVjcml0QGlldGYub3JnOyBSYW5kYWxsIEdlbGxlbnMNCkJldHJlZmY6
IFJlOiBbRWNyaXRdIEhFTEQgUm91dGluZyBzdW1tYXJ5DQoNCkkgc3RpbGwgZG9u4oCZdCB3YW50
IHRoZSBleHRyYSBzdHVmZiBhcyBJIGRvbuKAmXQgc2VlIGEgbmVlZCBmb3IgaXQuDQoNCkhvd2V2
ZXIsIGlmIHdlIHdlcmUgdG8gcHJvY2VlZCBkb3duIHRoaXMgcGF0aCB0aGVuOg0KVGhpcyBkb2N1
bWVudCBub3cgbm9ybWF0aXZlbHkgdXBkYXRlcyBSRkM1MjIyIHNvIEkgZG9u4oCZdCB0aGluayB0
aGF0IHRoZSBsYW5ndWFnZSBiZWxvdyBpcyBzdHJvbmcgZW5vdWdoIG9yIGNsZWFyIGVub3VnaCB0
aGF0IHdlIGFyZSBjaGFuZ2luZyB0aGUgbWVhbmluZyBvZiBzb3VyY2UgZnJvbSBSRkM1MjIyLiBU
aGlzIGlzIGJlY2F1c2UgdGhlIEhFTEQgc2VydmVyIG1heSBub3QgZ2VuZXJhdGUgdGhlIG1hcHBp
bmcgZGF0YSwgaXQgbWF5IHNpbXBseSBzdXBwbHkgaXQgYW5kIGEgVVJJIGZvciBob3cgaXQgb2J0
YWluZWQgaXQgbWF5IG5vdCBleGlzdC4NClRoZSBzb3VyY2UgaW4gUkZDNTIyMiBpcyBub3QgYSBV
UkksIGl0IGlzIGEgTG9TVCBhcHBsaWNhdGlvbiB1bmlxdWUgc3RyaW5nLCBJIGFtIG5vdCBzdXJl
IHRoYXQgbWFraW5nIHRoaXMgYSBIRUxEIGFwcGxpY2F0aW9uIHVuaXF1ZSBzdHJpbmcgbWFrZXMg
c2Vuc2UsIHNvIHRoaXMgd291bGQgcmVxdWlyZSBtb3JlIHRob3VnaHQsIHVubGVzcyB0aGlzIGlz
IGFsc28gcGFydCBvZiB0aGUgdXBkYXRpbmcgdG8gUkZDNTIyMiB3aGljaCB3b3VsZCBhbHNvIHJl
cXVpcmUgc2NoZW1hIGNoYW5nZSB0byBzdXBwb3J0Lg0KDQpUaGVzZSB3ZXJlIHRoZSBwcm9ibGVt
cyBJIGxvb2sgYXQgd2hlbiBJIGNyZWF0ZWQgdGhlIHNwZWNpZmljYXRpb24gdGhlIHdheSBpdCBp
cywgd2hpY2ggaXMgd2h5IEkgZGlkbuKAmXQgdXNlIHRoZSBtYXBwaW5nIGVsZW1lbnQuIEkganVz
dCBkb27igJl0IHRoaW5rIHlvdSBjYW4gdXNlIHdvcmRzIHRvIGV4cGxhaW4gYXdheSB0aGUgaXNz
dWVzIGFuZCBjcmFtIHRoZSBtYXBwaW5nIGVsZW1lbnQgaW4sIHlvdSB3b3VsZCBuZWVkIHRvIHJl
ZGVmaW5lIHRoZSBtYXBwaW5nIGVsZW1lbnQgYW5kIEkgc2VlIG5vIHZhbHVlIGluIHRoYXQuDQoN
CkNoZWVycw0KSmFtZXMNCg0KT24gMjcgTWFyIDIwMTUsIGF0IDY6NDQgYW0sIFJvc2VuLCBCcmlh
biA8QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo8bWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6
Pj4gd3JvdGU6DQoNClJlcGxhY2UgdGhlIGxhc3QgdHdvIHBhcmFncmFwaHMgb2YgU2VjdGlvbiA0
IHdpdGg6DQoNClRoZSBsb2NhdGlvbiByZXNwb25zZSB3aGVuIHRoZSBIRUxEIHNldmVyIHN1cHBv
cnRzIHRoaXMgc3BlY2lmaWNhdGlvbiBhbmQgcm91dGluZyBpcyByZXF1ZXN0ZWQgY29uc2lzdHMg
b2YgdGhlIDxtYXBwaW5nPiBlbGVtZW50IGZyb20gUkZDNTIyMi4gIFRoZSDigJxzb3VyY2XigJ0g
ZWxlbWVudCBzaGFsbCBiZSB0aGUgVVJJIG9mIHRoZSBhdXRob3JpdGF0aXZlIGdlbmVyYXRvciBv
ZiB0aGUgbWFwcGluZyBkYXRhLCB3aGljaCBtYXkgYmUgdGhlIEhFTEQgc2VydmVy4oCZcyBVUkku
ICAgQWxsIG90aGVyIGVsZW1lbnRzIG9mIHRoZSA8bWFwcGluZz4gZWxlbWVudCBhcmUgYXMgdGhl
eSBhcmUgZGVzY3JpYmVkIGluIFJGQzUyMjIuDQoNCg0KDQoNCklmIHRoaXMgbGFuZ3VhZ2UgaXMg
YWNjZXB0YWJsZSwgSeKAmWxsIGZpeCB0aGUgc2NoZW1hIGluIFNlY3Rpb24gNSBhbmQgdGhlIGV4
YW1wbGVzLg0KDQpCcmlhbg0KDQpGcm9tOiBKYW1lcyBXaW50ZXJib3R0b20gPGEuamFtZXMud2lu
dGVyYm90dG9tQGdtYWlsLmNvbTxtYWlsdG86YS5qYW1lcy53aW50ZXJib3R0b21AZ21haWwuY29t
Pj4NCkRhdGU6IFRodXJzZGF5LCBNYXJjaCAyNiwgMjAxNSBhdCAyOjI3IFBNDQpUbzogUmFuZGFs
bCBHZWxsZW5zIDxyZytpZXRmQHF0aS5xdWFsY29tbS5jb208bWFpbHRvOnJnK2lldGZAcXRpLnF1
YWxjb21tLmNvbT4+DQpDYzogQnJpYW4gUm9zZW4gPGJyaWFuLnJvc2VuQG5ldXN0YXIuYml6PG1h
aWx0bzpicmlhbi5yb3NlbkBuZXVzdGFyLmJpej4+LCAiZWNyaXRAaWV0Zi5vcmc8bWFpbHRvOmVj
cml0QGlldGYub3JnPiIgPGVjcml0QGlldGYub3JnPG1haWx0bzplY3JpdEBpZXRmLm9yZz4+DQpT
dWJqZWN0OiBSZTogW0Vjcml0XSBIRUxEIFJvdXRpbmcgc3VtbWFyeQ0KDQpUaGFua3MgZm9yIHRh
bGtpbmcgdGhlIHBvc2l0aW9uIGFzIGNvbmNpbGlhdG9yIFJhbmRhbGwuDQoNCg0KDQpPbiAyNyBN
YXIgMjAxNSwgYXQgNjoyNiBhbSwgUmFuZGFsbCBHZWxsZW5zIDxyZytpZXRmQHF0aS5xdWFsY29t
bS5jb208bWFpbHRvOnJnK2lldGZAcXRpLnF1YWxjb21tLmNvbT4+IHdyb3RlOg0KDQpNeSBpbXBy
ZXNzaW9uIGlzIHRoYXQgcGVvcGxlIGFyZSB0YWxraW5nIHBhc3QNCmVhY2ggb3RoZXIsIHdoaWNo
IGlzIHdoeSBJIHRob3VnaHQgc2VlaW5nIHRoZQ0KcHJvcG9zYWwgaW4gdGhlIGRvY3VtZW50IHdv
dWxkIGhlbHAgY2xhcmlmeSBpdC4NCg0KQXQgNjowNyBBTSArMTEwMCAzLzI3LzE1LCBKYW1lcyBX
aW50ZXJib3R0b20gd3JvdGU6DQoNCg0KUmFuZGFsbCwNCg0KSSBkb24ndCBhZ3JlZSB3aXRoIEJy
aWFuJ3MgcG9zaXRpb24gb24gdGhlDQpTb3VyY2UsIG15IHJlYWRpbmcgb2YgTG9TVCBpcyB0aGF0
IHRoaXMgY2FuJ3QNCmJlIHRoZSBIRUxEIHNlcnZlciBiZWNhdXNlIGl0IGRvZXNuJ3Qgc2F0aXNm
eQ0KdGhlIGRlc2NyaXB0aW9uIGFuZCByZXF1aXJlbWVudHMgZm9yIHRoZSB1c2Ugb2YNCnRoYXQg
ZmllbGQuDQoNCkJ1dCBmdXJ0aGVyIHRvIHRoYXQsIHRoZSB0aHJlZSBwZW9wbGUgaW4gdGhpcw0K
Z3JvdXAgdGhhdCByZXF1ZXN0ZWQgdGhpcyBmdW5jdGlvbmFsaXR5IGRvbid0DQpzZWUgYSBuZWVk
IGZvciB0aGlzIHN0dWZmLiBJbmRlZWQgdGhlIG9ubHkNCnBlcnNvbiBhcmd1aW5nIGZvciBpdCBp
cyBCcmlhbiBhbmQgaGUgaGFzbid0DQpwcm92aWRlZCBvciBkZW1vbnN0cmF0ZWQgYW55IG5lZWQg
Zm9yIGl0Lg0KT3B0aW9uIDMgb24gdGhhdCB0YWJsZSBhbGxvd3MgaXQgYmUgYWRkZWQgd2hlbg0K
bmVlZGVkIHdoaWNoIGlzIHRoZSBmYXN0ZXN0IGFuZCBlYXNpZXN0DQphcHByb2FjaC4NCg0KDQpD
aGVlcnMNCkphbWVzDQoNCg0KT24gMjcgTWFyIDIwMTUsIGF0IDQ6MTAgYW0sIFJhbmRhbGwgR2Vs
bGVucw0KPDxtYWlsdG86cmFuZHlAcXRpLnF1YWxjb21tLmNvbT5yYW5keUBxdGkucXVhbGNvbW0u
Y29tPG1haWx0bzpyYW5keUBxdGkucXVhbGNvbW0uY29tPj4NCndyb3RlOg0KDQpCcmlhbiwNCg0K
SWYgaXQncyBvbmx5IDEwIG1pbnV0ZXMgb2YgZWRpdGluZywgdGhlbiBtYXliZQ0KeW91IGNhbiBy
ZXZpc2UgZWl0aGVyIHRoZSBYTUwgKGFuZCB1cGRhdGUgdGhlDQpUWFQpIG9yIHRoZSBUWFQgYW5k
IHNob3cgd2hhdCBpdCB3b3VsZCBsb29rDQpsaWtlIGluIHRoZSBkb2N1bWVudD8gIEkgdGhpbmsg
cGVyaGFwcyB0d28NCmV4YW1wbGVzIHdvdWxkIGFsc28gaGVscDogb25lIHdoZXJlIHRoZSBzb3Vy
Y2UNCmlzIGEgbG9jYWwgZGF0YWJhc2UgYW5kIHRoZSBvdGhlciB3aGVyZSB0aGUNCnNvdXJjZSBp
cyBhIExvU1Qgc2VydmVyLiAgV2UnZCB0aGVuIGhhdmUgYQ0KY29uY3JldGUgcHJvcG9zYWwgaW4g
ZnJvbnQgb2YgdXMgYW5kIHdlIGNvdWxkDQphc2sgaWYgd2UgaGF2ZSBjb25zZW5zdXMgdG8gYWRv
cHQgaXQgYW5kIG1vdmUNCmZvcndhcmQuDQoNCkphbWVzLCBpZiBCcmlhbiBkb2VzIHRoaXMsIGNh
biB5b3UgdGhlbiBsb29rDQphdCB0aGUgcmV2aXNpb25zIGFuZCBzZWUgaWYgeW91IHN0aWxsIG9i
amVjdA0Kb3IgaWYgeW91IGNhbiBhY2NlcHQgdGhlbT8NCg0KQXQgMzoxOSBQTSArMDAwMCAzLzI2
LzE1LCBCcmlhbiBSb3NlbiB3cm90ZToNCg0KDQpDb21lIG9uLCB0aGUgbWFuZGF0b3J5IGVsZW1l
bnRzIGFyZSB0aGUNCnNvdXJjZSwgbGFzdFVwZGF0ZWQgYW5kIGV4cGlyZXMuICBUaGUgc291cmNl
DQptaWdodCBiZSB0aGUgSEVMRCBzZXJ2ZXIsIGJ1dCBpdCBtaWdodCBiZQ0Kc29tZXRoaW5nIGVs
c2UuICBJZiBpdCdzIHRoZSBIRUxEIHNlcnZlciwgc2F5DQpzby4NCkl0IGlzIGEgdHJpdmlhbCBh
c2sgdGhhdCB5b3UgaW5jbHVkZSBzb3VyY2UsDQpsYXN0VXBkYXRlZCBhbmQgZXhwaXJlcyBpbiB0
aGUgcmVzcG9uc2UsDQppZGVudGljYWwgdG8gTG9TVC4gIEl0IHByb3ZpZGVzIGEgbGV2ZWwgb2YN
CmNvbXBhdGliaWxpdHkgdGhhdCBpcyB1c2VmdWwsIGFuZA0Kbm9uLWludHJ1c2l2ZSBmb3IgaW1w
bGVtZW50YXRpb25zIHRvDQphY2NvbW1vZGF0ZS4gIEl0IENPVUxEIGJlIGEgZml4ZWQgc3RyaW5n
Lg0KDQpZb3UgdGhpbmsgb2YgaW1wbGVtZW50YXRpb25zIGFzIHRoZSBzZXJ2ZXINCmhhcywgaW50
ZXJuYWxseSwgYWxsIHRoZSByb3V0aW5nIGluZm9ybWF0aW9uLg0KVGhhdCdzIG9uZSB3YXkgdG8g
ZG8gaXQuICBBbm90aGVyIHdheSB0byBkbw0KaXQgaXMgdG8gaGF2ZSB0aGUgSEVMRCBzZXJ2ZXIg
Y29uc3VsdCBhIExvU1QNCnNlcnZlci4gIFllcywgSSBrbm93IHlvdSBkb24ndCB0aGluayBhbnlv
bmUNCndpbGwgaW1wbGVtZW50IGEgTG9TVCBzZXJ2ZXIuICBJIHRoaW5rIHlvdQ0KYXJlIHdyb25n
Lg0KDQpJIHVuZGVyc3RhbmQgdGhhdCBJIGNhbiBpbmNyZW1lbnRhbGx5IGFkZCB0aGUNCm1hcHBp
bmcgY29tcG9uZW50cyBhcyBleHRlbnNpb25zIGluIGEgd2F5DQp0aGF0IGlzIHRyYW5zZm9ybWFi
bGUgdG8gYSAicmVhbCIgPG1hcHBpbmc+DQpzdHJ1Y3R1cmUsIGJ1dCB0aGUgYml0cyBvbiB0aGUg
d2lyZSBhcmUNCmRpZmZlcmVudC4NCklmIHlvdSBwZXJzaXN0LCBhbmQgY29uc2Vuc3VzIGlzIHRv
IGhhdmUgYW4NCmV4dGVuc2lvbiBwb2ludCBhbmQgbm8gbW9yZSwgSSdsbCBzdWJtaXQgdGhlDQpk
cmFmdCB0aGF0IGRvZXMgaXQgcmlnaHQgYXdheS4gICBEb2VzIHRoYXQNClJFQUxMWSBtYWtlIGFu
eSBzZW5zZT8NCg0KQnJpYW4NCg0KDQpPbiBNYXIgMjYsIDIwMTUsIGF0IDk6MzUgQU0sIEphbWVz
DQpXaW50ZXJib3R0b20NCjw8PG1haWx0bzphLmphbWVzLndpbnRlcmJvdHRvbUBnbWFpbC5jb20+
bWFpbHRvOmEuamFtZXMud2ludGVyYm90dG9tQGdtYWlsLmNvbT48bWFpbHRvOmEuamFtZXMud2lu
dGVyYm90dG9tQGdtYWlsLmNvbT5hLmphbWVzLndpbnRlcmJvdHRvbUBnbWFpbC5jb208bWFpbHRv
OmEuamFtZXMud2ludGVyYm90dG9tQGdtYWlsLmNvbT4+DQp3cm90ZToNCg0KSFVIPz8/Pw0KDQpB
cyBJIGhhdmUgc2FpZCBiZWZvcmUgYW5kIGFzIHRoZSBkcmFmdA0Kc3RhdGVzLCBhdCBsZWFzdCBv
ZiB0aGUgbWFuZGF0b3J5IG1hcHBpbmcNCmVsZW1lbnRzIGlzIG5vdCBhcHBsaWNhYmxlIHdoZXJl
IHlvdSBkb24ndA0KTG9TVCwgc28gc2ltcGx5IHJlc3VtaW5nIG1hcHBpbmcgZG9lc24ndA0Kd29y
ay4NCg0KSWYgd2UgcHV0IHRoZSBleHRlbnNpb24gcG9pbnQgaW4sIGFuZCB5b3UNCndhbnQgdG8g
cmV1c2UgbWFwcGluZyBlbGVtZW50cyBpbiB5b3VyDQppbXBsZW1lbnRhdGlvbiB5b3UgY2FuIHNp
bXBseSByZWZlcmVuY2UgdGhlbQ0KaW4gdGhlIGV4dGVuc2lvbiBwb2ludCwgbm8gc3BlY2lmaWNh
dGlvbg0KcmVxdWlyZWQgYW5kIHRoaW5ncyB0aGF0IGNob29zZSBub3QgdG8NCnVuZGVyc3RhbmQg
dGhlIGV4dGVuc2lvbiBjYW4gaWdub3JlICB0aGVtLg0KTm8gZXh0cmEgc3BlY2lmaWNhdGlvbiBy
ZXF1aXJlZCwgbm8gZXh0cmENCndvcmsgYXQgYWxsIHJlcXVpcmVkIGluIHRoaXMgc3BlY2lmaWNh
dGlvbiwNCm5vdCBldmVuIDEwIG1pbnV0ZXMgZWRpdGluZyBhbmQgNCB5ZWFycyBvZg0KaGFnZ2xp
bmcuDQoNCkNoZWVycw0KSmFtZXMNCg0KDQpPbiAyNyBNYXIgMjAxNSwgYXQgMTozMSBhbSwgUm9z
ZW4sIEJyaWFuDQo8PDxtYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo+bWFpbHRvOkJyaWFu
LlJvc2VuQG5ldXN0YXIuYml6PjxtYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo+QnJpYW4u
Um9zZW5AbmV1c3Rhci5iaXo8bWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6Pj4NCndyb3Rl
Og0KDQpJIGRvbid0IHVuZGVyc3RhbmQgYW55IG9mIHRoaXMgbG9naWMuDQoNCllvdSBpbXBvcnQg
dGhlIGRlZmluaXRpb24gZnJvbSBSRkM1MjIyIGFuZA0KcmVmZXIgdG8gaXQgZm9yIHRoZSBtZWFu
aW5nIG9mIHRoZQ0KZWxlbWVudHMuICBEb25lLiAgTm8gdGltZSBkZWxheS4gIDEwDQptaW51dGVz
IG9mIGVkaXRpbmcuDQoNCkkgd2FudCB0byBiZSBhYmxlIHRvIGJ1aWxkIHN5c3RlbXMgdGhhdA0K
d29yayB3b3JsZC13aWRlLiAgVGhlIG1vcmUgY29tbW9uYWxpdHkgb2YNCmRhdGEgc3RydWN0dXJl
cywgdGhlIGJldHRlci4NCg0KWW91IGhhdmUgbm90IHNob3duIGFueSBoYXJtIHRvIHJlLXVzZSBv
ZiBhDQpkYXRhIHN0cnVjdHVyZSB0aGF0IHdhcyBkZXNpZ25lZCBmb3IgdGhlDQpwdXJwb3NlIHlv
dSBoYXZlLCBoYXMgaGFkIGV4dGVuc2l2ZSBJRVRGDQpyZXZpZXcsIGltcGxlbWVudGF0aW9uLCBh
bmQgY29uc2Vuc3VzLiAgWW91DQp3YW50IHRvIGludmVudCBzb21ldGhpbmcgbmV3LiAgSXQncyBj
bGVhcmx5DQphIHN1YnNldCwgYnV0IGl0J3Mgbm90IHByZWNpc2VseSBhIHN1YnNldC4NClRoYXQg
aXMgbm90IGEgZ29vZCBpZGVhIGluIG15IG9waW5pb24uICBBcw0KdGhlIG1ham9yaXR5IG9mIGVs
ZW1lbnRzIGluIDxtYXBwaW5nPiBhcmUNCm9wdGlvbmFsLCBhbiBpbXBsZW1lbnRhdGlvbiBjYW4g
Y2hvb3NlDQpuZXZlciB0byBzZW5kIHRoZW0gKHNlcnZlcikgb3IgaWdub3JlIHRoZW0NCmlmIHJl
Y2VpdmVkIChjbGllbnQpLiAgSWYgeW91IHVzZSB0aGUNCmV4dGVuc2lvbiBwb2ludCAoMyksIGFu
ZCB3ZSBsYXRlciBkZWNpZGUNCnRoYXQgbW9zdCBvZiA8bWFwcGluZz4gaXMgaW4gZmFjdCB1c2Vm
dWwsDQp3ZSB3b3VsZCBlbmQgdXAgZGlmZmVyZW50IGRhdGEgc3RydWN0dXJlcywNCmJlY2F1c2Ug
dGhlIGJhc2Ugc3RydWN0dXJlIGlzIGRpZmZlcmVudC4NCg0KQnJpYW4NCg0KDQpPbiBNYXIgMjYs
IDIwMTUsIGF0IDg6MjIgQU0sIExhdXJhIExpZXNzDQo8PDxtYWlsdG86bGF1cmEubGllc3MuZHRA
Z29vZ2xlbWFpbC5jb20+bWFpbHRvOmxhdXJhLmxpZXNzLmR0QGdvb2dsZW1haWwuY29tPjxtYWls
dG86bGF1cmEubGllc3MuZHRAZ29vZ2xlbWFpbC5jb20+bGF1cmEubGllc3MuZHRAZ29vZ2xlbWFp
bC5jb208bWFpbHRvOmxhdXJhLmxpZXNzLmR0QGdvb2dsZW1haWwuY29tPj4NCndyb3RlOg0KDQpJ
IHdvdWxkIHByZWZlciAzKSBhbmQgSSBjYW4gbGl2ZSB3aXRoIDIpLg0KDQpJIGFtIG9wb3NlZCB0
byAxKSBiZWNhdXNlIGl0IHdvdWxkIGRlbGF5DQp0aGUgZHJhZnQgcHJvZ3Jlc3MsIGp1c3QgdG8g
YWRkIGZlYXR1cmVzDQphYm91dCB3ZSBkb24ndCBrbm93IGlmIGFueW9uZSB3aWxsIG5lZWQNCnRo
ZW0gYW5kaWYgc28sICB3aGF0IGV4YWN0bHkgd2lsbCBiZQ0KbmVlZGVkLiBGb3IgdGhlIHdvcmsg
aW4gRVRTSSBvbiB0aGUgRUMNCk00OTMgdGhpcyBpcyBjbGVhcmx5IG5vdCBuZWVkZWQuIEVUU0kN
Cm5lZWRzIHRoZSBkcmFmdCBmaW5pc2hlZCB2ZXJ5IHNvb24sIGlmIHdlDQp3YW50IHRoZSBmaW5h
bCBFVFNJIHNwZWNpZmljYXRpb24sDQp0YXJnZXRlZCBmb3IgdGhlIGVuZCBvZiB0aGlzIHllYXIs
IHRvDQpyZWZlciBhbiBSRkMgYW5kIG5vdCBhIGRyYWZ0IGFuZCB0aGUNCmltcGxlbWVudGF0aW9u
cyB3aGljaCB3aWxsIGNvbWUgdGhlbiBzb29uLA0KdG8gYmUgYmFzZWQgYW4gUkZDIGFuZCBub3Qg
b24gc29tZQ0KaW50ZXJtZWRpYXJ5IHZlcnNpb24gb2YgdGhlIGRyYWZ0Lg0KDQpJIHRoaW5rIDMp
IGlzIGEgZ29vZCBzb2x1dGlvbiwgZmxleGlibGUNCmVub3VnaCB0aGF0IGV2ZXJ5b25lIGNvdWxk
IGxpdmUgd2l0aCBpdC4NCg0KVGhhbmsgeW91DQogTGF1cmENCg0KMjAxNS0wMy0yNSAyMDoyMSBH
TVQrMDE6MDAgSmFtZXMNCldpbnRlcmJvdHRvbQ0KPDw8bWFpbHRvOmEuamFtZXMud2ludGVyYm90
dG9tQGdtYWlsLmNvbT5tYWlsdG86YS5qYW1lcy53aW50ZXJib3R0b21AZ21haWwuY29tPjxtYWls
dG86YS5qYW1lcy53aW50ZXJib3R0b21AZ21haWwuY29tPmEuamFtZXMud2ludGVyYm90dG9tQGdt
YWlsLmNvbTxtYWlsdG86YS5qYW1lcy53aW50ZXJib3R0b21AZ21haWwuY29tPj46DQoNClRoZXJl
IGlzIGRvd25zaWRlIHRvIHVzaW5nIHRoZSBleGlzdGluZw0Kc2NoZW1hIEJyaWFuLCB0aGlzIGlz
IHNwZWx0IG91dCBjbGVhcmx5IGluDQp0aGUgZHJhZnQuIEluIG9yZGVyIHRvIGluY2x1ZGUgdGhl
IGZpZWxkcw0KeW91IHdhbnQgYSBuZXcgZWxlbWVudCB3b3VsZCBuZWVkIHRvIGJlDQpkZWZpbmVk
IGluIHRoaXMgZHJhZnQgdG8gc3VwcG9ydCBpdC4gSQ0KdGhpbmsgdGhhdCB0aGF0IGlzIHRoZSB3
cm9uZyB3YXkgdG8gZG8gaXQNCmFzIHRoZXJlIGhhcyBiZWVuIG5vIGV4cHJlc3Npb24gb2YgbmVl
ZC4NCklmIGEgbmVlZCBhcnJpc2VzIGFmdGVyIHRoaXMgZHJhZnQgaXMNCmRvbmUsIHRoZW4gaXQg
Y2FuIGJlIGFkZGVkIGxhdGVyLiBSaWdodA0Kbm93IGl0IGlzbid0IG5lZWRlZC4NCg0KQXMgSSBz
YWlkIGluIG15IHByZWZlcmVuY2UgZm9yIG9wdGlvbiAzLCBJDQp0aGluayB0aGF0IHRoZSBleHRl
bnNpb24gcG9pbnQgc2hvdWxkIGJlDQphZGRlZCB0aGVuIGFueXRoaW5nIGNhbiBiZSBhZGRlZCBs
YXRlciBpZg0KcmVxdWlyZWQuDQoNCkNoZWVycw0KSmFtZXMNCg0KDQoNCk9uIDI2IE1hciAyMDE1
LCBhdCAyOjUyIGFtLCBSb3NlbiwgQnJpYW4NCjw8PG1haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFy
LmJpej5tYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo+PG1haWx0bzpCcmlhbi5Sb3NlbkBu
ZXVzdGFyLmJpej5Ccmlhbi5Sb3NlbkBuZXVzdGFyLmJpejxtYWlsdG86QnJpYW4uUm9zZW5AbmV1
c3Rhci5iaXo+Pg0Kd3JvdGU6DQoNCkxldCdzIHNheSB0aGF0IHNvbWVvbmUgY29tZXMgYWxvbmcg
YW5kDQpzaG93cyBhIGRlY2VudCB1c2UgY2FzZSBmb3IgaW5jbHVkaW5nIGENCnNlcnZpY2UgYm91
bmRhcnkuDQoNClNvIHRoZXkgZGVmaW5lIGFuIGV4dGVuc2lvbiBmb3IgaXQuDQoNClRoYXQgZXh0
ZW5zaW9uIG1heSBvciBtYXkgbm90IGJlIHRoZSBzYW1lDQphcyB0aGUgc2VydmljZSBib3VuZGFy
eSB0aGF0IExvU1QNCnJldHVybnMuIEFuIGltcGxlbWVudGF0aW9uIGRlc2lnbmVkIHRvDQpwcm92
aWRlIHdvcmxkLXdpZGUgc2VydmljZSB3b3VsZCBoYXZlIHRvDQpjaGFuZ2UuDQoNClJldHVybmlu
ZyB0aGUgYm91bmRhcnkgaXMgYWxyZWFkeSBvcHRpb25hbCBpbiB0aGUgTG9TVCBzY2hlbWEuDQoN
CklmIHdlIHVzZWQgdGhlIGV4aXN0aW5nIGRlZmluaXRpb246DQoxLiBObyBuZXcgZG9jdW1lbnQg
aXMgcmVxdWlyZWQNCjIuIENvbXBhdGliaWxpdHkgYmV0d2VlbiB0aGlzIEhFTEQgZXh0ZW5zaW9u
IGFuZCBMb1NUIGlzIG1haW50YWluZWQNCjMuIFN5c3RlbXMgYnVpbHQgdG8gc3VwcG9ydCBib3Ro
IG1vZGVscyBkb24ndCBoYXZlIHRvIGNoYW5nZQ0KDQpUaGVyZSBpcywgYXMgZmFyIGFzIEkgY2Fu
IHNlZSwgbm8NCmRvd25zaWRlIHRvIHVzaW5nIHRoZSBleGlzdGluZyBzY2hlbWENCm90aGVyIHRo
YW4gbWFraW5nIHRoZSBzbWFsbGVzdCBwb3NzaWJsZQ0KcmVzcG9uc2UgYSBiaXQgYmlnZ2VyLiAg
IE9uZSBjYW4gYWx3YXlzDQppZ25vcmUgYW55IHJldHVybmVkIGl0ZW1zIG5vdA0KbmVlZGVkL3dh
bnRlZCwgYW5kIHNpbmNlIHRoZXkgYXJlDQpvcHRpb25hbCB0aGV5IGNhbid0IGJlIGFzc3VtZWQg
dG8gYmUNCnRoZXJlLg0KDQpPcHRpb24gMiAoZG9uJ3QgYWxsb3cgYW4gZXh0ZW5zaW9uIHBvaW50
DQpvbiB0aGUgcmV0dXJuKSBtYWtlcyBubyBzZW5zZSB0byBtZS4gIEkNCmNhbid0IGltYWdpbmUg
dGhlIElFVEYgZG9pbmcgdGhhdC4gQW55DQpleHRlbnNpb24gd291bGQgdGhlbiByZXF1aXJlIGFs
bCBleGlzdGluZw0KaW1wbGVtZW50YXRpb25zIHRvIGJlIGNoYW5nZWQuDQoNCkJyaWFuDQoNCg0K
T24gTWFyIDI1LCAyMDE1LCBhdCA5OjQ5IEFNLA0KPDxtYWlsdG86Ui5KZXNza2VAdGVsZWtvbS5k
ZT5tYWlsdG86Ui5KZXNza2VAdGVsZWtvbS5kZT48bWFpbHRvOlIuSmVzc2tlQHRlbGVrb20uZGU+
Ui5KZXNza2VAdGVsZWtvbS5kZTxtYWlsdG86Ui5KZXNza2VAdGVsZWtvbS5kZT4gd3JvdGU6DQoN
CkhpIEphbWVzLA0KdGhhbmsgeW91IGZvciB0aGUgc3VtbWFyeS4NCk15IHBvc2l0aW9uIGlzIHJl
ZmxlY3RlZCBpbiBwb2ludCAyLg0KDQpJZiBwZW9wbGUgd2FudCB0byBhZGQgc29tZXRoaW5nIHRv
IGENCm1lY2hhbmlzbSBjYW4gaXQgbm90IGJlIGRvbmUgb25seSBpbg0Kd3JpdGluZyBhIGZ1cnRo
ZXIgZHJhZnQ/DQpUaGlzIG1lYW5zIGFsc28gaW5jbHVkaW5nIGluIHN1Y2ggYSBkcmFmdCBhbHNv
IGEgZXh0ZW5zaW9uIG1lY2hhbmlzbS4NCg0KSSB0aGluayB0aGF0IHdvdWxkIGJlIGEgY2xlYXIg
bGluZSB0byBzYXRpc2Z5IGV2ZXJ5Ym9keS4NCg0KDQpCZXN0IFJlZ2FyZHMNCg0KUm9sYW5kDQoN
Ci0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NClZvbjogRWNyaXQNClttYWlsdG86
PDxtYWlsdG86JTNjPjxtYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZz5tYWlsdG86ZWNyaXQt
Ym91bmNlc0BpZXRmLm9yZz48bWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmc+ZWNyaXQtYm91
bmNlc0BpZXRmLm9yZzxtYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZz5dDQpJbSBBdWZ0cmFn
IHZvbiBKYW1lcyBXaW50ZXJib3R0b20NCkdlc2VuZGV0OiBNaXR0d29jaCwgMjUuIE3DpHJ6IDIw
MTUgMDk6MDMNCkFuOiA8PGh0dHA6Ly9lY3JpdF9pZXRmLm9yZy8+aHR0cDovL2Vjcml0X2lldGYu
b3JnLz5lY3JpdF9pZXRmLm9yZw0KQmV0cmVmZjogW0Vjcml0XSBIRUxEIFJvdXRpbmcgc3VtbWFy
eQ0KDQpIaSBBbGwsDQoNCkFzIEkgc2VlIGl0IHRoZXJlIGlzIG9uZSBvcGVuIGRpc2N1c3Npb24N
CnBvaW50IGFuZCB0aHJlZSBwb3NpdGlvbnMgb24gdGhpcyBwb2ludC4NClRoZSBkaXNjdXNzaW9u
IHBvaW50IGlzIHdoZXRoZXIgb3Igbm90DQphbGwgb2YgdGhlIGFuY2lsbGFyeSBkYXRhIHRoYXQg
aXMNCnJldHVybmVkIGJ5IGEgTG9TVCBmaW5kU2VydmljZSByZXF1ZXN0DQpzaG91bGQgYmUgaW5j
bHVkZWQgaW4gdGhlIEhFTEQgcm91dGluZw0KcmVzcG9uc2Ugb3Igbm90Lg0KDQpUaGUgdGhyZWUg
cG9zaXRpb25zIHRoYXQgaGF2ZSBiZWVuDQpzdGF0ZWQgYXJlIChpbiBubyBwYXJ0aWN1bGFyIG9y
ZGVyKToNCjEpIFRoZSBkZWZpbml0aW9uIGZvciB0aGlzIGluZm9ybWF0aW9uDQpzaG91bGQgYmUg
aW5jbHVkZWQgaW4gdGhlIGJhc2UNCnNwZWNpZmljYXRpb24gYnV0IGlzIG9wdGlvbmFsIHRvIHNl
bmQgb3INCmJlIGFjdGVkIG9uLg0KMikgSXNuJ3QgcmVxdWlyZWQgYXQgYWxsLCBsZXQgdGhlIGN1
cnJlbnQgZHJhZnQgc3RhbmQNCjMpIEFkZCBhbiBleHRlbnNpb24gcG9pbnQgdG8gdGhlIHNjaGVt
YQ0KaW4gdGhlIGRyYWZ0IHNvIHRoYXQgdGhlIGV4dHJhIGNhbiBiZQ0Kc3BlY2lmaWVkIGluIGEg
ZGlmZmVyZW50IGRyYWZ0IGFuZCBhZGRlZA0KYnkgc29tZXRoaW5nIHJlcXVpcmluZyBpdC4NCg0K
VGhpcyBlbWFpbCBtYWtlcyBubyBjbGFpbXMgdG8NCnByZWZlcmVuY2UsIGJ1dCBqdXN0IHByZXNl
bnRzIHRoZQ0Kb3BpbmlvbnMgdGhhdCBoYXZlIGJlZW4gZXhwcmVzc2VkLg0KDQpDaGVlcnMNCkph
bWVzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpF
Y3JpdCBtYWlsaW5nIGxpc3QNCg0KPDxtYWlsdG86RWNyaXRAaWV0Zi5vcmc+bWFpbHRvOkVjcml0
QGlldGYub3JnPjxtYWlsdG86RWNyaXRAaWV0Zi5vcmc+RWNyaXRAaWV0Zi5vcmc8bWFpbHRvOkVj
cml0QGlldGYub3JnPg0KDQo8PGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
ZWNyaXQ+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdD4gPGh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQ+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCkVjcml0IG1haWxpbmcgbGlzdA0KDQo8PG1haWx0bzpFY3JpdEBp
ZXRmLm9yZz5tYWlsdG86RWNyaXRAaWV0Zi5vcmc+PG1haWx0bzpFY3JpdEBpZXRmLm9yZz5FY3Jp
dEBpZXRmLm9yZzxtYWlsdG86RWNyaXRAaWV0Zi5vcmc+DQoNCjw8aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdD5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL2Vjcml0PiA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3Jp
dD5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQoNCg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkVjcml0IG1haWxpbmcg
bGlzdA0KDQo8PG1haWx0bzpFY3JpdEBpZXRmLm9yZz5tYWlsdG86RWNyaXRAaWV0Zi5vcmc+PG1h
aWx0bzpFY3JpdEBpZXRmLm9yZz5FY3JpdEBpZXRmLm9yZzxtYWlsdG86RWNyaXRAaWV0Zi5vcmc+
DQoNCjw8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdD5odHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0PjxodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vZWNyaXQNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KRWNyaXQgbWFpbGluZyBsaXN0DQoNCjw8bWFpbHRvOkVjcml0QGlldGYub3JnPm1h
aWx0bzpFY3JpdEBpZXRmLm9yZz48bWFpbHRvOkVjcml0QGlldGYub3JnPkVjcml0QGlldGYub3Jn
PG1haWx0bzpFY3JpdEBpZXRmLm9yZz4NCg0KPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vZWNyaXQ+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3Jp
dA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpF
Y3JpdCBtYWlsaW5nIGxpc3QNCjxtYWlsdG86RWNyaXRAaWV0Zi5vcmc+RWNyaXRAaWV0Zi5vcmc8
bWFpbHRvOkVjcml0QGlldGYub3JnPg0KDQo8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9lY3JpdD5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0
DQoNCg0KDQotLQ0KUmFuZGFsbCBHZWxsZW5zDQpPcGluaW9ucyBhcmUgcGVyc29uYWw7ICAgIGZh
Y3RzIGFyZSBzdXNwZWN0OyAgICBJIHNwZWFrIGZvciBteXNlbGYgb25seQ0KLS0tLS0tLS0tLS0t
LS0gUmFuZG9tbHkgc2VsZWN0ZWQgdGFnOiAtLS0tLS0tLS0tLS0tLS0NClNwb3R0ZWQgb24gdGhl
IGJhY2sgb2YgYSB0LXNoaXJ0IHdvcm4gYnkgTEFQRCBCb21iIFNxdWFkOg0KIklmIHlvdSBzZWUg
bWUgcnVubmluZywgdHJ5IHRvIGtlZXAgdXAuIg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQpFY3JpdCBtYWlsaW5nIGxpc3QNCkVjcml0QGlldGYu
b3JnPG1haWx0bzpFY3JpdEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vZWNyaXQNCg0KDQoNCi0tDQpSYW5kYWxsIEdlbGxlbnMNCk9waW5pb25zIGFyZSBw
ZXJzb25hbDsgICAgZmFjdHMgYXJlIHN1c3BlY3Q7ICAgIEkgc3BlYWsgZm9yIG15c2VsZiBvbmx5
DQotLS0tLS0tLS0tLS0tLSBSYW5kb21seSBzZWxlY3RlZCB0YWc6IC0tLS0tLS0tLS0tLS0tLQ0K
U2tpcHBlcjogICBNci4gSG93ZWxsLCBZb3UgZG9uJ3Qga25vdyB3aGF0IGl0J3MgbGlrZSBvdXQg
dGhlcmUgaW4NCiAgICAgICAgICB0aGUgb2NlYW4sIHlvdSBtYXkgYmUgYml0dGVuIGJ5IGEgc2hh
cmshDQpUaHVyc3RvbjogIEEgc2hhcmsgYml0ZSBhIEhvd2VsbCwgaGEgaGEgaGUgd291bGRuJ3Qg
ZGFyZS4NClNraXBwZXI6ICAgQmVzaWRlcyB3ZSBkb24ndCBoYXZlIHJvb20gZW5vdWdoIGZvciB5
b3VyIGx1Z2dhZ2UuDQpUaHVyc3RvbjogIFdlbGwgdGhhdCdzIGRpZmZlcmVudC4gSWYgSSBjYW4n
dCBnbyBmaXJzdCBjbGFzcyBJIHdvbid0DQogICAgICAgICAgZ28gYXQgYWxsLg0KDQoNCg==

--_000_058CE00BD4D6B94FAD033A2439EA1E4B01E9E52D8834HE113667eme_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50
PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv
bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0K
CXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p
bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u
dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg
MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx
MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs
LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3
IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl
LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu
TXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJTcHJlY2hibGFzZW50ZXh0IFpjaG4iOw0KCW1h
cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglm
b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQt
c3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uU3By
ZWNoYmxhc2VudGV4dFpjaG4NCgl7bXNvLXN0eWxlLW5hbWU6IlNwcmVjaGJsYXNlbnRleHQgWmNo
biI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOlNwcmVjaGJsYXNl
bnRleHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRS1NYWls
Rm9ybWF0dm9ybGFnZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw
RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0
O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46
NzAuODVwdCA3MC44NXB0IDIuMGNtIDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl
OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86
c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu
ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk
aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+
PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9REUgbGluaz1ibHVlIHZsaW5rPXB1
cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu
Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh
bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj
bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkZvciBtZSBp
dCBsb29rcyBsaWtlIG1vcmUgY29uZnVzaW5nIHRoYW4gb25seSB0byBhcHBseSB0byBPUFRJT04g
My48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t
VVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl
cmlmIjtjb2xvcjojMUY0OTdEJz5UaHVzIEnigJltIHN0aWxsIGluIGZhdm9yIGZvciBPcHRpb24g
MyB3aGljaCBuZWVkIG9ubHkgYSBzbWFsbCBjaGFuZ2UuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48
cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkFuZCBJ
IHRoaW5rIHRoZSByZXF1aXJlbWVudCBmb3IgZXh0ZW5zaWJpbGl0eSBhcyBkaXNjdXNzZWQgaW4g
dGhlIG1lZXRpbmcgaXMgZnVsZmlsbGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N
c29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y
OiMxRjQ5N0QnPkluIHNob3J0IEkgc3VwcG9ydCBub3cgT1BUSU9OIDMgYXMgSmFtZXMgcHJvcG9z
ZWQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVO
LVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z
ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz
PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs
aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoYW5rIHlvdSBhbmQgQmVzdCBSZWdh
cmRzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y
OiMxRjQ5N0QnPjxicj5Sb2xhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y
bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi
c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxk
aXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0
O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBz
dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiIn
PlZvbjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IEVjcml0IFttYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRm
Lm9yZ10gPGI+SW0gQXVmdHJhZyB2b24gPC9iPkphbWVzIFdpbnRlcmJvdHRvbTxicj48Yj5HZXNl
bmRldDo8L2I+IERvbm5lcnN0YWcsIDI2LiBNw6RyeiAyMDE1IDIxOjAyPGJyPjxiPkFuOjwvYj4g
Um9zZW4sIEJyaWFuPGJyPjxiPkNjOjwvYj4gZWNyaXRAaWV0Zi5vcmc7IFJhbmRhbGwgR2VsbGVu
czxicj48Yj5CZXRyZWZmOjwvYj4gUmU6IFtFY3JpdF0gSEVMRCBSb3V0aW5nIHN1bW1hcnk8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkkgc3RpbGwgZG9u4oCZdCB3YW50
IHRoZSBleHRyYSBzdHVmZiBhcyBJIGRvbuKAmXQgc2VlIGEgbmVlZCBmb3IgaXQuPG86cD48L286
cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+
PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SG93ZXZlciwgaWYgd2Ugd2VyZSB0byBwcm9j
ZWVkIGRvd24gdGhpcyBwYXRoIHRoZW46PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz
cz1Nc29Ob3JtYWw+VGhpcyBkb2N1bWVudCBub3cgbm9ybWF0aXZlbHkgdXBkYXRlcyBSRkM1MjIy
IHNvIEkgZG9u4oCZdCB0aGluayB0aGF0IHRoZSBsYW5ndWFnZSBiZWxvdyBpcyBzdHJvbmcgZW5v
dWdoIG9yIGNsZWFyIGVub3VnaCB0aGF0IHdlIGFyZSBjaGFuZ2luZyB0aGUgbWVhbmluZyBvZiBz
b3VyY2UgZnJvbSBSRkM1MjIyLiBUaGlzIGlzIGJlY2F1c2UgdGhlIEhFTEQgc2VydmVyIG1heSBu
b3QgZ2VuZXJhdGUgdGhlIG1hcHBpbmcgZGF0YSwgaXQgbWF5IHNpbXBseSBzdXBwbHkgaXQgYW5k
IGEgVVJJIGZvciBob3cgaXQgb2J0YWluZWQgaXQgbWF5IG5vdCBleGlzdC48bzpwPjwvbzpwPjwv
cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UaGUgc291cmNlIGluIFJGQzUyMjIgaXMg
bm90IGEgVVJJLCBpdCBpcyBhIExvU1QgYXBwbGljYXRpb24gdW5pcXVlIHN0cmluZywgSSBhbSBu
b3Qgc3VyZSB0aGF0IG1ha2luZyB0aGlzIGEgSEVMRCBhcHBsaWNhdGlvbiB1bmlxdWUgc3RyaW5n
IG1ha2VzIHNlbnNlLCBzbyB0aGlzIHdvdWxkIHJlcXVpcmUgbW9yZSB0aG91Z2h0LCB1bmxlc3Mg
dGhpcyBpcyBhbHNvIHBhcnQgb2YgdGhlIHVwZGF0aW5nIHRvIFJGQzUyMjIgd2hpY2ggd291bGQg
YWxzbyByZXF1aXJlIHNjaGVtYSBjaGFuZ2UgdG8gc3VwcG9ydC48bzpwPjwvbzpwPjwvcD48L2Rp
dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2
PjxwIGNsYXNzPU1zb05vcm1hbD5UaGVzZSB3ZXJlIHRoZSBwcm9ibGVtcyBJIGxvb2sgYXQgd2hl
biBJIGNyZWF0ZWQgdGhlIHNwZWNpZmljYXRpb24gdGhlIHdheSBpdCBpcywgd2hpY2ggaXMgd2h5
IEkgZGlkbuKAmXQgdXNlIHRoZSBtYXBwaW5nIGVsZW1lbnQuIEkganVzdCBkb27igJl0IHRoaW5r
IHlvdSBjYW4gdXNlIHdvcmRzIHRvIGV4cGxhaW4gYXdheSB0aGUgaXNzdWVzIGFuZCBjcmFtIHRo
ZSBtYXBwaW5nIGVsZW1lbnQgaW4sIHlvdSB3b3VsZCBuZWVkIHRvIHJlZGVmaW5lIHRoZSBtYXBw
aW5nIGVsZW1lbnQgYW5kIEkgc2VlIG5vIHZhbHVlIGluIHRoYXQuPG86cD48L286cD48L3A+PC9k
aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRp
dj48cCBjbGFzcz1Nc29Ob3JtYWw+Q2hlZXJzPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj
bGFzcz1Nc29Ob3JtYWw+SmFtZXM8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt
YWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5PbiAy
NyBNYXIgMjAxNSwgYXQgNjo0NCBhbSwgUm9zZW4sIEJyaWFuICZsdDs8YSBocmVmPSJtYWlsdG86
QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXoiPkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6PC9hPiZndDsg
d3JvdGU6PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5SZXBs
YWNlIHRoZSBsYXN0IHR3byBwYXJhZ3JhcGhzIG9mIFNlY3Rpb24gNCB3aXRoOjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u
dC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g
c3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm
Iic+VGhlIGxvY2F0aW9uIHJlc3BvbnNlIHdoZW4gdGhlIEhFTEQgc2V2ZXIgc3VwcG9ydHMgdGhp
cyBzcGVjaWZpY2F0aW9uIGFuZCByb3V0aW5nIGlzIHJlcXVlc3RlZCBjb25zaXN0cyBvZiB0aGUg
Jmx0O21hcHBpbmcmZ3Q7IGVsZW1lbnQgZnJvbSBSRkM1MjIyLiAmbmJzcDtUaGUg4oCcc291cmNl
4oCdIGVsZW1lbnQgc2hhbGwgYmUgdGhlIFVSSSBvZiB0aGUgYXV0aG9yaXRhdGl2ZSBnZW5lcmF0
b3Igb2YgdGhlIG1hcHBpbmcgZGF0YSwgd2hpY2ggbWF5IGJlIHRoZSBIRUxEIHNlcnZlcuKAmXMg
VVJJLiAmbmJzcDsgQWxsIG90aGVyIGVsZW1lbnRzIG9mIHRoZSAmbHQ7bWFwcGluZyZndDsgZWxl
bWVudCBhcmUgYXMgdGhleSBhcmUgZGVzY3JpYmVkIGluIFJGQzUyMjIuICZuYnNwOzxvOnA+PC9v
OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw
YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl
cmlmIic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv
Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp
Iiwic2Fucy1zZXJpZiInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw
IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls
eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9k
aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC41cHQ7
Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+SWYgdGhpcyBsYW5ndWFnZSBpcyBh
Y2NlcHRhYmxlLCBJ4oCZbGwgZml4IHRoZSBzY2hlbWEgaW4gU2VjdGlvbiA1IGFuZCB0aGUgZXhh
bXBsZXMuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu
cy1zZXJpZiInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz
PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQ2Fs
aWJyaSIsInNhbnMtc2VyaWYiJz5CcmlhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2
PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZh
bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
PC9kaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu
MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3Bh
biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy
aWYiJz5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPkphbWVzIFdpbnRlcmJvdHRvbSAmbHQ7PGEg
aHJlZj0ibWFpbHRvOmEuamFtZXMud2ludGVyYm90dG9tQGdtYWlsLmNvbSI+YS5qYW1lcy53aW50
ZXJib3R0b21AZ21haWwuY29tPC9hPiZndDs8YnI+PGI+RGF0ZTogPC9iPlRodXJzZGF5LCBNYXJj
aCAyNiwgMjAxNSBhdCAyOjI3IFBNPGJyPjxiPlRvOiA8L2I+UmFuZGFsbCBHZWxsZW5zICZsdDs8
YSBocmVmPSJtYWlsdG86cmcraWV0ZkBxdGkucXVhbGNvbW0uY29tIj5yZytpZXRmQHF0aS5xdWFs
Y29tbS5jb208L2E+Jmd0Ozxicj48Yj5DYzogPC9iPkJyaWFuIFJvc2VuICZsdDs8YSBocmVmPSJt
YWlsdG86YnJpYW4ucm9zZW5AbmV1c3Rhci5iaXoiPmJyaWFuLnJvc2VuQG5ldXN0YXIuYml6PC9h
PiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzplY3JpdEBpZXRmLm9yZyI+ZWNyaXRAaWV0Zi5v
cmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZWNyaXRAaWV0Zi5vcmciPmVjcml0QGll
dGYub3JnPC9hPiZndDs8YnI+PGI+U3ViamVjdDogPC9iPlJlOiBbRWNyaXRdIEhFTEQgUm91dGlu
ZyBzdW1tYXJ5PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y
bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi
c2Fucy1zZXJpZiInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXY+
PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt
aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPlRoYW5rcyBmb3IgdGFsa2luZyB0aGUgcG9zaXRp
b24gYXMgY29uY2lsaWF0b3IgUmFuZGFsbC4gPG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PHAg
Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5
OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rp
dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtm
b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6
ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPjxkaXY+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7
bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9
J2ZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+T24g
MjcgTWFyIDIwMTUsIGF0IDY6MjYgYW0sIFJhbmRhbGwgR2VsbGVucyAmbHQ7PGEgaHJlZj0ibWFp
bHRvOnJnK2lldGZAcXRpLnF1YWxjb21tLmNvbSI+cmcraWV0ZkBxdGkucXVhbGNvbW0uY29tPC9h
PiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1h
bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh
bnMtc2VyaWYiJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29O
b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiSGVsdmV0aWNh
Iiwic2Fucy1zZXJpZiInPk15IGltcHJlc3Npb24gaXMgdGhhdCBwZW9wbGUgYXJlIHRhbGtpbmcg
cGFzdDxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPmVh
Y2ggb3RoZXIsIHdoaWNoIGlzIHdoeSBJIHRob3VnaHQgc2VlaW5nIHRoZTxzcGFuIGNsYXNzPWFw
cGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPnByb3Bvc2FsIGluIHRoZSBkb2N1
bWVudCB3b3VsZCBoZWxwIGNsYXJpZnkgaXQuPGJyPjxicj5BdCA2OjA3IEFNICsxMTAwIDMvMjcv
MTUsIEphbWVzIFdpbnRlcmJvdHRvbSB3cm90ZTo8YnI+PGJyIHN0eWxlPSdvcnBoYW5zOiBhdXRv
O3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6
IDBweDt3b3JkLXNwYWNpbmc6MHB4Jz48YnI+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTAuNXB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtm
b250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiInPlJhbmRhbGwsPGJyPjxicj5JIGRv
bid0IGFncmVlIHdpdGggQnJpYW4ncyBwb3NpdGlvbiBvbiB0aGU8c3BhbiBjbGFzcz1hcHBsZS1j
b252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj5Tb3VyY2UsIG15IHJlYWRpbmcgb2YgTG9T
VCBpcyB0aGF0IHRoaXMgY2FuJ3Q8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5i
c3A7PC9zcGFuPjxicj5iZSB0aGUgSEVMRCBzZXJ2ZXIgYmVjYXVzZSBpdCBkb2Vzbid0IHNhdGlz
Znk8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj50aGUg
ZGVzY3JpcHRpb24gYW5kIHJlcXVpcmVtZW50cyBmb3IgdGhlIHVzZSBvZjxzcGFuIGNsYXNzPWFw
cGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPnRoYXQgZmllbGQuPGJyPjxicj5C
dXQgZnVydGhlciB0byB0aGF0LCB0aGUgdGhyZWUgcGVvcGxlIGluIHRoaXM8c3BhbiBjbGFzcz1h
cHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj5ncm91cCB0aGF0IHJlcXVlc3Rl
ZCB0aGlzIGZ1bmN0aW9uYWxpdHkgZG9uJ3Q8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3Bh
Y2U+Jm5ic3A7PC9zcGFuPjxicj5zZWUgYSBuZWVkIGZvciB0aGlzIHN0dWZmLiBJbmRlZWQgdGhl
IG9ubHk8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj5w
ZXJzb24gYXJndWluZyBmb3IgaXQgaXMgQnJpYW4gYW5kIGhlIGhhc24ndDxzcGFuIGNsYXNzPWFw
cGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPnByb3ZpZGVkIG9yIGRlbW9uc3Ry
YXRlZCBhbnkgbmVlZCBmb3IgaXQuPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZu
YnNwOzwvc3Bhbj48YnI+T3B0aW9uIDMgb24gdGhhdCB0YWJsZSBhbGxvd3MgaXQgYmUgYWRkZWQg
d2hlbjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPm5l
ZWRlZCB3aGljaCBpcyB0aGUgZmFzdGVzdCBhbmQgZWFzaWVzdDxzcGFuIGNsYXNzPWFwcGxlLWNv
bnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPmFwcHJvYWNoLjxicj48YnI+PGJyPkNoZWVy
czxicj5KYW1lczxicj48YnI+PGJyPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O
b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiSGVsdmV0aWNh
Iiwic2Fucy1zZXJpZiInPk9uIDI3IE1hciAyMDE1LCBhdCA0OjEwIGFtLCBSYW5kYWxsIEdlbGxl
bnM8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj4mbHQ7
Jmx0OzxhIGhyZWY9Im1haWx0bzpyYW5keUBxdGkucXVhbGNvbW0uY29tIj5tYWlsdG86cmFuZHlA
cXRpLnF1YWxjb21tLmNvbTwvYT4mZ3Q7PGEgaHJlZj0ibWFpbHRvOnJhbmR5QHF0aS5xdWFsY29t
bS5jb20iPnJhbmR5QHF0aS5xdWFsY29tbS5jb208L2E+Jmd0OzxzcGFuIGNsYXNzPWFwcGxlLWNv
bnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPndyb3RlOjxicj48YnI+QnJpYW4sPGJyPjxi
cj5JZiBpdCdzIG9ubHkgMTAgbWludXRlcyBvZiBlZGl0aW5nLCB0aGVuIG1heWJlPHNwYW4gY2xh
c3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+eW91IGNhbiByZXZpc2Ug
ZWl0aGVyIHRoZSBYTUwgKGFuZCB1cGRhdGUgdGhlPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVk
LXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+VFhUKSBvciB0aGUgVFhUIGFuZCBzaG93IHdoYXQgaXQg
d291bGQgbG9vazxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+
PGJyPmxpa2UgaW4gdGhlIGRvY3VtZW50PyAmbmJzcDtJIHRoaW5rIHBlcmhhcHMgdHdvPHNwYW4g
Y2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+ZXhhbXBsZXMgd291
bGQgYWxzbyBoZWxwOiBvbmUgd2hlcmUgdGhlIHNvdXJjZTxzcGFuIGNsYXNzPWFwcGxlLWNvbnZl
cnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPmlzIGEgbG9jYWwgZGF0YWJhc2UgYW5kIHRoZSBv
dGhlciB3aGVyZSB0aGU8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9z
cGFuPjxicj5zb3VyY2UgaXMgYSBMb1NUIHNlcnZlci4gJm5ic3A7V2UnZCB0aGVuIGhhdmUgYTxz
cGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPmNvbmNyZXRl
IHByb3Bvc2FsIGluIGZyb250IG9mIHVzIGFuZCB3ZSBjb3VsZDxzcGFuIGNsYXNzPWFwcGxlLWNv
bnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPmFzayBpZiB3ZSBoYXZlIGNvbnNlbnN1cyB0
byBhZG9wdCBpdCBhbmQgbW92ZTxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJz
cDs8L3NwYW4+PGJyPmZvcndhcmQuPGJyPjxicj5KYW1lcywgaWYgQnJpYW4gZG9lcyB0aGlzLCBj
YW4geW91IHRoZW4gbG9vazxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8
L3NwYW4+PGJyPmF0IHRoZSByZXZpc2lvbnMgYW5kIHNlZSBpZiB5b3Ugc3RpbGwgb2JqZWN0PHNw
YW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+b3IgaWYgeW91
IGNhbiBhY2NlcHQgdGhlbT88YnI+PGJyPkF0IDM6MTkgUE0gKzAwMDAgMy8yNi8xNSwgQnJpYW4g
Um9zZW4gd3JvdGU6PGJyPjxicj48YnI+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z
b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRp
Y2EiLCJzYW5zLXNlcmlmIic+Q29tZSBvbiwgdGhlIG1hbmRhdG9yeSBlbGVtZW50cyBhcmUgdGhl
PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+c291cmNl
LCBsYXN0VXBkYXRlZCBhbmQgZXhwaXJlcy4gJm5ic3A7VGhlIHNvdXJjZTxzcGFuIGNsYXNzPWFw
cGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPm1pZ2h0IGJlIHRoZSBIRUxEIHNl
cnZlciwgYnV0IGl0IG1pZ2h0IGJlPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZu
YnNwOzwvc3Bhbj48YnI+c29tZXRoaW5nIGVsc2UuICZuYnNwO0lmIGl0J3MgdGhlIEhFTEQgc2Vy
dmVyLCBzYXk8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxi
cj5zby48YnI+SXQgaXMgYSB0cml2aWFsIGFzayB0aGF0IHlvdSBpbmNsdWRlIHNvdXJjZSw8c3Bh
biBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj5sYXN0VXBkYXRl
ZCBhbmQgZXhwaXJlcyBpbiB0aGUgcmVzcG9uc2UsPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVk
LXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+aWRlbnRpY2FsIHRvIExvU1QuICZuYnNwO0l0IHByb3Zp
ZGVzIGEgbGV2ZWwgb2Y8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9z
cGFuPjxicj5jb21wYXRpYmlsaXR5IHRoYXQgaXMgdXNlZnVsLCBhbmQ8c3BhbiBjbGFzcz1hcHBs
ZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj5ub24taW50cnVzaXZlIGZvciBpbXBs
ZW1lbnRhdGlvbnMgdG88c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9z
cGFuPjxicj5hY2NvbW1vZGF0ZS4gJm5ic3A7SXQgQ09VTEQgYmUgYSBmaXhlZCBzdHJpbmcuPGJy
Pjxicj5Zb3UgdGhpbmsgb2YgaW1wbGVtZW50YXRpb25zIGFzIHRoZSBzZXJ2ZXI8c3BhbiBjbGFz
cz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj5oYXMsIGludGVybmFsbHks
IGFsbCB0aGUgcm91dGluZyBpbmZvcm1hdGlvbi48c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQt
c3BhY2U+Jm5ic3A7PC9zcGFuPjxicj5UaGF0J3Mgb25lIHdheSB0byBkbyBpdC4gJm5ic3A7QW5v
dGhlciB3YXkgdG8gZG88c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9z
cGFuPjxicj5pdCBpcyB0byBoYXZlIHRoZSBIRUxEIHNlcnZlciBjb25zdWx0IGEgTG9TVDxzcGFu
IGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPnNlcnZlci4gJm5i
c3A7WWVzLCBJIGtub3cgeW91IGRvbid0IHRoaW5rIGFueW9uZTxzcGFuIGNsYXNzPWFwcGxlLWNv
bnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPndpbGwgaW1wbGVtZW50IGEgTG9TVCBzZXJ2
ZXIuICZuYnNwO0kgdGhpbmsgeW91PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZu
YnNwOzwvc3Bhbj48YnI+YXJlIHdyb25nLjxicj48YnI+SSB1bmRlcnN0YW5kIHRoYXQgSSBjYW4g
aW5jcmVtZW50YWxseSBhZGQgdGhlPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZu
YnNwOzwvc3Bhbj48YnI+bWFwcGluZyBjb21wb25lbnRzIGFzIGV4dGVuc2lvbnMgaW4gYSB3YXk8
c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj50aGF0IGlz
IHRyYW5zZm9ybWFibGUgdG8gYSAmcXVvdDtyZWFsJnF1b3Q7ICZsdDttYXBwaW5nJmd0OzxzcGFu
IGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPnN0cnVjdHVyZSwg
YnV0IHRoZSBiaXRzIG9uIHRoZSB3aXJlIGFyZTxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1z
cGFjZT4mbmJzcDs8L3NwYW4+PGJyPmRpZmZlcmVudC48YnI+SWYgeW91IHBlcnNpc3QsIGFuZCBj
b25zZW5zdXMgaXMgdG8gaGF2ZSBhbjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4m
bmJzcDs8L3NwYW4+PGJyPmV4dGVuc2lvbiBwb2ludCBhbmQgbm8gbW9yZSwgSSdsbCBzdWJtaXQg
dGhlPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+ZHJh
ZnQgdGhhdCBkb2VzIGl0IHJpZ2h0IGF3YXkuICZuYnNwOyZuYnNwO0RvZXMgdGhhdDxzcGFuIGNs
YXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPlJFQUxMWSBtYWtlIGFu
eSBzZW5zZT88YnI+PGJyPkJyaWFuPGJyPjxicj48YnI+PG86cD48L286cD48L3NwYW4+PC9wPjxw
IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5
OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+T24gTWFyIDI2LCAyMDE1LCBhdCA5OjM1IEFNLCBK
YW1lczxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPldp
bnRlcmJvdHRvbTxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+
PGJyPiZsdDsmbHQ7Jmx0OzxhIGhyZWY9Im1haWx0bzphLmphbWVzLndpbnRlcmJvdHRvbUBnbWFp
bC5jb20iPm1haWx0bzphLmphbWVzLndpbnRlcmJvdHRvbUBnbWFpbC5jb208L2E+Jmd0OzxhIGhy
ZWY9Im1haWx0bzphLmphbWVzLndpbnRlcmJvdHRvbUBnbWFpbC5jb20iPm1haWx0bzphLmphbWVz
LndpbnRlcmJvdHRvbUBnbWFpbC5jb208L2E+Jmd0OyZsdDs8YSBocmVmPSJtYWlsdG86YS5qYW1l
cy53aW50ZXJib3R0b21AZ21haWwuY29tIj5tYWlsdG86YS5qYW1lcy53aW50ZXJib3R0b21AZ21h
aWwuY29tPC9hPiZndDs8YSBocmVmPSJtYWlsdG86YS5qYW1lcy53aW50ZXJib3R0b21AZ21haWwu
Y29tIj5hLmphbWVzLndpbnRlcmJvdHRvbUBnbWFpbC5jb208L2E+Jmd0OzxzcGFuIGNsYXNzPWFw
cGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPndyb3RlOjxicj48YnI+SFVIPz8/
Pzxicj48YnI+QXMgSSBoYXZlIHNhaWQgYmVmb3JlIGFuZCBhcyB0aGUgZHJhZnQ8c3BhbiBjbGFz
cz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj5zdGF0ZXMsIGF0IGxlYXN0
IG9mIHRoZSBtYW5kYXRvcnkgbWFwcGluZzxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFj
ZT4mbmJzcDs8L3NwYW4+PGJyPmVsZW1lbnRzIGlzIG5vdCBhcHBsaWNhYmxlIHdoZXJlIHlvdSBk
b24ndDxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPkxv
U1QsIHNvIHNpbXBseSByZXN1bWluZyBtYXBwaW5nIGRvZXNuJ3Q8c3BhbiBjbGFzcz1hcHBsZS1j
b252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj53b3JrLjxicj48YnI+SWYgd2UgcHV0IHRo
ZSBleHRlbnNpb24gcG9pbnQgaW4sIGFuZCB5b3U8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQt
c3BhY2U+Jm5ic3A7PC9zcGFuPjxicj53YW50IHRvIHJldXNlIG1hcHBpbmcgZWxlbWVudHMgaW4g
eW91cjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPmlt
cGxlbWVudGF0aW9uIHlvdSBjYW4gc2ltcGx5IHJlZmVyZW5jZSB0aGVtPHNwYW4gY2xhc3M9YXBw
bGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+aW4gdGhlIGV4dGVuc2lvbiBwb2lu
dCwgbm8gc3BlY2lmaWNhdGlvbjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJz
cDs8L3NwYW4+PGJyPnJlcXVpcmVkIGFuZCB0aGluZ3MgdGhhdCBjaG9vc2Ugbm90IHRvPHNwYW4g
Y2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+dW5kZXJzdGFuZCB0
aGUgZXh0ZW5zaW9uIGNhbiBpZ25vcmUgJm5ic3A7dGhlbS48c3BhbiBjbGFzcz1hcHBsZS1jb252
ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj5ObyBleHRyYSBzcGVjaWZpY2F0aW9uIHJlcXVp
cmVkLCBubyBleHRyYTxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3Nw
YW4+PGJyPndvcmsgYXQgYWxsIHJlcXVpcmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbiw8c3BhbiBj
bGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj5ub3QgZXZlbiAxMCBt
aW51dGVzIGVkaXRpbmcgYW5kIDQgeWVhcnMgb2Y8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQt
c3BhY2U+Jm5ic3A7PC9zcGFuPjxicj5oYWdnbGluZy48YnI+PGJyPkNoZWVyczxicj5KYW1lczxi
cj48YnI+PGJyPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g
c3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJp
ZiInPk9uIDI3IE1hciAyMDE1LCBhdCAxOjMxIGFtLCBSb3NlbiwgQnJpYW48c3BhbiBjbGFzcz1h
cHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj4mbHQ7Jmx0OyZsdDs8YSBocmVm
PSJtYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXoiPm1haWx0bzpCcmlhbi5Sb3NlbkBuZXVz
dGFyLmJpejwvYT4mZ3Q7PGEgaHJlZj0ibWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6Ij5t
YWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo8L2E+Jmd0OyZsdDs8YSBocmVmPSJtYWlsdG86
QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXoiPm1haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpejwv
YT4mZ3Q7PGEgaHJlZj0ibWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6Ij5Ccmlhbi5Sb3Nl
bkBuZXVzdGFyLmJpejwvYT4mZ3Q7PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZu
YnNwOzwvc3Bhbj48YnI+d3JvdGU6PGJyPjxicj5JIGRvbid0IHVuZGVyc3RhbmQgYW55IG9mIHRo
aXMgbG9naWMuPGJyPjxicj5Zb3UgaW1wb3J0IHRoZSBkZWZpbml0aW9uIGZyb20gUkZDNTIyMiBh
bmQ8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj5yZWZl
ciB0byBpdCBmb3IgdGhlIG1lYW5pbmcgb2YgdGhlPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVk
LXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+ZWxlbWVudHMuICZuYnNwO0RvbmUuICZuYnNwO05vIHRp
bWUgZGVsYXkuICZuYnNwOzEwPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNw
Ozwvc3Bhbj48YnI+bWludXRlcyBvZiBlZGl0aW5nLjxicj48YnI+SSB3YW50IHRvIGJlIGFibGUg
dG8gYnVpbGQgc3lzdGVtcyB0aGF0PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZu
YnNwOzwvc3Bhbj48YnI+d29yayB3b3JsZC13aWRlLiAmbmJzcDtUaGUgbW9yZSBjb21tb25hbGl0
eSBvZjxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPmRh
dGEgc3RydWN0dXJlcywgdGhlIGJldHRlci48YnI+PGJyPllvdSBoYXZlIG5vdCBzaG93biBhbnkg
aGFybSB0byByZS11c2Ugb2YgYTxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJz
cDs8L3NwYW4+PGJyPmRhdGEgc3RydWN0dXJlIHRoYXQgd2FzIGRlc2lnbmVkIGZvciB0aGU8c3Bh
biBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj5wdXJwb3NlIHlv
dSBoYXZlLCBoYXMgaGFkIGV4dGVuc2l2ZSBJRVRGPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVk
LXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+cmV2aWV3LCBpbXBsZW1lbnRhdGlvbiwgYW5kIGNvbnNl
bnN1cy4gJm5ic3A7WW91PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwv
c3Bhbj48YnI+d2FudCB0byBpbnZlbnQgc29tZXRoaW5nIG5ldy4gJm5ic3A7SXQncyBjbGVhcmx5
PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+YSBzdWJz
ZXQsIGJ1dCBpdCdzIG5vdCBwcmVjaXNlbHkgYSBzdWJzZXQuPHNwYW4gY2xhc3M9YXBwbGUtY29u
dmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+VGhhdCBpcyBub3QgYSBnb29kIGlkZWEgaW4g
bXkgb3Bpbmlvbi4gJm5ic3A7QXM8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5i
c3A7PC9zcGFuPjxicj50aGUgbWFqb3JpdHkgb2YgZWxlbWVudHMgaW4gJmx0O21hcHBpbmcmZ3Q7
IGFyZTxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPm9w
dGlvbmFsLCBhbiBpbXBsZW1lbnRhdGlvbiBjYW4gY2hvb3NlPHNwYW4gY2xhc3M9YXBwbGUtY29u
dmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+bmV2ZXIgdG8gc2VuZCB0aGVtIChzZXJ2ZXIp
IG9yIGlnbm9yZSB0aGVtPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwv
c3Bhbj48YnI+aWYgcmVjZWl2ZWQgKGNsaWVudCkuICZuYnNwO0lmIHlvdSB1c2UgdGhlPHNwYW4g
Y2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+ZXh0ZW5zaW9uIHBv
aW50ICgzKSwgYW5kIHdlIGxhdGVyIGRlY2lkZTxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1z
cGFjZT4mbmJzcDs8L3NwYW4+PGJyPnRoYXQgbW9zdCBvZiAmbHQ7bWFwcGluZyZndDsgaXMgaW4g
ZmFjdCB1c2VmdWwsPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bh
bj48YnI+d2Ugd291bGQgZW5kIHVwIGRpZmZlcmVudCBkYXRhIHN0cnVjdHVyZXMsPHNwYW4gY2xh
c3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+YmVjYXVzZSB0aGUgYmFz
ZSBzdHJ1Y3R1cmUgaXMgZGlmZmVyZW50Ljxicj48YnI+QnJpYW48YnI+PGJyPjxicj48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6IkhlbHZldGljYSIsInNhbnMtc2VyaWYiJz5PbiBNYXIgMjYsIDIw
MTUsIGF0IDg6MjIgQU0sIExhdXJhIExpZXNzPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNw
YWNlPiZuYnNwOzwvc3Bhbj48YnI+Jmx0OyZsdDsmbHQ7PGEgaHJlZj0ibWFpbHRvOmxhdXJhLmxp
ZXNzLmR0QGdvb2dsZW1haWwuY29tIj5tYWlsdG86bGF1cmEubGllc3MuZHRAZ29vZ2xlbWFpbC5j
b208L2E+Jmd0OzxhIGhyZWY9Im1haWx0bzpsYXVyYS5saWVzcy5kdEBnb29nbGVtYWlsLmNvbSI+
bWFpbHRvOmxhdXJhLmxpZXNzLmR0QGdvb2dsZW1haWwuY29tPC9hPiZndDsmbHQ7PGEgaHJlZj0i
bWFpbHRvOmxhdXJhLmxpZXNzLmR0QGdvb2dsZW1haWwuY29tIj5tYWlsdG86bGF1cmEubGllc3Mu
ZHRAZ29vZ2xlbWFpbC5jb208L2E+Jmd0OzxhIGhyZWY9Im1haWx0bzpsYXVyYS5saWVzcy5kdEBn
b29nbGVtYWlsLmNvbSI+bGF1cmEubGllc3MuZHRAZ29vZ2xlbWFpbC5jb208L2E+Jmd0OzxzcGFu
IGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPndyb3RlOjxicj48
YnI+SSB3b3VsZCBwcmVmZXIgMykgYW5kIEkgY2FuIGxpdmUgd2l0aCAyKS48YnI+PGJyPkkgYW0g
b3Bvc2VkIHRvIDEpIGJlY2F1c2UgaXQgd291bGQgZGVsYXk8c3BhbiBjbGFzcz1hcHBsZS1jb252
ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj50aGUgZHJhZnQgcHJvZ3Jlc3MsIGp1c3QgdG8g
YWRkIGZlYXR1cmVzPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bh
bj48YnI+YWJvdXQgd2UgZG9uJ3Qga25vdyBpZiBhbnlvbmUgd2lsbCBuZWVkPHNwYW4gY2xhc3M9
YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+dGhlbSBhbmRpZiBzbywgJm5i
c3A7d2hhdCBleGFjdGx5IHdpbGwgYmU8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+
Jm5ic3A7PC9zcGFuPjxicj5uZWVkZWQuIEZvciB0aGUgd29yayBpbiBFVFNJIG9uIHRoZSBFQzxz
cGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPk00OTMgdGhp
cyBpcyBjbGVhcmx5IG5vdCBuZWVkZWQuIEVUU0k8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQt
c3BhY2U+Jm5ic3A7PC9zcGFuPjxicj5uZWVkcyB0aGUgZHJhZnQgZmluaXNoZWQgdmVyeSBzb29u
LCBpZiB3ZTxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJy
PndhbnQgdGhlIGZpbmFsIEVUU0kgc3BlY2lmaWNhdGlvbiw8c3BhbiBjbGFzcz1hcHBsZS1jb252
ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj50YXJnZXRlZCBmb3IgdGhlIGVuZCBvZiB0aGlz
IHllYXIsIHRvPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48
YnI+cmVmZXIgYW4gUkZDIGFuZCBub3QgYSBkcmFmdCBhbmQgdGhlPHNwYW4gY2xhc3M9YXBwbGUt
Y29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+aW1wbGVtZW50YXRpb25zIHdoaWNoIHdp
bGwgY29tZSB0aGVuIHNvb24sPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNw
Ozwvc3Bhbj48YnI+dG8gYmUgYmFzZWQgYW4gUkZDIGFuZCBub3Qgb24gc29tZTxzcGFuIGNsYXNz
PWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPmludGVybWVkaWFyeSB2ZXJz
aW9uIG9mIHRoZSBkcmFmdC48YnI+PGJyPkkgdGhpbmsgMykgaXMgYSBnb29kIHNvbHV0aW9uLCBm
bGV4aWJsZTxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJy
PmVub3VnaCB0aGF0IGV2ZXJ5b25lIGNvdWxkIGxpdmUgd2l0aCBpdC48YnI+PGJyPlRoYW5rIHlv
dTxicj4mbmJzcDtMYXVyYTxicj48YnI+MjAxNS0wMy0yNSAyMDoyMSBHTVQrMDE6MDAgSmFtZXM8
c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj5XaW50ZXJi
b3R0b208c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj4m
bHQ7Jmx0OyZsdDs8YSBocmVmPSJtYWlsdG86YS5qYW1lcy53aW50ZXJib3R0b21AZ21haWwuY29t
Ij5tYWlsdG86YS5qYW1lcy53aW50ZXJib3R0b21AZ21haWwuY29tPC9hPiZndDs8YSBocmVmPSJt
YWlsdG86YS5qYW1lcy53aW50ZXJib3R0b21AZ21haWwuY29tIj5tYWlsdG86YS5qYW1lcy53aW50
ZXJib3R0b21AZ21haWwuY29tPC9hPiZndDsmbHQ7PGEgaHJlZj0ibWFpbHRvOmEuamFtZXMud2lu
dGVyYm90dG9tQGdtYWlsLmNvbSI+bWFpbHRvOmEuamFtZXMud2ludGVyYm90dG9tQGdtYWlsLmNv
bTwvYT4mZ3Q7PGEgaHJlZj0ibWFpbHRvOmEuamFtZXMud2ludGVyYm90dG9tQGdtYWlsLmNvbSI+
YS5qYW1lcy53aW50ZXJib3R0b21AZ21haWwuY29tPC9hPiZndDs6PGJyPjxicj5UaGVyZSBpcyBk
b3duc2lkZSB0byB1c2luZyB0aGUgZXhpc3Rpbmc8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQt
c3BhY2U+Jm5ic3A7PC9zcGFuPjxicj5zY2hlbWEgQnJpYW4sIHRoaXMgaXMgc3BlbHQgb3V0IGNs
ZWFybHkgaW48c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxi
cj50aGUgZHJhZnQuIEluIG9yZGVyIHRvIGluY2x1ZGUgdGhlIGZpZWxkczxzcGFuIGNsYXNzPWFw
cGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPnlvdSB3YW50IGEgbmV3IGVsZW1l
bnQgd291bGQgbmVlZCB0byBiZTxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJz
cDs8L3NwYW4+PGJyPmRlZmluZWQgaW4gdGhpcyBkcmFmdCB0byBzdXBwb3J0IGl0LiBJPHNwYW4g
Y2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+dGhpbmsgdGhhdCB0
aGF0IGlzIHRoZSB3cm9uZyB3YXkgdG8gZG8gaXQ8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQt
c3BhY2U+Jm5ic3A7PC9zcGFuPjxicj5hcyB0aGVyZSBoYXMgYmVlbiBubyBleHByZXNzaW9uIG9m
IG5lZWQuPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+
SWYgYSBuZWVkIGFycmlzZXMgYWZ0ZXIgdGhpcyBkcmFmdCBpczxzcGFuIGNsYXNzPWFwcGxlLWNv
bnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPmRvbmUsIHRoZW4gaXQgY2FuIGJlIGFkZGVk
IGxhdGVyLiBSaWdodDxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3Nw
YW4+PGJyPm5vdyBpdCBpc24ndCBuZWVkZWQuPGJyPjxicj5BcyBJIHNhaWQgaW4gbXkgcHJlZmVy
ZW5jZSBmb3Igb3B0aW9uIDMsIEk8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5i
c3A7PC9zcGFuPjxicj50aGluayB0aGF0IHRoZSBleHRlbnNpb24gcG9pbnQgc2hvdWxkIGJlPHNw
YW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+YWRkZWQgdGhl
biBhbnl0aGluZyBjYW4gYmUgYWRkZWQgbGF0ZXIgaWY8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0
ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj5yZXF1aXJlZC48YnI+PGJyPkNoZWVyczxicj5KYW1l
czxicj48YnI+PGJyPjxicj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkhlbHZldGljYSIsInNh
bnMtc2VyaWYiJz5PbiAyNiBNYXIgMjAxNSwgYXQgMjo1MiBhbSwgUm9zZW4sIEJyaWFuPHNwYW4g
Y2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+Jmx0OyZsdDsmbHQ7
PGEgaHJlZj0ibWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6Ij5tYWlsdG86QnJpYW4uUm9z
ZW5AbmV1c3Rhci5iaXo8L2E+Jmd0OzxhIGhyZWY9Im1haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFy
LmJpeiI+bWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6PC9hPiZndDsmbHQ7PGEgaHJlZj0i
bWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6Ij5tYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rh
ci5iaXo8L2E+Jmd0OzxhIGhyZWY9Im1haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpeiI+QnJp
YW4uUm9zZW5AbmV1c3Rhci5iaXo8L2E+Jmd0OzxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1z
cGFjZT4mbmJzcDs8L3NwYW4+PGJyPndyb3RlOjxicj48YnI+TGV0J3Mgc2F5IHRoYXQgc29tZW9u
ZSBjb21lcyBhbG9uZyBhbmQ8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7
PC9zcGFuPjxicj5zaG93cyBhIGRlY2VudCB1c2UgY2FzZSBmb3IgaW5jbHVkaW5nIGE8c3BhbiBj
bGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj5zZXJ2aWNlIGJvdW5k
YXJ5Ljxicj48YnI+U28gdGhleSBkZWZpbmUgYW4gZXh0ZW5zaW9uIGZvciBpdC48YnI+PGJyPlRo
YXQgZXh0ZW5zaW9uIG1heSBvciBtYXkgbm90IGJlIHRoZSBzYW1lPHNwYW4gY2xhc3M9YXBwbGUt
Y29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+YXMgdGhlIHNlcnZpY2UgYm91bmRhcnkg
dGhhdCBMb1NUPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48
YnI+cmV0dXJucy4gQW4gaW1wbGVtZW50YXRpb24gZGVzaWduZWQgdG88c3BhbiBjbGFzcz1hcHBs
ZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj5wcm92aWRlIHdvcmxkLXdpZGUgc2Vy
dmljZSB3b3VsZCBoYXZlIHRvPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNw
Ozwvc3Bhbj48YnI+Y2hhbmdlLjxicj48YnI+UmV0dXJuaW5nIHRoZSBib3VuZGFyeSBpcyBhbHJl
YWR5IG9wdGlvbmFsIGluIHRoZSBMb1NUIHNjaGVtYS48YnI+PGJyPklmIHdlIHVzZWQgdGhlIGV4
aXN0aW5nIGRlZmluaXRpb246PGJyPjEuIE5vIG5ldyBkb2N1bWVudCBpcyByZXF1aXJlZDxicj4y
LiBDb21wYXRpYmlsaXR5IGJldHdlZW4gdGhpcyBIRUxEIGV4dGVuc2lvbiBhbmQgTG9TVCBpcyBt
YWludGFpbmVkPGJyPjMuIFN5c3RlbXMgYnVpbHQgdG8gc3VwcG9ydCBib3RoIG1vZGVscyBkb24n
dCBoYXZlIHRvIGNoYW5nZTxicj48YnI+VGhlcmUgaXMsIGFzIGZhciBhcyBJIGNhbiBzZWUsIG5v
PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+ZG93bnNp
ZGUgdG8gdXNpbmcgdGhlIGV4aXN0aW5nIHNjaGVtYTxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRl
ZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPm90aGVyIHRoYW4gbWFraW5nIHRoZSBzbWFsbGVzdCBw
b3NzaWJsZTxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJy
PnJlc3BvbnNlIGEgYml0IGJpZ2dlci4gJm5ic3A7Jm5ic3A7T25lIGNhbiBhbHdheXM8c3BhbiBj
bGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj5pZ25vcmUgYW55IHJl
dHVybmVkIGl0ZW1zIG5vdDxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8
L3NwYW4+PGJyPm5lZWRlZC93YW50ZWQsIGFuZCBzaW5jZSB0aGV5IGFyZTxzcGFuIGNsYXNzPWFw
cGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPm9wdGlvbmFsIHRoZXkgY2FuJ3Qg
YmUgYXNzdW1lZCB0byBiZTxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8
L3NwYW4+PGJyPnRoZXJlLjxicj48YnI+T3B0aW9uIDIgKGRvbid0IGFsbG93IGFuIGV4dGVuc2lv
biBwb2ludDxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJy
Pm9uIHRoZSByZXR1cm4pIG1ha2VzIG5vIHNlbnNlIHRvIG1lLiAmbmJzcDtJPHNwYW4gY2xhc3M9
YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+Y2FuJ3QgaW1hZ2luZSB0aGUg
SUVURiBkb2luZyB0aGF0LiBBbnk8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5i
c3A7PC9zcGFuPjxicj5leHRlbnNpb24gd291bGQgdGhlbiByZXF1aXJlIGFsbCBleGlzdGluZzxz
cGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPmltcGxlbWVu
dGF0aW9ucyB0byBiZSBjaGFuZ2VkLjxicj48YnI+QnJpYW48YnI+PGJyPjxicj48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBw
dCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiSGVsdmV0aWNhIiwi
c2Fucy1zZXJpZiInPk9uIE1hciAyNSwgMjAxNSwgYXQgOTo0OSBBTSw8c3BhbiBjbGFzcz1hcHBs
ZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj4mbHQ7Jmx0OzxhIGhyZWY9Im1haWx0
bzpSLkplc3NrZUB0ZWxla29tLmRlIj5tYWlsdG86Ui5KZXNza2VAdGVsZWtvbS5kZTwvYT4mZ3Q7
PGEgaHJlZj0ibWFpbHRvOlIuSmVzc2tlQHRlbGVrb20uZGUiPm1haWx0bzpSLkplc3NrZUB0ZWxl
a29tLmRlPC9hPiZndDsmbHQ7PGEgaHJlZj0ibWFpbHRvOlIuSmVzc2tlQHRlbGVrb20uZGUiPm1h
aWx0bzpSLkplc3NrZUB0ZWxla29tLmRlPC9hPiZndDs8YSBocmVmPSJtYWlsdG86Ui5KZXNza2VA
dGVsZWtvbS5kZSI+Ui5KZXNza2VAdGVsZWtvbS5kZTwvYT48c3BhbiBjbGFzcz1hcHBsZS1jb252
ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPndyb3RlOjxicj48YnI+SGkgSmFtZXMsPGJyPnRoYW5r
IHlvdSBmb3IgdGhlIHN1bW1hcnkuPGJyPk15IHBvc2l0aW9uIGlzIHJlZmxlY3RlZCBpbiBwb2lu
dCAyLjxicj48YnI+SWYgcGVvcGxlIHdhbnQgdG8gYWRkIHNvbWV0aGluZyB0byBhPHNwYW4gY2xh
c3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+bWVjaGFuaXNtIGNhbiBp
dCBub3QgYmUgZG9uZSBvbmx5IGluPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZu
YnNwOzwvc3Bhbj48YnI+d3JpdGluZyBhIGZ1cnRoZXIgZHJhZnQ/PGJyPlRoaXMgbWVhbnMgYWxz
byBpbmNsdWRpbmcgaW4gc3VjaCBhIGRyYWZ0IGFsc28gYSBleHRlbnNpb24gbWVjaGFuaXNtLjxi
cj48YnI+SSB0aGluayB0aGF0IHdvdWxkIGJlIGEgY2xlYXIgbGluZSB0byBzYXRpc2Z5IGV2ZXJ5
Ym9keS48YnI+PGJyPjxicj5CZXN0IFJlZ2FyZHM8YnI+PGJyPlJvbGFuZDxicj48YnI+LS0tLS1V
cnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLTxicj5Wb246IEVjcml0PHNwYW4gY2xhc3M9YXBw
bGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+WzxhIGhyZWY9Im1haWx0bzolM2Mi
Pm1haWx0bzombHQ7PC9hPiZsdDs8YSBocmVmPSJtYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9y
ZyI+bWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OzxhIGhyZWY9Im1haWx0bzpl
Y3JpdC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZzwvYT4m
Z3Q7Jmx0OzxhIGhyZWY9Im1haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86ZWNy
aXQtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7PGEgaHJlZj0ibWFpbHRvOmVjcml0LWJvdW5jZXNA
aWV0Zi5vcmciPmVjcml0LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XTxzcGFuIGNsYXNzPWFwcGxlLWNv
bnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGJyPkltIEF1ZnRyYWcgdm9uIEphbWVzIFdpbnRl
cmJvdHRvbTxicj5HZXNlbmRldDogTWl0dHdvY2gsIDI1LiBNw6RyeiAyMDE1IDA5OjAzPGJyPkFu
OiAmbHQ7Jmx0OzxhIGhyZWY9Imh0dHA6Ly9lY3JpdF9pZXRmLm9yZy8iPmh0dHA6Ly9lY3JpdF9p
ZXRmLm9yZy88L2E+Jmd0OzxhIGhyZWY9Imh0dHA6Ly9lY3JpdF9pZXRmLm9yZy8iPmh0dHA6Ly9l
Y3JpdF9pZXRmLm9yZy88L2E+Jmd0O2Vjcml0X2lldGYub3JnPGJyPkJldHJlZmY6IFtFY3JpdF0g
SEVMRCBSb3V0aW5nIHN1bW1hcnk8YnI+PGJyPkhpIEFsbCw8YnI+PGJyPkFzIEkgc2VlIGl0IHRo
ZXJlIGlzIG9uZSBvcGVuIGRpc2N1c3Npb248c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3Bh
Y2U+Jm5ic3A7PC9zcGFuPjxicj5wb2ludCBhbmQgdGhyZWUgcG9zaXRpb25zIG9uIHRoaXMgcG9p
bnQuPGJyPlRoZSBkaXNjdXNzaW9uIHBvaW50IGlzIHdoZXRoZXIgb3Igbm90PHNwYW4gY2xhc3M9
YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+YWxsIG9mIHRoZSBhbmNpbGxh
cnkgZGF0YSB0aGF0IGlzPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwv
c3Bhbj48YnI+cmV0dXJuZWQgYnkgYSBMb1NUIGZpbmRTZXJ2aWNlIHJlcXVlc3Q8c3BhbiBjbGFz
cz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj5zaG91bGQgYmUgaW5jbHVk
ZWQgaW4gdGhlIEhFTEQgcm91dGluZzxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4m
bmJzcDs8L3NwYW4+PGJyPnJlc3BvbnNlIG9yIG5vdC48YnI+PGJyPlRoZSB0aHJlZSBwb3NpdGlv
bnMgdGhhdCBoYXZlIGJlZW48c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7
PC9zcGFuPjxicj5zdGF0ZWQgYXJlIChpbiBubyBwYXJ0aWN1bGFyIG9yZGVyKTo8YnI+MSkgVGhl
IGRlZmluaXRpb24gZm9yIHRoaXMgaW5mb3JtYXRpb248c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0
ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj5zaG91bGQgYmUgaW5jbHVkZWQgaW4gdGhlIGJhc2U8
c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj5zcGVjaWZp
Y2F0aW9uIGJ1dCBpcyBvcHRpb25hbCB0byBzZW5kIG9yPHNwYW4gY2xhc3M9YXBwbGUtY29udmVy
dGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+YmUgYWN0ZWQgb24uPGJyPjIpIElzbid0IHJlcXVp
cmVkIGF0IGFsbCwgbGV0IHRoZSBjdXJyZW50IGRyYWZ0IHN0YW5kPGJyPjMpIEFkZCBhbiBleHRl
bnNpb24gcG9pbnQgdG8gdGhlIHNjaGVtYTxzcGFuIGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFj
ZT4mbmJzcDs8L3NwYW4+PGJyPmluIHRoZSBkcmFmdCBzbyB0aGF0IHRoZSBleHRyYSBjYW4gYmU8
c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxicj5zcGVjaWZp
ZWQgaW4gYSBkaWZmZXJlbnQgZHJhZnQgYW5kIGFkZGVkPHNwYW4gY2xhc3M9YXBwbGUtY29udmVy
dGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+Ynkgc29tZXRoaW5nIHJlcXVpcmluZyBpdC48YnI+
PGJyPlRoaXMgZW1haWwgbWFrZXMgbm8gY2xhaW1zIHRvPHNwYW4gY2xhc3M9YXBwbGUtY29udmVy
dGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+cHJlZmVyZW5jZSwgYnV0IGp1c3QgcHJlc2VudHMg
dGhlPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48YnI+b3Bp
bmlvbnMgdGhhdCBoYXZlIGJlZW4gZXhwcmVzc2VkLjxicj48YnI+Q2hlZXJzPGJyPkphbWVzPGJy
Pjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5F
Y3JpdCBtYWlsaW5nIGxpc3Q8YnI+PGJyPiZsdDsmbHQ7PGEgaHJlZj0ibWFpbHRvOkVjcml0QGll
dGYub3JnIj5tYWlsdG86RWNyaXRAaWV0Zi5vcmc8L2E+Jmd0OzxhIGhyZWY9Im1haWx0bzpFY3Jp
dEBpZXRmLm9yZyI+bWFpbHRvOkVjcml0QGlldGYub3JnPC9hPiZndDsmbHQ7PGEgaHJlZj0ibWFp
bHRvOkVjcml0QGlldGYub3JnIj5tYWlsdG86RWNyaXRAaWV0Zi5vcmc8L2E+Jmd0OzxhIGhyZWY9
Im1haWx0bzpFY3JpdEBpZXRmLm9yZyI+RWNyaXRAaWV0Zi5vcmc8L2E+PGJyPjxicj4mbHQ7Jmx0
OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQiPmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQ8L2E+Jmd0OzxhIGhyZWY9
Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQiPmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQ8L2E+Jmd0OyAmbHQ7PGEgaHJlZj0iaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdCI+aHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdDwvYT4mZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9lY3JpdDwvYT48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX188YnI+RWNyaXQgbWFpbGluZyBsaXN0PGJyPjxicj4mbHQ7Jmx0Ozxh
IGhyZWY9Im1haWx0bzpFY3JpdEBpZXRmLm9yZyI+bWFpbHRvOkVjcml0QGlldGYub3JnPC9hPiZn
dDs8YSBocmVmPSJtYWlsdG86RWNyaXRAaWV0Zi5vcmciPm1haWx0bzpFY3JpdEBpZXRmLm9yZzwv
YT4mZ3Q7Jmx0OzxhIGhyZWY9Im1haWx0bzpFY3JpdEBpZXRmLm9yZyI+bWFpbHRvOkVjcml0QGll
dGYub3JnPC9hPiZndDs8YSBocmVmPSJtYWlsdG86RWNyaXRAaWV0Zi5vcmciPkVjcml0QGlldGYu
b3JnPC9hPjxicj48YnI+Jmx0OyZsdDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL2Vjcml0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L2Vjcml0PC9hPiZndDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL2Vjcml0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0PC9h
PiZndDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
ZWNyaXQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQ8L2E+Jmd0
OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQiPmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQ8L2E+PG86cD48L286cD48
L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQn
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6IkhlbHZldGljYSIsInNh
bnMtc2VyaWYiJz48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX188YnI+RWNyaXQgbWFpbGluZyBsaXN0PGJyPjxicj4mbHQ7Jmx0OzxhIGhyZWY9Im1haWx0
bzpFY3JpdEBpZXRmLm9yZyI+bWFpbHRvOkVjcml0QGlldGYub3JnPC9hPiZndDs8YSBocmVmPSJt
YWlsdG86RWNyaXRAaWV0Zi5vcmciPm1haWx0bzpFY3JpdEBpZXRmLm9yZzwvYT4mZ3Q7Jmx0Ozxh
IGhyZWY9Im1haWx0bzpFY3JpdEBpZXRmLm9yZyI+bWFpbHRvOkVjcml0QGlldGYub3JnPC9hPiZn
dDs8YSBocmVmPSJtYWlsdG86RWNyaXRAaWV0Zi5vcmciPkVjcml0QGlldGYub3JnPC9hPjxicj48
YnI+Jmx0OyZsdDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L2Vjcml0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0PC9hPiZn
dDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0Ij5o
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0PC9hPiZndDsmbHQ7PGEg
aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdCI+aHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdDwvYT4mZ3Q7PGEgaHJlZj0iaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdCI+aHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg
Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
IkhlbHZldGljYSIsInNhbnMtc2VyaWYiJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg
Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gc3R5bGU9
J2ZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiInPjxi
cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5FY3Jp
dCBtYWlsaW5nIGxpc3Q8YnI+PGJyPiZsdDsmbHQ7PGEgaHJlZj0ibWFpbHRvOkVjcml0QGlldGYu
b3JnIj5tYWlsdG86RWNyaXRAaWV0Zi5vcmc8L2E+Jmd0OzxhIGhyZWY9Im1haWx0bzpFY3JpdEBp
ZXRmLm9yZyI+bWFpbHRvOkVjcml0QGlldGYub3JnPC9hPiZndDsmbHQ7PGEgaHJlZj0ibWFpbHRv
OkVjcml0QGlldGYub3JnIj5tYWlsdG86RWNyaXRAaWV0Zi5vcmc8L2E+Jmd0OzxhIGhyZWY9Im1h
aWx0bzpFY3JpdEBpZXRmLm9yZyI+RWNyaXRAaWV0Zi5vcmc8L2E+PGJyPjxicj4mbHQ7PGEgaHJl
Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdCI+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdDwvYT4mZ3Q7PGEgaHJlZj0iaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdCI+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh
c3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiInPjxicj48
YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+RWNy
aXQgbWFpbGluZyBsaXN0PGJyPiZsdDs8YSBocmVmPSJtYWlsdG86RWNyaXRAaWV0Zi5vcmciPm1h
aWx0bzpFY3JpdEBpZXRmLm9yZzwvYT4mZ3Q7PGEgaHJlZj0ibWFpbHRvOkVjcml0QGlldGYub3Jn
Ij5FY3JpdEBpZXRmLm9yZzwvYT48YnI+PGJyPiZsdDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL2Vjcml0PC9hPiZndDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL2Vjcml0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L2Vjcml0PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9
J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+PGJyPjxicj48YnI+LS08YnI+UmFuZGFs
bCBHZWxsZW5zPGJyPk9waW5pb25zIGFyZSBwZXJzb25hbDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ZmFj
dHMgYXJlIHN1c3BlY3Q7ICZuYnNwOyZuYnNwOyZuYnNwO0kgc3BlYWsgZm9yIG15c2VsZiBvbmx5
PGJyPi0tLS0tLS0tLS0tLS0tIFJhbmRvbWx5IHNlbGVjdGVkIHRhZzogLS0tLS0tLS0tLS0tLS0t
PGJyPlNwb3R0ZWQgb24gdGhlIGJhY2sgb2YgYSB0LXNoaXJ0IHdvcm4gYnkgTEFQRCBCb21iIFNx
dWFkOjxicj4mcXVvdDtJZiB5b3Ugc2VlIG1lIHJ1bm5pbmcsIHRyeSB0byBrZWVwIHVwLiZxdW90
OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiInPjxicj48
YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+RWNy
aXQgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpFY3JpdEBpZXRmLm9yZyI+RWNyaXRA
aWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vZWNyaXQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQ8
L2E+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+PGJy
Pjxicj48YnI+LS08YnI+UmFuZGFsbCBHZWxsZW5zPGJyPk9waW5pb25zIGFyZSBwZXJzb25hbDsg
Jm5ic3A7Jm5ic3A7Jm5ic3A7ZmFjdHMgYXJlIHN1c3BlY3Q7ICZuYnNwOyZuYnNwOyZuYnNwO0kg
c3BlYWsgZm9yIG15c2VsZiBvbmx5PGJyPi0tLS0tLS0tLS0tLS0tIFJhbmRvbWx5IHNlbGVjdGVk
IHRhZzogLS0tLS0tLS0tLS0tLS0tPGJyPlNraXBwZXI6ICZuYnNwOyZuYnNwO01yLiBIb3dlbGws
IFlvdSBkb24ndCBrbm93IHdoYXQgaXQncyBsaWtlIG91dCB0aGVyZSBpbjxicj4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0aGUgb2Nl
YW4sIHlvdSBtYXkgYmUgYml0dGVuIGJ5IGEgc2hhcmshPGJyPlRodXJzdG9uOiAmbmJzcDtBIHNo
YXJrIGJpdGUgYSBIb3dlbGwsIGhhIGhhIGhlIHdvdWxkbid0IGRhcmUuPGJyPlNraXBwZXI6ICZu
YnNwOyZuYnNwO0Jlc2lkZXMgd2UgZG9uJ3QgaGF2ZSByb29tIGVub3VnaCBmb3IgeW91ciBsdWdn
YWdlLjxicj5UaHVyc3RvbjogJm5ic3A7V2VsbCB0aGF0J3MgZGlmZmVyZW50LiBJZiBJIGNhbid0
IGdvIGZpcnN0IGNsYXNzIEkgd29uJ3Q8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Z28gYXQgYWxsLjwvc3Bhbj48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjxwIGNsYXNzPU1z
b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseToiQ2FsaWJy
aSIsInNhbnMtc2VyaWYiJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+
PC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48
bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2JvZHk+PC9odG1sPg==

--_000_058CE00BD4D6B94FAD033A2439EA1E4B01E9E52D8834HE113667eme_--


From nobody Thu Mar 26 14:52:50 2015
Return-Path: 
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3068D1B2FA0 for ; Thu, 26 Mar 2015 14:52:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level: 
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 NPu2Yanc1sJI for ; Thu, 26 Mar 2015 14:52:42 -0700 (PDT)
Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B29321B2FA5 for ; Thu, 26 Mar 2015 14:52:38 -0700 (PDT)
Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) with ESMTP id 6af74155.2ab4199ca940.1095841.00-2437.3101897.nbfkord-smmo07.seg.att.com (envelope-from );  Thu, 26 Mar 2015 21:52:38 +0000 (UTC)
X-MXL-Hash: 55147fa6402ff72a-cface8168a67dd5fb24e66065ef5bdb409c79925
Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 1af74155.0.1095807.00-2327.3101788.nbfkord-smmo07.seg.att.com (envelope-from );  Thu, 26 Mar 2015 21:52:34 +0000 (UTC)
X-MXL-Hash: 55147fa234a81b0f-c1264575221bad2137a379676c8a4d5eb40e3450
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t2QLqWHF025905; Thu, 26 Mar 2015 17:52:33 -0400
Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t2QLqQOF025870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 26 Mar 2015 17:52:28 -0400
Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Thu, 26 Mar 2015 21:52:10 GMT
Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.147]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0224.002; Thu, 26 Mar 2015 17:52:09 -0400
From: "DOLLY, MARTIN C" 
To: "R.Jesske@telekom.de" 
Thread-Topic: [Ecrit] HELD Routing summary
Thread-Index: AQHQZ+fK+d8jv1j1uUeZHdgBwjdtIwADd/0QnS8yp9U=
Date: Thu, 26 Mar 2015 21:52:09 +0000
Message-ID: <005F9E88-3CFB-4F33-ABF8-FAFA63B72C2E@att.com>
References: <5F3DEAC5-1A13-45A3-B9C8-51579BAC22F9@gmail.com> <14546D76-AEF5-4C23-9BA0-00B6FA4C1E96@neustar.biz>    <75BAB4CE-E408-472D-80DD-569ADD918A8B@gmail.com>   <204B769A-295F-476E-8B36-8F428FD4EE67@gmail.com>    <9227FF13-3F48-44E3-A53E-68455DED2DD1@gmail.com>, <058CE00BD4D6B94FAD033A2439EA1E4B01E9E52D8834@HE113667.emea1.cds.t-internal.com>
In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01E9E52D8834@HE113667.emea1.cds.t-internal.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_005F9E883CFB4F33ABF8FAFA63B72C2Eattcom_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=XaA+OvF5 c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a]
X-AnalysisOut: [=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=emO1SXQWCLwA:10 a=48vg]
X-AnalysisOut: [C7mUAAAA:8 a=hGBaWAWWAAAA:8 a=pGLkceISAAAA:8 a=EUspDBNiAAA]
X-AnalysisOut: [A:8 a=mK_AVkanAAAA:8 a=z88tSTt-AAAA:8 a=IY4zEbbZBJNs_yBSU5]
X-AnalysisOut: [QA:9 a=pILNOxqGKmIA:10 a=qM39cor4HRgA:10 a=OgC_tr2ThIwB4_c]
X-AnalysisOut: [S:21 a=rX_dBOF6EpCf4-SF:21 a=OgZ9rShdXcIoLFujfXAA:9 a=UiCQ]
X-AnalysisOut: [7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg]
X-AnalysisOut: [-hUA:10 a=dT9YGeBpRMm-AhF8:21 a=hMkn7wejFcKHNoM8:21]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.229.24]
Archived-At: 
Cc: "Brian.Rosen@neustar.biz" , "ecrit@ietf.org" , "rg+ietf@qti.qualcomm.com" 
Subject: Re: [Ecrit] HELD Routing summary
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Mar 2015 21:52:48 -0000

--_000_005F9E883CFB4F33ABF8FAFA63B72C2Eattcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

I support option 3 as well

Martin Dolly
Lead Member of Technical Staff
Core & Gov't/Regulatory Standards
AT&T Standards and
Industry Alliances
+1-609-903-3360
Sent from my iPhone

On Mar 26, 2015, at 5:44 PM, "R.Jesske@telekom.de" > wrote:


For me it looks like more confusing than only to apply to OPTION 3.
Thus I=92m still in favor for Option 3 which need only a small change.
And I think the requirement for extensibility as discussed in the meeting i=
s fulfilled.

In short I support now OPTION 3 as James proposed.

Thank you and Best Regards

Roland

Von: Ecrit [mailto:ecrit-bounces@ietf.org] Im Auftrag von James Winterbotto=
m
Gesendet: Donnerstag, 26. M=E4rz 2015 21:02
An: Rosen, Brian
Cc: ecrit@ietf.org; Randall Gellens
Betreff: Re: [Ecrit] HELD Routing summary

I still don=92t want the extra stuff as I don=92t see a need for it.

However, if we were to proceed down this path then:
This document now normatively updates RFC5222 so I don=92t think that the l=
anguage below is strong enough or clear enough that we are changing the mea=
ning of source from RFC5222. This is because the HELD server may not genera=
te the mapping data, it may simply supply it and a URI for how it obtained =
it may not exist.
The source in RFC5222 is not a URI, it is a LoST application unique string,=
 I am not sure that making this a HELD application unique string makes sens=
e, so this would require more thought, unless this is also part of the upda=
ting to RFC5222 which would also require schema change to support.

These were the problems I look at when I created the specification the way =
it is, which is why I didn=92t use the mapping element. I just don=92t thin=
k you can use words to explain away the issues and cram the mapping element=
 in, you would need to redefine the mapping element and I see no value in t=
hat.

Cheers
James

On 27 Mar 2015, at 6:44 am, Rosen, Brian > wrote:

Replace the last two paragraphs of Section 4 with:

The location response when the HELD sever supports this specification and r=
outing is requested consists of the  element from RFC5222.  The =
=93source=94 element shall be the URI of the authoritative generator of the=
 mapping data, which may be the HELD server=92s URI.   All other elements o=
f the  element are as they are described in RFC5222.




If this language is acceptable, I=92ll fix the schema in Section 5 and the =
examples.

Brian

From: James Winterbottom >
Date: Thursday, March 26, 2015 at 2:27 PM
To: Randall Gellens >
Cc: Brian Rosen >, =
"ecrit@ietf.org" >
Subject: Re: [Ecrit] HELD Routing summary

Thanks for talking the position as conciliator Randall.



On 27 Mar 2015, at 6:26 am, Randall Gellens > wrote:

My impression is that people are talking past
each other, which is why I thought seeing the
proposal in the document would help clarify it.

At 6:07 AM +1100 3/27/15, James Winterbottom wrote:


Randall,

I don't agree with Brian's position on the
Source, my reading of LoST is that this can't
be the HELD server because it doesn't satisfy
the description and requirements for the use of
that field.

But further to that, the three people in this
group that requested this functionality don't
see a need for this stuff. Indeed the only
person arguing for it is Brian and he hasn't
provided or demonstrated any need for it.
Option 3 on that table allows it be added when
needed which is the fastest and easiest
approach.


Cheers
James


On 27 Mar 2015, at 4:10 am, Randall Gellens
<randy@qti.qualcomm.com>
wrote:

Brian,

If it's only 10 minutes of editing, then maybe
you can revise either the XML (and update the
TXT) or the TXT and show what it would look
like in the document?  I think perhaps two
examples would also help: one where the source
is a local database and the other where the
source is a LoST server.  We'd then have a
concrete proposal in front of us and we could
ask if we have consensus to adopt it and move
forward.

James, if Brian does this, can you then look
at the revisions and see if you still object
or if you can accept them?

At 3:19 PM +0000 3/26/15, Brian Rosen wrote:


Come on, the mandatory elements are the
source, lastUpdated and expires.  The source
might be the HELD server, but it might be
something else.  If it's the HELD server, say
so.
It is a trivial ask that you include source,
lastUpdated and expires in the response,
identical to LoST.  It provides a level of
compatibility that is useful, and
non-intrusive for implementations to
accommodate.  It COULD be a fixed string.

You think of implementations as the server
has, internally, all the routing information.
That's one way to do it.  Another way to do
it is to have the HELD server consult a LoST
server.  Yes, I know you don't think anyone
will implement a LoST server.  I think you
are wrong.

I understand that I can incrementally add the
mapping components as extensions in a way
that is transformable to a "real" 
structure, but the bits on the wire are
different.
If you persist, and consensus is to have an
extension point and no more, I'll submit the
draft that does it right away.   Does that
REALLY make any sense?

Brian


On Mar 26, 2015, at 9:35 AM, James
Winterbottom
<<mailto:a.james.winterbottom@gmail.=
com>a.james.winterbottom@gmail.com>
wrote:

HUH????

As I have said before and as the draft
states, at least of the mandatory mapping
elements is not applicable where you don't
LoST, so simply resuming mapping doesn't
work.

If we put the extension point in, and you
want to reuse mapping elements in your
implementation you can simply reference them
in the extension point, no specification
required and things that choose not to
understand the extension can ignore  them.
No extra specification required, no extra
work at all required in this specification,
not even 10 minutes editing and 4 years of
haggling.

Cheers
James


On 27 Mar 2015, at 1:31 am, Rosen, Brian
<<mailto:Brian.Rosen@neustar.biz>Brian.Rosen@neustar.biz>
wrote:

I don't understand any of this logic.

You import the definition from RFC5222 and
refer to it for the meaning of the
elements.  Done.  No time delay.  10
minutes of editing.

I want to be able to build systems that
work world-wide.  The more commonality of
data structures, the better.

You have not shown any harm to re-use of a
data structure that was designed for the
purpose you have, has had extensive IETF
review, implementation, and consensus.  You
want to invent something new.  It's clearly
a subset, but it's not precisely a subset.
That is not a good idea in my opinion.  As
the majority of elements in  are
optional, an implementation can choose
never to send them (server) or ignore them
if received (client).  If you use the
extension point (3), and we later decide
that most of  is in fact useful,
we would end up different data structures,
because the base structure is different.

Brian


On Mar 26, 2015, at 8:22 AM, Laura Liess
<<mailto:laura.liess.dt@googlemail.co=
m>laura.liess.dt@googlemail.com>
wrote:

I would prefer 3) and I can live with 2).

I am oposed to 1) because it would delay
the draft progress, just to add features
about we don't know if anyone will need
them andif so,  what exactly will be
needed. For the work in ETSI on the EC
M493 this is clearly not needed. ETSI
needs the draft finished very soon, if we
want the final ETSI specification,
targeted for the end of this year, to
refer an RFC and not a draft and the
implementations which will come then soon,
to be based an RFC and not on some
intermediary version of the draft.

I think 3) is a good solution, flexible
enough that everyone could live with it.

Thank you
 Laura

2015-03-25 20:21 GMT+01:00 James
Winterbottom
<<mailto:a.james.winterbottom@gmail.=
com>a.james.winterbottom@gmail.com>:

There is downside to using the existing
schema Brian, this is spelt out clearly in
the draft. In order to include the fields
you want a new element would need to be
defined in this draft to support it. I
think that that is the wrong way to do it
as there has been no expression of need.
If a need arrises after this draft is
done, then it can be added later. Right
now it isn't needed.

As I said in my preference for option 3, I
think that the extension point should be
added then anything can be added later if
required.

Cheers
James



On 26 Mar 2015, at 2:52 am, Rosen, Brian
<<mailto:Brian.Rosen@neustar.biz>Brian.Rosen@neustar.biz>
wrote:

Let's say that someone comes along and
shows a decent use case for including a
service boundary.

So they define an extension for it.

That extension may or may not be the same
as the service boundary that LoST
returns. An implementation designed to
provide world-wide service would have to
change.

Returning the boundary is already optional in the LoST schema.

If we used the existing definition:
1. No new document is required
2. Compatibility between this HELD extension and LoST is maintained
3. Systems built to support both models don't have to change

There is, as far as I can see, no
downside to using the existing schema
other than making the smallest possible
response a bit bigger.   One can always
ignore any returned items not
needed/wanted, and since they are
optional they can't be assumed to be
there.

Option 2 (don't allow an extension point
on the return) makes no sense to me.  I
can't imagine the IETF doing that. Any
extension would then require all existing
implementations to be changed.

Brian


On Mar 25, 2015, at 9:49 AM,
<mailto:R.Jesske@telekom.de>R.Jesske@telekom.de wrote:

Hi James,
thank you for the summary.
My position is reflected in point 2.

If people want to add something to a
mechanism can it not be done only in
writing a further draft?
This means also including in such a draft also a extension mechanism.

I think that would be a clear line to satisfy everybody.


Best Regards

Roland

-----Urspr=FCngliche Nachricht-----
Von: Ecrit
[mailto:<mailto:ecrit-bounces@ie=
tf.org>ecrit-bounces@ietf.org]
Im Auftrag von James Winterbottom
Gesendet: Mittwoch, 25. M=E4rz 2015 09:03
An: <http://ecrit_ietf.org/>ecrit_ietf.org
Betreff: [Ecrit] HELD Routing summary

Hi All,

As I see it there is one open discussion
point and three positions on this point.
The discussion point is whether or not
all of the ancillary data that is
returned by a LoST findService request
should be included in the HELD routing
response or not.

The three positions that have been
stated are (in no particular order):
1) The definition for this information
should be included in the base
specification but is optional to send or
be acted on.
2) Isn't required at all, let the current draft stand
3) Add an extension point to the schema
in the draft so that the extra can be
specified in a different draft and added
by something requiring it.

This email makes no claims to
preference, but just presents the
opinions that have been expressed.

Cheers
James

_______________________________________________
Ecrit mailing list

<mailto:Ecrit@ietf.org>Ecrit@=
ietf.org

<https://www.ietf.org/mailman/=
listinfo/ecrit> https://www.ie=
tf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list

<mailto:Ecrit@ietf.org>Ecrit@=
ietf.org

<https://www.ietf.org/mailman/=
listinfo/ecrit> https://www.ie=
tf.org/mailman/listinfo/ecrit


_______________________________________________
Ecrit mailing list

<mailto:Ecrit@ietf.org>Ecrit@=
ietf.org

<https://www.ietf.org/mailman/=
listinfo/ecrit>https://www.iet=
f.org/mailman/listinfo/ecrit


_______________________________________________
Ecrit mailing list

<mailto:Ecrit@ietf.org>Ecrit@=
ietf.org

https://www.ietf.org/mailman/l=
istinfo/ecrit


_______________________________________________
Ecrit mailing list
Ecrit@ietf.org

https://www.ietf.org/mailman/l=
istinfo/ecrit



--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Spotted on the back of a t-shirt worn by LAPD Bomb Squad:
"If you see me running, try to keep up."


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



--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Skipper:   Mr. Howell, You don't know what it's like out there in
          the ocean, you may be bitten by a shark!
Thurston:  A shark bite a Howell, ha ha he wouldn't dare.
Skipper:   Besides we don't have room enough for your luggage.
Thurston:  Well that's different. If I can't go first class I won't
          go at all.


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

--_000_005F9E883CFB4F33ABF8FAFA63B72C2Eattcom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable







I support option 3 as well



Martin Dolly

Lead Member of Technical Staff


Core & Gov't/Regulatory Standards


AT&T Standards and 


Industry Alliances


+1-609-903-3360


Sent from my iPhone








On Mar 26, 2015, at 5:44 PM, "R=
.Jesske@telekom.de" <R.J=
esske@telekom.de> wrote:














 =
;


For me it =
looks like more confusing than only to apply to OPTION 3.=



Thus I=92m=
 still in favor for Option 3 which need only a small change.



And I thin=
k the requirement for extensibility as discussed in the meeting is fulfille=
d.


 =
;


In short I=
 support now OPTION 3 as James proposed.


 =
;


Thank you and Best Regard=
s




Roland


 <=
/p>





Von: Ecrit [mailto:ecrit-bounces@ietf.org]
Im Auftrag von James Winterbottom

Gesendet: Donnerstag, 26. M=E4rz 2015 21:02

An: Rosen, Brian

Cc: ecrit@ietf.org; Randall Ge=
llens

Betreff: Re: [Ecrit] HELD Routing summary






 




I still don=92t want the extra stuff as I don=92t se=
e a need for it.






 






However, if we were to proceed down this path then:<=
o:p>






This document now normatively updates RFC5222 so I d=
on=92t think that the language below is strong enough or clear enough that =
we are changing the meaning of source from RFC5222. This is because the HEL=
D server may not generate the mapping
 data, it may simply supply it and a URI for how it obtained it may not exi=
st.






The source in RFC5222 is not a URI, it is a LoST app=
lication unique string, I am not sure that making this a HELD application u=
nique string makes sense, so this would require more thought, unless this i=
s also part of the updating to RFC5222
 which would also require schema change to support.






 






These were the problems I look at when I created the=
 specification the way it is, which is why I didn=92t use the mapping eleme=
nt. I just don=92t think you can use words to explain away the issues and c=
ram the mapping element in, you would
 need to redefine the mapping element and I see no value in that.






 






Cheers






James




 








On 27 Mar 2015, at 6:44 am, Rosen, Brian <Brian.Rosen@neustar.biz> wrote:<=
o:p>




 








Replace the last two paragraphs of Sect=
ion 4 with:






 






The location response when the HELD sev=
er supports this specification and routing is requested consists of the <=
;mapping> element from RFC5222.  The =93source=94 element shall
 be the URI of the authoritative generator of the mapping data, which may b=
e the HELD server=92s URI.   All other elements of the <mapping>=
 element are as they are described in RFC5222.  






 






 






 






 






If this language is acceptable, I=92ll =
fix the schema in Section 5 and the examples.






 






Brian






 






From:
James Winterbottom <a.james.winterbottom@gmail.com>

Date: Thursday, March 26, 2015 at 2:27 PM

To: Randall Gellens <rg+ietf@qti.qualcomm.com>

Cc: Brian Rosen <brian=
.rosen@neustar.biz>, "ecrit@i=
etf.org" <ecrit@ietf.org&=
gt;

Subject: Re: [Ecrit] HELD Routing summary






 








Thanks for talking the position as conc=
iliator Randall.





 






 






 








On 27 Mar 2015, at 6:26 am, Randall Gel=
lens <rg+ietf@qti.qu=
alcomm.com> wrote:




 




My impression is that people are talki=
ng past 

each other, which is why I thought seeing the 

proposal in the document would help clarify it.



At 6:07 AM +1100 3/27/15, James Winterbottom wrote:








Randall,



I don't agree with Brian's position on the 

Source, my reading of LoST is that this can't 

be the HELD server because it doesn't satisfy 

the description and requirements for the use of 

that field.



But further to that, the three people in this 

group that requested this functionality don't 

see a need for this stuff. Indeed the only 

person arguing for it is Brian and he hasn't 

provided or demonstrated any need for it. 

Option 3 on that table allows it be added when 

needed which is the fastest and easiest 

approach.





Cheers

James








On 27 Mar 2015, at 4:10 am, Randall Ge=
llens 

<<mailto:randy@qti.qualcomm=
.com>randy@qti.qualcomm.co=
m> 

wrote:



Brian,



If it's only 10 minutes of editing, then maybe 

you can revise either the XML (and update the 

TXT) or the TXT and show what it would look 

like in the document?  I think perhaps two 

examples would also help: one where the source 

is a local database and the other where the 

source is a LoST server.  We'd then have a 

concrete proposal in front of us and we could 

ask if we have consensus to adopt it and move 

forward.



James, if Brian does this, can you then look 

at the revisions and see if you still object 

or if you can accept them?



At 3:19 PM +0000 3/26/15, Brian Rosen wrote:








Come on, the mandatory elements are th=
e 

source, lastUpdated and expires.  The source 

might be the HELD server, but it might be 

something else.  If it's the HELD server, say 

so.

It is a trivial ask that you include source, 

lastUpdated and expires in the response, 

identical to LoST.  It provides a level of 

compatibility that is useful, and&nbs=
p;

non-intrusive for implementations to&=
nbsp;

accommodate.  It COULD be a fixed string.



You think of implementations as the server 

has, internally, all the routing information. 

That's one way to do it.  Another way to do 

it is to have the HELD server consult a LoST 

server.  Yes, I know you don't think anyone 

will implement a LoST server.  I think you 

are wrong.



I understand that I can incrementally add the 

mapping components as extensions in a way 

that is transformable to a "real" <mapping> 

structure, but the bits on the wire are 

different.

If you persist, and consensus is to have an 

extension point and no more, I'll submit the 

draft that does it right away.   Does that 

REALLY make any sense?



Brian








On Mar 26, 2015, at 9:35 AM, James 

Winterbottom 

<<<mailto:a.jame=
s.winterbottom@gmail.com>mailto:a.james.winterbottom@gmail.com><mailto:a.james.winterbottom@gmail.com>=
;a.james.winterbottom@gma=
il.com> 

wrote:



HUH????



As I have said before and as the draft 

states, at least of the mandatory mapping 

elements is not applicable where you don't 

LoST, so simply resuming mapping doesn't 

work.



If we put the extension point in, and you 

want to reuse mapping elements in your 

implementation you can simply reference them 

in the extension point, no specification 

required and things that choose not to 

understand the extension can ignore  them. 

No extra specification required, no extra 

work at all required in this specification, 

not even 10 minutes editing and 4 years of 

haggling.



Cheers

James








On 27 Mar 2015, at 1:31 am, Rosen, Bri=
an 

<<<mailto:Brian.Rosen@n=
eustar.biz>mailto:Brian.R=
osen@neustar.biz><mail=
to:Brian.Rosen@neustar.biz>Brian.Rosen@neustar.biz>&nbs=
p;

wrote:



I don't understand any of this logic.



You import the definition from RFC5222 and 

refer to it for the meaning of the&nb=
sp;

elements.  Done.  No time delay.  10 

minutes of editing.



I want to be able to build systems that 

work world-wide.  The more commonality of 

data structures, the better.



You have not shown any harm to re-use of a 

data structure that was designed for the 

purpose you have, has had extensive IETF 

review, implementation, and consensus.  You 

want to invent something new.  It's clearly 

a subset, but it's not precisely a subset. 

That is not a good idea in my opinion.  As 

the majority of elements in <mapping> are 

optional, an implementation can choose 

never to send them (server) or ignore them 

if received (client).  If you use the 

extension point (3), and we later decide 

that most of <mapping> is in fact useful, 

we would end up different data structures, 

because the base structure is different.



Brian








On Mar 26, 2015, at 8:22 AM, Laura Lie=
ss 

<<<mailto:laura.l=
iess.dt@googlemail.com>mailto:laura.liess.dt@googlemail.com><mailto:laura.liess.dt@googlemail.com>laura.liess.dt@googlemail.com> 

wrote:



I would prefer 3) and I can live with 2).



I am oposed to 1) because it would delay 

the draft progress, just to add features 

about we don't know if anyone will need 

them andif so,  what exactly will be 

needed. For the work in ETSI on the EC 

M493 this is clearly not needed. ETSI=
 

needs the draft finished very soon, if we 

want the final ETSI specification,&nb=
sp;

targeted for the end of this year, to=
 

refer an RFC and not a draft and the&=
nbsp;

implementations which will come then soon, 

to be based an RFC and not on some&nb=
sp;

intermediary version of the draft.



I think 3) is a good solution, flexible 

enough that everyone could live with it.



Thank you

 Laura



2015-03-25 20:21 GMT+01:00 James&=
nbsp;

Winterbottom 

<<<mailto:a.jame=
s.winterbottom@gmail.com>mailto:a.james.winterbottom@gmail.com><mailto:a.james.winterbottom@gmail.com>=
;a.james.winterbottom@gma=
il.com>:



There is downside to using the existing 

schema Brian, this is spelt out clearly in 

the draft. In order to include the fields 

you want a new element would need to be 

defined in this draft to support it. I 

think that that is the wrong way to do it 

as there has been no expression of need. 

If a need arrises after this draft is=
 

done, then it can be added later. Right 

now it isn't needed.



As I said in my preference for option 3, I 

think that the extension point should be 

added then anything can be added later if 

required.



Cheers

James










On 26 Mar 2015, at 2:52 am, Rosen, Bri=
an 

<<<mailto:Brian.Rosen@n=
eustar.biz>mailto:Brian.R=
osen@neustar.biz><mail=
to:Brian.Rosen@neustar.biz>Brian.Rosen@neustar.biz>&nbs=
p;

wrote:



Let's say that someone comes along and 

shows a decent use case for including a 

service boundary.



So they define an extension for it.



That extension may or may not be the same 

as the service boundary that LoST&nbs=
p;

returns. An implementation designed to 

provide world-wide service would have to 

change.



Returning the boundary is already optional in the LoST schema.



If we used the existing definition:

1. No new document is required

2. Compatibility between this HELD extension and LoST is maintained

3. Systems built to support both models don't have to change



There is, as far as I can see, no&nbs=
p;

downside to using the existing schema=
 

other than making the smallest possible 

response a bit bigger.   One can always 

ignore any returned items not 

needed/wanted, and since they are&nbs=
p;

optional they can't be assumed to be&=
nbsp;

there.



Option 2 (don't allow an extension point 

on the return) makes no sense to me.  I 

can't imagine the IETF doing that. Any 

extension would then require all existing 

implementations to be changed.



Brian








On Mar =
25, 2015, at 9:49 AM, 
<<mailto:R.Jesske@telekom.de>mailto:R.Jesske@telekom.de=
><mailto:R.Jesske@telekom.de>R.Jesske@telekom.de wrote:



Hi James,

thank you for the summary.

My position is reflected in point 2.



If people want to add something to a&=
nbsp;

mechanism can it not be done only in&=
nbsp;

writing a further draft?

This means also including in such a draft also a extension mechanism.



I think that would be a clear line to satisfy everybody.





Best Regards



Roland



-----Urspr=FCngliche Nachricht-----

Von: Ecrit 

[mailto:<<mailto:ecrit-bounces@ietf.org>mailto:ecrit-bounces@ietf.org><mailto:ecrit-bounces@ietf.org>ecrit-bounces@ietf.org] 

Im Auftrag von James Winterbottom

Gesendet: Mittwoch, 25. M=E4rz 2015 09:03

An: <<http://ecrit_ietf.org/&g=
t;http://ecrit_ietf.org/>ecrit_ie=
tf.org

Betreff: [Ecrit] HELD Routing summary



Hi All,



As I see it there is one open discussion 

point and three positions on this point.

The discussion point is whether or not 

all of the ancillary data that is&nbs=
p;

returned by a LoST findService request 

should be included in the HELD routing 

response or not.



The three positions that have been&nb=
sp;

stated are (in no particular order):

1) The definition for this information 

should be included in the base <=
/span>

specification but is optional to send or 

be acted on.

2) Isn't required at all, let the current draft stand

3) Add an extension point to the schema 

in the draft so that the extra can be=
 

specified in a different draft and added 

by something requiring it.



This email makes no claims to 

preference, but just presents the&nbs=
p;

opinions that have been expressed.



Cheers

James



_______________________________________________

Ecrit mailing list



<<mailto:Ecrit@ietf.org>mailto:Ecrit@ietf.org><mailto:Ecrit@ietf.org>Ecrit@ietf.org



<<https://www=
.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit> &l=
t;https://www.ietf.=
org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________

Ecrit mailing list



<<mailto:Ecrit@ietf.org>mailto:Ecrit@ietf.org><mailto:Ecrit@ietf.org>Ecrit@ietf.org



<<https://www=
.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit> &l=
t;https://www.ietf.=
org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit


 




_______________________________________________

Ecrit mailing list



<<mailto:Ecrit@ietf.org>mailto:Ecrit@ietf.org><mailto:Ecrit@ietf.org>Ecrit@ietf.org



<<https://www=
.ietf.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit><=
;https://www.ietf.o=
rg/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit


 




_______________________________________________

Ecrit mailing list



<<mailto:Ecrit@ietf.org>mailto:Ecrit@ietf.org><mailto:Ecrit@ietf.org>Ecrit@ietf.org



<https://www.iet=
f.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit=







_______________________________________________

Ecrit mailing list

<mailto:Ecrit@ietf.org>Ecrit@ietf.org



<https://www.iet=
f.org/mailman/listinfo/ecrit>https://www.ietf.org/mailman/listinfo/ecrit=









--

Randall Gellens

Opinions are personal;    facts are suspect;   &nb=
sp;I speak for myself only

-------------- Randomly selected tag: ---------------

Spotted on the back of a t-shirt worn by LAPD Bomb Squad:

"If you see me running, try to keep up."






_______________________________________________

Ecrit mailing list

Ecrit@ietf.org

https://www.ietf.or=
g/mailman/listinfo/ecrit








--

Randall Gellens

Opinions are personal;    facts are suspect;   &nb=
sp;I speak for myself only

-------------- Randomly selected tag: ---------------

Skipper:   Mr. Howell, You don't know what it's like out there in=


          the ocean, you =
may be bitten by a shark!

Thurston:  A shark bite a Howell, ha ha he wouldn't dare.

Skipper:   Besides we don't have room enough for your luggage.
Thurston:  Well that's different. If I can't go first class I won't
          go at all.








 
















 










_______________________________________________

Ecrit mailing list

Ecrit@ietf.org

https://www.i=
etf.org/mailman/listinfo/ecrit








--_000_005F9E883CFB4F33ABF8FAFA63B72C2Eattcom_--