From brian.rosen@neustar.biz Mon Feb 11 06:28:09 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039E521F866E for ; Mon, 11 Feb 2013 06:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.193 X-Spam-Level: X-Spam-Status: No, score=-6.193 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEfksgvxDsZr for ; Mon, 11 Feb 2013 06:28:08 -0800 (PST) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id B68A221F8644 for ; Mon, 11 Feb 2013 06:28:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1360592758; x=1675936942; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=PONB0hkgmSQDYVEHLeWuUgOE4oac1qxAK+qjaCZ7xLw=; b=R2qR3mDG3VX8NDGXuvw8WHV4CdtmHe3UA77qYUhCB4aA6320NFONqZFys7sYqU W8urEEJ0SGZAUcBk5qElfwCQ== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.16303304; Mon, 11 Feb 2013 09:25:42 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Mon, 11 Feb 2013 09:27:52 -0500 From: "Rosen, Brian" To: "ecrit@ietf.org Org" Date: Mon, 11 Feb 2013 09:27:51 -0500 Thread-Topic: I-D Action: draft-rosen-rph-reg-policy-00.txt Thread-Index: Ac4IY/ljJfHjz2HLSRuQUCdbRrsH4A== Message-ID: <32448F39-E047-4286-8C61-C221D5738B7C@neustar.biz> References: <20130211141557.13687.68712.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: /wmlQGY5f9OvV0QQ01BqIw== Content-Type: multipart/alternative; boundary="_000_32448F39E04742868C61C221D5738B7Cneustarbiz_" MIME-Version: 1.0 Subject: [Ecrit] Fwd: I-D Action: draft-rosen-rph-reg-policy-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 14:28:09 -0000 --_000_32448F39E04742868C61C221D5738B7Cneustarbiz_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgcHJvY2Vzc2luZyAgZHJhZnQtcG9say1sb2NhbC1lbWVyZ2VuY3ktcnBoLW5hbWVzcGFjZSAg dGhyb3VnaCB0aGUgSUVTRywgd2UgY2FtZSBhY3Jvc3MgYSBwcm9ibGVtLiAgVGhlIGVtZXJnZW5j eS1ycGggZG9jdW1lbnQgbWVyZWx5IGNyZWF0ZXMgYSBuYW1lc3BhY2UgYW5kIG5ldyBwcmlvcml0 eSB2YWx1ZXMsIGl0IGRvZXNuJ3QgY29udGFpbiBhbnkgcHJvdG9jb2wgbWVjaGFuaXNtLiAgU29t ZSBBRHMgY29tcGxhaW5lZCB0aGF0IHRoaXMgd2FzIG5vdCwgdGhlcmVmb3JlLCBhbiBhcHByb3By aWF0ZSBkb2N1bWVudCBmb3Igc3RhbmRhcmRzIHRyYWNrLiAgSG93ZXZlciwgdGhlIHJlZ2lzdHJ5 IG9mIG5hbWVzcGFjZXMgYW5kIHRoZSBwcmlvcml0eSByZWdpc3RyeSB3ZXJlIGNyZWF0ZWQgd2l0 aCBhIHBvbGljeSBvZiBzdGFuZGFyZHMtdHJhY2sgcmVxdWlyZWQgdG8gYWRkIHZhbHVlcy4NCg0K SW4gaGluZHNpZ2h0LCB0aGlzIHdhcyBhIG1pc3Rha2UuICBBZGRpbmcgYSBuYW1lc3BhY2Ugb3Ig cHJpb3JpdGllcyBkb2Vzbid0IG5lY2Vzc2FyaWx5IGFsdGVyIGFueSBwcm90b2NvbCwgYW5kIHNo b3VsZG4ndCBuZWVkIHN0YW5kYXJkLXRyYWNrLg0KDQpJIHdyb3RlIGEgZG9jdW1lbnQgdGhhdCB1 cGRhdGVzIFJGQzQ0MTIgdG8gY2hhbmdlIHRoZSByZWdpc3RyaWVzIHRvICJJRVRGIFJldmlldyIg KG5ldyBkZXNpZ25hdGlvbiBmb3Igd2hhdCB3YXMgIklFVEYgQ29uc2Vuc3VzIikuICBUaGF0J3Mg YWxsIGl0IGRvZXMsIGNoYW5nZSB0aGUgcG9saWN5LiAgSXQgbWFrZXMgTk8gb3RoZXIgY2hhbmdl cy4NCg0KSXQgaXMgZW50ZXJlZCBpbiB0aGUgInNob3J0ZXN0IFJGQyIgY29udGVzdC4NCg0KSSB3 b3VsZCBsaWtlIHRvIG1vdmUgdGhpcyB0aHJvdWdoIHRoZSBwcm9jZXNzIGV4cGVkaXRpb3VzbHku ICBPdXIgQUQgaXMgYmVoaW5kIHRoaXMgZWZmb3J0LiAgSWYgeW91IHdvdWxkIHRha2UgYSBxdWlj ayBsb29rIGF0IHRoZSBkb2N1bWVudCwgb3IsIGlmIHlvdSBhcmUgaW4gZmF2b3Igb2YsIG9yIG5v dCBpbiBmYXZvciBvZiBjaGFuZ2luZyB0aGUgcmVnaXN0cnkgcG9saWN5LCBwbGVhc2UgcmVzcG9u ZCB0byB0aGUgbGlzdCBzbyB3ZSBrbm93IGlmIHdlIGhhdmUgYSBxdWljayBjb25zZW5zdXMuDQoN CkJyaWFuDQoNCg0KQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQoNCkZyb206IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KU3ViamVjdDog SS1EIEFjdGlvbjogZHJhZnQtcm9zZW4tcnBoLXJlZy1wb2xpY3ktMDAudHh0DQpEYXRlOiBGZWJy dWFyeSAxMSwgMjAxMyA5OjE1OjU3IEFNIEVTVA0KVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZzxt YWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnPg0KUmVwbHktVG86IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KDQoNCkEgTmV3IEludGVy bmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBk aXJlY3Rvcmllcy4NCg0KDQpUaXRsZSAgICAgICAgICAgOiBSZXNvdXJjZSBQcmlvcml0eSBIZWFk ZXIgKFJQSCkgUmVnaXN0cnkgTWFuYWdlbWVudCBQb2xpY3kgdG8gSUVURiBSZXZpZXcNCkF1dGhv cihzKSAgICAgICA6IEJyaWFuIFJvc2VuDQpGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1yb3Nlbi1y cGgtcmVnLXBvbGljeS0wMC50eHQNClBhZ2VzICAgICAgICAgICA6IDMNCkRhdGUgICAgICAgICAg ICA6IDIwMTMtMDItMDgNCg0KQWJzdHJhY3Q6DQogIFJGQzQ0MTIgZGVmaW5lcyAiUmVzb3VyY2Ut UHJpb3JpdHkgTmFtZXNwYWNlcyIgYW5kICJSZXNvdXJjZS1Qcmlvcml0eQ0KICBQcmlvcml0eS12 YWx1ZXMiIHJlZ2lzdHJpZXMuICBUaGUgbWFuYWdlbWVudCBwb2xpY3kgb2YgdGhlc2UNCiAgcmVn aXN0cmllcyBpcyAiU3RhbmRhcmRzIEFjdGlvbiIuICBUaGlzIGRvY3VtZW50IGNoYW5nZXMgdGhl DQogIG1hbmFnZW1lbnQgcG9saWN5IG9mIHRoZXNlIHJlZ2lzdHJpZXMgdG8gIklFVEYgUmV2aWV3 Ii4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBp czoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJvc2VuLXJwaC1yZWct cG9saWN5DQoNClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0K aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcm9zZW4tcnBoLXJlZy1wb2xpY3ktMDAN Cg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAg YXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSS1ELUFubm91bmNlIG1haWxpbmcg bGlzdA0KSS1ELUFubm91bmNlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6 Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCm9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFz aGFkb3ctc2l0ZXMudHh0DQoNCg== --_000_32448F39E04742868C61C221D5738B7Cneustarbiz_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWwgY2hhcnNldD11dGYtOCI+PC9oZWFkPjxib2R5IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFr LXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRl ci13aGl0ZS1zcGFjZTsgIj5JdCBwcm9jZXNzaW5nJm5ic3A7DQoNCg0KDQoNCg0KDQoNCg0KDQo8 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpEb2N1bWVudFByb3BlcnRpZXM+DQogIDxvOlJl dmlzaW9uPjA8L286UmV2aXNpb24+DQogIDxvOlRvdGFsVGltZT4wPC9vOlRvdGFsVGltZT4NCiAg PG86UGFnZXM+MTwvbzpQYWdlcz4NCiAgPG86V29yZHM+NjwvbzpXb3Jkcz4NCiAgPG86Q2hhcmFj dGVycz4zNTwvbzpDaGFyYWN0ZXJzPg0KICA8bzpDb21wYW55Pk5ldVN0YXI8L286Q29tcGFueT4N CiAgPG86TGluZXM+MTwvbzpMaW5lcz4NCiAgPG86UGFyYWdyYXBocz4xPC9vOlBhcmFncmFwaHM+ DQogIDxvOkNoYXJhY3RlcnNXaXRoU3BhY2VzPjQwPC9vOkNoYXJhY3RlcnNXaXRoU3BhY2VzPg0K ICA8bzpWZXJzaW9uPjE0LjA8L286VmVyc2lvbj4NCiA8L286RG9jdW1lbnRQcm9wZXJ0aWVzPg0K IDxvOk9mZmljZURvY3VtZW50U2V0dGluZ3M+DQogIDxvOkFsbG93UE5HLz4NCiA8L286T2ZmaWNl RG9jdW1lbnRTZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPg0KDQo8IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCiA8dzpXb3JkRG9jdW1lbnQ+DQogIDx3OlZpZXc+Tm9ybWFsPC93OlZpZXc+DQog IDx3Olpvb20+MDwvdzpab29tPg0KICA8dzpUcmFja01vdmVzLz4NCiAgPHc6VHJhY2tGb3JtYXR0 aW5nLz4NCiAgPHc6UHVuY3R1YXRpb25LZXJuaW5nLz4NCiAgPHc6VmFsaWRhdGVBZ2FpbnN0U2No ZW1hcy8+DQogIDx3OlNhdmVJZlhNTEludmFsaWQ+ZmFsc2U8L3c6U2F2ZUlmWE1MSW52YWxpZD4N CiAgPHc6SWdub3JlTWl4ZWRDb250ZW50PmZhbHNlPC93Oklnbm9yZU1peGVkQ29udGVudD4NCiAg PHc6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD5mYWxzZTwvdzpBbHdheXNTaG93UGxhY2Vob2xk ZXJUZXh0Pg0KICA8dzpEb05vdFByb21vdGVRRi8+DQogIDx3OkxpZFRoZW1lT3RoZXI+RU4tVVM8 L3c6TGlkVGhlbWVPdGhlcj4NCiAgPHc6TGlkVGhlbWVBc2lhbj5KQTwvdzpMaWRUaGVtZUFzaWFu Pg0KICA8dzpMaWRUaGVtZUNvbXBsZXhTY3JpcHQ+WC1OT05FPC93OkxpZFRoZW1lQ29tcGxleFNj cmlwdD4NCiAgPHc6Q29tcGF0aWJpbGl0eT4NCiAgIDx3OkJyZWFrV3JhcHBlZFRhYmxlcy8+DQog ICA8dzpTbmFwVG9HcmlkSW5DZWxsLz4NCiAgIDx3OldyYXBUZXh0V2l0aFB1bmN0Lz4NCiAgIDx3 OlVzZUFzaWFuQnJlYWtSdWxlcy8+DQogICA8dzpEb250R3Jvd0F1dG9maXQvPg0KICAgPHc6U3Bs aXRQZ0JyZWFrQW5kUGFyYU1hcmsvPg0KICAgPHc6RW5hYmxlT3BlblR5cGVLZXJuaW5nLz4NCiAg IDx3OkRvbnRGbGlwTWlycm9ySW5kZW50cy8+DQogICA8dzpPdmVycmlkZVRhYmxlU3R5bGVIcHMv Pg0KICAgPHc6VXNlRkVMYXlvdXQvPg0KICA8L3c6Q29tcGF0aWJpbGl0eT4NCiAgPG06bWF0aFBy Pg0KICAgPG06bWF0aEZvbnQgbTp2YWw9IkNhbWJyaWEgTWF0aCIvPg0KICAgPG06YnJrQmluIG06 dmFsPSJiZWZvcmUiLz4NCiAgIDxtOmJya0JpblN1YiBtOnZhbD0iJiM0NTstIi8+DQogICA8bTpz bWFsbEZyYWMgbTp2YWw9Im9mZiIvPg0KICAgPG06ZGlzcERlZi8+DQogICA8bTpsTWFyZ2luIG06 dmFsPSIwIi8+DQogICA8bTpyTWFyZ2luIG06dmFsPSIwIi8+DQogICA8bTpkZWZKYyBtOnZhbD0i Y2VudGVyR3JvdXAiLz4NCiAgIDxtOndyYXBJbmRlbnQgbTp2YWw9IjE0NDAiLz4NCiAgIDxtOmlu dExpbSBtOnZhbD0ic3ViU3VwIi8+DQogICA8bTpuYXJ5TGltIG06dmFsPSJ1bmRPdnIiLz4NCiAg PC9tOm1hdGhQcj48L3c6V29yZERvY3VtZW50Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQogPHc6TGF0ZW50U3R5bGVzIERlZkxvY2tlZFN0YXRlPSJmYWxzZSIg RGVmVW5oaWRlV2hlblVzZWQ9InRydWUiDQogIERlZlNlbWlIaWRkZW49InRydWUiIERlZlFGb3Jt YXQ9ImZhbHNlIiBEZWZQcmlvcml0eT0iOTkiDQogIExhdGVudFN0eWxlQ291bnQ9IjI3NiI+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMCIgU2VtaUhpZGRlbj0i ZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5v cm1hbCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNl bWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVl IiBOYW1lPSJoZWFkaW5nIDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDIiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJo ZWFkaW5nIDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5 IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDUi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDciLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBO YW1lPSJoZWFkaW5nIDgiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDkiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDEiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDIiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDMi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0i dG9jIDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIg TmFtZT0idG9jIDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSIzOSIgTmFtZT0idG9jIDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIzOSIgTmFtZT0idG9jIDciLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDgiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDkiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iY2FwdGlv biIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEwIiBTZW1p SGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIg TmFtZT0iVGl0bGUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSIxIiBOYW1lPSJEZWZhdWx0IFBhcmFncmFwaCBGb250Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMTEiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0aXRsZSIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIyIiBTZW1pSGlkZGVuPSJmYWxz ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3Ryb25n Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjAiIFNlbWlI aWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBO YW1lPSJFbXBoYXNpcyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjU5IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iVGFibGUgR3JpZCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJQbGFjZWhvbGRlciBUZXh0Ii8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5vIFNwYWNpbmciLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRl bj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmci Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhp ZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3Qi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhp ZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhp ZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFk aW5nIDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIg U2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1 bSBTaGFkaW5nIDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBMaXN0IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBMaXN0IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9Ik1lZGl1bSBHcmlkIDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgMSIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJm YWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQg MSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1p SGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3Jp ZCBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAg IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMSIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJSZXZpc2lvbiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjM0IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iTGlzdCBQYXJhZ3JhcGgiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyOSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlF1b3RlIi8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzAiIFNlbWlIaWRkZW49ImZhbHNlIg0K ICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIFF1 b3RlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNl bWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g TGlzdCAyIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCAxIi8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49 ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50 IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2Vt aUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVs IFNoYWRpbmcgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQog ICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDIiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRl bj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNj ZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIg U2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0 IEdyaWQgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDIiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2Ui DQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDIi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhp ZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0 IDIgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDIiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFs c2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMiIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlk ZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hh ZGluZyBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgMyIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJm YWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQg MyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1p SGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3Jp ZCBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAg IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMyIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVu PSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBB Y2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3 IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVk aXVtIEdyaWQgMSBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMyIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIN CiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAzIi8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49 ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5n IEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzIiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJD b2xvcmZ1bCBMaXN0IEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA0Ii8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNl Ig0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA0Ii8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRk ZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFj Y2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMi IFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gU2hhZGluZyAxIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA0Ii8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZh bHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2Vu dCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNl bWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g R3JpZCAxIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDQiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFs c2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNj ZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIg U2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9y ZnVsIExpc3QgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiDQog ICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDUiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0i ZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50 IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2Vt aUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBT aGFkaW5nIDEgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDUiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2Ui DQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDUi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhp ZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlk IDEgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNSIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIN CiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQg NSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1p SGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwg TGlzdCBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNiIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxz ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNiIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlk ZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRp bmcgMSBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAg IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNiIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVu PSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBB Y2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4 IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVk aXVtIEdyaWQgMiBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSINCiAgIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA2Ii8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRk ZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0 IEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NzMiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJD b2xvcmZ1bCBHcmlkIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMTkiIFNlbWlIaWRkZW49ImZhbHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0bGUgRW1waGFzaXMiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMSIgU2VtaUhpZGRlbj0iZmFsc2UiDQog ICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgRW1w aGFzaXMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMSIg U2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRy dWUiIE5hbWU9IlN1YnRsZSBSZWZlcmVuY2UiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSIzMiIgU2VtaUhpZGRlbj0iZmFsc2UiDQogICBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgUmVmZXJlbmNlIi8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzMiIFNlbWlIaWRkZW49ImZh bHNlIg0KICAgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJCb29r IFRpdGxlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzci IE5hbWU9IkJpYmxpb2dyYXBoeSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjM5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJUT0MgSGVhZGluZyIvPg0KIDwvdzpM YXRlbnRTdHlsZXM+DQo8L3htbD48IVtlbmRpZl0tLT4NCg0KPCEtLVtpZiBndGUgbXNvIDEwXT4N CjxzdHlsZT4NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KdGFibGUuTXNvTm9ybWFsVGFibGUN Cgl7bXNvLXN0eWxlLW5hbWU6IlRhYmxlIE5vcm1hbCI7DQoJbXNvLXRzdHlsZS1yb3diYW5kLXNp emU6MDsNCgltc28tdHN0eWxlLWNvbGJhbmQtc2l6ZTowOw0KCW1zby1zdHlsZS1ub3Nob3c6eWVz Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtcGFyZW50OiIiOw0KCW1zby1w YWRkaW5nLWFsdDowaW4gNS40cHQgMGluIDUuNHB0Ow0KCW1zby1wYXJhLW1hcmdpbjowaW47DQoJ bXNvLXBhcmEtbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9y cGhhbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbWJyaWE7DQoJbXNvLWFz Y2lpLWZvbnQtZmFtaWx5OkNhbWJyaWE7DQoJbXNvLWFzY2lpLXRoZW1lLWZvbnQ6bWlub3ItbGF0 aW47DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNhbWJyaWE7DQoJbXNvLWhhbnNpLXRoZW1lLWZv bnQ6bWlub3ItbGF0aW47fQ0KPC9zdHlsZT4NCjwhW2VuZGlmXS0tPg0KDQoNCg0KPCEtLVN0YXJ0 RnJhZ21lbnQtLT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDttc28tYmlkaS1mb250LXNp emU6MTIuMHB0Ow0KZm9udC1mYW1pbHk6Q291cmllcjttc28tZmFyZWFzdC1mb250LWZhbWlseTom cXVvdDvvvK3vvLMg5piO5pydJnF1b3Q7O21zby1mYXJlYXN0LXRoZW1lLWZvbnQ6DQptaW5vci1m YXJlYXN0O21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztt c28tYmlkaS10aGVtZS1mb250Om1pbm9yLWJpZGk7DQptc28tYW5zaS1sYW5ndWFnZTpFTi1VUztt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzttc28tYmlkaS1sYW5ndWFnZTpBUi1TQSI+ZHJhZnQt cG9say1sb2NhbC1lbWVyZ2VuY3ktcnBoLW5hbWVzcGFjZTwvc3Bhbj48IS0tRW5kRnJhZ21lbnQt LT4mbmJzcDsgdGhyb3VnaCB0aGUgSUVTRywgd2UgY2FtZSBhY3Jvc3MgYSBwcm9ibGVtLiAmbmJz cDtUaGUgZW1lcmdlbmN5LXJwaCBkb2N1bWVudCBtZXJlbHkgY3JlYXRlcyBhIG5hbWVzcGFjZSBh bmQgbmV3IHByaW9yaXR5IHZhbHVlcywgaXQgZG9lc24ndCBjb250YWluIGFueSBwcm90b2NvbCBt ZWNoYW5pc20uICZuYnNwO1NvbWUgQURzIGNvbXBsYWluZWQgdGhhdCB0aGlzIHdhcyBub3QsIHRo ZXJlZm9yZSwgYW4gYXBwcm9wcmlhdGUgZG9jdW1lbnQgZm9yIHN0YW5kYXJkcyB0cmFjay4gJm5i c3A7SG93ZXZlciwgdGhlIHJlZ2lzdHJ5IG9mIG5hbWVzcGFjZXMgYW5kIHRoZSBwcmlvcml0eSBy ZWdpc3RyeSB3ZXJlIGNyZWF0ZWQgd2l0aCBhIHBvbGljeSBvZiBzdGFuZGFyZHMtdHJhY2sgcmVx dWlyZWQgdG8gYWRkIHZhbHVlcy48ZGl2Pjxicj48L2Rpdj48ZGl2PkluIGhpbmRzaWdodCwgdGhp cyB3YXMgYSBtaXN0YWtlLiAmbmJzcDtBZGRpbmcgYSBuYW1lc3BhY2Ugb3IgcHJpb3JpdGllcyBk b2Vzbid0IG5lY2Vzc2FyaWx5IGFsdGVyIGFueSBwcm90b2NvbCwgYW5kIHNob3VsZG4ndCBuZWVk IHN0YW5kYXJkLXRyYWNrLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SSB3cm90ZSBhIGRvY3Vt ZW50IHRoYXQgdXBkYXRlcyBSRkM0NDEyIHRvIGNoYW5nZSB0aGUgcmVnaXN0cmllcyB0byAiSUVU RiBSZXZpZXciIChuZXcgZGVzaWduYXRpb24gZm9yIHdoYXQgd2FzICJJRVRGIENvbnNlbnN1cyIp LiAmbmJzcDtUaGF0J3MgYWxsIGl0IGRvZXMsIGNoYW5nZSB0aGUgcG9saWN5LiAmbmJzcDtJdCBt YWtlcyBOTyBvdGhlciBjaGFuZ2VzLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SXQgaXMgZW50 ZXJlZCBpbiB0aGUgInNob3J0ZXN0IFJGQyIgY29udGVzdC48L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2Pkkgd291bGQgbGlrZSB0byBtb3ZlIHRoaXMgdGhyb3VnaCB0aGUgcHJvY2VzcyBleHBlZGl0 aW91c2x5LiAmbmJzcDtPdXIgQUQgaXMgYmVoaW5kIHRoaXMgZWZmb3J0LiAmbmJzcDtJZiB5b3Ug d291bGQgdGFrZSBhIHF1aWNrIGxvb2sgYXQgdGhlIGRvY3VtZW50LCBvciwgaWYgeW91IGFyZSBp biBmYXZvciBvZiwgb3Igbm90IGluIGZhdm9yIG9mIGNoYW5naW5nIHRoZSByZWdpc3RyeSBwb2xp Y3ksIHBsZWFzZSByZXNwb25kIHRvIHRoZSBsaXN0IHNvIHdlIGtub3cgaWYgd2UgaGF2ZSBhIHF1 aWNrIGNvbnNlbnN1cy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkJyaWFuPC9kaXY+PGRpdj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YnI+PGRpdj48YnI+PGRpdj5CZWdpbiBmb3J3YXJkZWQg bWVzc2FnZTo8L2Rpdj48YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLXJp Z2h0OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTonSGVsdmV0aWNhJzsgZm9udC1zaXplOm1lZGl1bTsgY29sb3I6cmdi YSgwLCAwLCAwLCAxLjApOyI+PGI+RnJvbTogPC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6J0hlbHZldGljYSc7IGZvbnQtc2l6ZTptZWRpdW07Ij48YSBocmVmPSJtYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+PGJyPjwv c3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1yaWdodDogMHB4 OyBtYXJnaW4tYm90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7Ij48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6J0hlbHZldGljYSc7IGZvbnQtc2l6ZTptZWRpdW07IGNvbG9yOnJnYmEoMCwgMCwg MCwgMS4wKTsiPjxiPlN1YmplY3Q6IDwvYj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OidIZWx2ZXRpY2EnOyBmb250LXNpemU6bWVkaXVtOyI+PGI+SS1EIEFjdGlvbjogZHJhZnQtcm9z ZW4tcnBoLXJlZy1wb2xpY3ktMDAudHh0PC9iPjxicj48L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0i bWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBt YXJnaW4tbGVmdDogMHB4OyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OidIZWx2ZXRpY2EnOyBm b250LXNpemU6bWVkaXVtOyBjb2xvcjpyZ2JhKDAsIDAsIDAsIDEuMCk7Ij48Yj5EYXRlOiA8L2I+ PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTonSGVsdmV0aWNhJzsgZm9udC1zaXplOm1l ZGl1bTsiPkZlYnJ1YXJ5IDExLCAyMDEzIDk6MTU6NTcgQU0gRVNUPGJyPjwvc3Bhbj48L2Rpdj48 ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1yaWdodDogMHB4OyBtYXJnaW4tYm90 dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6J0hl bHZldGljYSc7IGZvbnQtc2l6ZTptZWRpdW07IGNvbG9yOnJnYmEoMCwgMCwgMCwgMS4wKTsiPjxi PlRvOiA8L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTonSGVsdmV0aWNhJzsgZm9u dC1zaXplOm1lZGl1bTsiPjxhIGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmciPmkt ZC1hbm5vdW5jZUBpZXRmLm9yZzwvYT48YnI+PC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdp bi10b3A6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2lu LWxlZnQ6IDBweDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTonSGVsdmV0aWNhJzsgZm9udC1z aXplOm1lZGl1bTsgY29sb3I6cmdiYSgwLCAwLCAwLCAxLjApOyI+PGI+UmVwbHktVG86IDwvYj48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OidIZWx2ZXRpY2EnOyBmb250LXNpemU6bWVk aXVtOyI+PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPC9hPjxicj48L3NwYW4+PC9kaXY+PGJyPjxkaXY+PGJyPkEgTmV3IElu dGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0 cyBkaXJlY3Rvcmllcy48YnI+PGJyPjxicj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0 eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPgk8L3NwYW4+VGl0bGUgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBSZXNvdXJjZSBQcmlvcml0 eSBIZWFkZXIgKFJQSCkgUmVnaXN0cnkgTWFuYWdlbWVudCBQb2xpY3kgdG8gSUVURiBSZXZpZXc8 YnI+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj4J PC9zcGFuPkF1dGhvcihzKSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IEJy aWFuIFJvc2VuPGJyPjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNw YWNlOnByZSI+CTwvc3Bhbj5GaWxlbmFtZSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs6IGRyYWZ0LXJvc2VuLXJwaC1yZWctcG9saWN5LTAwLnR4dDxicj48c3BhbiBj bGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPgk8L3NwYW4+UGFn ZXMgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7OiAzPGJyPjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNw YWNlOnByZSI+CTwvc3Bhbj5EYXRlICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogMjAxMy0wMi0wODxicj48YnI+QWJzdHJh Y3Q6PGJyPiAmbmJzcDsmbmJzcDtSRkM0NDEyIGRlZmluZXMgIlJlc291cmNlLVByaW9yaXR5IE5h bWVzcGFjZXMiIGFuZCAiUmVzb3VyY2UtUHJpb3JpdHk8YnI+ICZuYnNwOyZuYnNwO1ByaW9yaXR5 LXZhbHVlcyIgcmVnaXN0cmllcy4gJm5ic3A7VGhlIG1hbmFnZW1lbnQgcG9saWN5IG9mIHRoZXNl PGJyPiAmbmJzcDsmbmJzcDtyZWdpc3RyaWVzIGlzICJTdGFuZGFyZHMgQWN0aW9uIi4gJm5ic3A7 VGhpcyBkb2N1bWVudCBjaGFuZ2VzIHRoZTxicj4gJm5ic3A7Jm5ic3A7bWFuYWdlbWVudCBwb2xp Y3kgb2YgdGhlc2UgcmVnaXN0cmllcyB0byAiSUVURiBSZXZpZXciLjxicj48YnI+PGJyPlRoZSBJ RVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxicj48YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1yb3Nlbi1ycGgtcmVnLXBv bGljeSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcm9zZW4tcnBoLXJl Zy1wb2xpY3k8L2E+PGJyPjxicj5UaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWls YWJsZSBhdDo8YnI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcm9zZW4tcnBoLXJl Zy1wb2xpY3ktMDA8YnI+PGJyPjxicj5JbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxl IGJ5IGFub255bW91cyBGVFAgYXQ6PGJyPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvPGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj5JLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0PGJyPkktRC1Bbm5vdW5jZUBpZXRmLm9yZzxi cj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZTxicj5J bnRlcm5ldC1EcmFmdCBkaXJlY3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRt bDxicj5vciBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dDxicj48L2Rp dj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_32448F39E04742868C61C221D5738B7Cneustarbiz_-- From randy@qti.qualcomm.com Mon Feb 11 14:37:37 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2713721F84F9 for ; Mon, 11 Feb 2013 14:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzsORudGnM6T for ; Mon, 11 Feb 2013 14:37:36 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE6C21F84F5 for ; Mon, 11 Feb 2013 14:37:36 -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=1360621027; x=1392157027; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=Ya69B8a6mTokiuiIvxIVLTDZ948UGsy8hzyHETXqWdY=; b=fQjftHY+LP6T1d1uy3nN+C552zTQP6+FnGmnVMOiiCZTNNl3LIbVdnKz 9wouhXWgdB94l8d515ScnwbGBXFvfrpNFf3WrqmAwJY3uzwpFLxqOzHr9 S5SwPC2M4vGUnqF2PLRZ5zfwTQbdm47nTxeK8n0EhZoFOrnxK3DpiV5ST Y=; X-IronPort-AV: E=Sophos;i="4.84,646,1355126400"; d="scan'208";a="22029650" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth01.qualcomm.com with ESMTP; 11 Feb 2013 14:17:06 -0800 X-IronPort-AV: E=Sophos;i="4.84,646,1355126400"; d="scan'208";a="421521627" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 11 Feb 2013 14:37:35 -0800 Received: from [10.2.13.86] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 11 Feb 2013 14:37:35 -0800 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Mon, 11 Feb 2013 14:37:32 -0800 To: "Rosen, Brian" , "ecrit@ietf.org Org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.48.1] Subject: Re: [Ecrit] Whither data-only X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 22:37:37 -0000 Excuse my top-posting. The suggested new name, "Citizen to Authority Alerts," gets to the heart of the issue, I think: is this functionality for autonomous devices sending alerts to an aggregator or a PSAP, or is this a "conventional" emergency call on behalf of a person? The use cases that were described for all sorts of autonomous systems seemed both compelling and numerous (e.g., building fire alarms, building burglar alarms, flood alerts, earthquake sensors, chemical leak sensors, etc.) If those use cases still exist and still need to be solved, then I suggest advancing the document as originally conceived, focused on autonomous alerts. When the concept of updates was first introduced, it was described as a rare edge case. If that is still true, then publish a simple document that simply handles one-shot data-only alerts, and add subscribe/notify as an extension later. In contrast, an emergency call where there is a human involved, even if the call is initiated by a device and not the person, should be handled as a normal emergency call with a media path. Even if the person is unconscious, a voice path is desirable for many reasons (including allowing the PSAP call taker to hear background noise). At 1:11 PM -0500 1/29/13, Brian Rosen wrote: > We ran a WGLC on data-only, and got some comments. The discussion > raises some fundamental issues that authors have been discussing. > Here is our current thinking, which we would like discussion on > before we rev the draft. > > "Data Only" was intended, originally, for a sensor equipped > automaton to send an alarm to a PSAP when there was no media. It > uses a CAP message in the body of a MESSAGE to do that. > > It's been observed that there are cases where you have exactly the > same kind of thing, with the same data, but you ALSO have media. > In such a case, we would like to have the data sent the same way > (CAP message in a body) > > It's also been asked how updates to the alarm are sent. At one > point there was some discussion of using MSRP to send a series of > messages. Authors don't like this mechanism because it doesn't > allow the PSAP to control the rate of updates. We suggest that > updates be handled with a SUB/NOT, with filtering, and the CAP > message in the body of the NOTIFY. > > If we were to do this, it would be major surgery to the existing > draft, including a name change. Nevertheless, that seems to be the > right way to go. We would: > a)Define the mechanism to carry a CAP message in the body of a SIP > transaction, and define it for use in INVITE, MESSAGE and NOTIFY > b) Specify that INVITE is appropriate for alarms with media > (creates session), and MESSAGE for alarms without media (doesn't > create a session), but otherwise are equivalent. > c) Define a SUB/NOT package, with filtering, for updates to the alarm data > d) Change the name to something like "Citizen to Authority Alerts". > > This would mean re-running WGLC. > > Comments? > > Brian > > _______________________________________________ > 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: --------------- I suppose when it gets to that point, we shan't know how it does it. --Alan Turing From brian.rosen@neustar.biz Mon Feb 11 15:00:57 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E45421F8AA0 for ; Mon, 11 Feb 2013 15:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.975 X-Spam-Level: X-Spam-Status: No, score=-5.975 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhWBoNqPxJ-r for ; Mon, 11 Feb 2013 15:00:56 -0800 (PST) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 26ABD21F8A9B for ; Mon, 11 Feb 2013 15:00:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1360623528; x=1675980191; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=bmjv7mLFZvVKF+f7Z92UV hvd8oNlm0ljoZIJS8nv1bs=; b=icCj3upsygObjDemt0bSvhxWz/As8RLchDb/+ 6KgzN4/khVzNie9d8/gWcvz7zNdS0G3VsP3EKrtaCr7hquSfQ== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.16325851; Mon, 11 Feb 2013 17:58:47 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Mon, 11 Feb 2013 18:00:53 -0500 From: "Rosen, Brian" To: Randall Gellens Date: Mon, 11 Feb 2013 18:00:51 -0500 Thread-Topic: [Ecrit] Whither data-only Thread-Index: Ac4Iq6PK/MxveMWiRoyuyorVjGlKNg== Message-ID: <0BE72612-3A42-4D4D-A5C6-AE5B4CF67299@neustar.biz> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: ChqSPbgSuqeVmykGHVu4uw== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "ecrit@ietf.org Org" Subject: Re: [Ecrit] Whither data-only X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 23:00:57 -0000 Thanks for the comments. See inline On Feb 11, 2013, at 5:37 PM, Randall Gellens wrote= : > Excuse my top-posting. >=20 > The suggested new name, "Citizen to Authority Alerts," gets to the heart = of the issue, I think: is this functionality for autonomous devices sending= alerts to an aggregator or a PSAP, or is this a "conventional" emergency c= all on behalf of a person? Well, the issue here is that we want to have a document that describes the = data structure that could be sent with a call (that is, with media), or wit= hout a call ("data only"). Citizen to Authority Alerts does get to the hea= rt of the matter, but it might be confusing when sent with a call. So, if you have a total automaton, say an alarm system in a building, you w= ould send the data without any media. If you had, say, an elevator distres= s alarm, that could have media. The data structure would look the same, an= d would be carried the same way. One would be carried with MESSAGE, the o= ther with INVITE. >=20 > The use cases that were described for all sorts of autonomous systems see= med both compelling and numerous (e.g., building fire alarms, building burg= lar alarms, flood alerts, earthquake sensors, chemical leak sensors, etc.) Yes, there are a lot of them. =20 >=20 > If those use cases still exist and still need to be solved, then I sugges= t advancing the document as originally conceived, focused on autonomous ale= rts. When the concept of updates was first introduced, it was described as= a rare edge case. If that is still true, then publish a simple document t= hat simply handles one-shot data-only alerts, and add subscribe/notify as a= n extension later. Well, but=85. In your list of examples, which is good, updates could happen for nearly an= y of them. It's not a corner case.=20 I don't really mind having two or three documents, but it seems, at the mom= ent, to be silly to do that when we know what we're trying to accomplish. >=20 > In contrast, an emergency call where there is a human involved, even if t= he call is initiated by a device and not the person, should be handled as a= normal emergency call with a media path. Even if the person is unconsciou= s, a voice path is desirable for many reasons (including allowing the PSAP = call taker to hear background noise). Yes, of course. We agree. But how do you handle the sensor data, with the= updates, that might come (elevator) or would never come (general building = alarm)? Let me take another crack at this: There are various automatons that create data that might be useful to send = to a PSAP. Some of these ALSO may have a media path. Many of these can pr= ovide updates to the sensor data. With and without media is, of course, an important difference, but the DATA= part, we think, ought to look the same - same data definition/XML/CAP Wrap= per/... Updates to the data is a frequently occurring thing, but the PSAP has to be= in control. So just repeating the initial alert is NOT the right thing t= o do. We could: a) Write a document that describes the data for an alert b) Write a document that describes carrying the data in an INVITE c) Write a document that describes carrying the data in a MESSAGE d) Write a document that describes updates to the data. The present document is, pretty much, a and c. We could leave it, then write two more documents (b and d) But that doesn't make a whole lot of sense, given that we know where we wan= t to go. But, as I said, it doesn't really matter to me how many documents this take= s, and I'll follow the wishes of the work group. If the path of least resi= stance is leave it (a and c), I'll restructure it a bit so we can reference= the "a" part when we create b and d. Brian >=20 >=20 >=20 >=20 > At 1:11 PM -0500 1/29/13, Brian Rosen wrote: >=20 >> We ran a WGLC on data-only, and got some comments. The discussion raise= s some fundamental issues that authors have been discussing. Here is our cu= rrent thinking, which we would like discussion on before we rev the draft. >>=20 >> "Data Only" was intended, originally, for a sensor equipped automaton to= send an alarm to a PSAP when there was no media. It uses a CAP message in= the body of a MESSAGE to do that. >>=20 >> It's been observed that there are cases where you have exactly the same = kind of thing, with the same data, but you ALSO have media. In such a case,= we would like to have the data sent the same way (CAP message in a body) >>=20 >> It's also been asked how updates to the alarm are sent. At one point th= ere was some discussion of using MSRP to send a series of messages. Author= s don't like this mechanism because it doesn't allow the PSAP to control th= e rate of updates. We suggest that updates be handled with a SUB/NOT, with= filtering, and the CAP message in the body of the NOTIFY. >>=20 >> If we were to do this, it would be major surgery to the existing draft, = including a name change. Nevertheless, that seems to be the right way to g= o. We would: >> a)Define the mechanism to carry a CAP message in the body of a SIP trans= action, and define it for use in INVITE, MESSAGE and NOTIFY >> b) Specify that INVITE is appropriate for alarms with media (creates ses= sion), and MESSAGE for alarms without media (doesn't create a session), but= otherwise are equivalent. >> c) Define a SUB/NOT package, with filtering, for updates to the alarm da= ta >> d) Change the name to something like "Citizen to Authority Alerts". >>=20 >> This would mean re-running WGLC. >>=20 >> Comments? >>=20 >> Brian >>=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: --------------- > I suppose when it gets to that point, we shan't know how it does it. > --Alan Turing > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From christer.holmberg@ericsson.com Fri Feb 15 00:33:25 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1905F21F8739 for ; Fri, 15 Feb 2013 00:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.183 X-Spam-Level: X-Spam-Status: No, score=-7.183 tagged_above=-999 required=5 tests=[AWL=1.066, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aubbPGNPyXR for ; Fri, 15 Feb 2013 00:33:23 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 699E721F88A1 for ; Fri, 15 Feb 2013 00:33:23 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-06-511df2cdb1bf Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 5F.1F.19728.DC2FD115; Fri, 15 Feb 2013 09:33:17 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.195]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0318.004; Fri, 15 Feb 2013 09:33:17 +0100 From: Christer Holmberg To: "ecrit@ietf.org" Thread-Topic: Draft new: draft-holmberg-ecrit-country-specific-emergency-services-00 Thread-Index: Ac4LU4j4ozfjOyGzQBKMNmy3g3cgvQ== Date: Fri, 15 Feb 2013 08:33:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0D8DCA@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM+Jvje7ZT7KBBgu3G1o0LnrK6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujDvfT7AWLGet+D3LrIFxLUsXIyeHhICJxKwd+9khbDGJC/fW s3UxcnEICRxilJg8Yy0ThLOEUeL8/H9ADgcHm4CFRPc/bZAGEQFViQ1nVjKC2MICgRIfO08x Q8TDJCYt+wpl60mcfXMPbBkLUP3xK9uZQGxeAW+Ji7t+gvUyAi3+fmoNWJxZQFzi1pP5TBAH CUgs2XOeGcIWlXj5+B8rhK0osfNsOzNEvY7Egt2f2CBsbYllC18zQ8wXlDg58wnLBEbhWUjG zkLSMgtJyywkLQsYWVYxsucmZuaklxttYgQG8cEtv1V3MN45J3KIUZqDRUmcN9z1QoCQQHpi SWp2ampBalF8UWlOavEhRiYOTqkGxsZ8PWvB/XZTcmMas1t/xVkd1c5jtxJznNrvbK6xeXfp 5YPiwrIJUzIjivJ8Mhe+Oi2Ru7W50Wxu98eW35sWxS5jWmjV/XzNn1+XagtaNUqmK5paL9p+ eMNZDStmNQEHsV+fbn/wjZRS59v1/cnNGxJbnP4/nRIxN/jns6yKZTbrV77oTBc9pcRSnJFo qMVcVJwIANgwWHQwAgAA Subject: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emergency-services-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 08:33:25 -0000 Hi, As previously discussed, some existing emergency services might be offered = in one specific country only, and RFC 5031 currently does not allow registe= ring country specific service URNs. We have submitted a draft, draft-holmberg-ecrit-country-emg-urn-00.txt, whi= ch suggests a solution, by defining a dedicated URN sub-service, with a rel= axed registration policy, for country specific emergency services. Such URN would look something like: urn:service:sos.country-specific.. Feel free to comment :) I would also like to request agenda in Orlando to discuss this. Regards, Christer From hannes.tschofenig@gmx.net Fri Feb 15 02:04:33 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010AB21F8A09 for ; Fri, 15 Feb 2013 02:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.456 X-Spam-Level: X-Spam-Status: No, score=-103.456 tagged_above=-999 required=5 tests=[AWL=1.143, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxhO9uKbKcxp for ; Fri, 15 Feb 2013 02:04:32 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0789121F89FC for ; Fri, 15 Feb 2013 02:04:31 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Lds7x-1UoBoL3WDL-00iz3g for ; Fri, 15 Feb 2013 11:04:30 +0100 Received: (qmail invoked by alias); 15 Feb 2013 10:04:30 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.100]) [88.115.219.140] by mail.gmx.net (mp027) with SMTP; 15 Feb 2013 11:04:30 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+31bwdZbi3DeJgm7SOmOcmVHyBpsh6Qi8bsnSpxO /cgu7ZjS2vgf45 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0D8DCA@ESESSMB209.ericsson.se> Date: Fri, 15 Feb 2013 12:04:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B0D8DCA@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emergency-services-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 10:04:33 -0000 Christer, I may misunderstand your writeup.=20 We already have certain service URNs that are applicable only to certain = countries. As an example pick mountain rescue = (urn:service:sos.mountain).=20 Karl Heinz later defined an extension that allows you to list the = available service URNs in a specific region, see =20 http://tools.ietf.org/html/rfc6197 You may want to do is to register a new Service URN for spy reporting, = GAULA (anti-kidnapping), etc. Ciao Hannes On Feb 15, 2013, at 10:33 AM, Christer Holmberg wrote: > Hi, >=20 > As previously discussed, some existing emergency services might be = offered in one specific country only, and RFC 5031 currently does not = allow registering country specific service URNs. >=20 > We have submitted a draft, = draft-holmberg-ecrit-country-emg-urn-00.txt, which suggests a solution, = by defining a dedicated URN sub-service, with a relaxed registration = policy, for country specific emergency services. >=20 > Such URN would look something like: = urn:service:sos.country-specific.. >=20 > Feel free to comment :) >=20 > I would also like to request agenda in Orlando to discuss this. >=20 > Regards, >=20 > Christer >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From ivo.sedlacek@ericsson.com Fri Feb 15 02:59:02 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC1521F86AF for ; Fri, 15 Feb 2013 02:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=1.710, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGdNR-1EeJaV for ; Fri, 15 Feb 2013 02:59:00 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id EDCDB21F8692 for ; Fri, 15 Feb 2013 02:58:59 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-7e-511e14f2740d Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C4.66.19728.2F41E115; Fri, 15 Feb 2013 11:58:59 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.40]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0318.004; Fri, 15 Feb 2013 11:58:58 +0100 From: Ivo Sedlacek To: Hannes Tschofenig , Christer Holmberg Thread-Topic: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emergency-services-00 Thread-Index: AQHOC2PfsGUnB5OkIky24qz/Lb9ZY5h6vKYQ Date: Fri, 15 Feb 2013 10:58:57 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101086378@ESESSMB301.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B0D8DCA@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B31079006101086378ESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvje5nEblAgyuL2S0aFz1ltVi68x6r A5PH4k372TyWLPnJFMAUxWWTkpqTWZZapG+XwJVx48NMtoKPORWPL7czNjA2xHcxcnJICJhI XP2+gQ3CFpO4cG89kM3FISRwiFHi3o9zLBDOYkaJvb1vmUGq2AT0JCZuOcIKYosIpEs82XSQ BcRmFlCVONf4GMwWFoiV2LpsOiNETZzE/0P/gXo5gGwjiR0/nEDCLEDlC6ecAlvMK+AtcWHW J7BWIYEaiQfPP4KN5xSwltjw7jnYWkYBWYmrf3oZIVaJS9x6Mp8J4mgBiSV7zjND2KISLx// YwVZJSGgKLG8Xw6iPF9i8dWtzBCrBCVOznzCMoFRdBaSSbOQlM1CUgYR15O4MXUKG4StLbFs 4WtmCFtXYsa/QyzI4gsY2VcxsucmZuaklxttYgRG1MEtv1V3MN45J3KIUZqDRUmcN9z1QoCQ QHpiSWp2ampBalF8UWlOavEhRiYOTqkGxtC9YTqq9yNmTQh2OhV1dcdCpWWbRV8H79lyjSPD 7chhFvd7D3iUU3dfD9ydcPJly9ZTbxebHmvrnznT3jDj7uzLjYKfJQW4/Q84ZaaeP8oicJTF fsrXY1c+srgkPnOrXeBotNn2yxG1+yX3Jp0/EiN+rFMxNq2+/G1WutxPmZ1O8zlmtbcumKHE UpyRaKjFXFScCADOZStcdgIAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emergency-services-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 10:59:02 -0000 --_000_39B5E4D390E9BD4890E2B31079006101086378ESESSMB301ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, The mountain rescue emergency service is offered at least in Austria (Alpin= e rescue) and Ireland (The Mountain and Cave Rescue) according to http://en= .wikipedia.org/wiki/Emergency_telephone_number and in Poland (ratownictwo m= orskie i g=F3rskie) according to http://uke.gov.pl/tablice-numerow-kierowan= ia-alarmowego-nka-9410 Thus, RFC5031 criteria for registration (see below) are satisfied for the m= ountain rescue emergency service. ------------------ The 'sos' service type describes emergency services requiring an immediate response, typically offered by various branches of the government or other public institutions. Additional sub-services can be added after expert review and must be of general public interest and have a similar emergency nature. The expert is designated by the ECRIT working group, its successor, or, in their absence, the IESG. >>The expert review should only approve emergency services that are offered widely and in different countries, with approximately the same caller expectation in terms of services rendered. << The 'sos' service is not meant to invoke general government, public information, counseling, or social services. ------------------ However, - the "Reporting spies" emergency service is offered in South Korea only an= d thus would not pass the RFC5031 criteria above. - the "GAULA (anti-kidnapping)" emergency service is offered in Colombia on= ly and thus would not pass the RFC5031 criteria above. 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 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: 15. =FAnora 2013 11:04 To: Christer Holmberg Cc: ecrit@ietf.org Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emerg= ency-services-00 Christer, I may misunderstand your writeup. We already have certain service URNs that are applicable only to certain co= untries. As an example pick mountain rescue (urn:service:sos.mountain). Karl Heinz later defined an extension that allows you to list the available= service URNs in a specific region, see http://tools.ietf.org/html/rfc6197 You may want to do is to register a new Service URN for spy reporting, GAUL= A (anti-kidnapping), etc. Ciao Hannes On Feb 15, 2013, at 10:33 AM, Christer Holmberg wrote: > Hi, > > As previously discussed, some existing emergency services might be offere= d in one specific country only, and RFC 5031 currently does not allow regis= tering country specific service URNs. > > We have submitted a draft, draft-holmberg-ecrit-country-emg-urn-00.txt, w= hich suggests a solution, by defining a dedicated URN sub-service, with a r= elaxed registration policy, for country specific emergency services. > > Such URN would look something like: urn:service:sos.country-specific.. > > Feel free to comment :) > > I would also like to request agenda in Orlando to discuss this. > > Regards, > > Christer > > > _______________________________________________ > 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_39B5E4D390E9BD4890E2B31079006101086378ESESSMB301ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

The mountain rescue emergency service is offered = at least in Austria (Alpine rescue) and Ireland (The Mountain and Cave Resc= ue) according to http://en.wikipedia.org/wiki/Emergency_telephone_number an= d in Poland (ratownictwo morskie i g=F3rskie) according to http://uke.gov.pl/tablice-numerow-kierowania-alarm= owego-nka-9410

 

Thus, RFC5031 criteria for registration (see belo= w) are satisfied for the mountain rescue emergency service.

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

   The 'sos' service type describes eme= rgency services requiring an

   immediate response, typically offere= d by various branches of the

   government or other public instituti= ons.  Additional sub-services can

   be added after expert review and mus= t be of general public interest

   and have a similar emergency nature.=   The expert is designated by the

   ECRIT working group, its successor, = or, in their absence, the IESG.

   >>The expert review shou= ld only approve emergency services that are

   offered widely and in differen= t countries, with approximately the

   same caller expectation in ter= ms of services rendered. << The 'sos'

   service is not meant to invoke gener= al government, public

   information, counseling, or social s= ervices.

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

 

However, 
- the "Reporting spies" emergency service is of=
fered in South Korea only and thus would not pass the RFC5031 criteria abov=
e.
- the "GAULA (anti-kidnapping)" emergency servi=
ce is offered in Colombia only and thus would not pass the RFC5031 criteria=
 above.

 

Kind regards

 

Ivo Sedlacek

 

This Communication is Confidential. We only send = and receive email on the basis of the terms set out at www.ericsson.com/ema= il_disclaimer

 

-----Original Message-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of H= annes Tschofenig
Sent: 15. =FAnora 2013 11:04
To: Christer Holmberg
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emerg= ency-services-00

 

Christer, I may misunderstand your writeup. =

 

We already have certain service URNs that are app= licable only to certain countries. As an example pick mountain rescue (urn:= service:sos.mountain).

 

Karl Heinz later defined an extension that allows= you to list the available service URNs in a specific region, see 

http://tools.ietf.org/h= tml/rfc6197

 

You may want to do is to register a new Service U= RN for spy reporting, GAULA (anti-kidnapping), etc.

 

Ciao

Hannes

 

On Feb 15, 2013, at 10:33 AM, Christer Holmberg w= rote:

 

> Hi,

>

> As previously discussed, some existing emerg= ency services might be offered in one specific country only, and RFC 5031 c= urrently does not allow registering country specific service URNs.

>

> We have submitted a draft, draft-holmberg-ec= rit-country-emg-urn-00.txt, which suggests a solution, by defining a dedica= ted URN sub-service, with a relaxed registration policy, for country specif= ic emergency services.

>

> Such URN would look something like: urn:serv= ice:sos.country-specific.<two letter country code>.<identifier ass= igned by PSAP>

>

> Feel free to comment :)

>

> I would also like to request agenda in Orlan= do to discuss this.

>

> Regards,

>

> Christer

>

>

> ____________________________________________= ___

> Ecrit mailing list

> Ecrit@ietf.org<= /o:p>

> https://w= ww.ietf.org/mailman/listinfo/ecrit

 

_______________________________________________

Ecrit mailing list

Ecrit@ietf.org=

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

--_000_39B5E4D390E9BD4890E2B31079006101086378ESESSMB301ericsso_-- From hannes.tschofenig@gmx.net Fri Feb 15 08:10:47 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A08B21F8857 for ; Fri, 15 Feb 2013 08:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.485 X-Spam-Level: X-Spam-Status: No, score=-103.485 tagged_above=-999 required=5 tests=[AWL=1.114, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTcghylsenJz for ; Fri, 15 Feb 2013 08:10:46 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id D9F9621F84E2 for ; Fri, 15 Feb 2013 08:10:45 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.4]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LdbDA-1Uo0AB0McM-00iowI for ; Fri, 15 Feb 2013 17:10:45 +0100 Received: (qmail invoked by alias); 15 Feb 2013 16:10:44 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.100]) [88.115.219.140] by mail.gmx.net (mp004) with SMTP; 15 Feb 2013 17:10:44 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX197nrFas5B7Nq8Vvs7X1hwDYIfDus7xcc2uzYPBTv hwSGWHVLh+NjEt Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Hannes Tschofenig In-Reply-To: <39B5E4D390E9BD4890E2B31079006101086378@ESESSMB301.ericsson.se> Date: Fri, 15 Feb 2013 18:10:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <076C52A7-194F-4C9B-A607-7C5AA685E8FF@gmx.net> References: <7594FB04B1934943A5C02806D1A2204B0D8DCA@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101086378@ESESSMB301.ericsson.se> To: Ivo Sedlacek X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emergency-services-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 16:10:47 -0000 Hi Ivo,=20 you are correct that there are restrictions on what you can register = under the sos tree. The idea was that it focuses on the emergency = services rescue functionality and not on other functionality that do not = have the emergency services nature (such as pizza delivery) or are = otherwise entirely different.=20 If you believe it does not belong under the sos tree for the indicated = reasons then it may make sense to register it under a different label.=20= Ciao Hannes On Feb 15, 2013, at 12:58 PM, Ivo Sedlacek wrote: > Hello, > =20 > The mountain rescue emergency service is offered at least in Austria = (Alpine rescue) and Ireland (The Mountain and Cave Rescue) according = tohttp://en.wikipedia.org/wiki/Emergency_telephone_number and in Poland = (ratownictwo morskie i g=F3rskie) according to = http://uke.gov.pl/tablice-numerow-kierowania-alarmowego-nka-9410 > =20 > Thus, RFC5031 criteria for registration (see below) are satisfied for = the mountain rescue emergency service. > ------------------ > The 'sos' service type describes emergency services requiring an > immediate response, typically offered by various branches of the > government or other public institutions. Additional sub-services = can > be added after expert review and must be of general public interest > and have a similar emergency nature. The expert is designated by = the > ECRIT working group, its successor, or, in their absence, the IESG. > >>The expert review should only approve emergency services that are > offered widely and in different countries, with approximately the > same caller expectation in terms of services rendered. << The 'sos' > service is not meant to invoke general government, public > information, counseling, or social services. > ------------------ > =20 > However,=20 > - the "Reporting spies" emergency service is offered in South Korea = only and thus would not pass the RFC5031 criteria above. > - the "GAULA (anti-kidnapping)" emergency service is offered in = Colombia only and thus would not pass the RFC5031 criteria above.=20 > =20 > Kind regards > =20 > Ivo Sedlacek > =20 > This Communication is Confidential. We only send and receive email on = the basis of the terms set out at www.ericsson.com/email_disclaimer > =20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Hannes Tschofenig > Sent: 15. =FAnora 2013 11:04 > To: Christer Holmberg > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Draft new: = draft-holmberg-ecrit-country-specific-emergency-services-00 > =20 > Christer, I may misunderstand your writeup. > =20 > We already have certain service URNs that are applicable only to = certain countries. As an example pick mountain rescue = (urn:service:sos.mountain). > =20 > Karl Heinz later defined an extension that allows you to list the = available service URNs in a specific region, see=20 > http://tools.ietf.org/html/rfc6197 > =20 > You may want to do is to register a new Service URN for spy reporting, = GAULA (anti-kidnapping), etc. > =20 > Ciao > Hannes > =20 > On Feb 15, 2013, at 10:33 AM, Christer Holmberg wrote: > =20 > > Hi, > > > > As previously discussed, some existing emergency services might be = offered in one specific country only, and RFC 5031 currently does not = allow registering country specific service URNs. > > > > We have submitted a draft, = draft-holmberg-ecrit-country-emg-urn-00.txt, which suggests a solution, = by defining a dedicated URN sub-service, with a relaxed registration = policy, for country specific emergency services. > > > > Such URN would look something like: = urn:service:sos.country-specific.. > > > > Feel free to comment :) > > > > I would also like to request agenda in Orlando to discuss this. > > > > Regards, > > > > Christer > > > > > > _______________________________________________ > > 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 From christer.holmberg@ericsson.com Fri Feb 15 08:24:49 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDC221F896B for ; Fri, 15 Feb 2013 08:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.246 X-Spam-Level: X-Spam-Status: No, score=-7.246 tagged_above=-999 required=5 tests=[AWL=1.003, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tvtWAAxr8G8 for ; Fri, 15 Feb 2013 08:24:48 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B872821F88E3 for ; Fri, 15 Feb 2013 08:24:47 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-15-511e614e62dc Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 6B.91.19728.E416E115; Fri, 15 Feb 2013 17:24:46 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.195]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0318.004; Fri, 15 Feb 2013 17:24:46 +0100 From: Christer Holmberg To: Hannes Tschofenig , Ivo Sedlacek Thread-Topic: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emergency-services-00 Thread-Index: AQHOC5cEZu2n977KGEGnXfxcgusK55h7Gh8w Date: Fri, 15 Feb 2013 16:24:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0D933D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B0D8DCA@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101086378@ESESSMB301.ericsson.se> <076C52A7-194F-4C9B-A607-7C5AA685E8FF@gmx.net> In-Reply-To: <076C52A7-194F-4C9B-A607-7C5AA685E8FF@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvja5folygwZIPahaNi56yWizdeY/V gclj8ab9bB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4tmUeW8F31YplncoNjJ/luhg5OSQETCT+ PDnKBGGLSVy4t56ti5GLQ0jgEKPE+dtvWEASQgJLGCVOT3PvYuTgYBOwkOj+pw0SFhGIlZiy 5wEriM0soCpxrvExWLkwUHzdooeMEDVxEksmzYeyjSS2/NvBBmKzANXf/TQDzOYV8Jbo3X8N au97RomjJ6eDNXAKWEucf3KGGcRmBDru+6k1TBDLxCVuPZkPdbSAxJI955khbFGJl4//sYLc KSGgKLG8Xw6iXE/ixtQpbBC2tsSyha+ZIfYKSpyc+YRlAqPYLCRTZyFpmYWkZRaSlgWMLKsY 2XMTM3PSy402MQLj4+CW36o7GO+cEznEKM3BoiTOG+56IUBIID2xJDU7NbUgtSi+qDQntfgQ IxMHp1QD48bgMFVG160i0ouSRPQ2ND/mZUj+u6HI4aDMxGUql/mX/jhkfyDdrTPH47yAregx nwkfrkSskfp4f5pVx5f9oY41Dve4Lxwu/nnx2bSzp9OkCg7+dc9fY3lc65Cdenyc1CmHx6LL Lke5HWU9LLYsUJk/WsGhrqnjC2OvF++Kv2cZj7MqiektUGIpzkg01GIuKk4EAK5Jgb5dAgAA Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emergency-services-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 16:24:49 -0000 Hi Hannes, The idea is not to create a mechanism for pizza delivery, or whatever other= non-emergency-nature service - even if they would be specific to one count= ry. Or, do you foresee that one would call James Bond to deliver a pizza? ;) Regards, Christer -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: 15. helmikuuta 2013 18:11 To: Ivo Sedlacek Cc: Hannes Tschofenig; Christer Holmberg; ecrit@ietf.org Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emerg= ency-services-00 Hi Ivo,=20 you are correct that there are restrictions on what you can register under = the sos tree. The idea was that it focuses on the emergency services rescue= functionality and not on other functionality that do not have the emergenc= y services nature (such as pizza delivery) or are otherwise entirely differ= ent.=20 If you believe it does not belong under the sos tree for the indicated reas= ons then it may make sense to register it under a different label.=20 Ciao Hannes On Feb 15, 2013, at 12:58 PM, Ivo Sedlacek wrote: > Hello, > =20 > The mountain rescue emergency service is offered at least in Austria (Alp= ine rescue) and Ireland (The Mountain and Cave Rescue) according tohttp://e= n.wikipedia.org/wiki/Emergency_telephone_number and in Poland (ratownictwo = morskie i g=F3rskie) according to http://uke.gov.pl/tablice-numerow-kierowa= nia-alarmowego-nka-9410 > =20 > Thus, RFC5031 criteria for registration (see below) are satisfied for the= mountain rescue emergency service. > ------------------ > The 'sos' service type describes emergency services requiring an > immediate response, typically offered by various branches of the > government or other public institutions. Additional sub-services can > be added after expert review and must be of general public interest > and have a similar emergency nature. The expert is designated by the > ECRIT working group, its successor, or, in their absence, the IESG. > >>The expert review should only approve emergency services that are > offered widely and in different countries, with approximately the > same caller expectation in terms of services rendered. << The 'sos' > service is not meant to invoke general government, public > information, counseling, or social services. > ------------------ > =20 > However,=20 > - the "Reporting spies" emergency service is offered in South Korea only = and thus would not pass the RFC5031 criteria above. > - the "GAULA (anti-kidnapping)" emergency service is offered in Colombia = only and thus would not pass the RFC5031 criteria above.=20 > =20 > Kind regards > =20 > Ivo Sedlacek > =20 > This Communication is Confidential. We only send and receive email on the= basis of the terms set out at www.ericsson.com/email_disclaimer > =20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of= Hannes Tschofenig > Sent: 15. =FAnora 2013 11:04 > To: Christer Holmberg > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-eme= rgency-services-00 > =20 > Christer, I may misunderstand your writeup. > =20 > We already have certain service URNs that are applicable only to certain = countries. As an example pick mountain rescue (urn:service:sos.mountain). > =20 > Karl Heinz later defined an extension that allows you to list the availab= le service URNs in a specific region, see=20 > http://tools.ietf.org/html/rfc6197 > =20 > You may want to do is to register a new Service URN for spy reporting, GA= ULA (anti-kidnapping), etc. > =20 > Ciao > Hannes > =20 > On Feb 15, 2013, at 10:33 AM, Christer Holmberg wrote: > =20 > > Hi, > > > > As previously discussed, some existing emergency services might be offe= red in one specific country only, and RFC 5031 currently does not allow reg= istering country specific service URNs. > > > > We have submitted a draft, draft-holmberg-ecrit-country-emg-urn-00.txt,= which suggests a solution, by defining a dedicated URN sub-service, with a= relaxed registration policy, for country specific emergency services. > > > > Such URN would look something like: urn:service:sos.country-specific.. > > > > Feel free to comment :) > > > > I would also like to request agenda in Orlando to discuss this. > > > > Regards, > > > > Christer > > > > > > _______________________________________________ > > 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 From rlb@ipv.sx Fri Feb 15 11:40:49 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0C321F862B for ; Fri, 15 Feb 2013 11:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=1.448, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxwRxuk3dE3Q for ; Fri, 15 Feb 2013 11:40:48 -0800 (PST) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id 16AFE21F8626 for ; Fri, 15 Feb 2013 11:40:48 -0800 (PST) Received: by mail-oa0-f49.google.com with SMTP id j6so4072790oag.8 for ; Fri, 15 Feb 2013 11:40:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=eAYIsn/h+y0ZGi0AenS27+CCxpFUYpcwWcxJAvp7cYs=; b=obwtIz3MAA7b/Y1C+23NaF+f3OVatRiFga+AWB0dpdVhZgMyizyNvBvTRFFI78tRt0 J2HLzJdA9jt9N7fRi8bEwh0nWxDGla+bi15BVmm1B3aSQBZrz+79KpKfRSwhIyq43+2Z v53jUtEiyp7g5W46GNLtDZs8vT7HwieZN5Cvt7SJTSBPmaxQrd1JRGAazlBd0fA47Srr 9rfwp8ZQwEqHPVWDJnUXBZWw2ko4d+XdsP9nDkdZUPlVmVnFxDRmkDva58IT47oHAMMn oCBp0/LXNjNhBrf4qOsnctwfg+75Bc2j9LoZnDhKBIsw552PiLEO6wnS+Fc1QWrbSuim 2shg== MIME-Version: 1.0 X-Received: by 10.60.30.201 with SMTP id u9mr2702025oeh.28.1360957247411; Fri, 15 Feb 2013 11:40:47 -0800 (PST) Received: by 10.60.59.163 with HTTP; Fri, 15 Feb 2013 11:40:47 -0800 (PST) X-Originating-IP: [192.1.48.2] In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0D933D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B0D8DCA@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101086378@ESESSMB301.ericsson.se> <076C52A7-194F-4C9B-A607-7C5AA685E8FF@gmx.net> <7594FB04B1934943A5C02806D1A2204B0D933D@ESESSMB209.ericsson.se> Date: Fri, 15 Feb 2013 14:40:47 -0500 Message-ID: From: Richard Barnes To: Christer Holmberg Content-Type: multipart/alternative; boundary=e89a8ff1c58449551004d5c88dea X-Gm-Message-State: ALoCoQmEA5C/2MajJbOM2pAp+eng3bWw0E4kdrqtgKzG9x+1Vrgr/IOJ57MD1M7ToRzzU0Rs38+z Cc: "ecrit@ietf.org" Subject: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emergency-services-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 19:40:49 -0000 --e89a8ff1c58449551004d5c88dea Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would be a little concerned about the registry growing quite large. Things are very number-based right now, but it's not a far stretch to imagine UI based on available emergency services (e.g., http://geopriv.dreamhosters.com/web911/). So it could be challenging for developers if the list grew large or rapidly changing. It seems to me that the more conservative approach would be to just update the IANA registration policy to be slightly more liberal. --Richard On Fri, Feb 15, 2013 at 11:24 AM, Christer Holmberg < christer.holmberg@ericsson.com > wrote: > Hi Hannes, > > The idea is not to create a mechanism for pizza delivery, or whatever > other non-emergency-nature service - even if they would be specific to on= e > country. > > Or, do you foresee that one would call James Bond to deliver a pizza? ;) > > Regards, > > Christer > > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net > ] > Sent: 15. helmikuuta 2013 18:11 > To: Ivo Sedlacek > Cc: Hannes Tschofenig; Christer Holmberg; ecrit@ietf.org > Subject: Re: [Ecrit] Draft new: > draft-holmberg-ecrit-country-specific-emergency-services-00 > > Hi Ivo, > > you are correct that there are restrictions on what you can register unde= r > the sos tree. The idea was that it focuses on the emergency services resc= ue > functionality and not on other functionality that do not have the emergen= cy > services nature (such as pizza delivery) or are otherwise entirely > different. > > If you believe it does not belong under the sos tree for the indicated > reasons then it may make sense to register it under a different label. > > Ciao > Hannes > > On Feb 15, 2013, at 12:58 PM, Ivo Sedlacek wrote: > > > Hello, > > > > The mountain rescue emergency service is offered at least in Austria > (Alpine rescue) and Ireland (The Mountain and Cave Rescue) according > tohttp://en.wikipedia.org/wiki/Emergency_telephone_number and in Poland > (ratownictwo morskie i g=F3rskie) according to > http://uke.gov.pl/tablice-numerow-kierowania-alarmowego-nka-9410 > > > > Thus, RFC5031 criteria for registration (see below) are satisfied for > the mountain rescue emergency service. > > ------------------ > > The 'sos' service type describes emergency services requiring an > > immediate response, typically offered by various branches of the > > government or other public institutions. Additional sub-services ca= n > > be added after expert review and must be of general public interest > > and have a similar emergency nature. The expert is designated by th= e > > ECRIT working group, its successor, or, in their absence, the IESG. > > >>The expert review should only approve emergency services that are > > offered widely and in different countries, with approximately the > > same caller expectation in terms of services rendered. << The 'sos' > > service is not meant to invoke general government, public > > information, counseling, or social services. > > ------------------ > > > > However, > > - the "Reporting spies" emergency service is offered in South Korea onl= y > and thus would not pass the RFC5031 criteria above. > > - the "GAULA (anti-kidnapping)" emergency service is offered in Colombi= a > only and thus would not pass the RFC5031 criteria above. > > > > Kind regards > > > > Ivo Sedlacek > > > > This Communication is Confidential. We only send and receive email on > the basis of the terms set out at www.ericsson.com/email_disclaimer > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org 'ecrit-bounces@ietf.org');> [mailto:ecrit-bounces@ietf.org] > On Behalf Of Hannes Tschofenig > > Sent: 15. =FAnora 2013 11:04 > > To: Christer Holmberg > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] Draft new: > draft-holmberg-ecrit-country-specific-emergency-services-00 > > > > Christer, I may misunderstand your writeup. > > > > We already have certain service URNs that are applicable only to certai= n > countries. As an example pick mountain rescue (urn:service:sos.mountain). > > > > Karl Heinz later defined an extension that allows you to list the > available service URNs in a specific region, see > > http://tools.ietf.org/html/rfc6197 > > > > You may want to do is to register a new Service URN for spy reporting, > GAULA (anti-kidnapping), etc. > > > > Ciao > > Hannes > > > > On Feb 15, 2013, at 10:33 AM, Christer Holmberg wrote: > > > > > Hi, > > > > > > As previously discussed, some existing emergency services might be > offered in one specific country only, and RFC 5031 currently does not all= ow > registering country specific service URNs. > > > > > > We have submitted a draft, > draft-holmberg-ecrit-country-emg-urn-00.txt, which suggests a solution, b= y > defining a dedicated URN sub-service, with a relaxed registration policy, > for country specific emergency services. > > > > > > Such URN would look something like: > urn:service:sos.country-specific.. assigned by PSAP> > > > > > > Feel free to comment :) > > > > > > I would also like to request agenda in Orlando to discuss this. > > > > > > Regards, > > > > > > Christer > > > > > > > > > _______________________________________________ > > > 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 > --e89a8ff1c58449551004d5c88dea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I would be a little concerned about the registry growing q= uite large. =A0Things are very number-based right now, but it's not a f= ar stretch to imagine UI based on available emergency services (e.g.,=A0http://g= eopriv.dreamhosters.com/web911/). =A0So it could be challenging for dev= elopers if the list grew large or rapidly changing.

It seems to me that the more conservative approach would be = to just update the IANA registration policy to be slightly more liberal.

--Richard


On Fri, Feb 15, 2013 at 11:24 AM, Christ= er Holmberg <christer.= holmberg@ericsson.com> wrote:
Hi Hannes,

The idea is not to create a mechanism for pizza delivery, or whatever other= non-emergency-nature service - even if they would be specific to one count= ry.

Or, do you foresee that one would call James Bond to deliver a pizza? ;)
Regards,

Christer

-----Original Message-----
From: Hannes Tschofenig [mailto:hannes.tschofeni= g@gmx.net]
Sent: 15. helmikuuta 2013 18:11
To: Ivo Sedlacek
Cc: Hannes Tschofenig; Christer Holmberg; ecrit@ietf.org
Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emerg= ency-services-00

Hi Ivo,

you are correct that there are restrictions on what you can register under = the sos tree. The idea was that it focuses on the emergency services rescue= functionality and not on other functionality that do not have the emergenc= y services nature (such as pizza delivery) or are otherwise entirely differ= ent.

If you believe it does not belong under the sos tree for the indicated reas= ons then it may make sense to register it under a different label.

Ciao
Hannes

On Feb 15, 2013, at 12:58 PM, Ivo Sedlacek wrote:

> Hello,
>
> The mountain rescue emergency service is offered at least in Austria (= Alpine rescue) and Ireland (The Mountain and Cave Rescue) according tohttp:= //en.wikipedia.org/wiki/Emergency_telephone_number and in Po= land (ratownictwo morskie i g=F3rskie) according to htt= p://uke.gov.pl/tablice-numerow-kierowania-alarmowego-nka-9410
>
> Thus, RFC5031 criteria for registration (see below) are satisfied for = the mountain rescue emergency service.
> ------------------
> =A0 =A0The 'sos' service type describes emergency services req= uiring an
> =A0 =A0immediate response, typically offered by various branches of th= e
> =A0 =A0government or other public institutions. =A0Additional sub-serv= ices can
> =A0 =A0be added after expert review and must be of general public inte= rest
> =A0 =A0and have a similar emergency nature. =A0The expert is designate= d by the
> =A0 =A0ECRIT working group, its successor, or, in their absence, the I= ESG.
> =A0 =A0>>The expert review should only approve emergency service= s that are
> =A0 =A0offered widely and in different countries, with approximately t= he
> =A0 =A0same caller expectation in terms of services rendered. <<= The 'sos'
> =A0 =A0service is not meant to invoke general government, public
> =A0 =A0information, counseling, or social services.
> ------------------
>
> However,
> - the "Reporting spies" emergency service is offered in Sout= h Korea only and thus would not pass the RFC5031 criteria above.
> - the "GAULA (anti-kidnapping)" emergency service is offered= in Colombia only and thus would not pass the RFC5031 criteria above.
>
> Kind regards
>
> Ivo Sedlacek
>
> This Communication is Confidential. We only send and receive email on = the basis of the terms set out at www.ericsson.com/email_disclaimer
>
> -----Original Message-----
> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofen= ig
> Sent: 15. =FAnora 2013 11:04
> To: Christer Holmberg
> Cc: ecrit@ietf.org
> Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-= emergency-services-00
>
> Christer, I may misunderstand your writeup.
>
> We already have certain service URNs that are applicable only to certa= in countries. As an example pick mountain rescue (urn:service:sos.mountain)= .
>
> Karl Heinz later defined an extension that allows you to list the avai= lable service URNs in a specific region, see
> http:= //tools.ietf.org/html/rfc6197
>
> You may want to do is to register a new Service URN for spy reporting,= GAULA (anti-kidnapping), etc.
>
> Ciao
> Hannes
>
> On Feb 15, 2013, at 10:33 AM, Christer Holmberg wrote:
>
> > Hi,
> >
> > As previously discussed, some existing emergency services might b= e offered in one specific country only, and RFC 5031 currently does not all= ow registering country specific service URNs.
> >
> > We have submitted a draft, draft-holmberg-ecrit-country-emg-urn-0= 0.txt, which suggests a solution, by defining a dedicated URN sub-service, = with a relaxed registration policy, for country specific emergency services= .
> >
> > Such URN would look something like: urn:service:sos.country-speci= fic.<two letter country code>.<identifier assigned by PSAP>
> >
> > Feel free to comment :)
> >
> > I would also like to request agenda in Orlando to discuss this. > >
> > Regards,
> >
> > Christer
> >
> >
> > _______________________________________________
> > 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

--e89a8ff1c58449551004d5c88dea-- From ivo.sedlacek@ericsson.com Mon Feb 18 06:00:31 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C7321F88DB for ; Mon, 18 Feb 2013 06:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.394 X-Spam-Level: X-Spam-Status: No, score=-6.394 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqTswBREExw4 for ; Mon, 18 Feb 2013 06:00:30 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 349F221F8903 for ; Mon, 18 Feb 2013 06:00:30 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-5b-512233fcf57a Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C0.FA.19728.CF332215; Mon, 18 Feb 2013 15:00:29 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.208]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0318.004; Mon, 18 Feb 2013 15:00:28 +0100 From: Ivo Sedlacek To: Richard Barnes , Christer Holmberg Thread-Topic: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emergency-services-00 Thread-Index: AQHOC5cF4c6/B+732keesSkHzYOExph7CfyAgAA2xoCABGRQ8A== Date: Mon, 18 Feb 2013 14:00:27 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101099B29@ESESSMB301.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B0D8DCA@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101086378@ESESSMB301.ericsson.se> <076C52A7-194F-4C9B-A607-7C5AA685E8FF@gmx.net> <7594FB04B1934943A5C02806D1A2204B0D933D@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje5fY6VAg3X3mS0aFz1ltVi68x6r xdQ+Wwdmj8Wb9rN5LFnyk8lj8sZZLAHMUVw2Kak5mWWpRfp2CVwZbVPvMhV8Za3Yf+ouewPj bZYuRk4OCQETiS0TbzJB2GISF+6tZ+ti5OIQEjjEKLH97yVGCGcJo8SuTxsZQarYBPQkJm45 wgpiiwiESix+exUsziwQJjFj+yQwW1ggVmLdooeMEDVxEksmzQeyOYBsJ4mXHzxBwiwCqhLN t86AjeEV8JZYf3IlK8SuH0wShw7+ZwZJcAoESlzaAFHEKCArcfVPL9QucYlbT+ZDXS0gsWTP eWYIW1Ti5eN/rBC2osTHV/ug6nUkFuz+xAZha0ssW/iaGWKxoMTJmU9YJjCKzUIydhaSlllI WmYhaVnAyLKKkT03MTMnvdxoEyMwbg5u+a26g/HOOZFDjNIcLErivOGuFwKEBNITS1KzU1ML Uovii0pzUosPMTJxcEo1MDJet0kxfrowTPVke8y1fM7TCVlfAyYxhj3eWGbvVmL0hiff6nm7 6ZlTH8L8X6vu73vUp/sx3T+5YJbU+hrX2Wf+btf5nPFSK/z/vXlXtz/w9J+1yWl731upztPd t/yWsz/o0/GUTM487re7aunHbfv+GHuKOsh7MPusZfvJscBlxR8vYT2zUCWW4oxEQy3mouJE AEnGh+NpAgAA Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emergency-services-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 14:00:31 -0000 Hello, thank you for your mail. > It seems to me that the more conservative approach would be to just updat= e the IANA registration policy to be slightly more liberal. By "slightly more liberal", do you propose that the IANA registration polic= y for registration of any sub-service of the service URN with the 'sos' ser= vice type would be relaxed similarly as proposed in the draft (i.e. it is s= ufficient if the emergency service exists in single country only)? That wou= ld be possible.=20 Or do you have other proposal? Thank you for clarification. 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 From rlb@ipv.sx Mon Feb 18 09:27:33 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F30021F883A for ; Mon, 18 Feb 2013 09:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lA5TrcQQg7Uc for ; Mon, 18 Feb 2013 09:27:32 -0800 (PST) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1D70E21F87FE for ; Mon, 18 Feb 2013 09:27:32 -0800 (PST) Received: by mail-oa0-f52.google.com with SMTP id k14so6149833oag.11 for ; Mon, 18 Feb 2013 09:27:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=+6eNrgnne5R1HyoudertYXC+Uof5+v7oogrUGrxZoTE=; b=aJxmkPpX14tRPtC/Jj8VqJecaURpyqksvLTH/fPHLRe7Ay1WKAqDjZgDCmocyeAemK wfB+V2G+s9u9h5xr7QjEUrNOaYxlByu4gSpc/0SKn4i1bRokL/1p5+ssWPhYkLuxVHfw S4OyUn5T+z+WksVyTVtDSddERxqpz96gQbDvUnWXE/4cNnfP1i01caSv8JFHIBtohyAW 5VBLyNjdmzAuokDXAs5WaKIr7w6YTiWk6fM24KiJr7QC2nL7W+aVV5cfwxd56q+p5ZQM xWcoMKwQwS7LfjGgb/ZLZOS1YXX46NUwD4RRlPD4VmmIMMWeSVuoNayooRum567DlseI yYJw== MIME-Version: 1.0 X-Received: by 10.182.231.39 with SMTP id td7mr6399741obc.86.1361208451541; Mon, 18 Feb 2013 09:27:31 -0800 (PST) Received: by 10.60.7.132 with HTTP; Mon, 18 Feb 2013 09:27:31 -0800 (PST) X-Originating-IP: [2606:4100:3880:2520:f035:6a9f:8a04:1595] In-Reply-To: <39B5E4D390E9BD4890E2B31079006101099B29@ESESSMB301.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B0D8DCA@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101086378@ESESSMB301.ericsson.se> <076C52A7-194F-4C9B-A607-7C5AA685E8FF@gmx.net> <7594FB04B1934943A5C02806D1A2204B0D933D@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101099B29@ESESSMB301.ericsson.se> Date: Mon, 18 Feb 2013 12:27:31 -0500 Message-ID: From: Richard Barnes To: Ivo Sedlacek Content-Type: multipart/alternative; boundary=f46d04446a4b3829b504d6030a2d X-Gm-Message-State: ALoCoQktOjfUJWrLkgO1NXceNcH4fCy3G+bg0W9ijWvaDi9xNecn4mPZz1MrbNIS3rT0nR0Hj33R Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emergency-services-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 17:27:33 -0000 --f46d04446a4b3829b504d6030a2d Content-Type: text/plain; charset=ISO-8859-1 Yes, I was thinking that the policy would be that an emergency service exists in one country. The purpose of the registry would be just be to encourage deduplication. So, for instance, to encourage the several different countries that have traffic police numbers* to all use something like "urn:service:sos.traffic". Or, to choose a better example, once Korea has registered "urn:service:sos.espionage", to encourage the second country that establishes a spy reporting service to also use that URN. Alternatively, someone could just go through the list of emergency numbers on Wikipedia and submit one big registration for the common ones (like traffic police). Those would be allowable under the current policy. --Richard * according to wikipedia: EG, SD, CN, IN**, PK, SA, AL, AM, AZ, NZ, CO, EC ** hopefully India could be persuaded to consolidate its three different traffic police numbers On Mon, Feb 18, 2013 at 9:00 AM, Ivo Sedlacek wrote: > Hello, > > thank you for your mail. > > > It seems to me that the more conservative approach would be to just > update the IANA registration policy to be slightly more liberal. > > By "slightly more liberal", do you propose that the IANA registration > policy for registration of any sub-service of the service URN with the > 'sos' service type would be relaxed similarly as proposed in the draft > (i.e. it is sufficient if the emergency service exists in single country > only)? That would be possible. > > Or do you have other proposal? > > Thank you for clarification. > > Kind regards > > Ivo Sedlacek > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out at www.ericsson.com/email_disclaimer > --f46d04446a4b3829b504d6030a2d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, I was thinking that the policy would be that an emerg= ency service exists in one country. =A0The purpose of the registry would be= just be to encourage deduplication. =A0So, for instance, to encourage the = several different countries that have traffic police numbers* to all use so= mething like "urn:service:sos.traffic". =A0Or, to choose a better= example, once Korea has registered "urn:service:sos.espionage", = to encourage the second country that establishes a spy reporting service to= also use that URN.

Alternatively, someone could just go through the list of eme= rgency numbers on Wikipedia and submit one big registration for the common = ones (like traffic police). =A0Those would be allowable under the current p= olicy.

--Richard=A0

* according to wi= kipedia: EG, SD, CN, IN**, PK, SA, AL, AM, AZ, NZ, CO, EC
*= * hopefully India could be persuaded to consolidate its three different tra= ffic police numbers


O= n Mon, Feb 18, 2013 at 9:00 AM, Ivo Sedlacek <ivo.sedlacek@ericss= on.com> wrote:
Hello,

thank you for your mail.

> It seems to me that the more conservative approach would be to just up= date the IANA registration policy to be slightly more liberal.

By "slightly more liberal", do you propose that the IANA re= gistration policy for registration of any sub-service of the service URN wi= th the 'sos' service type would be relaxed similarly as proposed in= the draft (i.e. it is sufficient if the emergency service exists in single= country only)? That would be possible.

Or do you have other proposal?

Thank you for clarification.

Kind regards

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

--f46d04446a4b3829b504d6030a2d-- From prvs=9761cdbec3=jbakker@rim.com Mon Feb 18 09:54:49 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E941021F8C17 for ; Mon, 18 Feb 2013 09:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyOgJxKDYeVl for ; Mon, 18 Feb 2013 09:54:47 -0800 (PST) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 400C921F8BDE for ; Mon, 18 Feb 2013 09:54:37 -0800 (PST) X-AuditID: 0a41282f-b7f606d000004b92-2d-5122674c7538 Received: from XCT104ADS.rim.net (xct104ads.rim.net [10.67.111.45]) by mhs060cnc.rim.net (SBG) with SMTP id C8.81.19346.D4762215; Mon, 18 Feb 2013 11:39:25 -0600 (CST) Received: from XMB103ADS.rim.net ([fe80::e54b:97d9:3777:f8dc]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.02.0328.009; Mon, 18 Feb 2013 11:39:24 -0600 From: John-Luc Bakker To: Richard Barnes , Ivo Sedlacek Thread-Topic: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emergency-services-00 Thread-Index: AQHODf1BBxsmRuJgQU2jPrzeJBJOyZh/35cQ Date: Mon, 18 Feb 2013 17:39:23 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA35CF313D@XMB103ADS.rim.net> References: <7594FB04B1934943A5C02806D1A2204B0D8DCA@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101086378@ESESSMB301.ericsson.se> <076C52A7-194F-4C9B-A607-7C5AA685E8FF@gmx.net> <7594FB04B1934943A5C02806D1A2204B0D933D@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101099B29@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.251] Content-Type: multipart/alternative; boundary="_000_155970D1DA8E174F9E46039E10E2AA35CF313DXMB103ADSrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrIKsWRmVeSWpSXmKPExsXC5Zyvq+ubrhRo0POVy6Jx0VNWi96V81gt pvbZOjB7/Pp6lc1jyZKfTB6TN85iCWCOamC0SUosKQvOTM/Tt7NJzMvLL0ksSVVISS1OtlXy SU1PzFEIKMosS0yuVHDJLE7OSczMTS1SUshMsVUyUVIoyElMTs1NzSuxVUosKEjNS1Gy41LA ADZAZZl5Cql5yfkpmXnptkqewf66FhamlrqGSna6CZ08GX9b3rAW/IiqmLZhAXsD4x7/LkZO DgkBE4kfey4wQdhiEhfurWfrYuTiEBJYySjxc98sFghnK6PEgdunGEGq2ATUJbau2M4MYosI eEq8XNvEDmIzC6hKnGt8zAJiCwvESmxdNp0RoiZO4v+h/1D1RhJTei+C1bMA1X8/dh5sM6+A m8SMD3ugljWySGzc/xusgVMgUOLl4i9gNiPQed9PrWGCWCYucevJfKizBSSW7DnPDGGLSrx8 /I8VwlaUmLFnPitEfa7EpAUH2SGWCUqcnPmEZQKj6Cwko2YhKZuFpAwiriOxYPcnNghbW2LZ wtfMMPaZA4+ZkMUXMLKvYhTMzSg2MDNIzkvWK8rM1ctLLdnECEo2jhr6Oxjfvrc4xCjAwajE wzshUilQiDWxrLgy9xCjBAezkghv+x3FQCHelMTKqtSi/Pii0pzU4kOMQcDgmsgsxZ2cD0yE eSXxxgYGRHKUxHlFAkUDhQTSgSkuOzW1ILUIZigTByfIUi4pkWJgokotSiwtyYgHpdP4YmBC lWpgdHMTXT5hx/rYYCGd/0/WFYbUpjw8ZvxF/U4lU2Pe3u4FzXsL5181nnmPR9blbX1f9Nqi m6xSKQ+bv2TZai1abB7Fzpgh+kejT66D3bOQw0h8a8dht5jABc+yUp33H0v4qiwrJb6FJewW v5jqpROvPQyLnXlVL3OvvRz4SXrFjiTmAJbg8w+UWIozEg21mIuKEwFgaf1BhAMAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emergency-services-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 17:54:50 -0000 --_000_155970D1DA8E174F9E46039E10E2AA35CF313DXMB103ADSrimnet_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Hi, A few observations on the contents of the Wikipedia page. The first entry shows Algeria having one number for medical AND fire: "14". Should there be one URN for "medical" and "fire" registered with IANA? (A se= cond country with one number for medical AND fire, "15" in their case, is Mo= rocco). Also, Algeria lists: National Gendarmerie : 1055; Counter Terrorist Unit : 1548; support for chil= dren : 3033. So, URNs for these may also be needed. However, I question if we should deri= ve IANA-registered URNs from any Wikipedia page (which can be edited by othe= rs that national regulators). Kind regards, John-Luc From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Ri= chard Barnes Sent: Monday, February 18, 2013 11:28 AM To: Ivo Sedlacek Cc: ecrit@ietf.org Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emerge= ncy-services-00 Yes, I was thinking that the policy would be that an emergency service exist= s in one country. The purpose of the registry would be just be to encourage= deduplication. So, for instance, to encourage the several different countr= ies that have traffic police numbers* to all use something like "urn:service= :sos.traffic". Or, to choose a better example, once Korea has registered "u= rn:service:sos.espionage", to encourage the second country that establishes= a spy reporting service to also use that URN. Alternatively, someone could just go through the list of emergency numbers o= n Wikipedia and submit one big registration for the common ones (like traffi= c police). Those would be allowable under the current policy. --Richard * according to wikipedia: EG, SD, CN, IN**, PK, SA, AL, AM, AZ, NZ, CO, EC ** hopefully India could be persuaded to consolidate its three different tra= ffic police numbers On Mon, Feb 18, 2013 at 9:00 AM, Ivo Sedlacek > wrote: Hello, thank you for your mail. > It seems to me that the more conservative approach would be to just update= the IANA registration policy to be slightly more liberal. By "slightly more liberal", do you propose that the IANA registration policy= for registration of any sub-service of the service URN with the 'sos' servi= ce type would be relaxed similarly as proposed in the draft (i.e. it is suff= icient if the emergency service exists in single country only)? That would b= e possible. Or do you have other proposal? Thank you for clarification. Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the ba= sis of the terms set out at www.ericsson.com/email_disclaimer --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_155970D1DA8E174F9E46039E10E2AA35CF313DXMB103ADSrimnet_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Hi,

 

A few observations on the c= ontents of the Wikipedia page.

The first entry shows Alger= ia having one number for medical AND fire: “14”.

Should there be one URN for= “medical” and “fire” registered with IANA? (A secon= d country with one number for medical AND fire, “15” in their ca= se, is Morocco).

 

Also, Algeria lists:

 

National Gendarmerie : 1055; Counter Terrorist= Unit : 1548; support for children : 3033.

 

So, URNs for these may also= be needed. However, I question if we should derive IANA-registered URNs fro= m any Wikipedia page (which can be edited by others that national regulators).

 

Kind regards,

 

    &nb= sp;          John-Luc

 

From: ecrit-bounc= es@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Monday, February 18, 2013 11:28 AM
To: Ivo Sedlacek
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific= -emergency-services-00

 

Yes, I was thinking that the policy would be that an= emergency service exists in one country.  The purpose of the registry= would be just be to encourage deduplication.  So, for instance, to enc= ourage the several different countries that have traffic police numbers* to all use something like "urn:service:so= s.traffic".  Or, to choose a better example, once Korea has regist= ered "urn:service:sos.espionage", to encourage the second country= that establishes a spy reporting service to also use that URN.

 

Alternatively, someone could just go through the list= of emergency numbers on Wikipedia and submit one big registration for the c= ommon ones (like traffic police).  Those would be allowable under the c= urrent policy.

 

--Richard 

 

* according to wikipedia: EG, SD, CN, IN**, PK, SA, A= L, AM, AZ, NZ, CO, EC

** hopefully India could be persuaded to consolidate= its three different traffic police numbers

 

On Mon, Feb 18, 2013 at 9:00 AM, Ivo Sedlacek <ivo.sedlacek@er= icsson.com> wrote:

Hello,

thank you for your mail.


> It seems to me that the more conservative approach would be to just upd= ate the IANA registration policy to be slightly more liberal.

By "slightly more liberal", do you propose= that the IANA registration policy for registration of any sub-service of th= e service URN with the 'sos' service type would be relaxed similarly as prop= osed in the draft (i.e. it is sufficient if the emergency service exists in single country only)? That would be possibl= e.

Or do you have other proposal?

Thank you for clarification.


Kind regards

 Ivo Sedlacek

This Communication is Confidential. We only send and receive email on the ba= sis of the terms set out at www.e= ricsson.com/email_disclaimer

 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_155970D1DA8E174F9E46039E10E2AA35CF313DXMB103ADSrimnet_-- From rlb@ipv.sx Mon Feb 18 09:56:14 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987BC21F8C66 for ; Mon, 18 Feb 2013 09:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.492, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvV5DkdFQLs3 for ; Mon, 18 Feb 2013 09:56:11 -0800 (PST) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id E95D021F8C55 for ; Mon, 18 Feb 2013 09:56:06 -0800 (PST) Received: by mail-oa0-f50.google.com with SMTP id l20so6149785oag.9 for ; Mon, 18 Feb 2013 09:56:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=vL2PhyxdHabgAxreFtkgzHTJESqNzLB0SWl49x7gGOM=; b=O+bAlHYEkUitufAtxTnIQkWGdhGm/mcPJs4EUUxZe0cPyaA6Ck3mwFXWvK5L4pCz/Y MEa9+r2mCFqTEV8Ho0hrSK042wkfW3jNvQqYSWeeIds3Gre2mA2WWScWVPfZGoAp6/M2 gmGY+MY5Lz5m62VtYRh+AK+0XMgU3nbxDsVO2R56HYreXNPyKRBY7QVbzEuVxyseGMLB KqlTdaEN4jHDdZT48JiCzHUsL7NlFeCHcdd9anlr4Gm2sr7gJqlCFWfAKe6KVlscNe6u YoLpnij9+bixNMG+Bk1zdmrGGhxcjAq66l14i4Mp/FWsGKL+07I9D4muurJD8DJkeH0Y Pasw== MIME-Version: 1.0 X-Received: by 10.182.98.44 with SMTP id ef12mr6465492obb.25.1361210166484; Mon, 18 Feb 2013 09:56:06 -0800 (PST) Received: by 10.60.7.132 with HTTP; Mon, 18 Feb 2013 09:56:06 -0800 (PST) X-Originating-IP: [2606:4100:3880:2520:f035:6a9f:8a04:1595] In-Reply-To: <155970D1DA8E174F9E46039E10E2AA35CF313D@XMB103ADS.rim.net> References: <7594FB04B1934943A5C02806D1A2204B0D8DCA@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101086378@ESESSMB301.ericsson.se> <076C52A7-194F-4C9B-A607-7C5AA685E8FF@gmx.net> <7594FB04B1934943A5C02806D1A2204B0D933D@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101099B29@ESESSMB301.ericsson.se> <155970D1DA8E174F9E46039E10E2AA35CF313D@XMB103ADS.rim.net> Date: Mon, 18 Feb 2013 12:56:06 -0500 Message-ID: From: Richard Barnes To: John-Luc Bakker Content-Type: multipart/alternative; boundary=14dae93b59b6701fbe04d603705b X-Gm-Message-State: ALoCoQmtdtx0ZPp/2zxZBBNrRsDv5WVIk/vsH3iREVxsEaAdiSATfAExnWBjG8JLBvILJR1WNPse Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emergency-services-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 17:56:14 -0000 --14dae93b59b6701fbe04d603705b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi John-Luc, We actually already have separate URNs for medical and fire -- "urn:service:sos.ambulance" and "urn:service:sos.fire" [1]. So that's not an issue. LoST can map them to the same or different numbers depending on the jurisdiction. There is also a "counseling" URN for children, "urn:service:counseling.children". It might make sense to define new URNs for "national gendarmerie" / "national police", and possibly "counter terrorism", since it seems that those exist in several countries. But in general, this is the sort of exercise that people should go through for the various countries. --Richard [1] < http://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-labels.x= ml > On Mon, Feb 18, 2013 at 12:39 PM, John-Luc Bakker wrote: > Hi,**** > > ** ** > > A few observations on the contents of the Wikipedia page.**** > > The first entry shows Algeria having one number for medical AND fire: > =9314=94. **** > > Should there be one URN for =93medical=94 and =93fire=94 registered with = IANA? (A > second country with one number for medical AND fire, =9315=94 in their ca= se, is > Morocco).**** > > ** ** > > Also, Algeria lists:**** > > ** ** > > National Gendarmerie : *1055*; Counter Terrorist Unit : *1548*; support > for children : *3033*.**** > > ** ** > > So, URNs for these may also be needed. However, I question if we should > derive IANA-registered URNs from any Wikipedia page (which can be edited = by > others that national regulators). **** > > ** ** > > Kind regards,**** > > ** ** > > John-Luc**** > > ** ** > > *From:* ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Monday, February 18, 2013 11:28 AM > *To:* Ivo Sedlacek > > *Cc:* ecrit@ietf.org > *Subject:* Re: [Ecrit] Draft new: > draft-holmberg-ecrit-country-specific-emergency-services-00**** > > ** ** > > Yes, I was thinking that the policy would be that an emergency service > exists in one country. The purpose of the registry would be just be to > encourage deduplication. So, for instance, to encourage the several > different countries that have traffic police numbers* to all use somethin= g > like "urn:service:sos.traffic". Or, to choose a better example, once Kor= ea > has registered "urn:service:sos.espionage", to encourage the second count= ry > that establishes a spy reporting service to also use that URN.**** > > ** ** > > Alternatively, someone could just go through the list of emergency number= s > on Wikipedia and submit one big registration for the common ones (like > traffic police). Those would be allowable under the current policy.**** > > ** ** > > --Richard **** > > ** ** > > * according to wikipedia: EG, SD, CN, IN**, PK, SA, AL, AM, AZ, NZ, CO, E= C > **** > > ** hopefully India could be persuaded to consolidate its three different > traffic police numbers**** > > ** ** > > On Mon, Feb 18, 2013 at 9:00 AM, Ivo Sedlacek > wrote:**** > > Hello, > > thank you for your mail.**** > > > > It seems to me that the more conservative approach would be to just > update the IANA registration policy to be slightly more liberal.**** > > By "slightly more liberal", do you propose that the IANA registration > policy for registration of any sub-service of the service URN with the > 'sos' service type would be relaxed similarly as proposed in the draft > (i.e. it is sufficient if the emergency service exists in single country > only)? That would be possible. > > Or do you have other proposal? > > Thank you for clarification.**** > > > Kind regards > > Ivo Sedlacek > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out at www.ericsson.com/email_disclaimer**** > > ** ** > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-publi= c > information. Any use of this information by anyone other than the intende= d > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be > unlawful. > --14dae93b59b6701fbe04d603705b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi John-Luc,

We actually already = have separate URNs for medical and fire -- "urn:service:sos.ambulance"= ; and "urn:service:sos.fire" [1]. =A0So that's not an i= ssue. =A0LoST can map them to the same or different numbers depending on th= e jurisdiction. =A0There is also a "counseling" URN for children,= "urn:service:counseling.children".

It might make sense to define new URNs for &= quot;national gendarmerie" / "national police", and possibly= "counter terrorism", since it seems that those exist in several = countries.

But in general, this is the sort of exercise= that people should go through for the various countries.

--Richard





On Mon,= Feb 18, 2013 at 12:39 PM, John-Luc Bakker <jbakker@rim.com> w= rote:

Hi,<= /p>

=A0<= /p>

A few observations on the= contents of the Wikipedia page.

The first entry shows Alg= eria having one number for medical AND fire: =9314=94.

Should there be one URN f= or =93medical=94 and =93fire=94 registered with IANA? (A second country wit= h one number for medical AND fire, =9315=94 in their case, is Morocco).<= /u>

=A0<= /p>

Also, Algeria lists:

=A0<= /p>

National Gendarmerie : 1055; Counter Terroris= t Unit : 1548; support for children : 3033.=

=A0<= /p>

So, URNs for these may al= so be needed. However, I question if we should derive IANA-registered URNs = from any Wikipedia page (which can be edited by others that national regulators).

=A0<= /p>

Kind regards,

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 John-Luc

=A0<= /p>

From: ecrit-bounces@ietf.org= [mailto:ec= rit-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Monday, February 18, 2013 11:28 AM
To: Ivo Sedlacek


Cc: ecrit@ietf.o= rg
Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specifi= c-emergency-services-00

=A0

Yes, I was thinking that the policy would be that an= emergency service exists in one country. =A0The purpose of the registry wo= uld be just be to encourage deduplication. =A0So, for instance, to encourag= e the several different countries that have traffic police numbers* to all use something like "urn:service:s= os.traffic". =A0Or, to choose a better example, once Korea has registe= red "urn:service:sos.espionage", to encourage the second country = that establishes a spy reporting service to also use that URN.

=A0

Alternatively, someone could just go through the lis= t of emergency numbers on Wikipedia and submit one big registration for the= common ones (like traffic police). =A0Those would be allowable under the c= urrent policy.

=A0

--Richard=A0

=A0

* according to wikipedia: EG, SD, CN, IN**, PK, SA, = AL, AM, AZ, NZ, CO, EC

** hopefully India could be persuaded to consolidate= its three different traffic police numbers

=A0

On Mon, Feb 18, 2013 at 9:00 AM, Ivo Sedlacek <ivo.sedlacek@e= ricsson.com> wrote:

Hello,

thank you for your mail.


> It seems to me that the more conservative approach would be to just up= date the IANA registration policy to be slightly more liberal.

By "slightly more liberal", do you propose= that the IANA registration policy for registration of any sub-service of t= he service URN with the 'sos' service type would be relaxed similar= ly as proposed in the draft (i.e. it is sufficient if the emergency service exists in single country only)? That would be possib= le.

Or do you have other proposal?

Thank you for clarification.


Kind regards

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

=A0

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful.

--14dae93b59b6701fbe04d603705b-- From prvs=1761508a76=jbakker@rim.com Mon Feb 18 10:27:18 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC3921F8A3D for ; Mon, 18 Feb 2013 10:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zT9nP+3eNyQU for ; Mon, 18 Feb 2013 10:27:13 -0800 (PST) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 84BB421F88F0 for ; Mon, 18 Feb 2013 10:27:12 -0800 (PST) X-AuditID: 0a41282f-b7f606d000004b92-34-51227274cb0d Received: from XCT105ADS.rim.net (xct105ads.rim.net [10.67.111.46]) by mhs060cnc.rim.net (SBG) with SMTP id 82.52.19346.47272215; Mon, 18 Feb 2013 12:27:00 -0600 (CST) Received: from XMB103ADS.rim.net ([fe80::e54b:97d9:3777:f8dc]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.02.0328.009; Mon, 18 Feb 2013 12:26:59 -0600 From: John-Luc Bakker To: Richard Barnes Thread-Topic: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emergency-services-00 Thread-Index: AQHODgE92qAuDJt+dESei53jw7Kqr5h/50vA Date: Mon, 18 Feb 2013 18:26:59 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA35CF331C@XMB103ADS.rim.net> References: <7594FB04B1934943A5C02806D1A2204B0D8DCA@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101086378@ESESSMB301.ericsson.se> <076C52A7-194F-4C9B-A607-7C5AA685E8FF@gmx.net> <7594FB04B1934943A5C02806D1A2204B0D933D@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101099B29@ESESSMB301.ericsson.se> <155970D1DA8E174F9E46039E10E2AA35CF313D@XMB103ADS.rim.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.251] Content-Type: multipart/alternative; boundary="_000_155970D1DA8E174F9E46039E10E2AA35CF331CXMB103ADSrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAKsWRmVeSWpSXmKPExsXC5Zyvp1tSpBRoMHWhrkXjoqesFr0r57Fa TO2zdWD2+PX1KpvHkiU/mTwmb5zFEsAc1cBok5RYUhacmZ6nb2eTmJeXX5JYkqqQklqcbKvk k5qemKMQUJRZlphcqeCSWZyck5iZm1qkpJCZYqtkoqRQkJOYnJqbmldiq5RYUJCal6Jkx6WA AWyAyjLzFFLzkvNTMvPSbZU8g/11LSxMLXUNlex0Ezp5Mp6ev8xWcH0TY8WSKZ2sDYw35zF2 MXJwSAiYSOx5F93FyAlkiklcuLeerYuRi0NIYCWjxMKZS5ghnK2MEitfbmQGqWITUJfYumI7 mC0iIC9x+voDVpBBzAKBEtv+VoGEhQViJdYtesgIURInsWTSfCjbSKJv80kmEJtFQFXi/qlP zCCtvAJuEvMfSEKsamWV2NMymQ2khhNo5OOJv8BsRqDjvp9aA9bLLCAucevJfCaIowUkluw5 zwxhi0q8fPyPFcJWlJixZz4rRH2uxKIbu8Hm8AoISpyc+YRlAqPoLCSjZiEpm4WkDCKuI7Fg 9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9iFMzNKDYwM0jOS9YryszVy0st2cQISjWOGvo7GN++ tzjEKMDBqMTDa5GhFCjEmlhWXJl7iFGCg1lJhLf9jmKgEG9KYmVValF+fFFpTmrxIcYgYGhN ZJbiTs4HpsG8knhjAwMiOUrivCKBooFCAunABJedmlqQWgQzlImDE2Qpl5RIMTBNpRYllpZk xIOSaXwxMJ1KNTBqR0z/aKc1m6XAn+O+6/TX73+6sykV/9zaZet6/Y/rnyn7a7r7roZHXy/V r7/2pY2nLWCF2EKFn1xLHZ2k/qgev9PtpFWkdO5q7cbJ83LuF1pn1c7uWPY9/oRW+NFTNRev OXPb69nd0bVYMOFcTZlDzdbO/R/3T6s4EHXokLRc0dkvXFz3PvcqsRRnJBpqMRcVJwIAAFlt 4oMDAAA= Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emergency-services-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 18:27:20 -0000 --_000_155970D1DA8E174F9E46039E10E2AA35CF331CXMB103ADSrimnet_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Hi, "urn:service:counseling.children" may be more suited for a non-emergency res= ponse (e.g. children requesting counseling because of a broken heart), where= as other examples exist where clearly a more urgent, more coordinated, local= response is needed, perhaps identified by the following new URN "urn:servic= e:sos.children". Regards, John-Luc From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Monday, February 18, 2013 11:56 AM To: John-Luc Bakker Cc: Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emerge= ncy-services-00 Hi John-Luc, We actually already have separate URNs for medical and fire -- "urn:service:= sos.ambulance" and "urn:service:sos.fire" [1]. So that's not an issue. LoS= T can map them to the same or different numbers depending on the jurisdictio= n. There is also a "counseling" URN for children, "urn:service:counseling.c= hildren". It might make sense to define new URNs for "national gendarmerie" / "nationa= l police", and possibly "counter terrorism", since it seems that those exist= in several countries. But in general, this is the sort of exercise that people should go through f= or the various countries. --Richard [1] On Mon, Feb 18, 2013 at 12:39 PM, John-Luc Bakker > wrote: Hi, A few observations on the contents of the Wikipedia page. The first entry shows Algeria having one number for medical AND fire: "14". Should there be one URN for "medical" and "fire" registered with IANA? (A se= cond country with one number for medical AND fire, "15" in their case, is Mo= rocco). Also, Algeria lists: National Gendarmerie : 1055; Counter Terrorist Unit : 1548; support for chil= dren : 3033. So, URNs for these may also be needed. However, I question if we should deri= ve IANA-registered URNs from any Wikipedia page (which can be edited by othe= rs that national regulators). Kind regards, John-Luc From: ecrit-bounces@ietf.org [mailto:ecrit-bo= unces@ietf.org] On Behalf Of Richard Barnes Sent: Monday, February 18, 2013 11:28 AM To: Ivo Sedlacek Cc: ecrit@ietf.org Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emerge= ncy-services-00 Yes, I was thinking that the policy would be that an emergency service exist= s in one country. The purpose of the registry would be just be to encourage= deduplication. So, for instance, to encourage the several different countr= ies that have traffic police numbers* to all use something like "urn:service= :sos.traffic". Or, to choose a better example, once Korea has registered "u= rn:service:sos.espionage", to encourage the second country that establishes= a spy reporting service to also use that URN. Alternatively, someone could just go through the list of emergency numbers o= n Wikipedia and submit one big registration for the common ones (like traffi= c police). Those would be allowable under the current policy. --Richard * according to wikipedia: EG, SD, CN, IN**, PK, SA, AL, AM, AZ, NZ, CO, EC ** hopefully India could be persuaded to consolidate its three different tra= ffic police numbers On Mon, Feb 18, 2013 at 9:00 AM, Ivo Sedlacek > wrote: Hello, thank you for your mail. > It seems to me that the more conservative approach would be to just update= the IANA registration policy to be slightly more liberal. By "slightly more liberal", do you propose that the IANA registration policy= for registration of any sub-service of the service URN with the 'sos' servi= ce type would be relaxed similarly as proposed in the draft (i.e. it is suff= icient if the emergency service exists in single country only)? That would b= e possible. Or do you have other proposal? Thank you for clarification. Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the ba= sis of the terms set out at www.ericsson.com/email_disclaimer --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_155970D1DA8E174F9E46039E10E2AA35CF331CXMB103ADSrimnet_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Hi,

 

"urn:service:counseling.ch= ildren" may be more suited for a non-emergency resp= onse (e.g. children requesting counseling because of a broken heart), wherea= s other examples exist where clearly a more urgent, more coordinated, local response is needed, perhaps identified by the follo= wing new URN “urn:service:sos.children”.

 

Regards,<= /p>

 

    &nb= sp;          John-Luc

 

From: Richard Bar= nes [mailto:rlb@ipv.sx]
Sent: Monday, February 18, 2013 11:56 AM
To: John-Luc Bakker
Cc: Ivo Sedlacek; ecrit@ietf.org
Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific= -emergency-services-00

 

Hi John-Luc,

 

We actually already have separate URNs for medical an= d fire -- "urn:service:sos.ambulance" and &q= uot;urn:service:sos.fire" [1].  So that's not an issue.  LoST can map them to the same or d= ifferent numbers depending on the jurisdiction.  There is also a "= counseling" URN for children, "urn:service:counseling.children&quo= t;.

 

It might make sense to define n= ew URNs for "national gendarmerie" / "national police",= and possibly "counter terrorism", since it seems that those exist= in several countries.

 

But in general, this is the sor= t of exercise that people should go through for the various countries.

 

--Richard

 

 

 

 

On Mon, Feb 18, 2013 at 12:39 PM, John-Luc Bakker <= ;jbakker@rim.com>= ; wrote:

Hi,

 

A few observations on the contents of the= Wikipedia page.

The first entry shows Algeria having one n= umber for medical AND fire: “14”.

Should there be one URN for “medical= ” and “fire” registered with IANA? (A second country with= one number for medical AND fire, “15” in their case, is Morocco).

 

Also, Algeria lists:

 

National Gendarmerie : 1055; Counter Terrorist Unit : 1548; support for children : 3033.

 

So, URNs for these may also be needed. How= ever, I question if we should derive IANA-registered URNs from any Wikipedia page (which can be edited by others that national regula= tors).

 

Kind regards,

 

       =         John-Luc

 

From: ecrit-bounces@ie= tf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Monday, February 18, 2013 11:28 AM
To: Ivo Sedlacek


Cc: ecrit@ietf.or= g
Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific= -emergency-services-00

 

Yes, I was thinking that the policy would be that an emergency servi= ce exists in one country.  The purpose of the registry would be just be= to encourage deduplication.  So, for instance, to encourage the several different countries that have traffic po= lice numbers* to all use something like "urn:service:sos.traffic".=  Or, to choose a better example, once Korea has registered "urn:s= ervice:sos.espionage", to encourage the second country that establishes a spy reporting service to also use that URN.

 

Alternatively, someone could just go through the list of emergency n= umbers on Wikipedia and submit one big registration for the common ones (lik= e traffic police).  Those would be allowable under the current policy.

 

--Richard 

 

* according to wikipedia: EG, SD, CN, IN**, PK, SA, AL, AM, AZ, NZ,= CO, EC

** hopefully India could be persuaded to consolidate its three diffe= rent traffic police numbers

 

On Mon, Feb 18, 2013 at 9:00 AM, Ivo Sedlacek <ivo.sedlacek@ericsson.com&g= t; wrote:

Hello,

thank you for your mail.


> It seems to me that the more conservative approach would be to just upd= ate the IANA registration policy to be slightly more liberal.

By "slightly more liberal", do you propose that the IANA r= egistration policy for registration of any sub-service of the service URN wi= th the 'sos' service type would be relaxed similarly as proposed in the draft (i.e. it is sufficient if the emergency= service exists in single country only)? That would be possible.

Or do you have other proposal?

Thank you for clarification.


Kind regards

 Ivo Sedlacek

This Communication is Confidential. We only send and receive email on the ba= sis of the terms set out at www.e= ricsson.com/email_disclaimer

 

-----------------------------------------------------= ----------------
This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is prohibited. If you have rece= ived this transmission in error, please immediately reply to the sender and= delete this information from your system. Use, dissemination, distribution,= or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. =

 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_155970D1DA8E174F9E46039E10E2AA35CF331CXMB103ADSrimnet_-- From dan@mongrain.org Mon Feb 18 12:29:44 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F5721F8CA8 for ; Mon, 18 Feb 2013 12:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFJ0V6O0SkKf for ; Mon, 18 Feb 2013 12:29:42 -0800 (PST) Received: from mail-ia0-x22a.google.com (mail-ia0-x22a.google.com [IPv6:2607:f8b0:4001:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id EC40621F8C98 for ; Mon, 18 Feb 2013 12:29:41 -0800 (PST) Received: by mail-ia0-f170.google.com with SMTP id k20so5501241iak.1 for ; Mon, 18 Feb 2013 12:29:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=rzpjBVBEw/8ZIsXmM2cxtWpIjRy0tm4lC6C0Sq30bKE=; b=Vfxzyrs2T3gMccPWnYJpYNfGcad3bThDcemM4OL1+cmxrBe8RWbY9Q2qKmmfudjY+a 4YbbLpCnoSzDxeQLC3yG17IndLqrO0gTVe2FZq6R5MkD5ituc+anvjDSmm13YIOKYV/V 8BRHsQQMSGtjlUa5JjYHYrukcpibmlfzCT6dmIHqAYPVZNfOFjz7IvLgD7Kd+ddm55Ni X/0rAw3/SzaFGSsqMb4vb5blgWyuRAGsRphLrTiJN/KIbK8bz/0KBYItIP3PxG+lnD1t Twfdshr3NkpaSmnIix3q9XUZeYPyHo4rv+VXGu83gLHfBr8w1vhs84ENfMYeA2cjXofG VzDw== MIME-Version: 1.0 X-Received: by 10.50.37.212 with SMTP id a20mr7282598igk.88.1361219381296; Mon, 18 Feb 2013 12:29:41 -0800 (PST) Received: by 10.50.171.41 with HTTP; Mon, 18 Feb 2013 12:29:41 -0800 (PST) X-Originating-IP: [209.87.237.3] In-Reply-To: <39B5E4D390E9BD4890E2B3107900610104C240@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B3107900610103F703@ESESSMB301.ericsson.se> <9E790F21-21D7-437B-820B-A88355047BBA@neustar.biz> <39B5E4D390E9BD4890E2B3107900610103FBB3@ESESSMB301.ericsson.se> <6E7FEA84-EBE2-4BE0-B8EA-67D5AD8CA9F2@neustar.biz> <50D08D29.2030303@mongrain.org> <39B5E4D390E9BD4890E2B3107900610104BB9D@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610104C240@ESESSMB301.ericsson.se> Date: Mon, 18 Feb 2013 15:29:41 -0500 Message-ID: From: Dan Mongrain To: Ivo Sedlacek Content-Type: multipart/alternative; boundary=f46d04446b21aefe1104d6059524 X-Gm-Message-State: ALoCoQm6aIaaDMJBkR5M9agSwy3fc2o4nefj9M73DL4M/kET4gE2PsHesRHKkZWTxbC8hYb/80aA Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 20:29:44 -0000 --f46d04446b21aefe1104d6059524 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry for responding late to this thread, it kinda fell into a crack=E2=80= =A6 The current thread reminded me to check this old thread=E2=80=A6 You are indicating that we need to register 77 Service URN (11 service subtypes * 7 jurisdiction types based on RFC 4119). I do not recommend that we create so many registrations. Instead, we should allow a service URN to be suffixed with a jurisdictional scope. So the following Service URN are all valid: urn:service:sos.police urn:service:sos.police.traffic urn:service:sos.police.A1 urn:service:sos.police.traffic.A1 Question is, do we want to leave jurisdictional scope to only be applicable to police branch or any Service URN? I=E2=80=99d say the latter as it is a= lways up to the LoST service provisioning (based on local policy) to determine what is locally acceptable. Thanx, Dan On Thu, Dec 20, 2012 at 2:53 AM, Ivo Sedlacek wr= ote: > Hello,**** > > ** ** > > thanks for the proposal and for the check of the Canadian usage.**** > > ** ** > > Let's try to assign the proposed service URNs to the Wikipedia list:**** > > - municipal police (Czech Republic, Poland) -> urn:service:sos.police.A3 = * > *** > > - tourist police (Egypt, Greece) -> urn:service:sos.police.tourist**** > > - traffic police (Egypt, Sudan, India, Pakistan, Saudi Arabia, Albania, > Armenia, Azerbaijan) -> urn:service:sos.police.traffic**** > > - state police (Italy) -> urn:service:sos.police.country**** > > - customs/financial Police (Italy) -> does not match - we probably need > urn:service:sos.police.financial (new)**** > > - gendarmerie (Romania) -> does not match - we probably need > urn:service:sos.police.military (new)**** > > - local police (Spain) -> urn:service:sos.police.A3**** > > - Catalan police (Spain) -> urn:service:sos.police.A1 (a person with > spanish/catalan background should check)**** > > - civil guard (Spain) -> does not match - we probably need > urn:service:sos.police.military (new) (a person with spanish/catalan > background should check)**** > > - Provincial Police (Canada) - urn:service:sos.police.A1**** > > - S=C3=BBret=C3=A9 du Qu=C3=A9bec (Canada) - urn:service:sos.police.A1***= * > > - federal highway police (Brazil) -> urn:service:sos.police.traffic**** > > - federal police (Brazil) -> urn:service:sos.police.country**** > > - civil police (Brazil) -> does not match - we probably need > urn:service:sos.police.civil (new)**** > > - state highway police (Brazil) -> urn:service:sos.police.A1.traffic**** > > - GAULA (Colombia) -> does not match - we probably need > urn:service:sos.police.antikidnapping (new)**** > > ** ** > > I.e. we would need additionally:**** > > - urn:service:sos.police.financial**** > > - urn:service:sos.police.military**** > > - urn:service:sos.police.civil**** > > - urn:service:sos.police.antikidnapping**** > > ** ** > > If I understood it correctly, all together, we would need 77 police > related emergency service URNs =3D (7 (specialized police corp below) + 4 > (additional above)) * 7 (nomenclature specified in Civic Addresses (RFC > 4119)). Seems quite a lot.Moreover, a regulator in a country can define a > new type of a police related emergency service - it depends on how the la= w > enforcement is structure in the country. Then the list will grow even mor= e. > Maybe it would really be better to let regulators to manage per-country > sub-registries.**** > > ** ** > > Kind regards**** > > ** ** > > Ivo Sedlacek**** > > ** ** > > ** ** > > ** ** > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out at www.ericsson.com/email_disclaimer **** > > ** ** > > *From:* Dan Mongrain [mailto:dan@mongrain.org] > *Sent:* 19. prosince 2012 16:00 > *To:* Ivo Sedlacek > *Cc:* ecrit@ietf.org > > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > ** ** > > I also recommend we create purpose keywords in order to reach a > specialized police corp. Such as: > sos.police.drugs > sos.police.traffic > sos.police.firearms > sos.police.alcohol > sos.police.tobacco > sos.police.tourist > sos.police.border > > The above keywords can be utilized with territorial designations in order > to specify a particular service if offered by multiple jurisdictions. Fo= r > example in the US: > sos.police.country.drugs could be used to reach the DEA whereas > sos.police.A3.drugs could be used to reach the narcotics division of the > city police. > > I can answer for Canada: > sos.police.country would be to reach the Royal Canadian Mountain Police > (RCMP) > In the provinces of Ontario and Qu=C3=A9bec which have provincal polices,= then > sos.police.A1 in Ontario would reach the Ontario Provincial Police (OPP) > and sos.police.A1 in Qu=C3=A9bec would reach the Suret=C3=A9 du Qu=C3=A9b= ec (SQ). > In Canada we do not have a police service at the county level (we do have > sheriff departments but they are more for court and jail security). > In Ontario and Qu=C3=A9bec, a city may have its police service otherwise = the > provincial police offers the service. In the rest of Canada, a city may > have its police service otherwise the RCMP offers the service. > > Thanx, > Dan**** > > On Wed, Dec 19, 2012 at 7:02 AM, Ivo Sedlacek > wrote:**** > > Hello,**** > > **** > > thanks.**** > > **** > > both options (Dan's and Brian's) seemed to work for the emergency service= s > of the police forces in the Czech republic.**** > > **** > > For completeness, I also checked the emergency services of the police > forces of other countries. Wikipedia ( > http://en.wikipedia.org/wiki/Emergency_telephone_number) lists the > following on top of emergency services of the regular police forces:**** > > - municipal police (Czech Republic, Poland) -> can map to > urn:service:sos.police.local or urn:service:sos.police.A3 **** > > - tourist police (Egypt, Greece) -> does not seem to fit into any of the > alternatives so far**** > > - traffic police (Egypt, Sudan, India, Pakistan, Saudi Arabia, Albania, > Armenia, Azerbaijan) -> does not seem to fit into any of the alternatives > so far**** > > - state police (Italy) -> can map to urn:service:sos.police.national or > urn:service:sos.police.country**** > > - customs/financial Police (Italy) -> does not seem to fit into any of th= e > alternatives so far**** > > - gendarmerie (Romania) -> does not seem to fit into any of the > alternatives so far**** > > - local police (Spain) -> can map to urn:service:sos.police.local or > urn:service:sos.police.A3**** > > - Catalan police (Spain) -> maybe this could map to > urn:service:sos.police.regional or urn:service:sos.police.A1 but a person > with spanish/catalan background should check.**** > > - civil guard (Spain) -> does not seem to fit into any of the alternative= s > so far**** > > - Provincial Police (Canada) - maybe this could map to > urn:service:sos.police.regional or urn:service:sos.police.A1 but a person > with canadian background should check**** > > - S=C3=BBret=C3=A9 du Qu=C3=A9bec (Canada) - maybe this could map to > urn:service:sos.police.regional or urn:service:sos.police.A1 but a person > with canadian background should check**** > > - federal highway police (Brazil) -> does not seem to fit into any of the > alternatives so far**** > > - federal police (Brazil) -> can map to urn:service:sos.police.national o= r > urn:service:sos.police.country**** > > - civil police (Brazil) -> does not seem to fit into any of the > alternatives so far**** > > - state highway police (Brazil) -> does not seem to fit into any of the > alternatives so far**** > > - GAULA (Colombia) -> does not seem to fit into any of the alternatives s= o > far**** > > **** > > For those emergency services above not fitting into any of the > alternatives, how should they be expressed in an emergency service URN? D= o > we assume IANA will register them too?**** > > **** > > Kind regards**** > > **** > > Ivo Sedlacek**** > > **** > > **** > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out at www.ericsson.com/email_disclaimer **** > > **** > > *From:* ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behalf > Of *Dan Mongrain, eng. > *Sent:* 18. prosince 2012 16:35 > *To:* ecrit@ietf.org**** > > > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > **** > > Instead of trying to come up with the proper nomenclature for the > jurisdiction to be used in the Service URN, why not utilize the > nomenclature specified in Civic Addresses (RFC 4119): > sos.police.country for police services at the country/national/federal/et= c > level > sos.police.A1 for police services at the > state/province/region/prefecture/etc level > sos.police.A2 for police services at the county/parish/gun/district/etc > level > sos.police.A3 for police services at the city/township/shi/etc level > sos.police.A4 for police services at the city division/borough/city > district/ward/chou/etc level > sos.police.A5 for police services at the neighborhood/block/etc level > > This way we avoid having to pick a term that has no applicability in > certain countries. > > Thanx, > Dan > > On 14/12/2012 9:12 AM, Rosen, Brian wrote:**** > > I have no problem using "national" instead of "federal". **** > > "State" and "Province" are equivalent. Some countries have one, some hav= e > the other. I don't think there are any with both. Some have neither of > course.**** > > **** > > I'd prefer not to have nation-specific values. **** > > **** > > Brian**** > > On Dec 14, 2012, at 3:48 AM, Ivo Sedlacek > wrote:**** > > ** ** > > Hello,**** > > **** > > thank you for your mail.**** > > **** > > > I'd support another (optional) level of police with at least 4 values.*= * > ** > > > **** > > > Perhaps "local"/"regional"/"provincial"/"federal"**** > > **** > > if I understood correctly, you propose that:**** > > - urn:service:sos.local,**** > > - urn:service:sos.regional,**** > > - urn:service:sos.provincial,**** > > - urn:service:sos.federal**** > > are registered. if I misunderstood, please correct me.**** > > **** > > urn:service:sos.local would map well to the emergency service provided by > the municipal police in the Czech republic.**** > > **** > > However, the emergency service provided by the national police in the > Czech republic is not easily mapped to any of the values:**** > > - Czech republic has provinces ("kraj") but the provinces (so far) do not > have their own police force.**** > > - Czech republic is not a federation so "federal" does not fit either.***= * > > **** > > Perhaps the following should be defined: urn:service:sos.local, > urn:service:sos.regional, urn:service:sos.*state*, urn:service:sos.federa= l > **** > > **** > > Alternatively, subregistries can be created for each country where the > regulator of the country would manage the emergency service URNs for the > country specific emergency services ( > http://en.wikipedia.org/wiki/Emergency_telephone_number seems to list > quite a lot of those )**** > > **** > > Kind regards**** > > **** > > Ivo Sedlacek**** > > **** > > **** > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out at www.ericsson.com/email_disclaimer**** > > **** > > *From:* Rosen, Brian [mailto:Brian.Rosen@neustar.biz > ] > *Sent:* 13. prosince 2012 15:41 > *To:* Ivo Sedlacek > *Cc:* ecrit@ietf.org > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > **** > > That issue occurs in several other countries.**** > > There are often 3 or more police agencies serving an area. In my home, > there are four:**** > > a) A local (township) police**** > > b) A county police agency that responds to some uncommon events**** > > c) A state police agency, which also has jurisdiction in some circumstanc= es > **** > > d) The federal police (FBI)**** > > **** > > While we do have a single number, if you explicitly wanted the state > police, there is no way to get to them.**** > > **** > > I'd support another (optional) level of police with at least 4 values.***= * > > **** > > Perhaps "local"/"regional"/"provincial"/"federal"**** > > **** > > Brian**** > > On Dec 13, 2012, at 8:22 AM, Ivo Sedlacek > wrote:**** > > > > **** > > Hello,**** > > **** > > in the Czech republic, the national regulator defined two police related > emergency services:**** > > A) emergency service provided by the national police (number 158 in the > public switched telephone network); and**** > > B) emergency service provided by the municipal police (number 156 in the > public switched telephone network).**** > > **** > > The regulation is > http://aplikace.mvcr.cz/archiv2008/sbirka/2007/sb043-07.pdf which lists > the numbers 156 and 158 in section 4.5. with note 2) which states "=C4=8C= =C3=ADslo je > n=C3=A1rodn=C3=ADm =C4=8D=C3=ADslem pro t=C3=ADs=C5=88ov=C3=A9 vol=C3=A1n= =C3=AD" (=3D the number is a national number for > emergency calls).**** > > **** > > Is it appropriate to register the following URNs for those services with > IANA?**** > > - urn:service:sos.police.national - The 'police.national' service refers > to the police department or other law enforcement authorities of the > national government.**** > > - urn:service:sos.police.municipal - The 'police.municipal' service refer= s > to the police department or other law enforcement authorities of the > municipal authorities.**** > > **** > > Or should those be registered with a prefix indicating that those are > applicable to Czech republic only, as other countries may have similar (b= ut > not necessarily identical) services:**** > > - urn:service:sos.police.czech.national - The 'police.czech.national' > service refers to the police department or other law enforcement > authorities of the national government.**** > > - urn:service:sos.police.czech.municipal - The 'police.czech.municipal' > service refers to the police department or other law enforcement > authorities of municipal authorities.**** > > **** > > I assume this question belongs to IANA, but as the expert reviewer most > likely will be from the ECRIT, I am sending it here.**** > > **** > > Kind regards**** > > **** > > Ivo Sedlacek**** > > **** > > **** > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out atwww.ericsson.com/email_disclaimer**** > > _______________________________________________ > 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**** > > **** > > ** ** > --f46d04446b21aefe1104d6059524 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Sorry for responding late= to this thread, it kinda fell into a=C2=A0 crack=E2=80= =A6=C2=A0 The current thread reminded me to check this old thread=E2=80=A6

=C2=A0

You are indicating that w= e need to register 77 Service URN (11 service subtypes * 7 jurisdiction types based on RFC 4119).=C2=A0 I do not recommend that we create so many registrations.=C2=A0 Instead, we should allow a service URN to be suffixed with a jurisdictional scope.=C2=A0= So the following Service URN are all valid:

=C2=A0

urn:service:sos.police

urn:service:sos.police.tr= affic

urn:service:sos.police.A1=

urn:service:sos.police.tr= affic.A1

=C2=A0

Question is, do we want t= o leave jurisdictional scope to only be applicable to police branch or any Service URN? =C2=A0I= =E2=80=99d say the latter as it is always up to the LoST service provisioning (based on local policy) to determine what is loca= lly acceptable.

=C2=A0

Thanx,

Dan



On Thu, Dec 20, 2012 at 2:53 AM, Ivo Sed= lacek <ivo.sedlacek@ericsson.com> wrote:

Hello,=

=C2=A0=

thanks for the proposal and= for the check of the Canadian usage.

=C2=A0=

Let's try to assign the= proposed service URNs to the Wikipedia list:

- municipal police (Czech R= epublic, Poland) -> urn:service:sos.police.A3

- tourist police (Egypt, Gr= eece) -> urn:service:sos.police.tourist

- traffic police (Egypt, Su= dan, India, Pakistan, Saudi Arabia, Albania, Armenia, Azerbaijan) -> urn= :service:sos.police.traffic

- state police (Italy) ->= ; urn:service:sos.police.country

- customs/financial Police = (Italy) -> does not match - we probably need urn:service:sos.police.fina= ncial (new)

- gendarmerie (Romania) -&g= t; does not match - we probably need urn:service:sos.police.military (new)<= u>

- local police (Spain) ->= ; urn:service:sos.police.A3

- Catalan police (Spain) -&= gt; urn:service:sos.police.A1 (a person with spanish/catalan background sho= uld check)

- civil guard (Spain) ->= does not match - we probably need urn:service:sos.police.military (new) (a= person with spanish/catalan background should check)<= /p>

- Provincial Police (Canada= ) - urn:service:sos.police.A1

- S=C3=BBret=C3=A9 du Qu=C3= =A9bec (Canada) - urn:service:sos.police.A1

- federal highway police (B= razil) -> urn:service:sos.police.traffic

- federal police (Brazil) -= > urn:service:sos.police.country

- civil police (Brazil) -&g= t; does not match - we probably need urn:service:sos.police.civil (new)<= /u>

- state highway police (Bra= zil) -> urn:service:sos.police.A1.traffic

- GAULA (Colombia) -> do= es not match - we probably need urn:service:sos.police.antikidnapping (new)=

=C2=A0=

I.e. we would need addition= ally:

- urn:service:sos.police.fi= nancial

- urn:service:sos.police.mi= litary

- urn:service:sos.police.ci= vil

- urn:service:sos.police.an= tikidnapping

=C2=A0=

If I understood it correctl= y, all together, we would need 77 police related emergency service URNs =3D= (7 (specialized police corp below) + 4 (additional above)) * 7 (nomenclature specified in Civic Addresses (RFC 4119)). Seems quite a = lot.Moreover, a regulator in a country can define a new type of a police re= lated emergency service - it depends on how the law enforcement is structur= e in the country. Then the list will grow even more. Maybe it would really be better to let regulators to = manage per-country sub-registries.

=C2=A0=

Kind regards<= /span>

=C2=A0=

Ivo Sedlacek<= /span>

=C2=A0=

=C2=A0=

=C2=A0=

This Communication is Confid= ential. We only send and receive email on the basis of the terms set out at www.ericsso= n.com/email_disclaimer

=C2=A0=

From: Da= n Mongrain [mailto:dan@mongrain.org]
Sent: 19. prosince 2012 16:00
To: Ivo Sedlacek
Cc: ecrit@ietf.org


Subject: Re: [Ecrit] What is the most appropriate method for registe= ring new sub-services of urn:service:sos

=C2=A0

I also recommend we c= reate purpose keywords in order to reach a specialized police corp.=C2=A0 S= uch as:
sos.police.drugs
sos.police.traffic
sos.police.firearms
sos.police.alcohol
sos.police.tobacco
sos.police.tourist
sos.police.border

The above keywords can be utilized with territorial designations in order t= o specify a particular service if offered by multiple jurisdictions.=C2=A0 = For example in the US:
sos.police.country.drugs could be used to reach the DEA whereas
sos.police.A3.drugs could be used to reach the narcotics division of the ci= ty police.

I can answer for Canada:
sos.police.country would be to reach the Royal Canadian Mountain Police (RC= MP)
In the provinces of Ontario and Qu=C3=A9bec which have provincal polices, t= hen sos.police.A1 in Ontario would reach the Ontario Provincial Police (OPP= ) and sos.police.A1 in Qu=C3=A9bec would reach the Suret=C3=A9 du Qu=C3=A9b= ec (SQ).
In Canada we do not have a police service at the county level (we do have s= heriff departments but they are more for court and jail security).
In Ontario and Qu=C3=A9bec, a city may have its police service otherwise th= e provincial police offers the service.=C2=A0 In the rest of Canada, a city= may have its police service otherwise the RCMP offers the service.

Thanx,
Dan

On Wed, Dec 19, 2012 at 7:02 AM, Ivo Sedlacek <ivo.sedlacek@e= ricsson.com> wrote:

Hello,=

=C2=A0=

thanks.

=C2=A0=

both options (Dan's and= Brian's) seemed to work for the emergency services of the police force= s in the Czech republic.

=C2=A0=

For completeness, I also ch= ecked the emergency services of the police forces of other countries. Wikip= edia (http://en.wikipedia.org/wiki/Emergency_telep= hone_number) lists the following on top of emergency services of the regular police for= ces:

- municipal police (Czech R= epublic, Poland) -> can map to urn:service:sos.police.local or urn:servi= ce:sos.police.A3

- tourist police (Egypt, Gr= eece) -> does not seem to fit into any of the alternatives so far=

- traffic police (Egypt, Su= dan, India, Pakistan, Saudi Arabia, Albania, Armenia, Azerbaijan) -> doe= s not seem to fit into any of the alternatives so far

- state police (Italy) ->= ; can map to urn:service:sos.police.national or urn:service:sos.police.coun= try

- customs/financial Police = (Italy) -> does not seem to fit into any of the alternatives so far

- gendarmerie (Romania) -&g= t; does not seem to fit into any of the alternatives so far

- local police (Spain) ->= ; can map to urn:service:sos.police.local or urn:service:sos.police.A3

- Catalan police (Spain) -&= gt; maybe this could map to urn:service:sos.police.regional or urn:service:= sos.police.A1 but a person with spanish/catalan background should check.

- civil guard (Spain) ->= does not seem to fit into any of the alternatives so far<= /u>

- Provincial Police (Canada= ) - maybe this could map to urn:service:sos.police.regional or urn:service:= sos.police.A1 but a person with canadian background should check

- S=C3=BBret=C3=A9 du Qu=C3= =A9bec (Canada) - maybe this could map to urn:service:sos.police.regional o= r urn:service:sos.police.A1 but a person with canadian background should check

- federal highway police (B= razil) -> does not seem to fit into any of the alternatives so far

- federal police (Brazil) -= > can map to urn:service:sos.police.national or urn:service:sos.police.c= ountry

- civil police (Brazil) -&g= t; does not seem to fit into any of the alternatives so far

- state highway police (Bra= zil) -> does not seem to fit into any of the alternatives so far<= u>

- GAULA (Colombia) -> do= es not seem to fit into any of the alternatives so far=

=C2=A0=

For those emergency service= s above not fitting into any of the alternatives, how should they be expres= sed in an emergency service URN? Do we assume IANA will register them too?

=C2=A0=

Kind regards<= u>

=C2=A0=

Ivo Sedlacek<= u>

=C2=A0=

=C2=A0=

This Communication is Confid= ential. We only send and receive email on the basis of the terms set out at www.eri= csson.com/email_disclaimer

=C2=A0=

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces= @ietf.org] On Behalf Of Dan Mongrain, eng.
Sent: 18. prosince 2012 16:35
To: ecrit@ietf.org


Subject: Re: [Ecrit] What is the most appropriate method for registe= ring new sub-services of urn:service:sos

=C2=A0

Instead of trying to come up with the proper nomencl= ature for the jurisdiction to be used in the Service URN, why not utilize t= he nomenclature specified in Civic Addresses (RFC 4119):
sos.police.country for police services at the country/national/federal/etc = level
sos.police.A1 for police services at the state/province/region/prefecture/e= tc level
sos.police.A2 for police services at the county/parish/gun/district/etc lev= el
sos.police.A3 for police services at the city/township/shi/etc level
sos.police.A4 for police services at the city division/borough/city distric= t/ward/chou/etc level
sos.police.A5 for police services at the neighborhood/block/etc level

This way we avoid having to pick a term that has no applicability in certai= n countries.

Thanx,
Dan

On 14/12/2012 9:12 AM, Rosen, Brian wrote:

I have no problem using "national" instead= of "federal".

"State" and "Province" are equiv= alent. =C2=A0Some countries have one, some have the other. =C2=A0I don'= t think there are any with both. =C2=A0Some have neither of course.<= u>

=C2=A0

I'd prefer not to have nation-specific values. = =C2=A0

=C2=A0

Brian

On Dec 14, 2012, at 3:48 AM, Ivo Sedlacek <ivo.sedlacek@erics= son.com> wrote:

=C2=A0<= /p>

Hello,=

=C2=A0=

thank you for your mail.

=C2=A0=

>=C2=A0I'd su= pport another (optional) level of police with at least 4 values.<= /u>

>=C2=A0=

>=C2=A0Perhaps &q= uot;local"/"regional"/"provincial"/"federal&q= uot;

=C2=A0=

if I understood correctly, = you propose that:

- urn:service:sos.local,

- urn:service:sos.regional,=

- urn:service:sos.provincia= l,

- urn:service:sos.federal

are registered. if I misund= erstood, please correct me.

=C2=A0=

urn:service:sos.local would= map well to the emergency service provided by the municipal police in the Czech republic.

=C2=A0=

However, the emergency serv= ice provided by the national police in the Czech republic is not easily mapped to any of the values:

- Czech republic has provin= ces ("kraj") but the provinces (so far) do not have their own pol= ice force.

- Czech republic is not a f= ederation so "federal" does not fit either.<= /p>

=C2=A0=

Perhaps the following shoul= d be defined: urn:service:sos.local, urn:service:sos.regional, urn:service:= sos.state, urn:service:sos.federal

=C2=A0=

Alternatively, subregistrie= s can be created for each country where the regulator of the country would manage the emergency service URNs for the country specific emergency servi= ces (=C2=A0http://en.wikipedia.or= g/wiki/Emergency_telephone_number=C2=A0= seems to list quite a lot of those )

=C2=A0=

Kind regards<= u>

=C2=A0=

Ivo Sedlacek<= u>

=C2=A0=

=C2=A0=

This Communication is Confid= ential. We only send and receive email on the basis of the terms set out at=C2=A0www.ericsson.com/email_disclaimer

=C2=A0=

From:=C2=A0Ros= en, Brian [mailto:Brian.Rosen@neustar.biz]=C2= =A0
Sent:=C2=A013. prosince 2012 15:41
To:=C2=A0Ivo Sedlacek
Cc:=C2=A0= ecrit@ietf.org
Subject:=C2=A0Re: [Ecrit] What is the most appropriate method for re= gistering new sub-services of urn:service:sos

=C2=A0

That issue occurs in several other countries.=

There are often 3 or more police agencies serving an= area. =C2=A0In my home, there are four:

a) A local (township) police

b) A county police agency that responds to some unco= mmon events

c) A state police agency, which also has jurisdictio= n in some circumstances

d) The federal police (FBI)

=C2=A0

While we do have a single number, if you explicitly = wanted the state police, there is no way to get to them.

=C2=A0

I'd support another (optional) level of police w= ith at least 4 values.

=C2=A0

Perhaps "local"/"regional"/"= ;provincial"/"federal"

=C2=A0

Brian

On Dec 13, 2012, at 8:22 AM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:



Hello,

=C2=A0

in the Czech republic, the national reg= ulator defined two police related emergency services:<= /p>

A) emergency service provided by the na= tional police (number 158 in the public switched telephone network); and

B) emergency service provided by the mu= nicipal police (number 156 in the public switched telephone network).

=C2=A0

The regulation is=C2=A0http://aplikace.mvcr.cz/archiv2008/sbirka= /2007/sb043-07.pdf=C2=A0which lists the numbers 156 and 158 in section 4.5. with note 2) which states &q= uot;=C4=8C=C3=ADslo je n=C3=A1rodn=C3=ADm =C4=8D=C3=ADslem pro t=C3=ADs=C5= =88ov=C3=A9 vol=C3=A1n=C3=AD" (=3D the number is a national number for= emergency calls).

=C2=A0

Is it appropriate to register the follo= wing URNs for those services with IANA?

- urn:service:sos.police.national - The= 'police.national' service refers to the police department or other= law enforcement authorities of the national government.

- urn:service:sos.police.municipal - Th= e 'police.municipal' service refers to the police department or oth= er law enforcement authorities of the municipal authorities.=

=C2=A0

Or should those be registered with a pr= efix indicating that those are applicable to Czech republic only, as other countries may have similar (but not necessarily identical) services:

- urn:service:sos.police.czech.national= - The 'police.czech.national' service refers to the police departm= ent or other law enforcement authorities of the national government.

- urn:service:sos.police.czech.municipa= l - The 'police.czech.municipal' service refers to the police depar= tment or other law enforcement authorities of municipal authorities.

=C2=A0

I assume this question belongs to IANA,= but as the expert reviewer most likely will be from the ECRIT, I am sendin= g it here.

=C2=A0

Kind regards

=C2=A0

Ivo Sedlacek

=C2=A0

=C2=A0

This Communication is Confidential. We = only send and receive email on the basis of the terms set out atwww.ericsson.com/email_disclaimer

_____________________________________= __________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecr= it

=C2=A0

=C2=A0



_______________________________________________
Ecrit mailing list
Ecrit@ietf.org=

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

=C2=A0

=C2=A0


--f46d04446b21aefe1104d6059524-- From James.Winterbottom@commscope.com Mon Feb 18 13:21:48 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0604121F8C9E for ; Mon, 18 Feb 2013 13:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGO7242LZ7AI for ; Mon, 18 Feb 2013 13:21:44 -0800 (PST) Received: from cdcsmgw02.commscope.com (smtp1.andrew.com [198.135.207.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2973921F8C84 for ; Mon, 18 Feb 2013 13:21:43 -0800 (PST) X-AuditID: 0a0404e9-b7f6c6d00000085c-d0-51229b6640b3 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw02.commscope.com (Symantec Messaging Gateway) with SMTP id DE.7D.02140.66B92215; Mon, 18 Feb 2013 15:21:42 -0600 (CST) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 18 Feb 2013 15:21:30 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 19 Feb 2013 05:21:12 +0800 From: "Winterbottom, James" To: Dan Mongrain , Ivo Sedlacek Date: Tue, 19 Feb 2013 05:21:08 +0800 Thread-Topic: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos Thread-Index: Ac4OFsLHYAOB1qirSYa6xM3zXnimggABthTQ Message-ID: <5A55A45AE77F5941B18E5457ECAC818801214077118C@SISPE7MB1.commscope.com> References: <39B5E4D390E9BD4890E2B3107900610103F703@ESESSMB301.ericsson.se> <9E790F21-21D7-437B-820B-A88355047BBA@neustar.biz> <39B5E4D390E9BD4890E2B3107900610103FBB3@ESESSMB301.ericsson.se> <6E7FEA84-EBE2-4BE0-B8EA-67D5AD8CA9F2@neustar.biz> <50D08D29.2030303@mongrain.org> <39B5E4D390E9BD4890E2B3107900610104BB9D@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610104C240@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC818801214077118CSISPE7MB1co_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOKsWRmVeSWpSXmKPExsXCFSaSpps2WynQ4PchS4v7c1pYLBoXPWW1 6F05j9WB2ePX16tsHkuW/GTyeLFNIYA5issmJTUnsyy1SN8ugSuj6/lrtoKeC6wV728cYGpg 3LOXtYuRk0NCwERiwsweNghbTOLCvfVANheHkMBuRokv574yQzgbGCVm75rJDFIlJLCOUeLC egkQm03ATuLw+htgcREBX4kVMy6DTWUWUJU41/iYBcRmAbInXn8CZgsL5Ekc7G5lhKjPl3i1 +SWUbSTx9PV8JhCbVyBI4u/Sj1CLV7NIXFy4F2wBp0CgxMIP7WANjECnfj+1hglimbjErScQ zRICAhJL9pxnhrBFJV4+/scKUS8qcad9PSNEfb7EsZNzWCGWCUqcnAlxnJCArkTTzq+sExjF ZyEZOwtJyywkLbMYOYDimhLrd+lDlChKTOl+yA5ha0i0zpnLjiy+gJF9FaN4ckpycW56uYGR XnJ+bm5xcn5BKoi1iREUuywsL3cwnt2gfYhRgINRiYfXw0UpUIg1say4MvcQoyQHk5Iob9hM oBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3o52oBxvSmJlVWpRPkxKg4ND4PST+6cYpVjy8vNS lSR4H4CMECxKTU+tSMvMASYumFImDk6QUTxAoy6B1PAWFyTmFmemQ+RPMapyNC9//oJRCGyQ lDgv0yygIgGQoozSPLg5rxjFgY4X5n0NMoIHmHrhJrwCGs4ENHzVXUWQ4SWJCCmpBsZFHyxP yJ2eURJ9dmeR8Rt1ngUNlVYNU0NeOXBbyS68zFrRxifU0cCYfGWVdHNKVr1LZZRiZl72+8Uh s3R+mXBuqX41d3GYeNSrRxbfq7TOl55z2TZh7wrNCcstKwRc9fuv5b4QuPD1NL+av3DGVj32 w3u7i7oaT8xSiJv/aNdur22r5j1cY6zEUpyRaKjFXFScCAD3Yf7jegMAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 21:21:48 -0000 --_000_5A55A45AE77F5941B18E5457ECAC818801214077118CSISPE7MB1co_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBJIGFtIG1pc3Npbmcgc29tZXRoaW5nIGhlcmUsIEExIGlzIHBhcnQgb2YgdGhlIGxv Y2F0aW9uLCBzbyB3aHkgZG9lcyBpdCBuZWVkIHRvIGJlIGluIHRoZSBVUk4gYXQgYWxsPw0KQXMg ZmFyIGFzIEkgdW5kZXJzdGFuZCBjdXJyZW50IGRlcGxveW1lbnRzLCB0aGV5IHVzZSB0aGUgVVJO IHRvIHNlbGVjdCBhIGxheWVyIGluIHRoZSBHSVMgdGhhdCBjb3JyZXNwb25kcyB0byB0aGUgc2Vy dmljZSB0eXBlLCBhbmQgdGhlbiB1c2UgZ2VvZ3JhcGhpYyBib3VuZGFyaWVzIHdpdGhpbiB0aGF0 IGxheWVyIHRvIHNlbGVjdCB0aGUgZmluYWwgZGVzdGluYXRpb24uDQoNCkZyb206IGVjcml0LWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgRGFuIE1vbmdyYWluDQpTZW50OiBUdWVzZGF5LCAxOSBGZWJydWFyeSAyMDEzIDc6MzAgQU0N ClRvOiBJdm8gU2VkbGFjZWsNCkNjOiBlY3JpdEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtFY3Jp dF0gV2hhdCBpcyB0aGUgbW9zdCBhcHByb3ByaWF0ZSBtZXRob2QgZm9yIHJlZ2lzdGVyaW5nIG5l dyBzdWItc2VydmljZXMgb2YgdXJuOnNlcnZpY2U6c29zDQoNClNvcnJ5IGZvciByZXNwb25kaW5n IGxhdGUgdG8gdGhpcyB0aHJlYWQsIGl0IGtpbmRhIGZlbGwgaW50byBhICBjcmFja+KApiAgVGhl IGN1cnJlbnQgdGhyZWFkIHJlbWluZGVkIG1lIHRvIGNoZWNrIHRoaXMgb2xkIHRocmVhZOKApg0K DQpZb3UgYXJlIGluZGljYXRpbmcgdGhhdCB3ZSBuZWVkIHRvIHJlZ2lzdGVyIDc3IFNlcnZpY2Ug VVJOICgxMSBzZXJ2aWNlIHN1YnR5cGVzICogNyBqdXJpc2RpY3Rpb24gdHlwZXMgYmFzZWQgb24g UkZDIDQxMTkpLiAgSSBkbyBub3QgcmVjb21tZW5kIHRoYXQgd2UgY3JlYXRlIHNvIG1hbnkgcmVn aXN0cmF0aW9ucy4gIEluc3RlYWQsIHdlIHNob3VsZCBhbGxvdyBhIHNlcnZpY2UgVVJOIHRvIGJl IHN1ZmZpeGVkIHdpdGggYSBqdXJpc2RpY3Rpb25hbCBzY29wZS4gIFNvIHRoZSBmb2xsb3dpbmcg U2VydmljZSBVUk4gYXJlIGFsbCB2YWxpZDoNCg0KdXJuOnNlcnZpY2U6c29zLnBvbGljZQ0KdXJu OnNlcnZpY2U6c29zLnBvbGljZS50cmFmZmljDQp1cm46c2VydmljZTpzb3MucG9saWNlLkExDQp1 cm46c2VydmljZTpzb3MucG9saWNlLnRyYWZmaWMuQTENCg0KUXVlc3Rpb24gaXMsIGRvIHdlIHdh bnQgdG8gbGVhdmUganVyaXNkaWN0aW9uYWwgc2NvcGUgdG8gb25seSBiZSBhcHBsaWNhYmxlIHRv IHBvbGljZSBicmFuY2ggb3IgYW55IFNlcnZpY2UgVVJOPyAgSeKAmWQgc2F5IHRoZSBsYXR0ZXIg YXMgaXQgaXMgYWx3YXlzIHVwIHRvIHRoZSBMb1NUIHNlcnZpY2UgcHJvdmlzaW9uaW5nIChiYXNl ZCBvbiBsb2NhbCBwb2xpY3kpIHRvIGRldGVybWluZSB3aGF0IGlzIGxvY2FsbHkgYWNjZXB0YWJs ZS4NCg0KVGhhbngsDQpEYW4NCg0KT24gVGh1LCBEZWMgMjAsIDIwMTIgYXQgMjo1MyBBTSwgSXZv IFNlZGxhY2VrIDxpdm8uc2VkbGFjZWtAZXJpY3Nzb24uY29tPG1haWx0bzppdm8uc2VkbGFjZWtA ZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIZWxsbywNCg0KdGhhbmtzIGZvciB0aGUgcHJvcG9zYWwg YW5kIGZvciB0aGUgY2hlY2sgb2YgdGhlIENhbmFkaWFuIHVzYWdlLg0KDQpMZXQncyB0cnkgdG8g YXNzaWduIHRoZSBwcm9wb3NlZCBzZXJ2aWNlIFVSTnMgdG8gdGhlIFdpa2lwZWRpYSBsaXN0Og0K LSBtdW5pY2lwYWwgcG9saWNlIChDemVjaCBSZXB1YmxpYywgUG9sYW5kKSAtPiB1cm46c2Vydmlj ZTpzb3MucG9saWNlLkEzDQotIHRvdXJpc3QgcG9saWNlIChFZ3lwdCwgR3JlZWNlKSAtPiB1cm46 c2VydmljZTpzb3MucG9saWNlLnRvdXJpc3QNCi0gdHJhZmZpYyBwb2xpY2UgKEVneXB0LCBTdWRh biwgSW5kaWEsIFBha2lzdGFuLCBTYXVkaSBBcmFiaWEsIEFsYmFuaWEsIEFybWVuaWEsIEF6ZXJi YWlqYW4pIC0+IHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UudHJhZmZpYw0KLSBzdGF0ZSBwb2xpY2Ug KEl0YWx5KSAtPiB1cm46c2VydmljZTpzb3MucG9saWNlLmNvdW50cnkNCi0gY3VzdG9tcy9maW5h bmNpYWwgUG9saWNlIChJdGFseSkgLT4gZG9lcyBub3QgbWF0Y2ggLSB3ZSBwcm9iYWJseSBuZWVk IHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UuZmluYW5jaWFsIChuZXcpDQotIGdlbmRhcm1lcmllIChS b21hbmlhKSAtPiBkb2VzIG5vdCBtYXRjaCAtIHdlIHByb2JhYmx5IG5lZWQgdXJuOnNlcnZpY2U6 c29zLnBvbGljZS5taWxpdGFyeSAobmV3KQ0KLSBsb2NhbCBwb2xpY2UgKFNwYWluKSAtPiB1cm46 c2VydmljZTpzb3MucG9saWNlLkEzDQotIENhdGFsYW4gcG9saWNlIChTcGFpbikgLT4gdXJuOnNl cnZpY2U6c29zLnBvbGljZS5BMSAoYSBwZXJzb24gd2l0aCBzcGFuaXNoL2NhdGFsYW4gYmFja2dy b3VuZCBzaG91bGQgY2hlY2spDQotIGNpdmlsIGd1YXJkIChTcGFpbikgLT4gZG9lcyBub3QgbWF0 Y2ggLSB3ZSBwcm9iYWJseSBuZWVkIHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UubWlsaXRhcnkgKG5l dykgKGEgcGVyc29uIHdpdGggc3BhbmlzaC9jYXRhbGFuIGJhY2tncm91bmQgc2hvdWxkIGNoZWNr KQ0KLSBQcm92aW5jaWFsIFBvbGljZSAoQ2FuYWRhKSAtIHVybjpzZXJ2aWNlOnNvcy5wb2xpY2Uu QTENCi0gU8O7cmV0w6kgZHUgUXXDqWJlYyAoQ2FuYWRhKSAtIHVybjpzZXJ2aWNlOnNvcy5wb2xp Y2UuQTENCi0gZmVkZXJhbCBoaWdod2F5IHBvbGljZSAoQnJhemlsKSAtPiB1cm46c2VydmljZTpz b3MucG9saWNlLnRyYWZmaWMNCi0gZmVkZXJhbCBwb2xpY2UgKEJyYXppbCkgLT4gdXJuOnNlcnZp Y2U6c29zLnBvbGljZS5jb3VudHJ5DQotIGNpdmlsIHBvbGljZSAoQnJhemlsKSAtPiBkb2VzIG5v dCBtYXRjaCAtIHdlIHByb2JhYmx5IG5lZWQgdXJuOnNlcnZpY2U6c29zLnBvbGljZS5jaXZpbCAo bmV3KQ0KLSBzdGF0ZSBoaWdod2F5IHBvbGljZSAoQnJhemlsKSAtPiB1cm46c2VydmljZTpzb3Mu cG9saWNlLkExLnRyYWZmaWMNCi0gR0FVTEEgKENvbG9tYmlhKSAtPiBkb2VzIG5vdCBtYXRjaCAt IHdlIHByb2JhYmx5IG5lZWQgdXJuOnNlcnZpY2U6c29zLnBvbGljZS5hbnRpa2lkbmFwcGluZyAo bmV3KQ0KDQpJLmUuIHdlIHdvdWxkIG5lZWQgYWRkaXRpb25hbGx5Og0KLSB1cm46c2VydmljZTpz b3MucG9saWNlLmZpbmFuY2lhbA0KLSB1cm46c2VydmljZTpzb3MucG9saWNlLm1pbGl0YXJ5DQot IHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UuY2l2aWwNCi0gdXJuOnNlcnZpY2U6c29zLnBvbGljZS5h bnRpa2lkbmFwcGluZw0KDQpJZiBJIHVuZGVyc3Rvb2QgaXQgY29ycmVjdGx5LCBhbGwgdG9nZXRo ZXIsIHdlIHdvdWxkIG5lZWQgNzcgcG9saWNlIHJlbGF0ZWQgZW1lcmdlbmN5IHNlcnZpY2UgVVJO cyA9ICg3IChzcGVjaWFsaXplZCBwb2xpY2UgY29ycCBiZWxvdykgKyA0IChhZGRpdGlvbmFsIGFi b3ZlKSkgKiA3IChub21lbmNsYXR1cmUgc3BlY2lmaWVkIGluIENpdmljIEFkZHJlc3NlcyAoUkZD IDQxMTkpKS4gU2VlbXMgcXVpdGUgYSBsb3QuTW9yZW92ZXIsIGEgcmVndWxhdG9yIGluIGEgY291 bnRyeSBjYW4gZGVmaW5lIGEgbmV3IHR5cGUgb2YgYSBwb2xpY2UgcmVsYXRlZCBlbWVyZ2VuY3kg c2VydmljZSAtIGl0IGRlcGVuZHMgb24gaG93IHRoZSBsYXcgZW5mb3JjZW1lbnQgaXMgc3RydWN0 dXJlIGluIHRoZSBjb3VudHJ5LiBUaGVuIHRoZSBsaXN0IHdpbGwgZ3JvdyBldmVuIG1vcmUuIE1h eWJlIGl0IHdvdWxkIHJlYWxseSBiZSBiZXR0ZXIgdG8gbGV0IHJlZ3VsYXRvcnMgdG8gbWFuYWdl IHBlci1jb3VudHJ5IHN1Yi1yZWdpc3RyaWVzLg0KDQpLaW5kIHJlZ2FyZHMNCg0KSXZvIFNlZGxh Y2VrDQoNCg0KDQpUaGlzIENvbW11bmljYXRpb24gaXMgQ29uZmlkZW50aWFsLiBXZSBvbmx5IHNl bmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0 IHd3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lcjxodHRwOi8vd3d3LmVyaWNzc29uLmNv bS9lbWFpbF9kaXNjbGFpbWVyPg0KDQpGcm9tOiBEYW4gTW9uZ3JhaW4gW21haWx0bzpkYW5AbW9u Z3JhaW4ub3JnXTxtYWlsdG86W21haWx0bzpkYW5AbW9uZ3JhaW4ub3JnXT4NClNlbnQ6IDE5LiBw cm9zaW5jZSAyMDEyIDE2OjAwDQpUbzogSXZvIFNlZGxhY2VrDQpDYzogZWNyaXRAaWV0Zi5vcmc8 bWFpbHRvOmVjcml0QGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW0Vjcml0XSBXaGF0IGlzIHRo ZSBtb3N0IGFwcHJvcHJpYXRlIG1ldGhvZCBmb3IgcmVnaXN0ZXJpbmcgbmV3IHN1Yi1zZXJ2aWNl cyBvZiB1cm46c2VydmljZTpzb3MNCg0KSSBhbHNvIHJlY29tbWVuZCB3ZSBjcmVhdGUgcHVycG9z ZSBrZXl3b3JkcyBpbiBvcmRlciB0byByZWFjaCBhIHNwZWNpYWxpemVkIHBvbGljZSBjb3JwLiAg U3VjaCBhczoNCnNvcy5wb2xpY2UuZHJ1Z3MNCnNvcy5wb2xpY2UudHJhZmZpYw0Kc29zLnBvbGlj ZS5maXJlYXJtcw0Kc29zLnBvbGljZS5hbGNvaG9sDQpzb3MucG9saWNlLnRvYmFjY28NCnNvcy5w b2xpY2UudG91cmlzdA0Kc29zLnBvbGljZS5ib3JkZXINCg0KVGhlIGFib3ZlIGtleXdvcmRzIGNh biBiZSB1dGlsaXplZCB3aXRoIHRlcnJpdG9yaWFsIGRlc2lnbmF0aW9ucyBpbiBvcmRlciB0byBz cGVjaWZ5IGEgcGFydGljdWxhciBzZXJ2aWNlIGlmIG9mZmVyZWQgYnkgbXVsdGlwbGUganVyaXNk aWN0aW9ucy4gIEZvciBleGFtcGxlIGluIHRoZSBVUzoNCnNvcy5wb2xpY2UuY291bnRyeS5kcnVn cyBjb3VsZCBiZSB1c2VkIHRvIHJlYWNoIHRoZSBERUEgd2hlcmVhcw0Kc29zLnBvbGljZS5BMy5k cnVncyBjb3VsZCBiZSB1c2VkIHRvIHJlYWNoIHRoZSBuYXJjb3RpY3MgZGl2aXNpb24gb2YgdGhl IGNpdHkgcG9saWNlLg0KDQpJIGNhbiBhbnN3ZXIgZm9yIENhbmFkYToNCnNvcy5wb2xpY2UuY291 bnRyeSB3b3VsZCBiZSB0byByZWFjaCB0aGUgUm95YWwgQ2FuYWRpYW4gTW91bnRhaW4gUG9saWNl IChSQ01QKQ0KSW4gdGhlIHByb3ZpbmNlcyBvZiBPbnRhcmlvIGFuZCBRdcOpYmVjIHdoaWNoIGhh dmUgcHJvdmluY2FsIHBvbGljZXMsIHRoZW4gc29zLnBvbGljZS5BMSBpbiBPbnRhcmlvIHdvdWxk IHJlYWNoIHRoZSBPbnRhcmlvIFByb3ZpbmNpYWwgUG9saWNlIChPUFApIGFuZCBzb3MucG9saWNl LkExIGluIFF1w6liZWMgd291bGQgcmVhY2ggdGhlIFN1cmV0w6kgZHUgUXXDqWJlYyAoU1EpLg0K SW4gQ2FuYWRhIHdlIGRvIG5vdCBoYXZlIGEgcG9saWNlIHNlcnZpY2UgYXQgdGhlIGNvdW50eSBs ZXZlbCAod2UgZG8gaGF2ZSBzaGVyaWZmIGRlcGFydG1lbnRzIGJ1dCB0aGV5IGFyZSBtb3JlIGZv ciBjb3VydCBhbmQgamFpbCBzZWN1cml0eSkuDQpJbiBPbnRhcmlvIGFuZCBRdcOpYmVjLCBhIGNp dHkgbWF5IGhhdmUgaXRzIHBvbGljZSBzZXJ2aWNlIG90aGVyd2lzZSB0aGUgcHJvdmluY2lhbCBw b2xpY2Ugb2ZmZXJzIHRoZSBzZXJ2aWNlLiAgSW4gdGhlIHJlc3Qgb2YgQ2FuYWRhLCBhIGNpdHkg bWF5IGhhdmUgaXRzIHBvbGljZSBzZXJ2aWNlIG90aGVyd2lzZSB0aGUgUkNNUCBvZmZlcnMgdGhl IHNlcnZpY2UuDQoNClRoYW54LA0KRGFuDQpPbiBXZWQsIERlYyAxOSwgMjAxMiBhdCA3OjAyIEFN LCBJdm8gU2VkbGFjZWsgPGl2by5zZWRsYWNla0Blcmljc3Nvbi5jb208bWFpbHRvOml2by5zZWRs YWNla0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhlbGxvLA0KDQp0aGFua3MuDQoNCmJvdGggb3B0 aW9ucyAoRGFuJ3MgYW5kIEJyaWFuJ3MpIHNlZW1lZCB0byB3b3JrIGZvciB0aGUgZW1lcmdlbmN5 IHNlcnZpY2VzIG9mIHRoZSBwb2xpY2UgZm9yY2VzIGluIHRoZSBDemVjaCByZXB1YmxpYy4NCg0K Rm9yIGNvbXBsZXRlbmVzcywgSSBhbHNvIGNoZWNrZWQgdGhlIGVtZXJnZW5jeSBzZXJ2aWNlcyBv ZiB0aGUgcG9saWNlIGZvcmNlcyBvZiBvdGhlciBjb3VudHJpZXMuIFdpa2lwZWRpYSAoaHR0cDov L2VuLndpa2lwZWRpYS5vcmcvd2lraS9FbWVyZ2VuY3lfdGVsZXBob25lX251bWJlcikgbGlzdHMg dGhlIGZvbGxvd2luZyBvbiB0b3Agb2YgZW1lcmdlbmN5IHNlcnZpY2VzIG9mIHRoZSByZWd1bGFy IHBvbGljZSBmb3JjZXM6DQotIG11bmljaXBhbCBwb2xpY2UgKEN6ZWNoIFJlcHVibGljLCBQb2xh bmQpIC0+IGNhbiBtYXAgdG8gdXJuOnNlcnZpY2U6c29zLnBvbGljZS5sb2NhbCBvciB1cm46c2Vy dmljZTpzb3MucG9saWNlLkEzDQotIHRvdXJpc3QgcG9saWNlIChFZ3lwdCwgR3JlZWNlKSAtPiBk b2VzIG5vdCBzZWVtIHRvIGZpdCBpbnRvIGFueSBvZiB0aGUgYWx0ZXJuYXRpdmVzIHNvIGZhcg0K LSB0cmFmZmljIHBvbGljZSAoRWd5cHQsIFN1ZGFuLCBJbmRpYSwgUGFraXN0YW4sIFNhdWRpIEFy YWJpYSwgQWxiYW5pYSwgQXJtZW5pYSwgQXplcmJhaWphbikgLT4gZG9lcyBub3Qgc2VlbSB0byBm aXQgaW50byBhbnkgb2YgdGhlIGFsdGVybmF0aXZlcyBzbyBmYXINCi0gc3RhdGUgcG9saWNlIChJ dGFseSkgLT4gY2FuIG1hcCB0byB1cm46c2VydmljZTpzb3MucG9saWNlLm5hdGlvbmFsIG9yIHVy bjpzZXJ2aWNlOnNvcy5wb2xpY2UuY291bnRyeQ0KLSBjdXN0b21zL2ZpbmFuY2lhbCBQb2xpY2Ug KEl0YWx5KSAtPiBkb2VzIG5vdCBzZWVtIHRvIGZpdCBpbnRvIGFueSBvZiB0aGUgYWx0ZXJuYXRp dmVzIHNvIGZhcg0KLSBnZW5kYXJtZXJpZSAoUm9tYW5pYSkgLT4gZG9lcyBub3Qgc2VlbSB0byBm aXQgaW50byBhbnkgb2YgdGhlIGFsdGVybmF0aXZlcyBzbyBmYXINCi0gbG9jYWwgcG9saWNlIChT cGFpbikgLT4gY2FuIG1hcCB0byB1cm46c2VydmljZTpzb3MucG9saWNlLmxvY2FsIG9yIHVybjpz ZXJ2aWNlOnNvcy5wb2xpY2UuQTMNCi0gQ2F0YWxhbiBwb2xpY2UgKFNwYWluKSAtPiBtYXliZSB0 aGlzIGNvdWxkIG1hcCB0byB1cm46c2VydmljZTpzb3MucG9saWNlLnJlZ2lvbmFsIG9yIHVybjpz ZXJ2aWNlOnNvcy5wb2xpY2UuQTEgYnV0IGEgcGVyc29uIHdpdGggc3BhbmlzaC9jYXRhbGFuIGJh Y2tncm91bmQgc2hvdWxkIGNoZWNrLg0KLSBjaXZpbCBndWFyZCAoU3BhaW4pIC0+IGRvZXMgbm90 IHNlZW0gdG8gZml0IGludG8gYW55IG9mIHRoZSBhbHRlcm5hdGl2ZXMgc28gZmFyDQotIFByb3Zp bmNpYWwgUG9saWNlIChDYW5hZGEpIC0gbWF5YmUgdGhpcyBjb3VsZCBtYXAgdG8gdXJuOnNlcnZp Y2U6c29zLnBvbGljZS5yZWdpb25hbCBvciB1cm46c2VydmljZTpzb3MucG9saWNlLkExIGJ1dCBh IHBlcnNvbiB3aXRoIGNhbmFkaWFuIGJhY2tncm91bmQgc2hvdWxkIGNoZWNrDQotIFPDu3JldMOp IGR1IFF1w6liZWMgKENhbmFkYSkgLSBtYXliZSB0aGlzIGNvdWxkIG1hcCB0byB1cm46c2Vydmlj ZTpzb3MucG9saWNlLnJlZ2lvbmFsIG9yIHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UuQTEgYnV0IGEg cGVyc29uIHdpdGggY2FuYWRpYW4gYmFja2dyb3VuZCBzaG91bGQgY2hlY2sNCi0gZmVkZXJhbCBo aWdod2F5IHBvbGljZSAoQnJhemlsKSAtPiBkb2VzIG5vdCBzZWVtIHRvIGZpdCBpbnRvIGFueSBv ZiB0aGUgYWx0ZXJuYXRpdmVzIHNvIGZhcg0KLSBmZWRlcmFsIHBvbGljZSAoQnJhemlsKSAtPiBj YW4gbWFwIHRvIHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UubmF0aW9uYWwgb3IgdXJuOnNlcnZpY2U6 c29zLnBvbGljZS5jb3VudHJ5DQotIGNpdmlsIHBvbGljZSAoQnJhemlsKSAtPiBkb2VzIG5vdCBz ZWVtIHRvIGZpdCBpbnRvIGFueSBvZiB0aGUgYWx0ZXJuYXRpdmVzIHNvIGZhcg0KLSBzdGF0ZSBo aWdod2F5IHBvbGljZSAoQnJhemlsKSAtPiBkb2VzIG5vdCBzZWVtIHRvIGZpdCBpbnRvIGFueSBv ZiB0aGUgYWx0ZXJuYXRpdmVzIHNvIGZhcg0KLSBHQVVMQSAoQ29sb21iaWEpIC0+IGRvZXMgbm90 IHNlZW0gdG8gZml0IGludG8gYW55IG9mIHRoZSBhbHRlcm5hdGl2ZXMgc28gZmFyDQoNCkZvciB0 aG9zZSBlbWVyZ2VuY3kgc2VydmljZXMgYWJvdmUgbm90IGZpdHRpbmcgaW50byBhbnkgb2YgdGhl IGFsdGVybmF0aXZlcywgaG93IHNob3VsZCB0aGV5IGJlIGV4cHJlc3NlZCBpbiBhbiBlbWVyZ2Vu Y3kgc2VydmljZSBVUk4/IERvIHdlIGFzc3VtZSBJQU5BIHdpbGwgcmVnaXN0ZXIgdGhlbSB0b28/ DQoNCktpbmQgcmVnYXJkcw0KDQpJdm8gU2VkbGFjZWsNCg0KDQpUaGlzIENvbW11bmljYXRpb24g aXMgQ29uZmlkZW50aWFsLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJh c2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0IHd3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xh aW1lcjxodHRwOi8vd3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyPg0KDQpGcm9tOiBl Y3JpdC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnPiBbbWFp bHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmc+ XSBPbiBCZWhhbGYgT2YgRGFuIE1vbmdyYWluLCBlbmcuDQpTZW50OiAxOC4gcHJvc2luY2UgMjAx MiAxNjozNQ0KVG86IGVjcml0QGlldGYub3JnPG1haWx0bzplY3JpdEBpZXRmLm9yZz4NCg0KU3Vi amVjdDogUmU6IFtFY3JpdF0gV2hhdCBpcyB0aGUgbW9zdCBhcHByb3ByaWF0ZSBtZXRob2QgZm9y IHJlZ2lzdGVyaW5nIG5ldyBzdWItc2VydmljZXMgb2YgdXJuOnNlcnZpY2U6c29zDQoNCkluc3Rl YWQgb2YgdHJ5aW5nIHRvIGNvbWUgdXAgd2l0aCB0aGUgcHJvcGVyIG5vbWVuY2xhdHVyZSBmb3Ig dGhlIGp1cmlzZGljdGlvbiB0byBiZSB1c2VkIGluIHRoZSBTZXJ2aWNlIFVSTiwgd2h5IG5vdCB1 dGlsaXplIHRoZSBub21lbmNsYXR1cmUgc3BlY2lmaWVkIGluIENpdmljIEFkZHJlc3NlcyAoUkZD IDQxMTkpOg0Kc29zLnBvbGljZS5jb3VudHJ5IGZvciBwb2xpY2Ugc2VydmljZXMgYXQgdGhlIGNv dW50cnkvbmF0aW9uYWwvZmVkZXJhbC9ldGMgbGV2ZWwNCnNvcy5wb2xpY2UuQTEgZm9yIHBvbGlj ZSBzZXJ2aWNlcyBhdCB0aGUgc3RhdGUvcHJvdmluY2UvcmVnaW9uL3ByZWZlY3R1cmUvZXRjIGxl dmVsDQpzb3MucG9saWNlLkEyIGZvciBwb2xpY2Ugc2VydmljZXMgYXQgdGhlIGNvdW50eS9wYXJp c2gvZ3VuL2Rpc3RyaWN0L2V0YyBsZXZlbA0Kc29zLnBvbGljZS5BMyBmb3IgcG9saWNlIHNlcnZp Y2VzIGF0IHRoZSBjaXR5L3Rvd25zaGlwL3NoaS9ldGMgbGV2ZWwNCnNvcy5wb2xpY2UuQTQgZm9y IHBvbGljZSBzZXJ2aWNlcyBhdCB0aGUgY2l0eSBkaXZpc2lvbi9ib3JvdWdoL2NpdHkgZGlzdHJp Y3Qvd2FyZC9jaG91L2V0YyBsZXZlbA0Kc29zLnBvbGljZS5BNSBmb3IgcG9saWNlIHNlcnZpY2Vz IGF0IHRoZSBuZWlnaGJvcmhvb2QvYmxvY2svZXRjIGxldmVsDQoNClRoaXMgd2F5IHdlIGF2b2lk IGhhdmluZyB0byBwaWNrIGEgdGVybSB0aGF0IGhhcyBubyBhcHBsaWNhYmlsaXR5IGluIGNlcnRh aW4gY291bnRyaWVzLg0KDQpUaGFueCwNCkRhbg0KDQpPbiAxNC8xMi8yMDEyIDk6MTIgQU0sIFJv c2VuLCBCcmlhbiB3cm90ZToNCkkgaGF2ZSBubyBwcm9ibGVtIHVzaW5nICJuYXRpb25hbCIgaW5z dGVhZCBvZiAiZmVkZXJhbCIuDQoiU3RhdGUiIGFuZCAiUHJvdmluY2UiIGFyZSBlcXVpdmFsZW50 LiAgU29tZSBjb3VudHJpZXMgaGF2ZSBvbmUsIHNvbWUgaGF2ZSB0aGUgb3RoZXIuICBJIGRvbid0 IHRoaW5rIHRoZXJlIGFyZSBhbnkgd2l0aCBib3RoLiAgU29tZSBoYXZlIG5laXRoZXIgb2YgY291 cnNlLg0KDQpJJ2QgcHJlZmVyIG5vdCB0byBoYXZlIG5hdGlvbi1zcGVjaWZpYyB2YWx1ZXMuDQoN CkJyaWFuDQpPbiBEZWMgMTQsIDIwMTIsIGF0IDM6NDggQU0sIEl2byBTZWRsYWNlayA8aXZvLnNl ZGxhY2VrQGVyaWNzc29uLmNvbTxtYWlsdG86aXZvLnNlZGxhY2VrQGVyaWNzc29uLmNvbT4+IHdy b3RlOg0KDQpIZWxsbywNCg0KdGhhbmsgeW91IGZvciB5b3VyIG1haWwuDQoNCj4gSSdkIHN1cHBv cnQgYW5vdGhlciAob3B0aW9uYWwpIGxldmVsIG9mIHBvbGljZSB3aXRoIGF0IGxlYXN0IDQgdmFs dWVzLg0KPg0KPiBQZXJoYXBzICJsb2NhbCIvInJlZ2lvbmFsIi8icHJvdmluY2lhbCIvImZlZGVy YWwiDQoNCmlmIEkgdW5kZXJzdG9vZCBjb3JyZWN0bHksIHlvdSBwcm9wb3NlIHRoYXQ6DQotIHVy bjpzZXJ2aWNlOnNvcy5sb2NhbCwNCi0gdXJuOnNlcnZpY2U6c29zLnJlZ2lvbmFsLA0KLSB1cm46 c2VydmljZTpzb3MucHJvdmluY2lhbCwNCi0gdXJuOnNlcnZpY2U6c29zLmZlZGVyYWwNCmFyZSBy ZWdpc3RlcmVkLiBpZiBJIG1pc3VuZGVyc3Rvb2QsIHBsZWFzZSBjb3JyZWN0IG1lLg0KDQp1cm46 c2VydmljZTpzb3MubG9jYWwgd291bGQgbWFwIHdlbGwgdG8gdGhlIGVtZXJnZW5jeSBzZXJ2aWNl IHByb3ZpZGVkIGJ5IHRoZSBtdW5pY2lwYWwgcG9saWNlIGluIHRoZSBDemVjaCByZXB1YmxpYy4N Cg0KSG93ZXZlciwgdGhlIGVtZXJnZW5jeSBzZXJ2aWNlIHByb3ZpZGVkIGJ5IHRoZSBuYXRpb25h bCBwb2xpY2UgaW4gdGhlIEN6ZWNoIHJlcHVibGljIGlzIG5vdCBlYXNpbHkgbWFwcGVkIHRvIGFu eSBvZiB0aGUgdmFsdWVzOg0KLSBDemVjaCByZXB1YmxpYyBoYXMgcHJvdmluY2VzICgia3JhaiIp IGJ1dCB0aGUgcHJvdmluY2VzIChzbyBmYXIpIGRvIG5vdCBoYXZlIHRoZWlyIG93biBwb2xpY2Ug Zm9yY2UuDQotIEN6ZWNoIHJlcHVibGljIGlzIG5vdCBhIGZlZGVyYXRpb24gc28gImZlZGVyYWwi IGRvZXMgbm90IGZpdCBlaXRoZXIuDQoNClBlcmhhcHMgdGhlIGZvbGxvd2luZyBzaG91bGQgYmUg ZGVmaW5lZDogdXJuOnNlcnZpY2U6c29zLmxvY2FsLCB1cm46c2VydmljZTpzb3MucmVnaW9uYWws IHVybjpzZXJ2aWNlOnNvcy5zdGF0ZSwgdXJuOnNlcnZpY2U6c29zLmZlZGVyYWwNCg0KQWx0ZXJu YXRpdmVseSwgc3VicmVnaXN0cmllcyBjYW4gYmUgY3JlYXRlZCBmb3IgZWFjaCBjb3VudHJ5IHdo ZXJlIHRoZSByZWd1bGF0b3Igb2YgdGhlIGNvdW50cnkgd291bGQgbWFuYWdlIHRoZSBlbWVyZ2Vu Y3kgc2VydmljZSBVUk5zIGZvciB0aGUgY291bnRyeSBzcGVjaWZpYyBlbWVyZ2VuY3kgc2Vydmlj ZXMgKCBodHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0VtZXJnZW5jeV90ZWxlcGhvbmVfbnVt YmVyIHNlZW1zIHRvIGxpc3QgcXVpdGUgYSBsb3Qgb2YgdGhvc2UgKQ0KDQpLaW5kIHJlZ2FyZHMN Cg0KSXZvIFNlZGxhY2VrDQoNCg0KVGhpcyBDb21tdW5pY2F0aW9uIGlzIENvbmZpZGVudGlhbC4g V2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMg c2V0IG91dCBhdCB3d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXI8aHR0cDovL3d3dy5l cmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lcj4NCg0KRnJvbTogUm9zZW4sIEJyaWFuIFttYWls dG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXpdDQpTZW50OiAxMy4gcHJvc2luY2UgMjAxMiAxNTo0 MQ0KVG86IEl2byBTZWRsYWNlaw0KQ2M6IGVjcml0QGlldGYub3JnPG1haWx0bzplY3JpdEBpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbRWNyaXRdIFdoYXQgaXMgdGhlIG1vc3QgYXBwcm9wcmlhdGUg bWV0aG9kIGZvciByZWdpc3RlcmluZyBuZXcgc3ViLXNlcnZpY2VzIG9mIHVybjpzZXJ2aWNlOnNv cw0KDQpUaGF0IGlzc3VlIG9jY3VycyBpbiBzZXZlcmFsIG90aGVyIGNvdW50cmllcy4NClRoZXJl IGFyZSBvZnRlbiAzIG9yIG1vcmUgcG9saWNlIGFnZW5jaWVzIHNlcnZpbmcgYW4gYXJlYS4gIElu IG15IGhvbWUsIHRoZXJlIGFyZSBmb3VyOg0KYSkgQSBsb2NhbCAodG93bnNoaXApIHBvbGljZQ0K YikgQSBjb3VudHkgcG9saWNlIGFnZW5jeSB0aGF0IHJlc3BvbmRzIHRvIHNvbWUgdW5jb21tb24g ZXZlbnRzDQpjKSBBIHN0YXRlIHBvbGljZSBhZ2VuY3ksIHdoaWNoIGFsc28gaGFzIGp1cmlzZGlj dGlvbiBpbiBzb21lIGNpcmN1bXN0YW5jZXMNCmQpIFRoZSBmZWRlcmFsIHBvbGljZSAoRkJJKQ0K DQpXaGlsZSB3ZSBkbyBoYXZlIGEgc2luZ2xlIG51bWJlciwgaWYgeW91IGV4cGxpY2l0bHkgd2Fu dGVkIHRoZSBzdGF0ZSBwb2xpY2UsIHRoZXJlIGlzIG5vIHdheSB0byBnZXQgdG8gdGhlbS4NCg0K SSdkIHN1cHBvcnQgYW5vdGhlciAob3B0aW9uYWwpIGxldmVsIG9mIHBvbGljZSB3aXRoIGF0IGxl YXN0IDQgdmFsdWVzLg0KDQpQZXJoYXBzICJsb2NhbCIvInJlZ2lvbmFsIi8icHJvdmluY2lhbCIv ImZlZGVyYWwiDQoNCkJyaWFuDQpPbiBEZWMgMTMsIDIwMTIsIGF0IDg6MjIgQU0sIEl2byBTZWRs YWNlayA8aXZvLnNlZGxhY2VrQGVyaWNzc29uLmNvbTxtYWlsdG86aXZvLnNlZGxhY2VrQGVyaWNz c29uLmNvbT4+IHdyb3RlOg0KDQpIZWxsbywNCg0KaW4gdGhlIEN6ZWNoIHJlcHVibGljLCB0aGUg bmF0aW9uYWwgcmVndWxhdG9yIGRlZmluZWQgdHdvIHBvbGljZSByZWxhdGVkIGVtZXJnZW5jeSBz ZXJ2aWNlczoNCkEpIGVtZXJnZW5jeSBzZXJ2aWNlIHByb3ZpZGVkIGJ5IHRoZSBuYXRpb25hbCBw b2xpY2UgKG51bWJlciAxNTggaW4gdGhlIHB1YmxpYyBzd2l0Y2hlZCB0ZWxlcGhvbmUgbmV0d29y ayk7IGFuZA0KQikgZW1lcmdlbmN5IHNlcnZpY2UgcHJvdmlkZWQgYnkgdGhlIG11bmljaXBhbCBw b2xpY2UgKG51bWJlciAxNTYgaW4gdGhlIHB1YmxpYyBzd2l0Y2hlZCB0ZWxlcGhvbmUgbmV0d29y aykuDQoNClRoZSByZWd1bGF0aW9uIGlzIGh0dHA6Ly9hcGxpa2FjZS5tdmNyLmN6L2FyY2hpdjIw MDgvc2JpcmthLzIwMDcvc2IwNDMtMDcucGRmIHdoaWNoIGxpc3RzIHRoZSBudW1iZXJzIDE1NiBh bmQgMTU4IGluIHNlY3Rpb24gNC41LiB3aXRoIG5vdGUgMikgd2hpY2ggc3RhdGVzICLEjMOtc2xv IGplIG7DoXJvZG7DrW0gxI3DrXNsZW0gcHJvIHTDrXPFiG92w6kgdm9sw6Fuw60iICg9IHRoZSBu dW1iZXIgaXMgYSBuYXRpb25hbCBudW1iZXIgZm9yIGVtZXJnZW5jeSBjYWxscykuDQoNCklzIGl0 IGFwcHJvcHJpYXRlIHRvIHJlZ2lzdGVyIHRoZSBmb2xsb3dpbmcgVVJOcyBmb3IgdGhvc2Ugc2Vy dmljZXMgd2l0aCBJQU5BPw0KLSB1cm46c2VydmljZTpzb3MucG9saWNlLm5hdGlvbmFsIC0gVGhl ICdwb2xpY2UubmF0aW9uYWwnIHNlcnZpY2UgcmVmZXJzIHRvIHRoZSBwb2xpY2UgZGVwYXJ0bWVu dCBvciBvdGhlciBsYXcgZW5mb3JjZW1lbnQgYXV0aG9yaXRpZXMgb2YgdGhlIG5hdGlvbmFsIGdv dmVybm1lbnQuDQotIHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UubXVuaWNpcGFsIC0gVGhlICdwb2xp Y2UubXVuaWNpcGFsJyBzZXJ2aWNlIHJlZmVycyB0byB0aGUgcG9saWNlIGRlcGFydG1lbnQgb3Ig b3RoZXIgbGF3IGVuZm9yY2VtZW50IGF1dGhvcml0aWVzIG9mIHRoZSBtdW5pY2lwYWwgYXV0aG9y aXRpZXMuDQoNCk9yIHNob3VsZCB0aG9zZSBiZSByZWdpc3RlcmVkIHdpdGggYSBwcmVmaXggaW5k aWNhdGluZyB0aGF0IHRob3NlIGFyZSBhcHBsaWNhYmxlIHRvIEN6ZWNoIHJlcHVibGljIG9ubHks IGFzIG90aGVyIGNvdW50cmllcyBtYXkgaGF2ZSBzaW1pbGFyIChidXQgbm90IG5lY2Vzc2FyaWx5 IGlkZW50aWNhbCkgc2VydmljZXM6DQotIHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UuY3plY2gubmF0 aW9uYWwgLSBUaGUgJ3BvbGljZS5jemVjaC5uYXRpb25hbCcgc2VydmljZSByZWZlcnMgdG8gdGhl IHBvbGljZSBkZXBhcnRtZW50IG9yIG90aGVyIGxhdyBlbmZvcmNlbWVudCBhdXRob3JpdGllcyBv ZiB0aGUgbmF0aW9uYWwgZ292ZXJubWVudC4NCi0gdXJuOnNlcnZpY2U6c29zLnBvbGljZS5jemVj aC5tdW5pY2lwYWwgLSBUaGUgJ3BvbGljZS5jemVjaC5tdW5pY2lwYWwnIHNlcnZpY2UgcmVmZXJz IHRvIHRoZSBwb2xpY2UgZGVwYXJ0bWVudCBvciBvdGhlciBsYXcgZW5mb3JjZW1lbnQgYXV0aG9y aXRpZXMgb2YgbXVuaWNpcGFsIGF1dGhvcml0aWVzLg0KDQpJIGFzc3VtZSB0aGlzIHF1ZXN0aW9u IGJlbG9uZ3MgdG8gSUFOQSwgYnV0IGFzIHRoZSBleHBlcnQgcmV2aWV3ZXIgbW9zdCBsaWtlbHkg d2lsbCBiZSBmcm9tIHRoZSBFQ1JJVCwgSSBhbSBzZW5kaW5nIGl0IGhlcmUuDQoNCktpbmQgcmVn YXJkcw0KDQpJdm8gU2VkbGFjZWsNCg0KDQpUaGlzIENvbW11bmljYXRpb24gaXMgQ29uZmlkZW50 aWFsLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0 ZXJtcyBzZXQgb3V0IGF0d3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyPGh0dHA6Ly93 d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KRWNyaXQgbWFpbGluZyBsaXN0DQpFY3JpdEBpZXRm Lm9yZzxtYWlsdG86RWNyaXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2Vjcml0DQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCkVjcml0IG1haWxpbmcgbGlzdA0KDQpFY3JpdEBpZXRmLm9yZzxt YWlsdG86RWNyaXRAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZWNyaXQNCg0KDQoNCg== --_000_5A55A45AE77F5941B18E5457ECAC818801214077118CSISPE7MB1co_ 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 MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0 ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJs dWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgdGhpbmsgSSBhbSBtaXNzaW5nIHNvbWV0aGluZyBo ZXJlLCBBMSBpcyBwYXJ0IG9mIHRoZSBsb2NhdGlvbiwgc28gd2h5IGRvZXMgaXQgbmVlZCB0byBi ZSBpbiB0aGUgVVJOIGF0IGFsbD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QXMgZmFyIGFzIEkgdW5kZXJzdGFuZCBjdXJyZW50 IGRlcGxveW1lbnRzLCB0aGV5IHVzZSB0aGUgVVJOIHRvIHNlbGVjdCBhIGxheWVyIGluIHRoZSBH SVMgdGhhdCBjb3JyZXNwb25kcyB0byB0aGUgc2VydmljZSB0eXBlLCBhbmQgdGhlbiB1c2UgZ2Vv Z3JhcGhpYyBib3VuZGFyaWVzIHdpdGhpbiB0aGF0IGxheWVyIHRvIHNlbGVjdCB0aGUgZmluYWwg ZGVzdGluYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxl PSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIic+IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzplY3JpdC1ib3VuY2Vz QGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPkRhbiBNb25ncmFpbjxicj48Yj5TZW50Ojwv Yj4gVHVlc2RheSwgMTkgRmVicnVhcnkgMjAxMyA3OjMwIEFNPGJyPjxiPlRvOjwvYj4gSXZvIFNl ZGxhY2VrPGJyPjxiPkNjOjwvYj4gZWNyaXRAaWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFJl OiBbRWNyaXRdIFdoYXQgaXMgdGhlIG1vc3QgYXBwcm9wcmlhdGUgbWV0aG9kIGZvciByZWdpc3Rl cmluZyBuZXcgc3ViLXNlcnZpY2VzIG9mIHVybjpzZXJ2aWNlOnNvczxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Tb3JyeSBmb3IgcmVzcG9uZGlu ZyBsYXRlIHRvIHRoaXMgdGhyZWFkLCBpdCBraW5kYSBmZWxsIGludG8gYSZuYnNwOyBjcmFja+KA piZuYnNwOyBUaGUgY3VycmVudCB0aHJlYWQgcmVtaW5kZWQgbWUgdG8gY2hlY2sgdGhpcyBvbGQg dGhyZWFk4oCmPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+WW91IGFyZSBpbmRpY2F0aW5nIHRoYXQg d2UgbmVlZCB0byByZWdpc3RlciA3NyBTZXJ2aWNlIFVSTiAoMTEgc2VydmljZSBzdWJ0eXBlcyAq IDcganVyaXNkaWN0aW9uIHR5cGVzIGJhc2VkIG9uIFJGQyA0MTE5KS4mbmJzcDsgSSBkbyBub3Qg cmVjb21tZW5kIHRoYXQgd2UgY3JlYXRlIHNvIG1hbnkgcmVnaXN0cmF0aW9ucy4mbmJzcDsgSW5z dGVhZCwgd2Ugc2hvdWxkIGFsbG93IGEgc2VydmljZSBVUk4gdG8gYmUgc3VmZml4ZWQgd2l0aCBh IGp1cmlzZGljdGlvbmFsIHNjb3BlLiZuYnNwOyBTbyB0aGUgZm9sbG93aW5nIFNlcnZpY2UgVVJO IGFyZSBhbGwgdmFsaWQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8n PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+dXJuOnNlcnZpY2U6c29zLnBv bGljZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPnVybjpzZXJ2aWNlOnNvcy5wb2xpY2UudHJhZmZpYzwvc3Bhbj48bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPnVybjpz ZXJ2aWNlOnNvcy5wb2xpY2UuQTE8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz51cm46c2VydmljZTpzb3MucG9saWNlLnRyYWZm aWMuQTE8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5RdWVzdGlvbiBpcywgZG8gd2Ugd2FudCB0byBs ZWF2ZSBqdXJpc2RpY3Rpb25hbCBzY29wZSB0byBvbmx5IGJlIGFwcGxpY2FibGUgdG8gcG9saWNl IGJyYW5jaCBvciBhbnkgU2VydmljZSBVUk4/ICZuYnNwO0nigJlkIHNheSB0aGUgbGF0dGVyIGFz IGl0IGlzIGFsd2F5cyB1cCB0byB0aGUgTG9TVCBzZXJ2aWNlIHByb3Zpc2lvbmluZyAoYmFzZWQg b24gbG9jYWwgcG9saWN5KSB0byBkZXRlcm1pbmUgd2hhdCBpcyBsb2NhbGx5IGFjY2VwdGFibGUu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8n PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhhbngsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+RGFuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9uIFRodSwgRGVjIDIw LCAyMDEyIGF0IDI6NTMgQU0sIEl2byBTZWRsYWNlayAmbHQ7PGEgaHJlZj0ibWFpbHRvOml2by5z ZWRsYWNla0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5pdm8uc2VkbGFjZWtAZXJpY3Nz b24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPkhlbGxvLDwvc3Bhbj48bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+ dGhhbmtzIGZvciB0aGUgcHJvcG9zYWwgYW5kIGZvciB0aGUgY2hlY2sgb2YgdGhlIENhbmFkaWFu IHVzYWdlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtj b2xvcjojQzA1MDREJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+TGV0J3MgdHJ5IHRvIGFzc2lnbiB0aGUgcHJvcG9z ZWQgc2VydmljZSBVUk5zIHRvIHRoZSBXaWtpcGVkaWEgbGlzdDo8L3NwYW4+PG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+LSBtdW5pY2lwYWwg cG9saWNlIChDemVjaCBSZXB1YmxpYywgUG9sYW5kKSAtJmd0OyB1cm46c2VydmljZTpzb3MucG9s aWNlLkEzIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtj b2xvcjojQzA1MDREJz4tIHRvdXJpc3QgcG9saWNlIChFZ3lwdCwgR3JlZWNlKSAtJmd0OyB1cm46 c2VydmljZTpzb3MucG9saWNlLnRvdXJpc3Q8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+LSB0cmFmZmljIHBvbGljZSAoRWd5cHQs IFN1ZGFuLCBJbmRpYSwgUGFraXN0YW4sIFNhdWRpIEFyYWJpYSwgQWxiYW5pYSwgQXJtZW5pYSwg QXplcmJhaWphbikgLSZndDsgdXJuOnNlcnZpY2U6c29zLnBvbGljZS50cmFmZmljPC9zcGFuPjxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPi0g c3RhdGUgcG9saWNlIChJdGFseSkgLSZndDsgdXJuOnNlcnZpY2U6c29zLnBvbGljZS5jb3VudHJ5 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiND MDUwNEQnPi0gY3VzdG9tcy9maW5hbmNpYWwgUG9saWNlIChJdGFseSkgLSZndDsgZG9lcyBub3Qg bWF0Y2ggLSB3ZSBwcm9iYWJseSBuZWVkIHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UuZmluYW5jaWFs IChuZXcpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2Nv bG9yOiNDMDUwNEQnPi0gZ2VuZGFybWVyaWUgKFJvbWFuaWEpIC0mZ3Q7IGRvZXMgbm90IG1hdGNo IC0gd2UgcHJvYmFibHkgbmVlZCB1cm46c2VydmljZTpzb3MucG9saWNlLm1pbGl0YXJ5IChuZXcp PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiND MDUwNEQnPi0gbG9jYWwgcG9saWNlIChTcGFpbikgLSZndDsgdXJuOnNlcnZpY2U6c29zLnBvbGlj ZS5BMzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xv cjojQzA1MDREJz4tIENhdGFsYW4gcG9saWNlIChTcGFpbikgLSZndDsgdXJuOnNlcnZpY2U6c29z LnBvbGljZS5BMSAoYSBwZXJzb24gd2l0aCBzcGFuaXNoL2NhdGFsYW4gYmFja2dyb3VuZCBzaG91 bGQgY2hlY2spPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi O2NvbG9yOiNDMDUwNEQnPi0gY2l2aWwgZ3VhcmQgKFNwYWluKSAtJmd0OyBkb2VzIG5vdCBtYXRj aCAtIHdlIHByb2JhYmx5IG5lZWQgdXJuOnNlcnZpY2U6c29zLnBvbGljZS5taWxpdGFyeSAobmV3 KSAoYSBwZXJzb24gd2l0aCBzcGFuaXNoL2NhdGFsYW4gYmFja2dyb3VuZCBzaG91bGQgY2hlY2sp PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiND MDUwNEQnPi0gUHJvdmluY2lhbCBQb2xpY2UgKENhbmFkYSkgLSB1cm46c2VydmljZTpzb3MucG9s aWNlLkExPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2Nv bG9yOiNDMDUwNEQnPi0gU8O7cmV0w6kgZHUgUXXDqWJlYyAoQ2FuYWRhKSAtIHVybjpzZXJ2aWNl OnNvcy5wb2xpY2UuQTE8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7Y29sb3I6I0MwNTA0RCc+LSBmZWRlcmFsIGhpZ2h3YXkgcG9saWNlIChCcmF6aWwpIC0m Z3Q7IHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UudHJhZmZpYzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4tIGZlZGVyYWwgcG9saWNl IChCcmF6aWwpIC0mZ3Q7IHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UuY291bnRyeTwvc3Bhbj48bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4tIGNp dmlsIHBvbGljZSAoQnJhemlsKSAtJmd0OyBkb2VzIG5vdCBtYXRjaCAtIHdlIHByb2JhYmx5IG5l ZWQgdXJuOnNlcnZpY2U6c29zLnBvbGljZS5jaXZpbCAobmV3KTwvc3Bhbj48bzpwPjwvbzpwPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4tIHN0YXRlIGhpZ2h3 YXkgcG9saWNlIChCcmF6aWwpIC0mZ3Q7IHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UuQTEudHJhZmZp Yzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjoj QzA1MDREJz4tIEdBVUxBIChDb2xvbWJpYSkgLSZndDsgZG9lcyBub3QgbWF0Y2ggLSB3ZSBwcm9i YWJseSBuZWVkIHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UuYW50aWtpZG5hcHBpbmcgKG5ldyk8L3Nw YW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0 RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi O2NvbG9yOiNDMDUwNEQnPkkuZS4gd2Ugd291bGQgbmVlZCBhZGRpdGlvbmFsbHk6PC9zcGFuPjxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPi0g dXJuOnNlcnZpY2U6c29zLnBvbGljZS5maW5hbmNpYWw8L3NwYW4+PG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+LSB1cm46c2VydmljZTpzb3Mu cG9saWNlLm1pbGl0YXJ5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8n PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiO2NvbG9yOiNDMDUwNEQnPi0gdXJuOnNlcnZpY2U6c29zLnBvbGljZS5jaXZpbDwvc3Bh bj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDRE Jz4tIHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UuYW50aWtpZG5hcHBpbmc8L3NwYW4+PG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUw NEQnPklmIEkgdW5kZXJzdG9vZCBpdCBjb3JyZWN0bHksIGFsbCB0b2dldGhlciwgd2Ugd291bGQg bmVlZCA3NyBwb2xpY2UgcmVsYXRlZCBlbWVyZ2VuY3kgc2VydmljZSBVUk5zID0gKDcgKHNwZWNp YWxpemVkIHBvbGljZSBjb3JwIGJlbG93KSArIDQgKGFkZGl0aW9uYWwgYWJvdmUpKSAqIDcgKG5v bWVuY2xhdHVyZSBzcGVjaWZpZWQgaW4gQ2l2aWMgQWRkcmVzc2VzIChSRkMgNDExOSkpLiBTZWVt cyBxdWl0ZSBhIGxvdC5Nb3Jlb3ZlciwgYSByZWd1bGF0b3IgaW4gYSBjb3VudHJ5IGNhbiBkZWZp bmUgYSBuZXcgdHlwZSBvZiBhIHBvbGljZSByZWxhdGVkIGVtZXJnZW5jeSBzZXJ2aWNlIC0gaXQg ZGVwZW5kcyBvbiBob3cgdGhlIGxhdyBlbmZvcmNlbWVudCBpcyBzdHJ1Y3R1cmUgaW4gdGhlIGNv dW50cnkuIFRoZW4gdGhlIGxpc3Qgd2lsbCBncm93IGV2ZW4gbW9yZS4gTWF5YmUgaXQgd291bGQg cmVhbGx5IGJlIGJldHRlciB0byBsZXQgcmVndWxhdG9ycyB0byBtYW5hZ2UgcGVyLWNvdW50cnkg c3ViLXJlZ2lzdHJpZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPktpbmQgcmVnYXJkczwvc3Bh bj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDRE Jz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 Y29sb3I6I0MwNTA0RCc+SXZvIFNlZGxhY2VrPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0 RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFu IHN0eWxlPSdmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzMzMzMzMyc+VGhpcyBDb21tdW5pY2F0aW9uIGlzIENvbmZpZGVudGlhbC4gV2Ugb25s eSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91 dCBhdCA8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3d3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xh aW1lciIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSJodHRwOi8vd3d3LmVyaWNzc29uLmNvbS9lbWFp bF9kaXNjbGFpbWVyIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiJz53d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXI8L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzMzMzMzMyc+IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz4gRGFuIE1vbmdyYWluIDwvc3Bhbj48YSBocmVmPSJtYWlsdG86W21haWx0bzpk YW5AbW9uZ3JhaW4ub3JnXSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+W21haWx0bzpkYW5AbW9u Z3JhaW4ub3JnXTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gPGJyPjxiPlNlbnQ6PC9iPiAxOS4gcHJvc2lu Y2UgMjAxMiAxNjowMDxicj48Yj5Ubzo8L2I+IEl2byBTZWRsYWNlazxicj48Yj5DYzo8L2I+IDwv c3Bhbj48YSBocmVmPSJtYWlsdG86ZWNyaXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiInPmVjcml0QGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+PGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW0Vjcml0XSBX aGF0IGlzIHRoZSBtb3N0IGFwcHJvcHJpYXRlIG1ldGhvZCBmb3IgcmVnaXN0ZXJpbmcgbmV3IHN1 Yi1zZXJ2aWNlcyBvZiB1cm46c2VydmljZTpzb3M8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+ PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQnPkkgYWxzbyByZWNvbW1lbmQgd2UgY3JlYXRlIHB1cnBvc2Uga2V5d29y ZHMgaW4gb3JkZXIgdG8gcmVhY2ggYSBzcGVjaWFsaXplZCBwb2xpY2UgY29ycC4mbmJzcDsgU3Vj aCBhczo8YnI+c29zLnBvbGljZS5kcnVnczxicj5zb3MucG9saWNlLnRyYWZmaWM8YnI+c29zLnBv bGljZS5maXJlYXJtczxicj5zb3MucG9saWNlLmFsY29ob2w8YnI+c29zLnBvbGljZS50b2JhY2Nv PGJyPnNvcy5wb2xpY2UudG91cmlzdDxicj5zb3MucG9saWNlLmJvcmRlcjxicj48YnI+VGhlIGFi b3ZlIGtleXdvcmRzIGNhbiBiZSB1dGlsaXplZCB3aXRoIHRlcnJpdG9yaWFsIGRlc2lnbmF0aW9u cyBpbiBvcmRlciB0byBzcGVjaWZ5IGEgcGFydGljdWxhciBzZXJ2aWNlIGlmIG9mZmVyZWQgYnkg bXVsdGlwbGUganVyaXNkaWN0aW9ucy4mbmJzcDsgRm9yIGV4YW1wbGUgaW4gdGhlIFVTOjxicj5z b3MucG9saWNlLmNvdW50cnkuZHJ1Z3MgY291bGQgYmUgdXNlZCB0byByZWFjaCB0aGUgREVBIHdo ZXJlYXM8YnI+c29zLnBvbGljZS5BMy5kcnVncyBjb3VsZCBiZSB1c2VkIHRvIHJlYWNoIHRoZSBu YXJjb3RpY3MgZGl2aXNpb24gb2YgdGhlIGNpdHkgcG9saWNlLjxicj48YnI+SSBjYW4gYW5zd2Vy IGZvciBDYW5hZGE6PGJyPnNvcy5wb2xpY2UuY291bnRyeSB3b3VsZCBiZSB0byByZWFjaCB0aGUg Um95YWwgQ2FuYWRpYW4gTW91bnRhaW4gUG9saWNlIChSQ01QKTxicj5JbiB0aGUgcHJvdmluY2Vz IG9mIE9udGFyaW8gYW5kIFF1w6liZWMgd2hpY2ggaGF2ZSBwcm92aW5jYWwgcG9saWNlcywgdGhl biBzb3MucG9saWNlLkExIGluIE9udGFyaW8gd291bGQgcmVhY2ggdGhlIE9udGFyaW8gUHJvdmlu Y2lhbCBQb2xpY2UgKE9QUCkgYW5kIHNvcy5wb2xpY2UuQTEgaW4gUXXDqWJlYyB3b3VsZCByZWFj aCB0aGUgU3VyZXTDqSBkdSBRdcOpYmVjIChTUSkuPGJyPkluIENhbmFkYSB3ZSBkbyBub3QgaGF2 ZSBhIHBvbGljZSBzZXJ2aWNlIGF0IHRoZSBjb3VudHkgbGV2ZWwgKHdlIGRvIGhhdmUgc2hlcmlm ZiBkZXBhcnRtZW50cyBidXQgdGhleSBhcmUgbW9yZSBmb3IgY291cnQgYW5kIGphaWwgc2VjdXJp dHkpLjxicj5JbiBPbnRhcmlvIGFuZCBRdcOpYmVjLCBhIGNpdHkgbWF5IGhhdmUgaXRzIHBvbGlj ZSBzZXJ2aWNlIG90aGVyd2lzZSB0aGUgcHJvdmluY2lhbCBwb2xpY2Ugb2ZmZXJzIHRoZSBzZXJ2 aWNlLiZuYnNwOyBJbiB0aGUgcmVzdCBvZiBDYW5hZGEsIGEgY2l0eSBtYXkgaGF2ZSBpdHMgcG9s aWNlIHNlcnZpY2Ugb3RoZXJ3aXNlIHRoZSBSQ01QIG9mZmVycyB0aGUgc2VydmljZS48YnI+PGJy PlRoYW54LDxicj5EYW48bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPk9u IFdlZCwgRGVjIDE5LCAyMDEyIGF0IDc6MDIgQU0sIEl2byBTZWRsYWNlayAmbHQ7PGEgaHJlZj0i bWFpbHRvOml2by5zZWRsYWNla0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5pdm8uc2Vk bGFjZWtAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PGRpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPkhlbGxvLDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6I0MwNTA0RCc+dGhhbmtzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+Ym90aCBvcHRpb25zIChEYW4n cyBhbmQgQnJpYW4ncykgc2VlbWVkIHRvIHdvcmsgZm9yIHRoZSBlbWVyZ2VuY3kgc2VydmljZXMg b2YgdGhlIHBvbGljZSBmb3JjZXMgaW4gdGhlIEN6ZWNoIHJlcHVibGljLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0Mw NTA0RCc+Rm9yIGNvbXBsZXRlbmVzcywgSSBhbHNvIGNoZWNrZWQgdGhlIGVtZXJnZW5jeSBzZXJ2 aWNlcyBvZiB0aGUgcG9saWNlIGZvcmNlcyBvZiBvdGhlciBjb3VudHJpZXMuIFdpa2lwZWRpYSAo PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvRW1lcmdlbmN5X3Rl bGVwaG9uZV9udW1iZXIiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+aHR0cDovL2VuLndpa2lwZWRp YS5vcmcvd2lraS9FbWVyZ2VuY3lfdGVsZXBob25lX251bWJlcjwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6I0MwNTA0RCc+KSBsaXN0cyB0aGUgZm9sbG93aW5nIG9uIHRvcCBvZiBlbWVyZ2VuY3kgc2Vy dmljZXMgb2YgdGhlIHJlZ3VsYXIgcG9saWNlIGZvcmNlczo8L3NwYW4+PG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+LSBtdW5pY2lwYWwgcG9s aWNlIChDemVjaCBSZXB1YmxpYywgUG9sYW5kKSAtJmd0OyBjYW4gbWFwIHRvIHVybjpzZXJ2aWNl OnNvcy5wb2xpY2UubG9jYWwgb3IgdXJuOnNlcnZpY2U6c29zLnBvbGljZS5BMyA8L3NwYW4+PG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+LSB0 b3VyaXN0IHBvbGljZSAoRWd5cHQsIEdyZWVjZSkgLSZndDsgZG9lcyBub3Qgc2VlbSB0byBmaXQg aW50byBhbnkgb2YgdGhlIGFsdGVybmF0aXZlcyBzbyBmYXI8L3NwYW4+PG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+LSB0cmFmZmljIHBvbGlj ZSAoRWd5cHQsIFN1ZGFuLCBJbmRpYSwgUGFraXN0YW4sIFNhdWRpIEFyYWJpYSwgQWxiYW5pYSwg QXJtZW5pYSwgQXplcmJhaWphbikgLSZndDsgZG9lcyBub3Qgc2VlbSB0byBmaXQgaW50byBhbnkg b2YgdGhlIGFsdGVybmF0aXZlcyBzbyBmYXI8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+LSBzdGF0ZSBwb2xpY2UgKEl0YWx5KSAt Jmd0OyBjYW4gbWFwIHRvIHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UubmF0aW9uYWwgb3IgdXJuOnNl cnZpY2U6c29zLnBvbGljZS5jb3VudHJ5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPi0gY3VzdG9tcy9maW5hbmNpYWwgUG9saWNl IChJdGFseSkgLSZndDsgZG9lcyBub3Qgc2VlbSB0byBmaXQgaW50byBhbnkgb2YgdGhlIGFsdGVy bmF0aXZlcyBzbyBmYXI8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7Y29sb3I6I0MwNTA0RCc+LSBnZW5kYXJtZXJpZSAoUm9tYW5pYSkgLSZndDsgZG9lcyBu b3Qgc2VlbSB0byBmaXQgaW50byBhbnkgb2YgdGhlIGFsdGVybmF0aXZlcyBzbyBmYXI8L3NwYW4+ PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+ LSBsb2NhbCBwb2xpY2UgKFNwYWluKSAtJmd0OyBjYW4gbWFwIHRvIHVybjpzZXJ2aWNlOnNvcy5w b2xpY2UubG9jYWwgb3IgdXJuOnNlcnZpY2U6c29zLnBvbGljZS5BMzwvc3Bhbj48bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4tIENhdGFsYW4g cG9saWNlIChTcGFpbikgLSZndDsgbWF5YmUgdGhpcyBjb3VsZCBtYXAgdG8gdXJuOnNlcnZpY2U6 c29zLnBvbGljZS5yZWdpb25hbCBvciB1cm46c2VydmljZTpzb3MucG9saWNlLkExIGJ1dCBhIHBl cnNvbiB3aXRoIHNwYW5pc2gvY2F0YWxhbiBiYWNrZ3JvdW5kIHNob3VsZCBjaGVjay48L3NwYW4+ PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+ LSBjaXZpbCBndWFyZCAoU3BhaW4pIC0mZ3Q7IGRvZXMgbm90IHNlZW0gdG8gZml0IGludG8gYW55 IG9mIHRoZSBhbHRlcm5hdGl2ZXMgc28gZmFyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPi0gUHJvdmluY2lhbCBQb2xpY2UgKENh bmFkYSkgLSBtYXliZSB0aGlzIGNvdWxkIG1hcCB0byB1cm46c2VydmljZTpzb3MucG9saWNlLnJl Z2lvbmFsIG9yIHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UuQTEgYnV0IGEgcGVyc29uIHdpdGggY2Fu YWRpYW4gYmFja2dyb3VuZCBzaG91bGQgY2hlY2s8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+LSBTw7tyZXTDqSBkdSBRdcOpYmVj IChDYW5hZGEpIC0gbWF5YmUgdGhpcyBjb3VsZCBtYXAgdG8gdXJuOnNlcnZpY2U6c29zLnBvbGlj ZS5yZWdpb25hbCBvciB1cm46c2VydmljZTpzb3MucG9saWNlLkExIGJ1dCBhIHBlcnNvbiB3aXRo IGNhbmFkaWFuIGJhY2tncm91bmQgc2hvdWxkIGNoZWNrPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPi0gZmVkZXJhbCBoaWdod2F5 IHBvbGljZSAoQnJhemlsKSAtJmd0OyBkb2VzIG5vdCBzZWVtIHRvIGZpdCBpbnRvIGFueSBvZiB0 aGUgYWx0ZXJuYXRpdmVzIHNvIGZhcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4tIGZlZGVyYWwgcG9saWNlIChCcmF6aWwpIC0m Z3Q7IGNhbiBtYXAgdG8gdXJuOnNlcnZpY2U6c29zLnBvbGljZS5uYXRpb25hbCBvciB1cm46c2Vy dmljZTpzb3MucG9saWNlLmNvdW50cnk8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+LSBjaXZpbCBwb2xpY2UgKEJyYXppbCkgLSZn dDsgZG9lcyBub3Qgc2VlbSB0byBmaXQgaW50byBhbnkgb2YgdGhlIGFsdGVybmF0aXZlcyBzbyBm YXI8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6 I0MwNTA0RCc+LSBzdGF0ZSBoaWdod2F5IHBvbGljZSAoQnJhemlsKSAtJmd0OyBkb2VzIG5vdCBz ZWVtIHRvIGZpdCBpbnRvIGFueSBvZiB0aGUgYWx0ZXJuYXRpdmVzIHNvIGZhcjwvc3Bhbj48bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4tIEdB VUxBIChDb2xvbWJpYSkgLSZndDsgZG9lcyBub3Qgc2VlbSB0byBmaXQgaW50byBhbnkgb2YgdGhl IGFsdGVybmF0aXZlcyBzbyBmYXI8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPkZvciB0aG9zZSBlbWVyZ2Vu Y3kgc2VydmljZXMgYWJvdmUgbm90IGZpdHRpbmcgaW50byBhbnkgb2YgdGhlIGFsdGVybmF0aXZl cywgaG93IHNob3VsZCB0aGV5IGJlIGV4cHJlc3NlZCBpbiBhbiBlbWVyZ2VuY3kgc2VydmljZSBV Uk4/IERvIHdlIGFzc3VtZSBJQU5BIHdpbGwgcmVnaXN0ZXIgdGhlbSB0b28/PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2Nv bG9yOiNDMDUwNEQnPktpbmQgcmVnYXJkczwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+SXZvIFNlZGxhY2Vr PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiND MDUwNEQnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIjtjb2xvcjojQzA1MDREJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMzMzMzMzMnPlRoaXMgQ29tbXVuaWNhdGlvbiBp cyBDb25maWRlbnRpYWwuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFz aXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQgPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly93d3cuZXJp Y3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXIiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iaHR0cDov L3d3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lciI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZTo4LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+d3d3LmVyaWNzc29uLmNv bS9lbWFpbF9kaXNjbGFpbWVyPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguMHB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMzMzMzMzMnPiA8L3NwYW4+ PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0Mw NTA0RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0n Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxiPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIic+IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+ZWNyaXQtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48 L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz4gW21haWx0bzo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmVjcml0LWJvdW5jZXNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPmVjcml0LWJvdW5jZXNAaWV0Zi5vcmc8 L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIic+XSA8Yj5PbiBCZWhhbGYgT2YgPC9iPkRhbiBNb25ncmFpbiwgZW5n Ljxicj48Yj5TZW50OjwvYj4gMTguIHByb3NpbmNlIDIwMTIgMTY6MzU8YnI+PGI+VG86PC9iPiA8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmVjcml0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiJz5lY3JpdEBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+PGRpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtFY3JpdF0gV2hhdCBp cyB0aGUgbW9zdCBhcHByb3ByaWF0ZSBtZXRob2QgZm9yIHJlZ2lzdGVyaW5nIG5ldyBzdWItc2Vy dmljZXMgb2YgdXJuOnNlcnZpY2U6c29zPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+ PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9w PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+SW5zdGVhZCBvZiB0cnlpbmcgdG8gY29tZSB1cCB3 aXRoIHRoZSBwcm9wZXIgbm9tZW5jbGF0dXJlIGZvciB0aGUganVyaXNkaWN0aW9uIHRvIGJlIHVz ZWQgaW4gdGhlIFNlcnZpY2UgVVJOLCB3aHkgbm90IHV0aWxpemUgdGhlIG5vbWVuY2xhdHVyZSBz cGVjaWZpZWQgaW4gQ2l2aWMgQWRkcmVzc2VzIChSRkMgNDExOSk6PGJyPnNvcy5wb2xpY2UuY291 bnRyeSBmb3IgcG9saWNlIHNlcnZpY2VzIGF0IHRoZSBjb3VudHJ5L25hdGlvbmFsL2ZlZGVyYWwv ZXRjIGxldmVsPGJyPnNvcy5wb2xpY2UuQTEgZm9yIHBvbGljZSBzZXJ2aWNlcyBhdCB0aGUgc3Rh dGUvcHJvdmluY2UvcmVnaW9uL3ByZWZlY3R1cmUvZXRjIGxldmVsPGJyPnNvcy5wb2xpY2UuQTIg Zm9yIHBvbGljZSBzZXJ2aWNlcyBhdCB0aGUgY291bnR5L3BhcmlzaC9ndW4vZGlzdHJpY3QvZXRj IGxldmVsPGJyPnNvcy5wb2xpY2UuQTMgZm9yIHBvbGljZSBzZXJ2aWNlcyBhdCB0aGUgY2l0eS90 b3duc2hpcC9zaGkvZXRjIGxldmVsPGJyPnNvcy5wb2xpY2UuQTQgZm9yIHBvbGljZSBzZXJ2aWNl cyBhdCB0aGUgY2l0eSBkaXZpc2lvbi9ib3JvdWdoL2NpdHkgZGlzdHJpY3Qvd2FyZC9jaG91L2V0 YyBsZXZlbDxicj5zb3MucG9saWNlLkE1IGZvciBwb2xpY2Ugc2VydmljZXMgYXQgdGhlIG5laWdo Ym9yaG9vZC9ibG9jay9ldGMgbGV2ZWw8YnI+PGJyPlRoaXMgd2F5IHdlIGF2b2lkIGhhdmluZyB0 byBwaWNrIGEgdGVybSB0aGF0IGhhcyBubyBhcHBsaWNhYmlsaXR5IGluIGNlcnRhaW4gY291bnRy aWVzLjxicj48YnI+VGhhbngsPGJyPkRhbjxicj48YnI+T24gMTQvMTIvMjAxMiA5OjEyIEFNLCBS b3NlbiwgQnJpYW4gd3JvdGU6PG86cD48L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9 J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byc+SSBoYXZlIG5vIHByb2JsZW0gdXNpbmcgJnF1b3Q7bmF0aW9uYWwmcXVvdDsgaW5zdGVhZCBv ZiAmcXVvdDtmZWRlcmFsJnF1b3Q7LiA8bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8nPiZxdW90O1N0YXRlJnF1b3Q7IGFuZCAmcXVvdDtQcm92aW5jZSZxdW90OyBhcmUgZXF1 aXZhbGVudC4gJm5ic3A7U29tZSBjb3VudHJpZXMgaGF2ZSBvbmUsIHNvbWUgaGF2ZSB0aGUgb3Ro ZXIuICZuYnNwO0kgZG9uJ3QgdGhpbmsgdGhlcmUgYXJlIGFueSB3aXRoIGJvdGguICZuYnNwO1Nv bWUgaGF2ZSBuZWl0aGVyIG9mIGNvdXJzZS48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+SSdkIHByZWZlciBub3QgdG8gaGF2ZSBuYXRpb24tc3BlY2lmaWMgdmFsdWVz LiAmbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZu YnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+QnJpYW48 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz5P biBEZWMgMTQsIDIwMTIsIGF0IDM6NDggQU0sIEl2byBTZWRsYWNlayAmbHQ7PGEgaHJlZj0ibWFp bHRvOml2by5zZWRsYWNla0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5pdm8uc2VkbGFj ZWtAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t OjEyLjBwdCc+Jm5ic3A7PG86cD48L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPkhlbGxvLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi O2NvbG9yOiNDMDUwNEQnPnRoYW5rIHlvdSBmb3IgeW91ciBtYWlsLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQn PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPiZndDsmbmJzcDs8L3NwYW4+SSdkIHN1cHBvcnQgYW5v dGhlciAob3B0aW9uYWwpIGxldmVsIG9mIHBvbGljZSB3aXRoIGF0IGxlYXN0IDQgdmFsdWVzLjxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6 I0MwNTA0RCc+Jmd0OyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPiZndDsmbmJzcDs8L3NwYW4+UGVy aGFwcyAmcXVvdDtsb2NhbCZxdW90Oy8mcXVvdDtyZWdpb25hbCZxdW90Oy8mcXVvdDtwcm92aW5j aWFsJnF1b3Q7LyZxdW90O2ZlZGVyYWwmcXVvdDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiND MDUwNEQnPmlmIEkgdW5kZXJzdG9vZCBjb3JyZWN0bHksIHlvdSBwcm9wb3NlIHRoYXQ6PC9zcGFu PjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6I0MwNTA0RCc+LSB1cm46c2VydmljZTpzb3MubG9jYWwsPC9zcGFuPjxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+LSB1 cm46c2VydmljZTpzb3MucmVnaW9uYWwsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+LSB1cm46c2VydmljZTpz b3MucHJvdmluY2lhbCw8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4tIHVybjpzZXJ2aWNlOnNvcy5mZWRlcmFs PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6I0MwNTA0RCc+YXJlIHJlZ2lzdGVyZWQuIGlmIEkgbWlzdW5kZXJzdG9vZCwgcGxl YXNlIGNvcnJlY3QgbWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+ dXJuOnNlcnZpY2U6c29zLmxvY2FsIHdvdWxkIG1hcCB3ZWxsIHRvIHRoZSBlbWVyZ2VuY3kgc2Vy dmljZSBwcm92aWRlZCBieSB0aGUgbXVuaWNpcGFsIHBvbGljZSBpbiB0aGUgQ3plY2ggcmVwdWJs aWMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7Y29sb3I6I0MwNTA0RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+SG93ZXZlciwgdGhl IGVtZXJnZW5jeSBzZXJ2aWNlIHByb3ZpZGVkIGJ5IHRoZSBuYXRpb25hbCBwb2xpY2UgaW4gdGhl IEN6ZWNoIHJlcHVibGljIGlzIG5vdCBlYXNpbHkgbWFwcGVkIHRvIGFueSBvZiB0aGUgdmFsdWVz Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiO2NvbG9yOiNDMDUwNEQnPi0gQ3plY2ggcmVwdWJsaWMgaGFzIHByb3ZpbmNlcyAoJnF1b3Q7 a3JhaiZxdW90OykgYnV0IHRoZSBwcm92aW5jZXMgKHNvIGZhcikgZG8gbm90IGhhdmUgdGhlaXIg b3duIHBvbGljZSBmb3JjZS48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4tIEN6ZWNoIHJlcHVibGljIGlzIG5v dCBhIGZlZGVyYXRpb24gc28gJnF1b3Q7ZmVkZXJhbCZxdW90OyBkb2VzIG5vdCBmaXQgZWl0aGVy Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiO2NvbG9yOiNDMDUwNEQnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPlBlcmhhcHMgdGhlIGZv bGxvd2luZyBzaG91bGQgYmUgZGVmaW5lZDogdXJuOnNlcnZpY2U6c29zLmxvY2FsLCB1cm46c2Vy dmljZTpzb3MucmVnaW9uYWwsIHVybjpzZXJ2aWNlOnNvcy48Yj48dT5zdGF0ZTwvdT48L2I+LCB1 cm46c2VydmljZTpzb3MuZmVkZXJhbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiND MDUwNEQnPkFsdGVybmF0aXZlbHksIHN1YnJlZ2lzdHJpZXMgY2FuIGJlIGNyZWF0ZWQgZm9yIGVh Y2ggY291bnRyeSB3aGVyZSB0aGUgcmVndWxhdG9yIG9mIHRoZSBjb3VudHJ5IHdvdWxkIG1hbmFn ZSB0aGUgZW1lcmdlbmN5IHNlcnZpY2UgVVJOcyBmb3IgdGhlIGNvdW50cnkgc3BlY2lmaWMgZW1l cmdlbmN5IHNlcnZpY2VzICgmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL2VuLndpa2lwZWRp YS5vcmcvd2lraS9FbWVyZ2VuY3lfdGVsZXBob25lX251bWJlciIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiO2NvbG9yOnB1cnBsZSc+aHR0cDovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9FbWVyZ2VuY3lf dGVsZXBob25lX251bWJlcjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+Jm5ic3A7c2Vl bXMgdG8gbGlzdCBxdWl0ZSBhIGxvdCBvZiB0aG9zZSApPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6I0MwNTA0RCc+S2luZCByZWdhcmRzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 Y29sb3I6I0MwNTA0RCc+SXZvIFNlZGxhY2VrPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6I0MwNTA0RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMzMzMzMzMnPlRoaXMgQ29tbXVuaWNhdGlv biBpcyBDb25maWRlbnRpYWwuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUg YmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDov L3d3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lciIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxl PSJodHRwOi8vd3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyIj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOnB1 cnBsZSc+d3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyPC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9y OiNDMDUwNEQnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxkaXYgc3R5 bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtJz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxiPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIic+Jm5ic3A7Um9zZW4sIEJyaWFuIFs8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5t YWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+XSZuYnNwOzxi cj48Yj5TZW50OjwvYj4mbmJzcDsxMy4gcHJvc2luY2UgMjAxMiAxNTo0MTxicj48Yj5Ubzo8L2I+ Jm5ic3A7SXZvIFNlZGxhY2VrPGJyPjxiPkNjOjwvYj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOmVjcml0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOnB1cnBsZSc+ ZWNyaXRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+PGJyPjxiPlN1YmplY3Q6PC9iPiZuYnNw O1JlOiBbRWNyaXRdIFdoYXQgaXMgdGhlIG1vc3QgYXBwcm9wcmlhdGUgbWV0aG9kIGZvciByZWdp c3RlcmluZyBuZXcgc3ViLXNlcnZpY2VzIG9mIHVybjpzZXJ2aWNlOnNvczwvc3Bhbj48bzpwPjwv bzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNw OzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+VGhhdCBpc3N1 ZSBvY2N1cnMgaW4gc2V2ZXJhbCBvdGhlciBjb3VudHJpZXMuPG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPlRoZXJlIGFyZSBvZnRlbiAzIG9yIG1vcmUg cG9saWNlIGFnZW5jaWVzIHNlcnZpbmcgYW4gYXJlYS4gJm5ic3A7SW4gbXkgaG9tZSwgdGhlcmUg YXJlIGZvdXI6PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPmEpIEEgbG9jYWwgKHRvd25zaGlwKSBwb2xpY2U8bzpwPjwvbzpwPjwvcD48L2Rp dj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+YikgQSBjb3VudHkgcG9saWNl IGFnZW5jeSB0aGF0IHJlc3BvbmRzIHRvIHNvbWUgdW5jb21tb24gZXZlbnRzPG86cD48L286cD48 L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPmMpIEEgc3RhdGUg cG9saWNlIGFnZW5jeSwgd2hpY2ggYWxzbyBoYXMganVyaXNkaWN0aW9uIGluIHNvbWUgY2lyY3Vt c3RhbmNlczxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz5kKSBUaGUgZmVkZXJhbCBwb2xpY2UgKEZCSSk8bzpwPjwvbzpwPjwvcD48L2Rpdj48 L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+ PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPldoaWxlIHdlIGRvIGhh dmUgYSBzaW5nbGUgbnVtYmVyLCBpZiB5b3UgZXhwbGljaXRseSB3YW50ZWQgdGhlIHN0YXRlIHBv bGljZSwgdGhlcmUgaXMgbm8gd2F5IHRvIGdldCB0byB0aGVtLjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwv cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+SSdkIHN1cHBvcnQg YW5vdGhlciAob3B0aW9uYWwpIGxldmVsIG9mIHBvbGljZSB3aXRoIGF0IGxlYXN0IDQgdmFsdWVz LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Jz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byc+UGVyaGFwcyAmcXVvdDtsb2NhbCZxdW90Oy8mcXVvdDtyZWdpb25hbCZxdW90Oy8m cXVvdDtwcm92aW5jaWFsJnF1b3Q7LyZxdW90O2ZlZGVyYWwmcXVvdDs8bzpwPjwvbzpwPjwvcD48 L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286 cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPkJyaWFuPG86 cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz5PbiBEZWMgMTMsIDIwMTIsIGF0IDg6MjIgQU0sIEl2byBTZWRsYWNlayAmbHQ7PGEg aHJlZj0ibWFpbHRvOml2by5zZWRsYWNla0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0nY29sb3I6cHVycGxlJz5pdm8uc2VkbGFjZWtAZXJpY3Nzb24uY29tPC9zcGFu PjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCc+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIic+SGVsbG8sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjwv ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8n PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiInPmluIHRoZSBDemVjaCByZXB1YmxpYywgdGhlIG5hdGlvbmFsIHJlZ3VsYXRvciBk ZWZpbmVkIHR3byBwb2xpY2UgcmVsYXRlZCBlbWVyZ2VuY3kgc2VydmljZXM6PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiJz5BKSBlbWVyZ2VuY3kgc2VydmljZSBwcm92aWRlZCBieSB0aGUgbmF0aW9uYWwgcG9saWNl IChudW1iZXIgMTU4IGluIHRoZSBwdWJsaWMgc3dpdGNoZWQgdGVsZXBob25lIG5ldHdvcmspOyBh bmQ8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiInPkIpIGVtZXJnZW5jeSBzZXJ2aWNlIHByb3ZpZGVkIGJ5IHRoZSBt dW5pY2lwYWwgcG9saWNlIChudW1iZXIgMTU2IGluIHRoZSBwdWJsaWMgc3dpdGNoZWQgdGVsZXBo b25lIG5ldHdvcmspLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w PjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5UaGUg cmVndWxhdGlvbiBpcyZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vYXBsaWthY2UubXZjci5j ei9hcmNoaXYyMDA4L3NiaXJrYS8yMDA3L3NiMDQzLTA3LnBkZiIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6cHVycGxlJz5odHRwOi8vYXBsaWthY2UubXZjci5jei9hcmNoaXYyMDA4L3Ni aXJrYS8yMDA3L3NiMDQzLTA3LnBkZjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7d2hpY2ggbGlz dHMgdGhlIG51bWJlcnMgMTU2IGFuZCAxNTggaW4gc2VjdGlvbiA0LjUuIHdpdGggbm90ZSAyKSB3 aGljaCBzdGF0ZXMgJnF1b3Q7xIzDrXNsbyBqZSBuw6Fyb2Ruw61tIMSNw61zbGVtIHBybyB0w61z xYhvdsOpIHZvbMOhbsOtJnF1b3Q7ICg9IHRoZSBudW1iZXIgaXMgYSBuYXRpb25hbCBudW1iZXIg Zm9yIGVtZXJnZW5jeSBjYWxscykuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2Pjxk aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiInPklzIGl0IGFwcHJvcHJpYXRlIHRvIHJlZ2lzdGVyIHRoZSBmb2xsb3dpbmcgVVJOcyBmb3Ig dGhvc2Ugc2VydmljZXMgd2l0aCBJQU5BPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rp dj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+LSB1cm46c2VydmljZTpz b3MucG9saWNlLm5hdGlvbmFsIC0gVGhlICdwb2xpY2UubmF0aW9uYWwnIHNlcnZpY2UgcmVmZXJz IHRvIHRoZSBwb2xpY2UgZGVwYXJ0bWVudCBvciBvdGhlciBsYXcgZW5mb3JjZW1lbnQgYXV0aG9y aXRpZXMgb2YgdGhlIG5hdGlvbmFsIGdvdmVybm1lbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4tIHVybjpz ZXJ2aWNlOnNvcy5wb2xpY2UubXVuaWNpcGFsIC0gVGhlICdwb2xpY2UubXVuaWNpcGFsJyBzZXJ2 aWNlIHJlZmVycyB0byB0aGUgcG9saWNlIGRlcGFydG1lbnQgb3Igb3RoZXIgbGF3IGVuZm9yY2Vt ZW50IGF1dGhvcml0aWVzIG9mIHRoZSBtdW5pY2lwYWwgYXV0aG9yaXRpZXMuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPk9yIHNob3VsZCB0aG9zZSBiZSByZWdpc3RlcmVk IHdpdGggYSBwcmVmaXggaW5kaWNhdGluZyB0aGF0IHRob3NlIGFyZSBhcHBsaWNhYmxlIHRvIEN6 ZWNoIHJlcHVibGljIG9ubHksIGFzIG90aGVyIGNvdW50cmllcyBtYXkgaGF2ZSBzaW1pbGFyIChi dXQgbm90IG5lY2Vzc2FyaWx5IGlkZW50aWNhbCkgc2VydmljZXM6PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4t IHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UuY3plY2gubmF0aW9uYWwgLSBUaGUgJ3BvbGljZS5jemVj aC5uYXRpb25hbCcgc2VydmljZSByZWZlcnMgdG8gdGhlIHBvbGljZSBkZXBhcnRtZW50IG9yIG90 aGVyIGxhdyBlbmZvcmNlbWVudCBhdXRob3JpdGllcyBvZiB0aGUgbmF0aW9uYWwgZ292ZXJubWVu dC48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiInPi0gdXJuOnNlcnZpY2U6c29zLnBvbGljZS5jemVjaC5tdW5pY2lw YWwgLSBUaGUgJ3BvbGljZS5jemVjaC5tdW5pY2lwYWwnIHNlcnZpY2UgcmVmZXJzIHRvIHRoZSBw b2xpY2UgZGVwYXJ0bWVudCBvciBvdGhlciBsYXcgZW5mb3JjZW1lbnQgYXV0aG9yaXRpZXMgb2Yg bXVuaWNpcGFsIGF1dGhvcml0aWVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48 ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiJz5JIGFzc3VtZSB0aGlzIHF1ZXN0aW9uIGJlbG9uZ3MgdG8gSUFOQSwgYnV0IGFzIHRoZSBl eHBlcnQgcmV2aWV3ZXIgbW9zdCBsaWtlbHkgd2lsbCBiZSBmcm9tIHRoZSBFQ1JJVCwgSSBhbSBz ZW5kaW5nIGl0IGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPktp bmQgcmVnYXJkczwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5Jdm8gU2Vk bGFjZWs8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiInPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48 L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiJz5UaGlzIENvbW11bmljYXRpb24gaXMgQ29uZmlkZW50aWFsLiBXZSBvbmx5IHNl bmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0 PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly93d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXIi IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOnB1cnBsZSc+d3d3LmVyaWNzc29uLmNvbS9l bWFpbF9kaXNjbGFpbWVyPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQt ZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+RWNyaXQgbWFpbGluZyBsaXN0PGJyPjwvc3Bhbj48 YSBocmVmPSJtYWlsdG86RWNyaXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiI7 Y29sb3I6cHVycGxlJz5FY3JpdEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6IkhlbHZldGljYSIsInNhbnMtc2VyaWYiJz48YnI+PC9z cGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQi IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWls eToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiI7Y29sb3I6cHVycGxlJz5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD48L2Rp dj48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxv OnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxw cmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwv bzpwPjwvcHJlPjxwcmU+RWNyaXQgbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT48cHJlPjxh IGhyZWY9Im1haWx0bzpFY3JpdEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkVjcml0QGlldGYu b3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+PHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdDwvYT48bzpwPjwvbzpwPjwvcHJlPjwvYmxvY2tx dW90ZT48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rp dj48L2Rpdj48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpw PjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_5A55A45AE77F5941B18E5457ECAC818801214077118CSISPE7MB1co_-- From rlb@ipv.sx Mon Feb 18 13:57:15 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E7921F8CFF for ; Mon, 18 Feb 2013 13:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLlTBFjK0f+U for ; Mon, 18 Feb 2013 13:57:12 -0800 (PST) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id 87F5A21F8CFE for ; Mon, 18 Feb 2013 13:57:11 -0800 (PST) Received: by mail-oa0-f49.google.com with SMTP id j6so6189399oag.8 for ; Mon, 18 Feb 2013 13:57:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=cG2LYVluzJyIIkGzfLfckZGzJNwvG5Xp5gKmmXh1HE0=; b=JGRzT+R1ZVzb1IHRRaFSdrhKK930iz1OEJpiErrHphH3qXBGcXw6lhVWyEHRMO1HC7 TY5pzazuFH+3WUHUPa/9Xsda5HbCzAnSvk98Acw9ECYPE/dn0ikBMl+J7NPLYymhXA4y HdJODL66S1czrv7orFG62eN9QKDArfw6O89AqWlXEg0nw2keYJ1Ty1Pmj9qQ3fYOfToV bu0XMfElZZau0909Mo97tF8r4vIM5twieN3F+WXByjhUxFY+Obe0O93wgVH9eeTNVaIo Os+8+AxxpEgRuS9UO/T01gkNErTUT/1cKZHsxDvTREzQguIaKnFefHoTuy1BAVjL37Sc IjHA== MIME-Version: 1.0 X-Received: by 10.60.8.199 with SMTP id t7mr6479887oea.26.1361224631021; Mon, 18 Feb 2013 13:57:11 -0800 (PST) Received: by 10.60.7.132 with HTTP; Mon, 18 Feb 2013 13:57:10 -0800 (PST) X-Originating-IP: [132.177.252.40] In-Reply-To: <5A55A45AE77F5941B18E5457ECAC818801214077118C@SISPE7MB1.commscope.com> References: <39B5E4D390E9BD4890E2B3107900610103F703@ESESSMB301.ericsson.se> <9E790F21-21D7-437B-820B-A88355047BBA@neustar.biz> <39B5E4D390E9BD4890E2B3107900610103FBB3@ESESSMB301.ericsson.se> <6E7FEA84-EBE2-4BE0-B8EA-67D5AD8CA9F2@neustar.biz> <50D08D29.2030303@mongrain.org> <39B5E4D390E9BD4890E2B3107900610104BB9D@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610104C240@ESESSMB301.ericsson.se> <5A55A45AE77F5941B18E5457ECAC818801214077118C@SISPE7MB1.commscope.com> Date: Mon, 18 Feb 2013 16:57:10 -0500 Message-ID: From: Richard Barnes To: "Winterbottom, James" Content-Type: multipart/alternative; boundary=e89a8ff1ce46976f4004d606cee0 X-Gm-Message-State: ALoCoQnQk680En4Dnz/F5oP5BbG3E0+2KeNddInHfeMU2W9CdOYEW3AeCEll3MoChjpv4jYhTxv9 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 21:57:15 -0000 --e89a8ff1ce46976f4004d606cee0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It might make sense if you wanted to allow the caller to explicitly select police at a different level of responsibility, e.g., the state police rather than the local police. On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James < James.Winterbottom@commscope.com> wrote: > I think I am missing something here, A1 is part of the location, so why > does it need to be in the URN at all?**** > > As far as I understand current deployments, they use the URN to select a > layer in the GIS that corresponds to the service type, and then use > geographic boundaries within that layer to select the final destination.*= * > ** > > ** ** > > *From:* ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behalf > Of *Dan Mongrain > *Sent:* Tuesday, 19 February 2013 7:30 AM > > *To:* Ivo Sedlacek > *Cc:* ecrit@ietf.org > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > ** ** > > Sorry for responding late to this thread, it kinda fell into a crack=E2= =80=A6 > The current thread reminded me to check this old thread=E2=80=A6**** > > **** > > You are indicating that we need to register 77 Service URN (11 service > subtypes * 7 jurisdiction types based on RFC 4119). I do not recommend > that we create so many registrations. Instead, we should allow a service > URN to be suffixed with a jurisdictional scope. So the following Service > URN are all valid:**** > > **** > > urn:service:sos.police**** > > urn:service:sos.police.traffic**** > > urn:service:sos.police.A1**** > > urn:service:sos.police.traffic.A1**** > > **** > > Question is, do we want to leave jurisdictional scope to only be > applicable to police branch or any Service URN? I=E2=80=99d say the latt= er as it > is always up to the LoST service provisioning (based on local policy) to > determine what is locally acceptable.**** > > **** > > Thanx,**** > > Dan**** > > ** ** > > On Thu, Dec 20, 2012 at 2:53 AM, Ivo Sedlacek > wrote:**** > > Hello,**** > > **** > > thanks for the proposal and for the check of the Canadian usage.**** > > **** > > Let's try to assign the proposed service URNs to the Wikipedia list:**** > > - municipal police (Czech Republic, Poland) -> urn:service:sos.police.A3 = * > *** > > - tourist police (Egypt, Greece) -> urn:service:sos.police.tourist**** > > - traffic police (Egypt, Sudan, India, Pakistan, Saudi Arabia, Albania, > Armenia, Azerbaijan) -> urn:service:sos.police.traffic**** > > - state police (Italy) -> urn:service:sos.police.country**** > > - customs/financial Police (Italy) -> does not match - we probably need > urn:service:sos.police.financial (new)**** > > - gendarmerie (Romania) -> does not match - we probably need > urn:service:sos.police.military (new)**** > > - local police (Spain) -> urn:service:sos.police.A3**** > > - Catalan police (Spain) -> urn:service:sos.police.A1 (a person with > spanish/catalan background should check)**** > > - civil guard (Spain) -> does not match - we probably need > urn:service:sos.police.military (new) (a person with spanish/catalan > background should check)**** > > - Provincial Police (Canada) - urn:service:sos.police.A1**** > > - S=C3=BBret=C3=A9 du Qu=C3=A9bec (Canada) - urn:service:sos.police.A1***= * > > - federal highway police (Brazil) -> urn:service:sos.police.traffic**** > > - federal police (Brazil) -> urn:service:sos.police.country**** > > - civil police (Brazil) -> does not match - we probably need > urn:service:sos.police.civil (new)**** > > - state highway police (Brazil) -> urn:service:sos.police.A1.traffic**** > > - GAULA (Colombia) -> does not match - we probably need > urn:service:sos.police.antikidnapping (new)**** > > **** > > I.e. we would need additionally:**** > > - urn:service:sos.police.financial**** > > - urn:service:sos.police.military**** > > - urn:service:sos.police.civil**** > > - urn:service:sos.police.antikidnapping**** > > **** > > If I understood it correctly, all together, we would need 77 police > related emergency service URNs =3D (7 (specialized police corp below) + 4 > (additional above)) * 7 (nomenclature specified in Civic Addresses (RFC > 4119)). Seems quite a lot.Moreover, a regulator in a country can define a > new type of a police related emergency service - it depends on how the la= w > enforcement is structure in the country. Then the list will grow even mor= e. > Maybe it would really be better to let regulators to manage per-country > sub-registries.**** > > **** > > Kind regards**** > > **** > > Ivo Sedlacek**** > > **** > > **** > > **** > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out at www.ericsson.com/email_disclaimer **** > > **** > > *From:* Dan Mongrain [mailto:dan@mongrain.org] > *Sent:* 19. prosince 2012 16:00 > *To:* Ivo Sedlacek > *Cc:* ecrit@ietf.org**** > > > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > **** > > I also recommend we create purpose keywords in order to reach a > specialized police corp. Such as: > sos.police.drugs > sos.police.traffic > sos.police.firearms > sos.police.alcohol > sos.police.tobacco > sos.police.tourist > sos.police.border > > The above keywords can be utilized with territorial designations in order > to specify a particular service if offered by multiple jurisdictions. Fo= r > example in the US: > sos.police.country.drugs could be used to reach the DEA whereas > sos.police.A3.drugs could be used to reach the narcotics division of the > city police. > > I can answer for Canada: > sos.police.country would be to reach the Royal Canadian Mountain Police > (RCMP) > In the provinces of Ontario and Qu=C3=A9bec which have provincal polices,= then > sos.police.A1 in Ontario would reach the Ontario Provincial Police (OPP) > and sos.police.A1 in Qu=C3=A9bec would reach the Suret=C3=A9 du Qu=C3=A9b= ec (SQ). > In Canada we do not have a police service at the county level (we do have > sheriff departments but they are more for court and jail security). > In Ontario and Qu=C3=A9bec, a city may have its police service otherwise = the > provincial police offers the service. In the rest of Canada, a city may > have its police service otherwise the RCMP offers the service. > > Thanx, > Dan**** > > On Wed, Dec 19, 2012 at 7:02 AM, Ivo Sedlacek > wrote:**** > > Hello,**** > > **** > > thanks.**** > > **** > > both options (Dan's and Brian's) seemed to work for the emergency service= s > of the police forces in the Czech republic.**** > > **** > > For completeness, I also checked the emergency services of the police > forces of other countries. Wikipedia ( > http://en.wikipedia.org/wiki/Emergency_telephone_number) lists the > following on top of emergency services of the regular police forces:**** > > - municipal police (Czech Republic, Poland) -> can map to > urn:service:sos.police.local or urn:service:sos.police.A3 **** > > - tourist police (Egypt, Greece) -> does not seem to fit into any of the > alternatives so far**** > > - traffic police (Egypt, Sudan, India, Pakistan, Saudi Arabia, Albania, > Armenia, Azerbaijan) -> does not seem to fit into any of the alternatives > so far**** > > - state police (Italy) -> can map to urn:service:sos.police.national or > urn:service:sos.police.country**** > > - customs/financial Police (Italy) -> does not seem to fit into any of th= e > alternatives so far**** > > - gendarmerie (Romania) -> does not seem to fit into any of the > alternatives so far**** > > - local police (Spain) -> can map to urn:service:sos.police.local or > urn:service:sos.police.A3**** > > - Catalan police (Spain) -> maybe this could map to > urn:service:sos.police.regional or urn:service:sos.police.A1 but a person > with spanish/catalan background should check.**** > > - civil guard (Spain) -> does not seem to fit into any of the alternative= s > so far**** > > - Provincial Police (Canada) - maybe this could map to > urn:service:sos.police.regional or urn:service:sos.police.A1 but a person > with canadian background should check**** > > - S=C3=BBret=C3=A9 du Qu=C3=A9bec (Canada) - maybe this could map to > urn:service:sos.police.regional or urn:service:sos.police.A1 but a person > with canadian background should check**** > > - federal highway police (Brazil) -> does not seem to fit into any of the > alternatives so far**** > > - federal police (Brazil) -> can map to urn:service:sos.police.national o= r > urn:service:sos.police.country**** > > - civil police (Brazil) -> does not seem to fit into any of the > alternatives so far**** > > - state highway police (Brazil) -> does not seem to fit into any of the > alternatives so far**** > > - GAULA (Colombia) -> does not seem to fit into any of the alternatives s= o > far**** > > **** > > For those emergency services above not fitting into any of the > alternatives, how should they be expressed in an emergency service URN? D= o > we assume IANA will register them too?**** > > **** > > Kind regards**** > > **** > > Ivo Sedlacek**** > > **** > > **** > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out at www.ericsson.com/email_disclaimer **** > > **** > > *From:* ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behalf > Of *Dan Mongrain, eng. > *Sent:* 18. prosince 2012 16:35 > *To:* ecrit@ietf.org**** > > > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > **** > > Instead of trying to come up with the proper nomenclature for the > jurisdiction to be used in the Service URN, why not utilize the > nomenclature specified in Civic Addresses (RFC 4119): > sos.police.country for police services at the country/national/federal/et= c > level > sos.police.A1 for police services at the > state/province/region/prefecture/etc level > sos.police.A2 for police services at the county/parish/gun/district/etc > level > sos.police.A3 for police services at the city/township/shi/etc level > sos.police.A4 for police services at the city division/borough/city > district/ward/chou/etc level > sos.police.A5 for police services at the neighborhood/block/etc level > > This way we avoid having to pick a term that has no applicability in > certain countries. > > Thanx, > Dan > > On 14/12/2012 9:12 AM, Rosen, Brian wrote:**** > > I have no problem using "national" instead of "federal". **** > > "State" and "Province" are equivalent. Some countries have one, some hav= e > the other. I don't think there are any with both. Some have neither of > course.**** > > **** > > I'd prefer not to have nation-specific values. **** > > **** > > Brian**** > > On Dec 14, 2012, at 3:48 AM, Ivo Sedlacek > wrote:**** > > **** > > Hello,**** > > **** > > thank you for your mail.**** > > **** > > > I'd support another (optional) level of police with at least 4 values.*= * > ** > > > **** > > > Perhaps "local"/"regional"/"provincial"/"federal"**** > > **** > > if I understood correctly, you propose that:**** > > - urn:service:sos.local,**** > > - urn:service:sos.regional,**** > > - urn:service:sos.provincial,**** > > - urn:service:sos.federal**** > > are registered. if I misunderstood, please correct me.**** > > **** > > urn:service:sos.local would map well to the emergency service provided by > the municipal police in the Czech republic.**** > > **** > > However, the emergency service provided by the national police in the > Czech republic is not easily mapped to any of the values:**** > > - Czech republic has provinces ("kraj") but the provinces (so far) do not > have their own police force.**** > > - Czech republic is not a federation so "federal" does not fit either.***= * > > **** > > Perhaps the following should be defined: urn:service:sos.local, > urn:service:sos.regional, urn:service:sos.*state*, urn:service:sos.federa= l > **** > > **** > > Alternatively, subregistries can be created for each country where the > regulator of the country would manage the emergency service URNs for the > country specific emergency services ( > http://en.wikipedia.org/wiki/Emergency_telephone_number seems to list > quite a lot of those )**** > > **** > > Kind regards**** > > **** > > Ivo Sedlacek**** > > **** > > **** > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out at www.ericsson.com/email_disclaimer**** > > **** > > *From:* Rosen, Brian [mailto:Brian.Rosen@neustar.biz > ] > *Sent:* 13. prosince 2012 15:41 > *To:* Ivo Sedlacek > *Cc:* ecrit@ietf.org > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > **** > > That issue occurs in several other countries.**** > > There are often 3 or more police agencies serving an area. In my home, > there are four:**** > > a) A local (township) police**** > > b) A county police agency that responds to some uncommon events**** > > c) A state police agency, which also has jurisdiction in some circumstanc= es > **** > > d) The federal police (FBI)**** > > **** > > While we do have a single number, if you explicitly wanted the state > police, there is no way to get to them.**** > > **** > > I'd support another (optional) level of police with at least 4 values.***= * > > **** > > Perhaps "local"/"regional"/"provincial"/"federal"**** > > **** > > Brian**** > > On Dec 13, 2012, at 8:22 AM, Ivo Sedlacek > wrote:**** > > ** ** > > Hello,**** > > **** > > in the Czech republic, the national regulator defined two police related > emergency services:**** > > A) emergency service provided by the national police (number 158 in the > public switched telephone network); and**** > > B) emergency service provided by the municipal police (number 156 in the > public switched telephone network).**** > > **** > > The regulation is > http://aplikace.mvcr.cz/archiv2008/sbirka/2007/sb043-07.pdf which lists > the numbers 156 and 158 in section 4.5. with note 2) which states "=C4=8C= =C3=ADslo je > n=C3=A1rodn=C3=ADm =C4=8D=C3=ADslem pro t=C3=ADs=C5=88ov=C3=A9 vol=C3=A1n= =C3=AD" (=3D the number is a national number for > emergency calls).**** > > **** > > Is it appropriate to register the following URNs for those services with > IANA?**** > > - urn:service:sos.police.national - The 'police.national' service refers > to the police department or other law enforcement authorities of the > national government.**** > > - urn:service:sos.police.municipal - The 'police.municipal' service refer= s > to the police department or other law enforcement authorities of the > municipal authorities.**** > > **** > > Or should those be registered with a prefix indicating that those are > applicable to Czech republic only, as other countries may have similar (b= ut > not necessarily identical) services:**** > > - urn:service:sos.police.czech.national - The 'police.czech.national' > service refers to the police department or other law enforcement > authorities of the national government.**** > > - urn:service:sos.police.czech.municipal - The 'police.czech.municipal' > service refers to the police department or other law enforcement > authorities of municipal authorities.**** > > **** > > I assume this question belongs to IANA, but as the expert reviewer most > likely will be from the ECRIT, I am sending it here.**** > > **** > > Kind regards**** > > **** > > Ivo Sedlacek**** > > **** > > **** > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out atwww.ericsson.com/email_disclaimer**** > > _______________________________________________ > 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 > > --e89a8ff1ce46976f4004d606cee0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It might make sense if you wanted to allow the caller to e= xplicitly select police at a different level of responsibility, e.g., the s= tate police rather than the local police. =C2=A0


On Mon, Feb 18, 2013 at 4:21 PM, Winterb= ottom, James <James.Winterbottom@commscope.com> wrote:

I think I am = missing something here, A1 is part of the location, so why does it need to = be in the URN at all?

As far as I understand cu= rrent deployments, they use the URN to select a layer in the GIS that corre= sponds to the service type, and then use geographic boundaries within that = layer to select the final destination.

=C2=A0

From: ecrit-bounces@ietf.org= [mailto:ec= rit-bounces@ietf.org] On Behalf Of Dan Mongrain
Sent: Tuesday, 19 February 2013 7:30 AM


To: Ivo Sedlacek
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] W= hat is the most appropriate method for registering new sub-services of urn:= service:sos

=C2= =A0

Sorry for r= esponding late to this thread, it kinda fell into a=C2=A0 crack=E2=80=A6=C2= =A0 The current thread reminded me to check this old thread=E2=80=A6=

=C2=A0

You are indicating = that we need to register 77 Service URN (11 service subtypes * 7 jurisdicti= on types based on RFC 4119).=C2=A0 I do not recommend that we create so man= y registrations.=C2=A0 Instead, we should allow a service URN to be suffixe= d with a jurisdictional scope.=C2=A0 So the following Service URN are all v= alid:

=C2=A0

urn:service:sos.pol= ice

urn:service:sos.police.tr= affic

urn:service:sos.police.A1

urn:service:sos.police.tr= affic.A1

=C2=A0

Question is, do we want t= o leave jurisdictional scope to only be applicable to police branch or any = Service URN? =C2=A0I=E2=80=99d say the latter as it is always up to the LoS= T service provisioning (based on local policy) to determine what is locally= acceptable.

=C2=A0

Thanx,

Dan<= /p>

=C2=A0

On Thu, Dec 20, 2012 at 2:53 AM, Ivo Sedlacek <ivo.sedlacek@e= ricsson.com> wrote:

Hello,

=C2=A0=

thanks for the proposal= and for the check of the Canadian usage.

=C2=A0=

Let's try to assign= the proposed service URNs to the Wikipedia list:

- municipal police (Czech R= epublic, Poland) -> urn:service:sos.police.A3

<= p class=3D"MsoNormal"> - tourist police (Egypt, Greece) -> urn:service= :sos.police.tourist

- traffic police (Egypt, Sudan, India, Pakistan, Saudi Ara= bia, Albania, Armenia, Azerbaijan) -> urn:service:sos.police.traffic

- state police (Italy) ->= ; urn:service:sos.police.country

- customs/financial Police (Italy) -> does not = match - we probably need urn:service:sos.police.financial (new)

- gendarmerie (Romania) -&g= t; does not match - we probably need urn:service:sos.police.military (new)<= /span>

- local police (Spain) ->= ; urn:service:sos.police.A3

= - Catalan police (Spain) -> urn:service:sos.pol= ice.A1 (a person with spanish/catalan background should check)

- civil guard (Spain) ->= does not match - we probably need urn:service:sos.police.military (new) (a= person with spanish/catalan background should check)<= /p>

- Provincial Police (Canada= ) - urn:service:sos.police.A1

- S=C3=BBret=C3=A9 du Qu=C3=A9bec (Canada) - urn:s= ervice:sos.police.A1

- federal highway police (Brazil) -> urn:service:sos.p= olice.traffic

- federal police (Brazil) -= > urn:service:sos.police.country

- civil police (Brazil) -> does not match - we = probably need urn:service:sos.police.civil (new)

- state highway police (Bra= zil) -> urn:service:sos.police.A1.traffic

- GAULA (Colombia) -> does not match - we proba= bly need urn:service:sos.police.antikidnapping (new)

=C2=A0=

I.e. we would need addi= tionally:

- urn:service:sos.police.fi= nancial

- urn:service:sos.police.military

- urn:service:sos.police.ci= vil

- urn:service:sos.police.antikidnapping

=C2=A0=

If I understood it corr= ectly, all together, we would need 77 police related emergency service URNs= =3D (7 (specialized police corp below) + 4 (additional above)) * 7 (nomenc= lature specified in Civic Addresses (RFC 4119)). Seems quite a lot.Moreover= , a regulator in a country can define a new type of a police related emerge= ncy service - it depends on how the law enforcement is structure in the cou= ntry. Then the list will grow even more. Maybe it would really be better to= let regulators to manage per-country sub-registries.<= /p>

=C2=A0

Kind regards

=C2=A0=

Ivo Sedlacek<= /u>

=C2=A0=

=C2=A0=

=C2=A0=

This Communication is Co= nfidential. We only send and receive email on the basis of the terms set ou= t at www.er= icsson.com/email_disclaimer

=C2=A0=

From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. prosince 2012 16:00
To: Ivo Sedlacek
Cc: ecrit@ietf.org


Subject: Re: [Ecrit= ] What is the most appropriate method for registering new sub-services of u= rn:service:sos

=C2=A0

I also recommend we create = purpose keywords in order to reach a specialized police corp.=C2=A0 Such as= :
sos.police.drugs
sos.police.traffic
sos.police.firearms
sos.police.alcohol
sos.poli= ce.tobacco
sos.police.tourist
sos.police.border

The above keyw= ords can be utilized with territorial designations in order to specify a pa= rticular service if offered by multiple jurisdictions.=C2=A0 For example in= the US:
sos.police.country.drugs could be used to reach the DEA whereas
sos.poli= ce.A3.drugs could be used to reach the narcotics division of the city polic= e.

I can answer for Canada:
sos.police.country would be to reach = the Royal Canadian Mountain Police (RCMP)
In the provinces of Ontario and Qu=C3=A9bec which have provincal polices, t= hen sos.police.A1 in Ontario would reach the Ontario Provincial Police (OPP= ) and sos.police.A1 in Qu=C3=A9bec would reach the Suret=C3=A9 du Qu=C3=A9b= ec (SQ).
In Canada we do not have a police service at the county level (= we do have sheriff departments but they are more for court and jail securit= y).
In Ontario and Qu=C3=A9bec, a city may have its police service otherwise th= e provincial police offers the service.=C2=A0 In the rest of Canada, a city= may have its police service otherwise the RCMP offers the service.

= Thanx,
Dan

On Wed, Dec 19, 2012 at 7:= 02 AM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:

=

Hello,=

=C2=A0=

thanks.

=C2=A0

both options (Dan's and= Brian's) seemed to work for the emergency services of the police force= s in the Czech republic.

=C2=A0=

For completeness, I als= o checked the emergency services of the police forces of other countries. W= ikipedia (http://en.wikipedia.org/wiki/Emergen= cy_telephone_number) lists the followin= g on top of emergency services of the regular police forces:<= u>

- municipal police (Czech R= epublic, Poland) -> can map to urn:service:sos.police.local or urn:servi= ce:sos.police.A3

- tourist police (Egypt, Gr= eece) -> does not seem to fit into any of the alternatives so far=

- traffic police (Egypt, Su= dan, India, Pakistan, Saudi Arabia, Albania, Armenia, Azerbaijan) -> doe= s not seem to fit into any of the alternatives so far<= /p>

- state police (Italy) ->= ; can map to urn:service:sos.police.national or urn:service:sos.police.coun= try

- customs/financial Police = (Italy) -> does not seem to fit into any of the alternatives so far

- gendarmerie (Romania) -&g= t; does not seem to fit into any of the alternatives so far

- local police (Spain) ->= ; can map to urn:service:sos.police.local or urn:service:sos.police.A3

- Catalan police (Spain) -&= gt; maybe this could map to urn:service:sos.police.regional or urn:service:= sos.police.A1 but a person with spanish/catalan background should check.

- civil guard (Spain) ->= does not seem to fit into any of the alternatives so far<= /u>

- Provincial Police (Canada= ) - maybe this could map to urn:service:sos.police.regional or urn:service:= sos.police.A1 but a person with canadian background should check<= /u>

- S=C3=BBret=C3=A9 du Qu=C3= =A9bec (Canada) - maybe this could map to urn:service:sos.police.regional o= r urn:service:sos.police.A1 but a person with canadian background should ch= eck

- federal highway police (B= razil) -> does not seem to fit into any of the alternatives so far

- federal police (Brazil) -= > can map to urn:service:sos.police.national or urn:service:sos.police.c= ountry

- civil police (Brazil) -&g= t; does not seem to fit into any of the alternatives so far

- state highway police (Bra= zil) -> does not seem to fit into any of the alternatives so far<= u>

- GAULA (Colombia) -> do= es not seem to fit into any of the alternatives so far=

=C2=A0=

For those emergency ser= vices above not fitting into any of the alternatives, how should they be ex= pressed in an emergency service URN? Do we assume IANA will register them t= oo?

=C2=A0

Kind regards

=C2=A0=

Ivo Sedlacek<= /u>

=C2=A0=

=C2=A0=

This Communication is C= onfidential. We only send and receive email on the basis of the terms set o= ut at www.e= ricsson.com/email_disclaimer <= /u>

=C2=A0<= u>

From: <= a href=3D"mailto:ecrit-bounces@ietf.org" target=3D"_blank">ecri= t-bounces@ietf.org [mailto:ecrit-bounces@ietf.or= g] On Behalf Of Dan Mongrain, eng.
Sent: 18. prosince 2012 16:35
To: ecrit@ietf.org=


Subject: Re: [Ecrit] What is th= e most appropriate method for registering new sub-services of urn:service:s= os

=C2=A0

Instead of trying to co= me up with the proper nomenclature for the jurisdiction to be used in the S= ervice URN, why not utilize the nomenclature specified in Civic Addresses (= RFC 4119):
sos.police.country for police services at the country/national/federal/etc = level
sos.police.A1 for police services at the state/province/region/pre= fecture/etc level
sos.police.A2 for police services at the county/parish= /gun/district/etc level
sos.police.A3 for police services at the city/township/shi/etc level
sos= .police.A4 for police services at the city division/borough/city district/w= ard/chou/etc level
sos.police.A5 for police services at the neighborhood= /block/etc level

This way we avoid having to pick a term that has no applicability in ce= rtain countries.

Thanx,
Dan

On 14/12/2012 9:12 AM, Rosen, = Brian wrote:

I have no problem using "national" instead= of "federal".

&quo= t;State" and "Province" are equivalent. =C2=A0Some countries= have one, some have the other. =C2=A0I don't think there are any with = both. =C2=A0Some have neither of course.

=C2=A0

I'd prefer not to have nation-specific values. =C2=A0<= u>

=C2=A0

=

Brian

On Dec 1= 4, 2012, at 3:48 AM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:

=C2=A0

Hello,

=C2=A0=

t= hank you for your mail.

=C2=A0=

&= gt;=C2=A0I'd support another (optional) level of police with at = least 4 values.

>=C2=A0

>=C2=A0Perhaps "local"/"regional"/"pr= ovincial"/"federal"

=C2=A0=

i= f I understood correctly, you propose that:

- urn:service:so= s.local,

- urn:service:sos.regional,

- urn:service:so= s.provincial,

- urn:service:sos.federal

are registered. = if I misunderstood, please correct me.

<= p class=3D"MsoNormal"> =C2=A0

urn:service:sos.local would map wel= l to the emergency service provided by the municipal police in the Czech re= public.

=C2=A0=

H= owever, the emergency service provided by the national police in the Czech = republic is not easily mapped to any of the values:

- Czech republic= has provinces ("kraj") but the provinces (so far) do not have th= eir own police force.

- Czech republic= is not a federation so "federal" does not fit either.<= /u>

=C2=A0=

P= erhaps the following should be defined: urn:service:sos.local, urn:service:= sos.regional, urn:service:sos.state, urn:service:sos.federal<= /span>

=C2=A0=

A= lternatively, subregistries can be created for each country where the regul= ator of the country would manage the emergency service URNs for the country= specific emergency services (=C2=A0http://en.wikipedia.org/wiki/Emergency_telephone_number=C2=A0seems to list quite a lot of those )=

=C2=A0=

K= ind regards

=C2=A0=

I= vo Sedlacek

=C2=A0=

= =C2=A0

This Communi= cation is Confidential. We only send and receive email on the basis of the = terms set out at=C2=A0www.ericsson.com/email_disclaimer=

=C2=A0

From:=C2= =A0Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=C2=A0
Sent:=C2=A013. prosince 2012 15:41
To:=C2=A0Ivo SedlacekCc:=C2=A0ecrit@ietf.org
Subject:=C2=A0Re: [Ecrit] What is the most appropriate method for re= gistering new sub-services of urn:service:sos

=C2=A0

That issue occurs in several other countries.

<= div>

There are often 3 or more police agencies servin= g an area. =C2=A0In my home, there are four:

<= div>

a) A local (township) police

<= /div>

b) A county police agency that = responds to some uncommon events

c) A state police agency, which also has jurisdiction in some circumstances=

d) The feder= al police (FBI)

=C2=A0

While = we do have a single number, if you explicitly wanted the state police, ther= e is no way to get to them.

=C2=A0

I'= d support another (optional) level of police with at least 4 values.=

=C2=A0

Perhaps "local"/"regi= onal"/"provincial"/"federal"

=C2=A0

Brian

On Dec 13, 2012, at 8:22 AM, Ivo Sedlacek &l= t;ivo.sedlacek@ericsson.com> wrote:

<= /u>=C2=A0

Hello,

=C2=A0<= /u>

in = the Czech republic, the national regulator defined two police related emerg= ency services:

A) emergency serv= ice provided by the national police (number 158 in the public switched tele= phone network); and

B) emergency serv= ice provided by the municipal police (number 156 in the public switched tel= ephone network).

=C2=A0<= /u>

The= regulation is=C2=A0http://= aplikace.mvcr.cz/archiv2008/sbirka/2007/sb043-07.pdf=C2=A0which lists the numbers 156 and 158 in section 4.5. with note 2) wh= ich states "=C4=8C=C3=ADslo je n=C3=A1rodn=C3=ADm =C4=8D=C3=ADslem pro= t=C3=ADs=C5=88ov=C3=A9 vol=C3=A1n=C3=AD" (=3D the number is a nationa= l number for emergency calls).

=C2=A0<= /u>

Is = it appropriate to register the following URNs for those services with IANA?=

- urn:service:sos= .police.national - The 'police.national' service refers to the poli= ce department or other law enforcement authorities of the national governme= nt.

- urn:service:sos= .police.municipal - The 'police.municipal' service refers to the po= lice department or other law enforcement authorities of the municipal autho= rities.

=C2=A0<= /u>

Or = should those be registered with a prefix indicating that those are applicab= le to Czech republic only, as other countries may have similar (but not nec= essarily identical) services:

- urn:service:sos= .police.czech.national - The 'police.czech.national' service refers= to the police department or other law enforcement authorities of the natio= nal government.

- urn:service:sos= .police.czech.municipal - The 'police.czech.municipal' service refe= rs to the police department or other law enforcement authorities of municip= al authorities.

=C2=A0<= /u>

I a= ssume this question belongs to IANA, but as the expert reviewer most likely= will be from the ECRIT, I am sending it here.

=C2=A0<= /u>

Kin= d regards

=C2=A0<= /u>

Ivo= Sedlacek

=C2=A0<= /u>

=C2= =A0

This Communicatio= n is Confidential. We only send and receive email on the basis of the terms= set out atwww.ericsson.com/email_disclaimer

____________________= ___________________________
Ecrit mailing list
Ecrit@ietf= .org
https://www.ietf.org/mailman/listinfo/ecr= it

=C2=A0

=C2=A0

=C2=A0

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

=C2=A0

=C2=A0

<= /div>

=C2=A0


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


--e89a8ff1ce46976f4004d606cee0-- From James.Winterbottom@commscope.com Mon Feb 18 14:02:34 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDFA21F8775 for ; Mon, 18 Feb 2013 14:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCz5PIwrbUtr for ; Mon, 18 Feb 2013 14:02:31 -0800 (PST) Received: from cdcsmgw01.commscope.com (cdcsmgw01.commscope.com [198.135.207.232]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB8B21F872D for ; Mon, 18 Feb 2013 14:02:28 -0800 (PST) X-AuditID: 0a0404e8-b7f796d000000835-c5-5122a4f2778c Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw01.commscope.com (Symantec Messaging Gateway) with SMTP id B7.C5.02101.2F4A2215; Mon, 18 Feb 2013 16:02:27 -0600 (CST) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 18 Feb 2013 16:01:46 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 19 Feb 2013 06:01:34 +0800 From: "Winterbottom, James" To: Richard Barnes Date: Tue, 19 Feb 2013 06:01:31 +0800 Thread-Topic: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos Thread-Index: Ac4OIunZx3zzTaR1Ssa4LC6hxhRpDgAAIakg Message-ID: <5A55A45AE77F5941B18E5457ECAC8188012140771193@SISPE7MB1.commscope.com> References: <39B5E4D390E9BD4890E2B3107900610103F703@ESESSMB301.ericsson.se> <9E790F21-21D7-437B-820B-A88355047BBA@neustar.biz> <39B5E4D390E9BD4890E2B3107900610103FBB3@ESESSMB301.ericsson.se> <6E7FEA84-EBE2-4BE0-B8EA-67D5AD8CA9F2@neustar.biz> <50D08D29.2030303@mongrain.org> <39B5E4D390E9BD4890E2B3107900610104BB9D@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610104C240@ESESSMB301.ericsson.se> <5A55A45AE77F5941B18E5457ECAC818801214077118C@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC8188012140771193SISPE7MB1co_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA02SS0wTURSGc9uZdmgYHMqjl0ajNCEiBCnGmBoEjXFRXFkTNbpQxnZom9AO zhSkhgVQoTxSQgIoFpRXCUKUIqhBQBMxGAWMbFQkKAio5bExggQQdaYDyO6/53zn/+/NPZhY vowqMbPVRjFWMl0lkSGys6FpcT89Kp16YRxoJmqvI5q8xq+oxtV6B9VUlSUdQ7SrS+8kWo9n RaSteOBGtL7He04hF2RHDFS6OYti4pNTZaaKCRfIGFlFs/t/vEFzweI3tAQEYJA4CG+WdUsE HQ5HPns5LcPkRC+AnvU6kXDoANA73ywWDu0Ads/WAH5EQiTDF95RMa9Did1w6MOk31ZMMDBv Mt+vESIK/m2Z8vMhhBU+Ly0AAk/Dua7ZDX0A1vxeRHiNE6dh+/DARlgvCitnmv1QAKGDPU6X /66Au+vy4D2REKaAYzN1IuENBPT0vRULOgzOTv9BBT4Mjju9QOBp6PYUASEsGL6+NeMPlhNx MP/JEloOFO5ttu5tI+5tI26AcfV90NsTLyCRsLL0i1TQ0bCg9rZ0e70eSNuAQm/QsxbjVXXC fj1tsbB6OoPiVSfg/xlBfN1gqCO2HxAYUAXiKSdUOjlKZrF2Sz+IwESqMFzZwJWCLtMGu4lk TZeYzHSK7QcQE6tC8SIn18MNpP0axdCbrWgMI4ZmJgaBErHSVkoFcWcThwUzlJHKTjOnc2u2 iYqwAN4qkLNK4hmczSAtrNko9AdBLFb/fsoHMEfLdx+Q++2UCpzkUYJHTZnWLbc5oOCeEIKj 3NrKA7lt3vKZ4yJEXETbp0g+wkb+bylzAUMeV6dENYz+Wqd76hENsqK+iFbHLB2uKow5i55U vqwOpvqK40yHghYYmEzOrzkaj67t0CGtNuM585nyj7vsjunOgsTEV1W18Q9zstccA6k555vU 1RFPC8eCrzzLXJK0+VwlxWWR9q6d8P7UI6ktPH7vXbsHFA37kNQbgxMqhDWRCTFihiX/AYxw dS6KAwAA Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 22:02:34 -0000 --_000_5A55A45AE77F5941B18E5457ECAC8188012140771193SISPE7MB1co_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gdGhhdCBjYXNlLCBvbmUgbWlnaHQgc2F5IHN0YXRlIGluIHRoZSBoaWVyYXJjaHksIG5vdCBB MS4NCg0KQ2hlZXJzDQpKYW1lcw0KDQoNCkZyb206IFJpY2hhcmQgQmFybmVzIFttYWlsdG86cmxi QGlwdi5zeF0NClNlbnQ6IFR1ZXNkYXksIDE5IEZlYnJ1YXJ5IDIwMTMgODo1NyBBTQ0KVG86IFdp bnRlcmJvdHRvbSwgSmFtZXMNCkNjOiBEYW4gTW9uZ3JhaW47IEl2byBTZWRsYWNlazsgZWNyaXRA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRWNyaXRdIFdoYXQgaXMgdGhlIG1vc3QgYXBwcm9wcmlh dGUgbWV0aG9kIGZvciByZWdpc3RlcmluZyBuZXcgc3ViLXNlcnZpY2VzIG9mIHVybjpzZXJ2aWNl OnNvcw0KDQpJdCBtaWdodCBtYWtlIHNlbnNlIGlmIHlvdSB3YW50ZWQgdG8gYWxsb3cgdGhlIGNh bGxlciB0byBleHBsaWNpdGx5IHNlbGVjdCBwb2xpY2UgYXQgYSBkaWZmZXJlbnQgbGV2ZWwgb2Yg cmVzcG9uc2liaWxpdHksIGUuZy4sIHRoZSBzdGF0ZSBwb2xpY2UgcmF0aGVyIHRoYW4gdGhlIGxv Y2FsIHBvbGljZS4NCg0KT24gTW9uLCBGZWIgMTgsIDIwMTMgYXQgNDoyMSBQTSwgV2ludGVyYm90 dG9tLCBKYW1lcyA8SmFtZXMuV2ludGVyYm90dG9tQGNvbW1zY29wZS5jb208bWFpbHRvOkphbWVz LldpbnRlcmJvdHRvbUBjb21tc2NvcGUuY29tPj4gd3JvdGU6DQpJIHRoaW5rIEkgYW0gbWlzc2lu ZyBzb21ldGhpbmcgaGVyZSwgQTEgaXMgcGFydCBvZiB0aGUgbG9jYXRpb24sIHNvIHdoeSBkb2Vz IGl0IG5lZWQgdG8gYmUgaW4gdGhlIFVSTiBhdCBhbGw/DQpBcyBmYXIgYXMgSSB1bmRlcnN0YW5k IGN1cnJlbnQgZGVwbG95bWVudHMsIHRoZXkgdXNlIHRoZSBVUk4gdG8gc2VsZWN0IGEgbGF5ZXIg aW4gdGhlIEdJUyB0aGF0IGNvcnJlc3BvbmRzIHRvIHRoZSBzZXJ2aWNlIHR5cGUsIGFuZCB0aGVu IHVzZSBnZW9ncmFwaGljIGJvdW5kYXJpZXMgd2l0aGluIHRoYXQgbGF5ZXIgdG8gc2VsZWN0IHRo ZSBmaW5hbCBkZXN0aW5hdGlvbi4NCg0KRnJvbTogZWNyaXQtYm91bmNlc0BpZXRmLm9yZzxtYWls dG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIERhbiBNb25ncmFp bg0KU2VudDogVHVlc2RheSwgMTkgRmVicnVhcnkgMjAxMyA3OjMwIEFNDQoNClRvOiBJdm8gU2Vk bGFjZWsNCkNjOiBlY3JpdEBpZXRmLm9yZzxtYWlsdG86ZWNyaXRAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW0Vjcml0XSBXaGF0IGlzIHRoZSBtb3N0IGFwcHJvcHJpYXRlIG1ldGhvZCBmb3IgcmVn aXN0ZXJpbmcgbmV3IHN1Yi1zZXJ2aWNlcyBvZiB1cm46c2VydmljZTpzb3MNCg0KU29ycnkgZm9y IHJlc3BvbmRpbmcgbGF0ZSB0byB0aGlzIHRocmVhZCwgaXQga2luZGEgZmVsbCBpbnRvIGEgIGNy YWNr4oCmICBUaGUgY3VycmVudCB0aHJlYWQgcmVtaW5kZWQgbWUgdG8gY2hlY2sgdGhpcyBvbGQg dGhyZWFk4oCmDQoNCllvdSBhcmUgaW5kaWNhdGluZyB0aGF0IHdlIG5lZWQgdG8gcmVnaXN0ZXIg NzcgU2VydmljZSBVUk4gKDExIHNlcnZpY2Ugc3VidHlwZXMgKiA3IGp1cmlzZGljdGlvbiB0eXBl cyBiYXNlZCBvbiBSRkMgNDExOSkuICBJIGRvIG5vdCByZWNvbW1lbmQgdGhhdCB3ZSBjcmVhdGUg c28gbWFueSByZWdpc3RyYXRpb25zLiAgSW5zdGVhZCwgd2Ugc2hvdWxkIGFsbG93IGEgc2Vydmlj ZSBVUk4gdG8gYmUgc3VmZml4ZWQgd2l0aCBhIGp1cmlzZGljdGlvbmFsIHNjb3BlLiAgU28gdGhl IGZvbGxvd2luZyBTZXJ2aWNlIFVSTiBhcmUgYWxsIHZhbGlkOg0KDQp1cm46c2VydmljZTpzb3Mu cG9saWNlDQp1cm46c2VydmljZTpzb3MucG9saWNlLnRyYWZmaWMNCnVybjpzZXJ2aWNlOnNvcy5w b2xpY2UuQTENCnVybjpzZXJ2aWNlOnNvcy5wb2xpY2UudHJhZmZpYy5BMQ0KDQpRdWVzdGlvbiBp cywgZG8gd2Ugd2FudCB0byBsZWF2ZSBqdXJpc2RpY3Rpb25hbCBzY29wZSB0byBvbmx5IGJlIGFw cGxpY2FibGUgdG8gcG9saWNlIGJyYW5jaCBvciBhbnkgU2VydmljZSBVUk4/ICBJ4oCZZCBzYXkg dGhlIGxhdHRlciBhcyBpdCBpcyBhbHdheXMgdXAgdG8gdGhlIExvU1Qgc2VydmljZSBwcm92aXNp b25pbmcgKGJhc2VkIG9uIGxvY2FsIHBvbGljeSkgdG8gZGV0ZXJtaW5lIHdoYXQgaXMgbG9jYWxs eSBhY2NlcHRhYmxlLg0KDQpUaGFueCwNCkRhbg0KDQpPbiBUaHUsIERlYyAyMCwgMjAxMiBhdCAy OjUzIEFNLCBJdm8gU2VkbGFjZWsgPGl2by5zZWRsYWNla0Blcmljc3Nvbi5jb208bWFpbHRvOml2 by5zZWRsYWNla0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhlbGxvLA0KDQp0aGFua3MgZm9yIHRo ZSBwcm9wb3NhbCBhbmQgZm9yIHRoZSBjaGVjayBvZiB0aGUgQ2FuYWRpYW4gdXNhZ2UuDQoNCkxl dCdzIHRyeSB0byBhc3NpZ24gdGhlIHByb3Bvc2VkIHNlcnZpY2UgVVJOcyB0byB0aGUgV2lraXBl ZGlhIGxpc3Q6DQotIG11bmljaXBhbCBwb2xpY2UgKEN6ZWNoIFJlcHVibGljLCBQb2xhbmQpIC0+ IHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UuQTMNCi0gdG91cmlzdCBwb2xpY2UgKEVneXB0LCBHcmVl Y2UpIC0+IHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UudG91cmlzdA0KLSB0cmFmZmljIHBvbGljZSAo RWd5cHQsIFN1ZGFuLCBJbmRpYSwgUGFraXN0YW4sIFNhdWRpIEFyYWJpYSwgQWxiYW5pYSwgQXJt ZW5pYSwgQXplcmJhaWphbikgLT4gdXJuOnNlcnZpY2U6c29zLnBvbGljZS50cmFmZmljDQotIHN0 YXRlIHBvbGljZSAoSXRhbHkpIC0+IHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UuY291bnRyeQ0KLSBj dXN0b21zL2ZpbmFuY2lhbCBQb2xpY2UgKEl0YWx5KSAtPiBkb2VzIG5vdCBtYXRjaCAtIHdlIHBy b2JhYmx5IG5lZWQgdXJuOnNlcnZpY2U6c29zLnBvbGljZS5maW5hbmNpYWwgKG5ldykNCi0gZ2Vu ZGFybWVyaWUgKFJvbWFuaWEpIC0+IGRvZXMgbm90IG1hdGNoIC0gd2UgcHJvYmFibHkgbmVlZCB1 cm46c2VydmljZTpzb3MucG9saWNlLm1pbGl0YXJ5IChuZXcpDQotIGxvY2FsIHBvbGljZSAoU3Bh aW4pIC0+IHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UuQTMNCi0gQ2F0YWxhbiBwb2xpY2UgKFNwYWlu KSAtPiB1cm46c2VydmljZTpzb3MucG9saWNlLkExIChhIHBlcnNvbiB3aXRoIHNwYW5pc2gvY2F0 YWxhbiBiYWNrZ3JvdW5kIHNob3VsZCBjaGVjaykNCi0gY2l2aWwgZ3VhcmQgKFNwYWluKSAtPiBk b2VzIG5vdCBtYXRjaCAtIHdlIHByb2JhYmx5IG5lZWQgdXJuOnNlcnZpY2U6c29zLnBvbGljZS5t aWxpdGFyeSAobmV3KSAoYSBwZXJzb24gd2l0aCBzcGFuaXNoL2NhdGFsYW4gYmFja2dyb3VuZCBz aG91bGQgY2hlY2spDQotIFByb3ZpbmNpYWwgUG9saWNlIChDYW5hZGEpIC0gdXJuOnNlcnZpY2U6 c29zLnBvbGljZS5BMQ0KLSBTw7tyZXTDqSBkdSBRdcOpYmVjIChDYW5hZGEpIC0gdXJuOnNlcnZp Y2U6c29zLnBvbGljZS5BMQ0KLSBmZWRlcmFsIGhpZ2h3YXkgcG9saWNlIChCcmF6aWwpIC0+IHVy bjpzZXJ2aWNlOnNvcy5wb2xpY2UudHJhZmZpYw0KLSBmZWRlcmFsIHBvbGljZSAoQnJhemlsKSAt PiB1cm46c2VydmljZTpzb3MucG9saWNlLmNvdW50cnkNCi0gY2l2aWwgcG9saWNlIChCcmF6aWwp IC0+IGRvZXMgbm90IG1hdGNoIC0gd2UgcHJvYmFibHkgbmVlZCB1cm46c2VydmljZTpzb3MucG9s aWNlLmNpdmlsIChuZXcpDQotIHN0YXRlIGhpZ2h3YXkgcG9saWNlIChCcmF6aWwpIC0+IHVybjpz ZXJ2aWNlOnNvcy5wb2xpY2UuQTEudHJhZmZpYw0KLSBHQVVMQSAoQ29sb21iaWEpIC0+IGRvZXMg bm90IG1hdGNoIC0gd2UgcHJvYmFibHkgbmVlZCB1cm46c2VydmljZTpzb3MucG9saWNlLmFudGlr aWRuYXBwaW5nIChuZXcpDQoNCkkuZS4gd2Ugd291bGQgbmVlZCBhZGRpdGlvbmFsbHk6DQotIHVy bjpzZXJ2aWNlOnNvcy5wb2xpY2UuZmluYW5jaWFsDQotIHVybjpzZXJ2aWNlOnNvcy5wb2xpY2Uu bWlsaXRhcnkNCi0gdXJuOnNlcnZpY2U6c29zLnBvbGljZS5jaXZpbA0KLSB1cm46c2VydmljZTpz b3MucG9saWNlLmFudGlraWRuYXBwaW5nDQoNCklmIEkgdW5kZXJzdG9vZCBpdCBjb3JyZWN0bHks IGFsbCB0b2dldGhlciwgd2Ugd291bGQgbmVlZCA3NyBwb2xpY2UgcmVsYXRlZCBlbWVyZ2VuY3kg c2VydmljZSBVUk5zID0gKDcgKHNwZWNpYWxpemVkIHBvbGljZSBjb3JwIGJlbG93KSArIDQgKGFk ZGl0aW9uYWwgYWJvdmUpKSAqIDcgKG5vbWVuY2xhdHVyZSBzcGVjaWZpZWQgaW4gQ2l2aWMgQWRk cmVzc2VzIChSRkMgNDExOSkpLiBTZWVtcyBxdWl0ZSBhIGxvdC5Nb3Jlb3ZlciwgYSByZWd1bGF0 b3IgaW4gYSBjb3VudHJ5IGNhbiBkZWZpbmUgYSBuZXcgdHlwZSBvZiBhIHBvbGljZSByZWxhdGVk IGVtZXJnZW5jeSBzZXJ2aWNlIC0gaXQgZGVwZW5kcyBvbiBob3cgdGhlIGxhdyBlbmZvcmNlbWVu dCBpcyBzdHJ1Y3R1cmUgaW4gdGhlIGNvdW50cnkuIFRoZW4gdGhlIGxpc3Qgd2lsbCBncm93IGV2 ZW4gbW9yZS4gTWF5YmUgaXQgd291bGQgcmVhbGx5IGJlIGJldHRlciB0byBsZXQgcmVndWxhdG9y cyB0byBtYW5hZ2UgcGVyLWNvdW50cnkgc3ViLXJlZ2lzdHJpZXMuDQoNCktpbmQgcmVnYXJkcw0K DQpJdm8gU2VkbGFjZWsNCg0KDQoNClRoaXMgQ29tbXVuaWNhdGlvbiBpcyBDb25maWRlbnRpYWwu IFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1z IHNldCBvdXQgYXQgd3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyPGh0dHA6Ly93d3cu ZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXI+DQoNCkZyb206IERhbiBNb25ncmFpbiBbbWFp bHRvOmRhbkBtb25ncmFpbi5vcmddPG1haWx0bzpbbWFpbHRvOmRhbkBtb25ncmFpbi5vcmddPg0K U2VudDogMTkuIHByb3NpbmNlIDIwMTIgMTY6MDANClRvOiBJdm8gU2VkbGFjZWsNCkNjOiBlY3Jp dEBpZXRmLm9yZzxtYWlsdG86ZWNyaXRAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbRWNyaXRd IFdoYXQgaXMgdGhlIG1vc3QgYXBwcm9wcmlhdGUgbWV0aG9kIGZvciByZWdpc3RlcmluZyBuZXcg c3ViLXNlcnZpY2VzIG9mIHVybjpzZXJ2aWNlOnNvcw0KDQpJIGFsc28gcmVjb21tZW5kIHdlIGNy ZWF0ZSBwdXJwb3NlIGtleXdvcmRzIGluIG9yZGVyIHRvIHJlYWNoIGEgc3BlY2lhbGl6ZWQgcG9s aWNlIGNvcnAuICBTdWNoIGFzOg0Kc29zLnBvbGljZS5kcnVncw0Kc29zLnBvbGljZS50cmFmZmlj DQpzb3MucG9saWNlLmZpcmVhcm1zDQpzb3MucG9saWNlLmFsY29ob2wNCnNvcy5wb2xpY2UudG9i YWNjbw0Kc29zLnBvbGljZS50b3VyaXN0DQpzb3MucG9saWNlLmJvcmRlcg0KDQpUaGUgYWJvdmUg a2V5d29yZHMgY2FuIGJlIHV0aWxpemVkIHdpdGggdGVycml0b3JpYWwgZGVzaWduYXRpb25zIGlu IG9yZGVyIHRvIHNwZWNpZnkgYSBwYXJ0aWN1bGFyIHNlcnZpY2UgaWYgb2ZmZXJlZCBieSBtdWx0 aXBsZSBqdXJpc2RpY3Rpb25zLiAgRm9yIGV4YW1wbGUgaW4gdGhlIFVTOg0Kc29zLnBvbGljZS5j b3VudHJ5LmRydWdzIGNvdWxkIGJlIHVzZWQgdG8gcmVhY2ggdGhlIERFQSB3aGVyZWFzDQpzb3Mu cG9saWNlLkEzLmRydWdzIGNvdWxkIGJlIHVzZWQgdG8gcmVhY2ggdGhlIG5hcmNvdGljcyBkaXZp c2lvbiBvZiB0aGUgY2l0eSBwb2xpY2UuDQoNCkkgY2FuIGFuc3dlciBmb3IgQ2FuYWRhOg0Kc29z LnBvbGljZS5jb3VudHJ5IHdvdWxkIGJlIHRvIHJlYWNoIHRoZSBSb3lhbCBDYW5hZGlhbiBNb3Vu dGFpbiBQb2xpY2UgKFJDTVApDQpJbiB0aGUgcHJvdmluY2VzIG9mIE9udGFyaW8gYW5kIFF1w6li ZWMgd2hpY2ggaGF2ZSBwcm92aW5jYWwgcG9saWNlcywgdGhlbiBzb3MucG9saWNlLkExIGluIE9u dGFyaW8gd291bGQgcmVhY2ggdGhlIE9udGFyaW8gUHJvdmluY2lhbCBQb2xpY2UgKE9QUCkgYW5k IHNvcy5wb2xpY2UuQTEgaW4gUXXDqWJlYyB3b3VsZCByZWFjaCB0aGUgU3VyZXTDqSBkdSBRdcOp YmVjIChTUSkuDQpJbiBDYW5hZGEgd2UgZG8gbm90IGhhdmUgYSBwb2xpY2Ugc2VydmljZSBhdCB0 aGUgY291bnR5IGxldmVsICh3ZSBkbyBoYXZlIHNoZXJpZmYgZGVwYXJ0bWVudHMgYnV0IHRoZXkg YXJlIG1vcmUgZm9yIGNvdXJ0IGFuZCBqYWlsIHNlY3VyaXR5KS4NCkluIE9udGFyaW8gYW5kIFF1 w6liZWMsIGEgY2l0eSBtYXkgaGF2ZSBpdHMgcG9saWNlIHNlcnZpY2Ugb3RoZXJ3aXNlIHRoZSBw cm92aW5jaWFsIHBvbGljZSBvZmZlcnMgdGhlIHNlcnZpY2UuICBJbiB0aGUgcmVzdCBvZiBDYW5h ZGEsIGEgY2l0eSBtYXkgaGF2ZSBpdHMgcG9saWNlIHNlcnZpY2Ugb3RoZXJ3aXNlIHRoZSBSQ01Q IG9mZmVycyB0aGUgc2VydmljZS4NCg0KVGhhbngsDQpEYW4NCk9uIFdlZCwgRGVjIDE5LCAyMDEy IGF0IDc6MDIgQU0sIEl2byBTZWRsYWNlayA8aXZvLnNlZGxhY2VrQGVyaWNzc29uLmNvbTxtYWls dG86aXZvLnNlZGxhY2VrQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGVsbG8sDQoNCnRoYW5rcy4N Cg0KYm90aCBvcHRpb25zIChEYW4ncyBhbmQgQnJpYW4ncykgc2VlbWVkIHRvIHdvcmsgZm9yIHRo ZSBlbWVyZ2VuY3kgc2VydmljZXMgb2YgdGhlIHBvbGljZSBmb3JjZXMgaW4gdGhlIEN6ZWNoIHJl cHVibGljLg0KDQpGb3IgY29tcGxldGVuZXNzLCBJIGFsc28gY2hlY2tlZCB0aGUgZW1lcmdlbmN5 IHNlcnZpY2VzIG9mIHRoZSBwb2xpY2UgZm9yY2VzIG9mIG90aGVyIGNvdW50cmllcy4gV2lraXBl ZGlhIChodHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0VtZXJnZW5jeV90ZWxlcGhvbmVfbnVt YmVyKSBsaXN0cyB0aGUgZm9sbG93aW5nIG9uIHRvcCBvZiBlbWVyZ2VuY3kgc2VydmljZXMgb2Yg dGhlIHJlZ3VsYXIgcG9saWNlIGZvcmNlczoNCi0gbXVuaWNpcGFsIHBvbGljZSAoQ3plY2ggUmVw dWJsaWMsIFBvbGFuZCkgLT4gY2FuIG1hcCB0byB1cm46c2VydmljZTpzb3MucG9saWNlLmxvY2Fs IG9yIHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UuQTMNCi0gdG91cmlzdCBwb2xpY2UgKEVneXB0LCBH cmVlY2UpIC0+IGRvZXMgbm90IHNlZW0gdG8gZml0IGludG8gYW55IG9mIHRoZSBhbHRlcm5hdGl2 ZXMgc28gZmFyDQotIHRyYWZmaWMgcG9saWNlIChFZ3lwdCwgU3VkYW4sIEluZGlhLCBQYWtpc3Rh biwgU2F1ZGkgQXJhYmlhLCBBbGJhbmlhLCBBcm1lbmlhLCBBemVyYmFpamFuKSAtPiBkb2VzIG5v dCBzZWVtIHRvIGZpdCBpbnRvIGFueSBvZiB0aGUgYWx0ZXJuYXRpdmVzIHNvIGZhcg0KLSBzdGF0 ZSBwb2xpY2UgKEl0YWx5KSAtPiBjYW4gbWFwIHRvIHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UubmF0 aW9uYWwgb3IgdXJuOnNlcnZpY2U6c29zLnBvbGljZS5jb3VudHJ5DQotIGN1c3RvbXMvZmluYW5j aWFsIFBvbGljZSAoSXRhbHkpIC0+IGRvZXMgbm90IHNlZW0gdG8gZml0IGludG8gYW55IG9mIHRo ZSBhbHRlcm5hdGl2ZXMgc28gZmFyDQotIGdlbmRhcm1lcmllIChSb21hbmlhKSAtPiBkb2VzIG5v dCBzZWVtIHRvIGZpdCBpbnRvIGFueSBvZiB0aGUgYWx0ZXJuYXRpdmVzIHNvIGZhcg0KLSBsb2Nh bCBwb2xpY2UgKFNwYWluKSAtPiBjYW4gbWFwIHRvIHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UubG9j YWwgb3IgdXJuOnNlcnZpY2U6c29zLnBvbGljZS5BMw0KLSBDYXRhbGFuIHBvbGljZSAoU3BhaW4p IC0+IG1heWJlIHRoaXMgY291bGQgbWFwIHRvIHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UucmVnaW9u YWwgb3IgdXJuOnNlcnZpY2U6c29zLnBvbGljZS5BMSBidXQgYSBwZXJzb24gd2l0aCBzcGFuaXNo L2NhdGFsYW4gYmFja2dyb3VuZCBzaG91bGQgY2hlY2suDQotIGNpdmlsIGd1YXJkIChTcGFpbikg LT4gZG9lcyBub3Qgc2VlbSB0byBmaXQgaW50byBhbnkgb2YgdGhlIGFsdGVybmF0aXZlcyBzbyBm YXINCi0gUHJvdmluY2lhbCBQb2xpY2UgKENhbmFkYSkgLSBtYXliZSB0aGlzIGNvdWxkIG1hcCB0 byB1cm46c2VydmljZTpzb3MucG9saWNlLnJlZ2lvbmFsIG9yIHVybjpzZXJ2aWNlOnNvcy5wb2xp Y2UuQTEgYnV0IGEgcGVyc29uIHdpdGggY2FuYWRpYW4gYmFja2dyb3VuZCBzaG91bGQgY2hlY2sN Ci0gU8O7cmV0w6kgZHUgUXXDqWJlYyAoQ2FuYWRhKSAtIG1heWJlIHRoaXMgY291bGQgbWFwIHRv IHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UucmVnaW9uYWwgb3IgdXJuOnNlcnZpY2U6c29zLnBvbGlj ZS5BMSBidXQgYSBwZXJzb24gd2l0aCBjYW5hZGlhbiBiYWNrZ3JvdW5kIHNob3VsZCBjaGVjaw0K LSBmZWRlcmFsIGhpZ2h3YXkgcG9saWNlIChCcmF6aWwpIC0+IGRvZXMgbm90IHNlZW0gdG8gZml0 IGludG8gYW55IG9mIHRoZSBhbHRlcm5hdGl2ZXMgc28gZmFyDQotIGZlZGVyYWwgcG9saWNlIChC cmF6aWwpIC0+IGNhbiBtYXAgdG8gdXJuOnNlcnZpY2U6c29zLnBvbGljZS5uYXRpb25hbCBvciB1 cm46c2VydmljZTpzb3MucG9saWNlLmNvdW50cnkNCi0gY2l2aWwgcG9saWNlIChCcmF6aWwpIC0+ IGRvZXMgbm90IHNlZW0gdG8gZml0IGludG8gYW55IG9mIHRoZSBhbHRlcm5hdGl2ZXMgc28gZmFy DQotIHN0YXRlIGhpZ2h3YXkgcG9saWNlIChCcmF6aWwpIC0+IGRvZXMgbm90IHNlZW0gdG8gZml0 IGludG8gYW55IG9mIHRoZSBhbHRlcm5hdGl2ZXMgc28gZmFyDQotIEdBVUxBIChDb2xvbWJpYSkg LT4gZG9lcyBub3Qgc2VlbSB0byBmaXQgaW50byBhbnkgb2YgdGhlIGFsdGVybmF0aXZlcyBzbyBm YXINCg0KRm9yIHRob3NlIGVtZXJnZW5jeSBzZXJ2aWNlcyBhYm92ZSBub3QgZml0dGluZyBpbnRv IGFueSBvZiB0aGUgYWx0ZXJuYXRpdmVzLCBob3cgc2hvdWxkIHRoZXkgYmUgZXhwcmVzc2VkIGlu IGFuIGVtZXJnZW5jeSBzZXJ2aWNlIFVSTj8gRG8gd2UgYXNzdW1lIElBTkEgd2lsbCByZWdpc3Rl ciB0aGVtIHRvbz8NCg0KS2luZCByZWdhcmRzDQoNCkl2byBTZWRsYWNlaw0KDQoNClRoaXMgQ29t bXVuaWNhdGlvbiBpcyBDb25maWRlbnRpYWwuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFp bCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQgd3d3LmVyaWNzc29uLmNvbS9l bWFpbF9kaXNjbGFpbWVyPGh0dHA6Ly93d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXI+ DQoNCkZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0 Zi5vcmc+IFttYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZWNyaXQtYm91bmNl c0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBEYW4gTW9uZ3JhaW4sIGVuZy4NClNlbnQ6IDE4LiBw cm9zaW5jZSAyMDEyIDE2OjM1DQpUbzogZWNyaXRAaWV0Zi5vcmc8bWFpbHRvOmVjcml0QGlldGYu b3JnPg0KDQpTdWJqZWN0OiBSZTogW0Vjcml0XSBXaGF0IGlzIHRoZSBtb3N0IGFwcHJvcHJpYXRl IG1ldGhvZCBmb3IgcmVnaXN0ZXJpbmcgbmV3IHN1Yi1zZXJ2aWNlcyBvZiB1cm46c2VydmljZTpz b3MNCg0KSW5zdGVhZCBvZiB0cnlpbmcgdG8gY29tZSB1cCB3aXRoIHRoZSBwcm9wZXIgbm9tZW5j bGF0dXJlIGZvciB0aGUganVyaXNkaWN0aW9uIHRvIGJlIHVzZWQgaW4gdGhlIFNlcnZpY2UgVVJO LCB3aHkgbm90IHV0aWxpemUgdGhlIG5vbWVuY2xhdHVyZSBzcGVjaWZpZWQgaW4gQ2l2aWMgQWRk cmVzc2VzIChSRkMgNDExOSk6DQpzb3MucG9saWNlLmNvdW50cnkgZm9yIHBvbGljZSBzZXJ2aWNl cyBhdCB0aGUgY291bnRyeS9uYXRpb25hbC9mZWRlcmFsL2V0YyBsZXZlbA0Kc29zLnBvbGljZS5B MSBmb3IgcG9saWNlIHNlcnZpY2VzIGF0IHRoZSBzdGF0ZS9wcm92aW5jZS9yZWdpb24vcHJlZmVj dHVyZS9ldGMgbGV2ZWwNCnNvcy5wb2xpY2UuQTIgZm9yIHBvbGljZSBzZXJ2aWNlcyBhdCB0aGUg Y291bnR5L3BhcmlzaC9ndW4vZGlzdHJpY3QvZXRjIGxldmVsDQpzb3MucG9saWNlLkEzIGZvciBw b2xpY2Ugc2VydmljZXMgYXQgdGhlIGNpdHkvdG93bnNoaXAvc2hpL2V0YyBsZXZlbA0Kc29zLnBv bGljZS5BNCBmb3IgcG9saWNlIHNlcnZpY2VzIGF0IHRoZSBjaXR5IGRpdmlzaW9uL2Jvcm91Z2gv Y2l0eSBkaXN0cmljdC93YXJkL2Nob3UvZXRjIGxldmVsDQpzb3MucG9saWNlLkE1IGZvciBwb2xp Y2Ugc2VydmljZXMgYXQgdGhlIG5laWdoYm9yaG9vZC9ibG9jay9ldGMgbGV2ZWwNCg0KVGhpcyB3 YXkgd2UgYXZvaWQgaGF2aW5nIHRvIHBpY2sgYSB0ZXJtIHRoYXQgaGFzIG5vIGFwcGxpY2FiaWxp dHkgaW4gY2VydGFpbiBjb3VudHJpZXMuDQoNClRoYW54LA0KRGFuDQoNCk9uIDE0LzEyLzIwMTIg OToxMiBBTSwgUm9zZW4sIEJyaWFuIHdyb3RlOg0KSSBoYXZlIG5vIHByb2JsZW0gdXNpbmcgIm5h dGlvbmFsIiBpbnN0ZWFkIG9mICJmZWRlcmFsIi4NCiJTdGF0ZSIgYW5kICJQcm92aW5jZSIgYXJl IGVxdWl2YWxlbnQuICBTb21lIGNvdW50cmllcyBoYXZlIG9uZSwgc29tZSBoYXZlIHRoZSBvdGhl ci4gIEkgZG9uJ3QgdGhpbmsgdGhlcmUgYXJlIGFueSB3aXRoIGJvdGguICBTb21lIGhhdmUgbmVp dGhlciBvZiBjb3Vyc2UuDQoNCkknZCBwcmVmZXIgbm90IHRvIGhhdmUgbmF0aW9uLXNwZWNpZmlj IHZhbHVlcy4NCg0KQnJpYW4NCk9uIERlYyAxNCwgMjAxMiwgYXQgMzo0OCBBTSwgSXZvIFNlZGxh Y2VrIDxpdm8uc2VkbGFjZWtAZXJpY3Nzb24uY29tPG1haWx0bzppdm8uc2VkbGFjZWtAZXJpY3Nz b24uY29tPj4gd3JvdGU6DQoNCkhlbGxvLA0KDQp0aGFuayB5b3UgZm9yIHlvdXIgbWFpbC4NCg0K PiBJJ2Qgc3VwcG9ydCBhbm90aGVyIChvcHRpb25hbCkgbGV2ZWwgb2YgcG9saWNlIHdpdGggYXQg bGVhc3QgNCB2YWx1ZXMuDQo+DQo+IFBlcmhhcHMgImxvY2FsIi8icmVnaW9uYWwiLyJwcm92aW5j aWFsIi8iZmVkZXJhbCINCg0KaWYgSSB1bmRlcnN0b29kIGNvcnJlY3RseSwgeW91IHByb3Bvc2Ug dGhhdDoNCi0gdXJuOnNlcnZpY2U6c29zLmxvY2FsLA0KLSB1cm46c2VydmljZTpzb3MucmVnaW9u YWwsDQotIHVybjpzZXJ2aWNlOnNvcy5wcm92aW5jaWFsLA0KLSB1cm46c2VydmljZTpzb3MuZmVk ZXJhbA0KYXJlIHJlZ2lzdGVyZWQuIGlmIEkgbWlzdW5kZXJzdG9vZCwgcGxlYXNlIGNvcnJlY3Qg bWUuDQoNCnVybjpzZXJ2aWNlOnNvcy5sb2NhbCB3b3VsZCBtYXAgd2VsbCB0byB0aGUgZW1lcmdl bmN5IHNlcnZpY2UgcHJvdmlkZWQgYnkgdGhlIG11bmljaXBhbCBwb2xpY2UgaW4gdGhlIEN6ZWNo IHJlcHVibGljLg0KDQpIb3dldmVyLCB0aGUgZW1lcmdlbmN5IHNlcnZpY2UgcHJvdmlkZWQgYnkg dGhlIG5hdGlvbmFsIHBvbGljZSBpbiB0aGUgQ3plY2ggcmVwdWJsaWMgaXMgbm90IGVhc2lseSBt YXBwZWQgdG8gYW55IG9mIHRoZSB2YWx1ZXM6DQotIEN6ZWNoIHJlcHVibGljIGhhcyBwcm92aW5j ZXMgKCJrcmFqIikgYnV0IHRoZSBwcm92aW5jZXMgKHNvIGZhcikgZG8gbm90IGhhdmUgdGhlaXIg b3duIHBvbGljZSBmb3JjZS4NCi0gQ3plY2ggcmVwdWJsaWMgaXMgbm90IGEgZmVkZXJhdGlvbiBz byAiZmVkZXJhbCIgZG9lcyBub3QgZml0IGVpdGhlci4NCg0KUGVyaGFwcyB0aGUgZm9sbG93aW5n IHNob3VsZCBiZSBkZWZpbmVkOiB1cm46c2VydmljZTpzb3MubG9jYWwsIHVybjpzZXJ2aWNlOnNv cy5yZWdpb25hbCwgdXJuOnNlcnZpY2U6c29zLnN0YXRlLCB1cm46c2VydmljZTpzb3MuZmVkZXJh bA0KDQpBbHRlcm5hdGl2ZWx5LCBzdWJyZWdpc3RyaWVzIGNhbiBiZSBjcmVhdGVkIGZvciBlYWNo IGNvdW50cnkgd2hlcmUgdGhlIHJlZ3VsYXRvciBvZiB0aGUgY291bnRyeSB3b3VsZCBtYW5hZ2Ug dGhlIGVtZXJnZW5jeSBzZXJ2aWNlIFVSTnMgZm9yIHRoZSBjb3VudHJ5IHNwZWNpZmljIGVtZXJn ZW5jeSBzZXJ2aWNlcyAoIGh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvRW1lcmdlbmN5X3Rl bGVwaG9uZV9udW1iZXIgc2VlbXMgdG8gbGlzdCBxdWl0ZSBhIGxvdCBvZiB0aG9zZSApDQoNCktp bmQgcmVnYXJkcw0KDQpJdm8gU2VkbGFjZWsNCg0KDQpUaGlzIENvbW11bmljYXRpb24gaXMgQ29u ZmlkZW50aWFsLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9m IHRoZSB0ZXJtcyBzZXQgb3V0IGF0IHd3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lcjxo dHRwOi8vd3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyPg0KDQpGcm9tOiBSb3Nlbiwg QnJpYW4gW21haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpel0NClNlbnQ6IDEzLiBwcm9zaW5j ZSAyMDEyIDE1OjQxDQpUbzogSXZvIFNlZGxhY2VrDQpDYzogZWNyaXRAaWV0Zi5vcmc8bWFpbHRv OmVjcml0QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtFY3JpdF0gV2hhdCBpcyB0aGUgbW9zdCBh cHByb3ByaWF0ZSBtZXRob2QgZm9yIHJlZ2lzdGVyaW5nIG5ldyBzdWItc2VydmljZXMgb2YgdXJu OnNlcnZpY2U6c29zDQoNClRoYXQgaXNzdWUgb2NjdXJzIGluIHNldmVyYWwgb3RoZXIgY291bnRy aWVzLg0KVGhlcmUgYXJlIG9mdGVuIDMgb3IgbW9yZSBwb2xpY2UgYWdlbmNpZXMgc2VydmluZyBh biBhcmVhLiAgSW4gbXkgaG9tZSwgdGhlcmUgYXJlIGZvdXI6DQphKSBBIGxvY2FsICh0b3duc2hp cCkgcG9saWNlDQpiKSBBIGNvdW50eSBwb2xpY2UgYWdlbmN5IHRoYXQgcmVzcG9uZHMgdG8gc29t ZSB1bmNvbW1vbiBldmVudHMNCmMpIEEgc3RhdGUgcG9saWNlIGFnZW5jeSwgd2hpY2ggYWxzbyBo YXMganVyaXNkaWN0aW9uIGluIHNvbWUgY2lyY3Vtc3RhbmNlcw0KZCkgVGhlIGZlZGVyYWwgcG9s aWNlIChGQkkpDQoNCldoaWxlIHdlIGRvIGhhdmUgYSBzaW5nbGUgbnVtYmVyLCBpZiB5b3UgZXhw bGljaXRseSB3YW50ZWQgdGhlIHN0YXRlIHBvbGljZSwgdGhlcmUgaXMgbm8gd2F5IHRvIGdldCB0 byB0aGVtLg0KDQpJJ2Qgc3VwcG9ydCBhbm90aGVyIChvcHRpb25hbCkgbGV2ZWwgb2YgcG9saWNl IHdpdGggYXQgbGVhc3QgNCB2YWx1ZXMuDQoNClBlcmhhcHMgImxvY2FsIi8icmVnaW9uYWwiLyJw cm92aW5jaWFsIi8iZmVkZXJhbCINCg0KQnJpYW4NCk9uIERlYyAxMywgMjAxMiwgYXQgODoyMiBB TSwgSXZvIFNlZGxhY2VrIDxpdm8uc2VkbGFjZWtAZXJpY3Nzb24uY29tPG1haWx0bzppdm8uc2Vk bGFjZWtAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQoNCkhlbGxvLA0KDQppbiB0aGUgQ3plY2ggcmVw dWJsaWMsIHRoZSBuYXRpb25hbCByZWd1bGF0b3IgZGVmaW5lZCB0d28gcG9saWNlIHJlbGF0ZWQg ZW1lcmdlbmN5IHNlcnZpY2VzOg0KQSkgZW1lcmdlbmN5IHNlcnZpY2UgcHJvdmlkZWQgYnkgdGhl IG5hdGlvbmFsIHBvbGljZSAobnVtYmVyIDE1OCBpbiB0aGUgcHVibGljIHN3aXRjaGVkIHRlbGVw aG9uZSBuZXR3b3JrKTsgYW5kDQpCKSBlbWVyZ2VuY3kgc2VydmljZSBwcm92aWRlZCBieSB0aGUg bXVuaWNpcGFsIHBvbGljZSAobnVtYmVyIDE1NiBpbiB0aGUgcHVibGljIHN3aXRjaGVkIHRlbGVw aG9uZSBuZXR3b3JrKS4NCg0KVGhlIHJlZ3VsYXRpb24gaXMgaHR0cDovL2FwbGlrYWNlLm12Y3Iu Y3ovYXJjaGl2MjAwOC9zYmlya2EvMjAwNy9zYjA0My0wNy5wZGYgd2hpY2ggbGlzdHMgdGhlIG51 bWJlcnMgMTU2IGFuZCAxNTggaW4gc2VjdGlvbiA0LjUuIHdpdGggbm90ZSAyKSB3aGljaCBzdGF0 ZXMgIsSMw61zbG8gamUgbsOhcm9kbsOtbSDEjcOtc2xlbSBwcm8gdMOtc8WIb3bDqSB2b2zDoW7D rSIgKD0gdGhlIG51bWJlciBpcyBhIG5hdGlvbmFsIG51bWJlciBmb3IgZW1lcmdlbmN5IGNhbGxz KS4NCg0KSXMgaXQgYXBwcm9wcmlhdGUgdG8gcmVnaXN0ZXIgdGhlIGZvbGxvd2luZyBVUk5zIGZv ciB0aG9zZSBzZXJ2aWNlcyB3aXRoIElBTkE/DQotIHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UubmF0 aW9uYWwgLSBUaGUgJ3BvbGljZS5uYXRpb25hbCcgc2VydmljZSByZWZlcnMgdG8gdGhlIHBvbGlj ZSBkZXBhcnRtZW50IG9yIG90aGVyIGxhdyBlbmZvcmNlbWVudCBhdXRob3JpdGllcyBvZiB0aGUg bmF0aW9uYWwgZ292ZXJubWVudC4NCi0gdXJuOnNlcnZpY2U6c29zLnBvbGljZS5tdW5pY2lwYWwg LSBUaGUgJ3BvbGljZS5tdW5pY2lwYWwnIHNlcnZpY2UgcmVmZXJzIHRvIHRoZSBwb2xpY2UgZGVw YXJ0bWVudCBvciBvdGhlciBsYXcgZW5mb3JjZW1lbnQgYXV0aG9yaXRpZXMgb2YgdGhlIG11bmlj aXBhbCBhdXRob3JpdGllcy4NCg0KT3Igc2hvdWxkIHRob3NlIGJlIHJlZ2lzdGVyZWQgd2l0aCBh IHByZWZpeCBpbmRpY2F0aW5nIHRoYXQgdGhvc2UgYXJlIGFwcGxpY2FibGUgdG8gQ3plY2ggcmVw dWJsaWMgb25seSwgYXMgb3RoZXIgY291bnRyaWVzIG1heSBoYXZlIHNpbWlsYXIgKGJ1dCBub3Qg bmVjZXNzYXJpbHkgaWRlbnRpY2FsKSBzZXJ2aWNlczoNCi0gdXJuOnNlcnZpY2U6c29zLnBvbGlj ZS5jemVjaC5uYXRpb25hbCAtIFRoZSAncG9saWNlLmN6ZWNoLm5hdGlvbmFsJyBzZXJ2aWNlIHJl ZmVycyB0byB0aGUgcG9saWNlIGRlcGFydG1lbnQgb3Igb3RoZXIgbGF3IGVuZm9yY2VtZW50IGF1 dGhvcml0aWVzIG9mIHRoZSBuYXRpb25hbCBnb3Zlcm5tZW50Lg0KLSB1cm46c2VydmljZTpzb3Mu cG9saWNlLmN6ZWNoLm11bmljaXBhbCAtIFRoZSAncG9saWNlLmN6ZWNoLm11bmljaXBhbCcgc2Vy dmljZSByZWZlcnMgdG8gdGhlIHBvbGljZSBkZXBhcnRtZW50IG9yIG90aGVyIGxhdyBlbmZvcmNl bWVudCBhdXRob3JpdGllcyBvZiBtdW5pY2lwYWwgYXV0aG9yaXRpZXMuDQoNCkkgYXNzdW1lIHRo aXMgcXVlc3Rpb24gYmVsb25ncyB0byBJQU5BLCBidXQgYXMgdGhlIGV4cGVydCByZXZpZXdlciBt b3N0IGxpa2VseSB3aWxsIGJlIGZyb20gdGhlIEVDUklULCBJIGFtIHNlbmRpbmcgaXQgaGVyZS4N Cg0KS2luZCByZWdhcmRzDQoNCkl2byBTZWRsYWNlaw0KDQoNClRoaXMgQ29tbXVuaWNhdGlvbiBp cyBDb25maWRlbnRpYWwuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFz aXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXR3d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWlt ZXI8aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lcj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpFY3JpdCBtYWlsaW5nIGxpc3QN CkVjcml0QGlldGYub3JnPG1haWx0bzpFY3JpdEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRWNyaXQgbWFpbGluZyBsaXN0DQoNCkVjcml0 QGlldGYub3JnPG1haWx0bzpFY3JpdEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KRWNyaXQgbWFpbGluZyBsaXN0DQpFY3JpdEBpZXRmLm9y ZzxtYWlsdG86RWNyaXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2Vjcml0DQoNCg== --_000_5A55A45AE77F5941B18E5457ECAC8188012140771193SISPE7MB1co_ 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 MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0 ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJs dWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkluIHRoYXQgY2FzZSwgb25lIG1pZ2h0IHNheSBzdGF0 ZSBpbiB0aGUgaGllcmFyY2h5LCBub3QgQTEuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5DaGVlcnM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+SmFtZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIic+IFJpY2hhcmQgQmFybmVzIFttYWlsdG86cmxiQGlwdi5zeF0g PGJyPjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCAxOSBGZWJydWFyeSAyMDEzIDg6NTcgQU08YnI+PGI+ VG86PC9iPiBXaW50ZXJib3R0b20sIEphbWVzPGJyPjxiPkNjOjwvYj4gRGFuIE1vbmdyYWluOyBJ dm8gU2VkbGFjZWs7IGVjcml0QGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW0Vjcml0 XSBXaGF0IGlzIHRoZSBtb3N0IGFwcHJvcHJpYXRlIG1ldGhvZCBmb3IgcmVnaXN0ZXJpbmcgbmV3 IHN1Yi1zZXJ2aWNlcyBvZiB1cm46c2VydmljZTpzb3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPkl0IG1pZ2h0IG1ha2Ugc2Vuc2UgaWYgeW91IHdhbnRlZCB0byBhbGxvdyB0aGUg Y2FsbGVyIHRvIGV4cGxpY2l0bHkgc2VsZWN0IHBvbGljZSBhdCBhIGRpZmZlcmVudCBsZXZlbCBv ZiByZXNwb25zaWJpbGl0eSwgZS5nLiwgdGhlIHN0YXRlIHBvbGljZSByYXRoZXIgdGhhbiB0aGUg bG9jYWwgcG9saWNlLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9uIE1vbiwgRmViIDE4LCAyMDEzIGF0IDQ6MjEgUE0s IFdpbnRlcmJvdHRvbSwgSmFtZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpKYW1lcy5XaW50ZXJib3R0 b21AY29tbXNjb3BlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkphbWVzLldpbnRlcmJvdHRvbUBjb21t c2NvcGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSB0aGluayBJIGFtIG1pc3Npbmcg c29tZXRoaW5nIGhlcmUsIEExIGlzIHBhcnQgb2YgdGhlIGxvY2F0aW9uLCBzbyB3aHkgZG9lcyBp dCBuZWVkIHRvIGJlIGluIHRoZSBVUk4gYXQgYWxsPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkFzIGZhciBhcyBJIHVuZGVy c3RhbmQgY3VycmVudCBkZXBsb3ltZW50cywgdGhleSB1c2UgdGhlIFVSTiB0byBzZWxlY3QgYSBs YXllciBpbiB0aGUgR0lTIHRoYXQgY29ycmVzcG9uZHMgdG8gdGhlIHNlcnZpY2UgdHlwZSwgYW5k IHRoZW4gdXNlIGdlb2dyYXBoaWMgYm91bmRhcmllcyB3aXRoaW4gdGhhdCBsYXllciB0byBzZWxl Y3QgdGhlIGZpbmFsIGRlc3RpbmF0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PGI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gPGEgaHJlZj0ibWFpbHRvOmVjcml0LWJvdW5j ZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5lY3JpdC1ib3VuY2VzQGlldGYub3JnPC9hPiBb bWFpbHRvOjxhIGhyZWY9Im1haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+ZWNyaXQtYm91bmNlc0BpZXRmLm9yZzwvYT5dIDxiPk9uIEJlaGFsZiBPZiA8L2I+RGFu IE1vbmdyYWluPGJyPjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCAxOSBGZWJydWFyeSAyMDEzIDc6MzAg QU08L3NwYW4+PG86cD48L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48YnI+ PGI+VG86PC9iPiBJdm8gU2VkbGFjZWs8YnI+PGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86ZWNy aXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5lY3JpdEBpZXRmLm9yZzwvYT48YnI+PGI+U3Vi amVjdDo8L2I+IFJlOiBbRWNyaXRdIFdoYXQgaXMgdGhlIG1vc3QgYXBwcm9wcmlhdGUgbWV0aG9k IGZvciByZWdpc3RlcmluZyBuZXcgc3ViLXNlcnZpY2VzIG9mIHVybjpzZXJ2aWNlOnNvczxvOnA+ PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Jz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPlNvcnJ5IGZvciByZXNwb25kaW5nIGxhdGUgdG8gdGhpcyB0aHJlYWQsIGl0IGtp bmRhIGZlbGwgaW50byBhJm5ic3A7IGNyYWNr4oCmJm5ic3A7IFRoZSBjdXJyZW50IHRocmVhZCBy ZW1pbmRlZCBtZSB0byBjaGVjayB0aGlzIG9sZCB0aHJlYWTigKY8L3NwYW4+PG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5Zb3UgYXJlIGluZGljYXRpbmcgdGhhdCB3ZSBuZWVkIHRvIHJlZ2lzdGVyIDc3IFNlcnZp Y2UgVVJOICgxMSBzZXJ2aWNlIHN1YnR5cGVzICogNyBqdXJpc2RpY3Rpb24gdHlwZXMgYmFzZWQg b24gUkZDIDQxMTkpLiZuYnNwOyBJIGRvIG5vdCByZWNvbW1lbmQgdGhhdCB3ZSBjcmVhdGUgc28g bWFueSByZWdpc3RyYXRpb25zLiZuYnNwOyBJbnN0ZWFkLCB3ZSBzaG91bGQgYWxsb3cgYSBzZXJ2 aWNlIFVSTiB0byBiZSBzdWZmaXhlZCB3aXRoIGEganVyaXNkaWN0aW9uYWwgc2NvcGUuJm5ic3A7 IFNvIHRoZSBmb2xsb3dpbmcgU2VydmljZSBVUk4gYXJlIGFsbCB2YWxpZDo8L3NwYW4+PG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz51cm46c2VydmljZTpzb3MucG9saWNlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+dXJuOnNlcnZpY2U6c29z LnBvbGljZS50cmFmZmljPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8n PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+dXJuOnNlcnZpY2U6c29zLnBvbGljZS5BMTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PnVybjpzZXJ2aWNlOnNvcy5wb2xpY2UudHJhZmZpYy5BMTwvc3Bhbj48bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PlF1ZXN0aW9uIGlzLCBkbyB3ZSB3YW50IHRvIGxlYXZlIGp1cmlzZGljdGlvbmFsIHNjb3BlIHRv IG9ubHkgYmUgYXBwbGljYWJsZSB0byBwb2xpY2UgYnJhbmNoIG9yIGFueSBTZXJ2aWNlIFVSTj8g Jm5ic3A7SeKAmWQgc2F5IHRoZSBsYXR0ZXIgYXMgaXQgaXMgYWx3YXlzIHVwIHRvIHRoZSBMb1NU IHNlcnZpY2UgcHJvdmlzaW9uaW5nIChiYXNlZCBvbiBsb2NhbCBwb2xpY3kpIHRvIGRldGVybWlu ZSB3aGF0IGlzIGxvY2FsbHkgYWNjZXB0YWJsZS48L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGFu eCw8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5EYW48L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCc+Jm5ic3A7 PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz5PbiBUaHUsIERlYyAyMCwg MjAxMiBhdCAyOjUzIEFNLCBJdm8gU2VkbGFjZWsgJmx0OzxhIGhyZWY9Im1haWx0bzppdm8uc2Vk bGFjZWtAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+aXZvLnNlZGxhY2VrQGVyaWNzc29u LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz5IZWxsbyw8L3NwYW4+PG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPnRo YW5rcyBmb3IgdGhlIHByb3Bvc2FsIGFuZCBmb3IgdGhlIGNoZWNrIG9mIHRoZSBDYW5hZGlhbiB1 c2FnZS48L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6I0MwNTA0RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPkxldCdzIHRyeSB0byBhc3NpZ24gdGhlIHByb3Bvc2Vk IHNlcnZpY2UgVVJOcyB0byB0aGUgV2lraXBlZGlhIGxpc3Q6PC9zcGFuPjxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPi0gbXVuaWNpcGFsIHBv bGljZSAoQ3plY2ggUmVwdWJsaWMsIFBvbGFuZCkgLSZndDsgdXJuOnNlcnZpY2U6c29zLnBvbGlj ZS5BMyA8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6I0MwNTA0RCc+LSB0b3VyaXN0IHBvbGljZSAoRWd5cHQsIEdyZWVjZSkgLSZndDsgdXJuOnNl cnZpY2U6c29zLnBvbGljZS50b3VyaXN0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPi0gdHJhZmZpYyBwb2xpY2UgKEVneXB0LCBT dWRhbiwgSW5kaWEsIFBha2lzdGFuLCBTYXVkaSBBcmFiaWEsIEFsYmFuaWEsIEFybWVuaWEsIEF6 ZXJiYWlqYW4pIC0mZ3Q7IHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UudHJhZmZpYzwvc3Bhbj48bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4tIHN0 YXRlIHBvbGljZSAoSXRhbHkpIC0mZ3Q7IHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UuY291bnRyeTwv c3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1 MDREJz4tIGN1c3RvbXMvZmluYW5jaWFsIFBvbGljZSAoSXRhbHkpIC0mZ3Q7IGRvZXMgbm90IG1h dGNoIC0gd2UgcHJvYmFibHkgbmVlZCB1cm46c2VydmljZTpzb3MucG9saWNlLmZpbmFuY2lhbCAo bmV3KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xv cjojQzA1MDREJz4tIGdlbmRhcm1lcmllIChSb21hbmlhKSAtJmd0OyBkb2VzIG5vdCBtYXRjaCAt IHdlIHByb2JhYmx5IG5lZWQgdXJuOnNlcnZpY2U6c29zLnBvbGljZS5taWxpdGFyeSAobmV3KTwv c3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1 MDREJz4tIGxvY2FsIHBvbGljZSAoU3BhaW4pIC0mZ3Q7IHVybjpzZXJ2aWNlOnNvcy5wb2xpY2Uu QTM8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6 I0MwNTA0RCc+LSBDYXRhbGFuIHBvbGljZSAoU3BhaW4pIC0mZ3Q7IHVybjpzZXJ2aWNlOnNvcy5w b2xpY2UuQTEgKGEgcGVyc29uIHdpdGggc3BhbmlzaC9jYXRhbGFuIGJhY2tncm91bmQgc2hvdWxk IGNoZWNrKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtj b2xvcjojQzA1MDREJz4tIGNpdmlsIGd1YXJkIChTcGFpbikgLSZndDsgZG9lcyBub3QgbWF0Y2gg LSB3ZSBwcm9iYWJseSBuZWVkIHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UubWlsaXRhcnkgKG5ldykg KGEgcGVyc29uIHdpdGggc3BhbmlzaC9jYXRhbGFuIGJhY2tncm91bmQgc2hvdWxkIGNoZWNrKTwv c3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1 MDREJz4tIFByb3ZpbmNpYWwgUG9saWNlIChDYW5hZGEpIC0gdXJuOnNlcnZpY2U6c29zLnBvbGlj ZS5BMTwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xv cjojQzA1MDREJz4tIFPDu3JldMOpIGR1IFF1w6liZWMgKENhbmFkYSkgLSB1cm46c2VydmljZTpz b3MucG9saWNlLkExPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiO2NvbG9yOiNDMDUwNEQnPi0gZmVkZXJhbCBoaWdod2F5IHBvbGljZSAoQnJhemlsKSAtJmd0 OyB1cm46c2VydmljZTpzb3MucG9saWNlLnRyYWZmaWM8L3NwYW4+PG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+LSBmZWRlcmFsIHBvbGljZSAo QnJhemlsKSAtJmd0OyB1cm46c2VydmljZTpzb3MucG9saWNlLmNvdW50cnk8L3NwYW4+PG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+LSBjaXZp bCBwb2xpY2UgKEJyYXppbCkgLSZndDsgZG9lcyBub3QgbWF0Y2ggLSB3ZSBwcm9iYWJseSBuZWVk IHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UuY2l2aWwgKG5ldyk8L3NwYW4+PG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+LSBzdGF0ZSBoaWdod2F5 IHBvbGljZSAoQnJhemlsKSAtJmd0OyB1cm46c2VydmljZTpzb3MucG9saWNlLkExLnRyYWZmaWM8 L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0Mw NTA0RCc+LSBHQVVMQSAoQ29sb21iaWEpIC0mZ3Q7IGRvZXMgbm90IG1hdGNoIC0gd2UgcHJvYmFi bHkgbmVlZCB1cm46c2VydmljZTpzb3MucG9saWNlLmFudGlraWRuYXBwaW5nIChuZXcpPC9zcGFu PjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQn PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtj b2xvcjojQzA1MDREJz5JLmUuIHdlIHdvdWxkIG5lZWQgYWRkaXRpb25hbGx5Ojwvc3Bhbj48bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4tIHVy bjpzZXJ2aWNlOnNvcy5wb2xpY2UuZmluYW5jaWFsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPi0gdXJuOnNlcnZpY2U6c29zLnBv bGljZS5taWxpdGFyeTwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIjtjb2xvcjojQzA1MDREJz4tIHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UuY2l2aWw8L3NwYW4+ PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+ LSB1cm46c2VydmljZTpzb3MucG9saWNlLmFudGlraWRuYXBwaW5nPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDRE Jz5JZiBJIHVuZGVyc3Rvb2QgaXQgY29ycmVjdGx5LCBhbGwgdG9nZXRoZXIsIHdlIHdvdWxkIG5l ZWQgNzcgcG9saWNlIHJlbGF0ZWQgZW1lcmdlbmN5IHNlcnZpY2UgVVJOcyA9ICg3IChzcGVjaWFs aXplZCBwb2xpY2UgY29ycCBiZWxvdykgKyA0IChhZGRpdGlvbmFsIGFib3ZlKSkgKiA3IChub21l bmNsYXR1cmUgc3BlY2lmaWVkIGluIENpdmljIEFkZHJlc3NlcyAoUkZDIDQxMTkpKS4gU2VlbXMg cXVpdGUgYSBsb3QuTW9yZW92ZXIsIGEgcmVndWxhdG9yIGluIGEgY291bnRyeSBjYW4gZGVmaW5l IGEgbmV3IHR5cGUgb2YgYSBwb2xpY2UgcmVsYXRlZCBlbWVyZ2VuY3kgc2VydmljZSAtIGl0IGRl cGVuZHMgb24gaG93IHRoZSBsYXcgZW5mb3JjZW1lbnQgaXMgc3RydWN0dXJlIGluIHRoZSBjb3Vu dHJ5LiBUaGVuIHRoZSBsaXN0IHdpbGwgZ3JvdyBldmVuIG1vcmUuIE1heWJlIGl0IHdvdWxkIHJl YWxseSBiZSBiZXR0ZXIgdG8gbGV0IHJlZ3VsYXRvcnMgdG8gbWFuYWdlIHBlci1jb3VudHJ5IHN1 Yi1yZWdpc3RyaWVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz5LaW5kIHJlZ2FyZHM8L3NwYW4+ PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2Nv bG9yOiNDMDUwNEQnPkl2byBTZWRsYWNlazwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQn PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBz dHlsZT0nZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2Nv bG9yOiMzMzMzMzMnPlRoaXMgQ29tbXVuaWNhdGlvbiBpcyBDb25maWRlbnRpYWwuIFdlIG9ubHkg c2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQg YXQgPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly93d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWlt ZXIiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iaHR0cDovL3d3dy5lcmljc3Nvbi5jb20vZW1haWxf ZGlzY2xhaW1lciI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIic+d3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyPC9zcGFu PjwvYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOiMzMzMzMzMnPiA8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIic+IERhbiBNb25ncmFpbiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOlttYWlsdG86ZGFu QG1vbmdyYWluLm9yZ10iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPlttYWlsdG86ZGFuQG1vbmdy YWluLm9yZ108L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IDxicj48Yj5TZW50OjwvYj4gMTkuIHByb3NpbmNl IDIwMTIgMTY6MDA8YnI+PGI+VG86PC9iPiBJdm8gU2VkbGFjZWs8YnI+PGI+Q2M6PC9iPiA8L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOmVjcml0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi Jz5lY3JpdEBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+PGRpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+PGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW0Vjcml0XSBX aGF0IGlzIHRoZSBtb3N0IGFwcHJvcHJpYXRlIG1ldGhvZCBmb3IgcmVnaXN0ZXJpbmcgbmV3IHN1 Yi1zZXJ2aWNlcyBvZiB1cm46c2VydmljZTpzb3M8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+ PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQnPkkgYWxzbyByZWNvbW1lbmQgd2UgY3JlYXRlIHB1cnBvc2Uga2V5d29y ZHMgaW4gb3JkZXIgdG8gcmVhY2ggYSBzcGVjaWFsaXplZCBwb2xpY2UgY29ycC4mbmJzcDsgU3Vj aCBhczo8YnI+c29zLnBvbGljZS5kcnVnczxicj5zb3MucG9saWNlLnRyYWZmaWM8YnI+c29zLnBv bGljZS5maXJlYXJtczxicj5zb3MucG9saWNlLmFsY29ob2w8YnI+c29zLnBvbGljZS50b2JhY2Nv PGJyPnNvcy5wb2xpY2UudG91cmlzdDxicj5zb3MucG9saWNlLmJvcmRlcjxicj48YnI+VGhlIGFi b3ZlIGtleXdvcmRzIGNhbiBiZSB1dGlsaXplZCB3aXRoIHRlcnJpdG9yaWFsIGRlc2lnbmF0aW9u cyBpbiBvcmRlciB0byBzcGVjaWZ5IGEgcGFydGljdWxhciBzZXJ2aWNlIGlmIG9mZmVyZWQgYnkg bXVsdGlwbGUganVyaXNkaWN0aW9ucy4mbmJzcDsgRm9yIGV4YW1wbGUgaW4gdGhlIFVTOjxicj5z b3MucG9saWNlLmNvdW50cnkuZHJ1Z3MgY291bGQgYmUgdXNlZCB0byByZWFjaCB0aGUgREVBIHdo ZXJlYXM8YnI+c29zLnBvbGljZS5BMy5kcnVncyBjb3VsZCBiZSB1c2VkIHRvIHJlYWNoIHRoZSBu YXJjb3RpY3MgZGl2aXNpb24gb2YgdGhlIGNpdHkgcG9saWNlLjxicj48YnI+SSBjYW4gYW5zd2Vy IGZvciBDYW5hZGE6PGJyPnNvcy5wb2xpY2UuY291bnRyeSB3b3VsZCBiZSB0byByZWFjaCB0aGUg Um95YWwgQ2FuYWRpYW4gTW91bnRhaW4gUG9saWNlIChSQ01QKTxicj5JbiB0aGUgcHJvdmluY2Vz IG9mIE9udGFyaW8gYW5kIFF1w6liZWMgd2hpY2ggaGF2ZSBwcm92aW5jYWwgcG9saWNlcywgdGhl biBzb3MucG9saWNlLkExIGluIE9udGFyaW8gd291bGQgcmVhY2ggdGhlIE9udGFyaW8gUHJvdmlu Y2lhbCBQb2xpY2UgKE9QUCkgYW5kIHNvcy5wb2xpY2UuQTEgaW4gUXXDqWJlYyB3b3VsZCByZWFj aCB0aGUgU3VyZXTDqSBkdSBRdcOpYmVjIChTUSkuPGJyPkluIENhbmFkYSB3ZSBkbyBub3QgaGF2 ZSBhIHBvbGljZSBzZXJ2aWNlIGF0IHRoZSBjb3VudHkgbGV2ZWwgKHdlIGRvIGhhdmUgc2hlcmlm ZiBkZXBhcnRtZW50cyBidXQgdGhleSBhcmUgbW9yZSBmb3IgY291cnQgYW5kIGphaWwgc2VjdXJp dHkpLjxicj5JbiBPbnRhcmlvIGFuZCBRdcOpYmVjLCBhIGNpdHkgbWF5IGhhdmUgaXRzIHBvbGlj ZSBzZXJ2aWNlIG90aGVyd2lzZSB0aGUgcHJvdmluY2lhbCBwb2xpY2Ugb2ZmZXJzIHRoZSBzZXJ2 aWNlLiZuYnNwOyBJbiB0aGUgcmVzdCBvZiBDYW5hZGEsIGEgY2l0eSBtYXkgaGF2ZSBpdHMgcG9s aWNlIHNlcnZpY2Ugb3RoZXJ3aXNlIHRoZSBSQ01QIG9mZmVycyB0aGUgc2VydmljZS48YnI+PGJy PlRoYW54LDxicj5EYW48bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPk9u IFdlZCwgRGVjIDE5LCAyMDEyIGF0IDc6MDIgQU0sIEl2byBTZWRsYWNlayAmbHQ7PGEgaHJlZj0i bWFpbHRvOml2by5zZWRsYWNla0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5pdm8uc2Vk bGFjZWtAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PGRpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPkhlbGxvLDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6I0MwNTA0RCc+dGhhbmtzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+Ym90aCBvcHRpb25zIChEYW4n cyBhbmQgQnJpYW4ncykgc2VlbWVkIHRvIHdvcmsgZm9yIHRoZSBlbWVyZ2VuY3kgc2VydmljZXMg b2YgdGhlIHBvbGljZSBmb3JjZXMgaW4gdGhlIEN6ZWNoIHJlcHVibGljLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0Mw NTA0RCc+Rm9yIGNvbXBsZXRlbmVzcywgSSBhbHNvIGNoZWNrZWQgdGhlIGVtZXJnZW5jeSBzZXJ2 aWNlcyBvZiB0aGUgcG9saWNlIGZvcmNlcyBvZiBvdGhlciBjb3VudHJpZXMuIFdpa2lwZWRpYSAo PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvRW1lcmdlbmN5X3Rl bGVwaG9uZV9udW1iZXIiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+aHR0cDovL2VuLndpa2lwZWRp YS5vcmcvd2lraS9FbWVyZ2VuY3lfdGVsZXBob25lX251bWJlcjwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6I0MwNTA0RCc+KSBsaXN0cyB0aGUgZm9sbG93aW5nIG9uIHRvcCBvZiBlbWVyZ2VuY3kgc2Vy dmljZXMgb2YgdGhlIHJlZ3VsYXIgcG9saWNlIGZvcmNlczo8L3NwYW4+PG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+LSBtdW5pY2lwYWwgcG9s aWNlIChDemVjaCBSZXB1YmxpYywgUG9sYW5kKSAtJmd0OyBjYW4gbWFwIHRvIHVybjpzZXJ2aWNl OnNvcy5wb2xpY2UubG9jYWwgb3IgdXJuOnNlcnZpY2U6c29zLnBvbGljZS5BMyA8L3NwYW4+PG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+LSB0 b3VyaXN0IHBvbGljZSAoRWd5cHQsIEdyZWVjZSkgLSZndDsgZG9lcyBub3Qgc2VlbSB0byBmaXQg aW50byBhbnkgb2YgdGhlIGFsdGVybmF0aXZlcyBzbyBmYXI8L3NwYW4+PG86cD48L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+LSB0cmFmZmljIHBvbGlj ZSAoRWd5cHQsIFN1ZGFuLCBJbmRpYSwgUGFraXN0YW4sIFNhdWRpIEFyYWJpYSwgQWxiYW5pYSwg QXJtZW5pYSwgQXplcmJhaWphbikgLSZndDsgZG9lcyBub3Qgc2VlbSB0byBmaXQgaW50byBhbnkg b2YgdGhlIGFsdGVybmF0aXZlcyBzbyBmYXI8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+LSBzdGF0ZSBwb2xpY2UgKEl0YWx5KSAt Jmd0OyBjYW4gbWFwIHRvIHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UubmF0aW9uYWwgb3IgdXJuOnNl cnZpY2U6c29zLnBvbGljZS5jb3VudHJ5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPi0gY3VzdG9tcy9maW5hbmNpYWwgUG9saWNl IChJdGFseSkgLSZndDsgZG9lcyBub3Qgc2VlbSB0byBmaXQgaW50byBhbnkgb2YgdGhlIGFsdGVy bmF0aXZlcyBzbyBmYXI8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7Y29sb3I6I0MwNTA0RCc+LSBnZW5kYXJtZXJpZSAoUm9tYW5pYSkgLSZndDsgZG9lcyBu b3Qgc2VlbSB0byBmaXQgaW50byBhbnkgb2YgdGhlIGFsdGVybmF0aXZlcyBzbyBmYXI8L3NwYW4+ PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+ LSBsb2NhbCBwb2xpY2UgKFNwYWluKSAtJmd0OyBjYW4gbWFwIHRvIHVybjpzZXJ2aWNlOnNvcy5w b2xpY2UubG9jYWwgb3IgdXJuOnNlcnZpY2U6c29zLnBvbGljZS5BMzwvc3Bhbj48bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4tIENhdGFsYW4g cG9saWNlIChTcGFpbikgLSZndDsgbWF5YmUgdGhpcyBjb3VsZCBtYXAgdG8gdXJuOnNlcnZpY2U6 c29zLnBvbGljZS5yZWdpb25hbCBvciB1cm46c2VydmljZTpzb3MucG9saWNlLkExIGJ1dCBhIHBl cnNvbiB3aXRoIHNwYW5pc2gvY2F0YWxhbiBiYWNrZ3JvdW5kIHNob3VsZCBjaGVjay48L3NwYW4+ PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+ LSBjaXZpbCBndWFyZCAoU3BhaW4pIC0mZ3Q7IGRvZXMgbm90IHNlZW0gdG8gZml0IGludG8gYW55 IG9mIHRoZSBhbHRlcm5hdGl2ZXMgc28gZmFyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPi0gUHJvdmluY2lhbCBQb2xpY2UgKENh bmFkYSkgLSBtYXliZSB0aGlzIGNvdWxkIG1hcCB0byB1cm46c2VydmljZTpzb3MucG9saWNlLnJl Z2lvbmFsIG9yIHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UuQTEgYnV0IGEgcGVyc29uIHdpdGggY2Fu YWRpYW4gYmFja2dyb3VuZCBzaG91bGQgY2hlY2s8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+LSBTw7tyZXTDqSBkdSBRdcOpYmVj IChDYW5hZGEpIC0gbWF5YmUgdGhpcyBjb3VsZCBtYXAgdG8gdXJuOnNlcnZpY2U6c29zLnBvbGlj ZS5yZWdpb25hbCBvciB1cm46c2VydmljZTpzb3MucG9saWNlLkExIGJ1dCBhIHBlcnNvbiB3aXRo IGNhbmFkaWFuIGJhY2tncm91bmQgc2hvdWxkIGNoZWNrPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPi0gZmVkZXJhbCBoaWdod2F5 IHBvbGljZSAoQnJhemlsKSAtJmd0OyBkb2VzIG5vdCBzZWVtIHRvIGZpdCBpbnRvIGFueSBvZiB0 aGUgYWx0ZXJuYXRpdmVzIHNvIGZhcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4tIGZlZGVyYWwgcG9saWNlIChCcmF6aWwpIC0m Z3Q7IGNhbiBtYXAgdG8gdXJuOnNlcnZpY2U6c29zLnBvbGljZS5uYXRpb25hbCBvciB1cm46c2Vy dmljZTpzb3MucG9saWNlLmNvdW50cnk8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+LSBjaXZpbCBwb2xpY2UgKEJyYXppbCkgLSZn dDsgZG9lcyBub3Qgc2VlbSB0byBmaXQgaW50byBhbnkgb2YgdGhlIGFsdGVybmF0aXZlcyBzbyBm YXI8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6 I0MwNTA0RCc+LSBzdGF0ZSBoaWdod2F5IHBvbGljZSAoQnJhemlsKSAtJmd0OyBkb2VzIG5vdCBz ZWVtIHRvIGZpdCBpbnRvIGFueSBvZiB0aGUgYWx0ZXJuYXRpdmVzIHNvIGZhcjwvc3Bhbj48bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4tIEdB VUxBIChDb2xvbWJpYSkgLSZndDsgZG9lcyBub3Qgc2VlbSB0byBmaXQgaW50byBhbnkgb2YgdGhl IGFsdGVybmF0aXZlcyBzbyBmYXI8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPkZvciB0aG9zZSBlbWVyZ2Vu Y3kgc2VydmljZXMgYWJvdmUgbm90IGZpdHRpbmcgaW50byBhbnkgb2YgdGhlIGFsdGVybmF0aXZl cywgaG93IHNob3VsZCB0aGV5IGJlIGV4cHJlc3NlZCBpbiBhbiBlbWVyZ2VuY3kgc2VydmljZSBV Uk4/IERvIHdlIGFzc3VtZSBJQU5BIHdpbGwgcmVnaXN0ZXIgdGhlbSB0b28/PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2Nv bG9yOiNDMDUwNEQnPktpbmQgcmVnYXJkczwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+SXZvIFNlZGxhY2Vr PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiND MDUwNEQnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIjtjb2xvcjojQzA1MDREJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMzMzMzMzMnPlRoaXMgQ29tbXVuaWNhdGlvbiBp cyBDb25maWRlbnRpYWwuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFz aXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQgPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly93d3cuZXJp Y3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXIiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iaHR0cDov L3d3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lciI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZTo4LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+d3d3LmVyaWNzc29uLmNv bS9lbWFpbF9kaXNjbGFpbWVyPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguMHB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMzMzMzMzMnPiA8L3NwYW4+ PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0Mw NTA0RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0n Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxiPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIic+IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+ZWNyaXQtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48 L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz4gW21haWx0bzo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmVjcml0LWJvdW5jZXNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPmVjcml0LWJvdW5jZXNAaWV0Zi5vcmc8 L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIic+XSA8Yj5PbiBCZWhhbGYgT2YgPC9iPkRhbiBNb25ncmFpbiwgZW5n Ljxicj48Yj5TZW50OjwvYj4gMTguIHByb3NpbmNlIDIwMTIgMTY6MzU8YnI+PGI+VG86PC9iPiA8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmVjcml0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiJz5lY3JpdEBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+PGRpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtFY3JpdF0gV2hhdCBp cyB0aGUgbW9zdCBhcHByb3ByaWF0ZSBtZXRob2QgZm9yIHJlZ2lzdGVyaW5nIG5ldyBzdWItc2Vy dmljZXMgb2YgdXJuOnNlcnZpY2U6c29zPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+ PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9w PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+SW5zdGVhZCBvZiB0cnlpbmcgdG8gY29tZSB1cCB3 aXRoIHRoZSBwcm9wZXIgbm9tZW5jbGF0dXJlIGZvciB0aGUganVyaXNkaWN0aW9uIHRvIGJlIHVz ZWQgaW4gdGhlIFNlcnZpY2UgVVJOLCB3aHkgbm90IHV0aWxpemUgdGhlIG5vbWVuY2xhdHVyZSBz cGVjaWZpZWQgaW4gQ2l2aWMgQWRkcmVzc2VzIChSRkMgNDExOSk6PGJyPnNvcy5wb2xpY2UuY291 bnRyeSBmb3IgcG9saWNlIHNlcnZpY2VzIGF0IHRoZSBjb3VudHJ5L25hdGlvbmFsL2ZlZGVyYWwv ZXRjIGxldmVsPGJyPnNvcy5wb2xpY2UuQTEgZm9yIHBvbGljZSBzZXJ2aWNlcyBhdCB0aGUgc3Rh dGUvcHJvdmluY2UvcmVnaW9uL3ByZWZlY3R1cmUvZXRjIGxldmVsPGJyPnNvcy5wb2xpY2UuQTIg Zm9yIHBvbGljZSBzZXJ2aWNlcyBhdCB0aGUgY291bnR5L3BhcmlzaC9ndW4vZGlzdHJpY3QvZXRj IGxldmVsPGJyPnNvcy5wb2xpY2UuQTMgZm9yIHBvbGljZSBzZXJ2aWNlcyBhdCB0aGUgY2l0eS90 b3duc2hpcC9zaGkvZXRjIGxldmVsPGJyPnNvcy5wb2xpY2UuQTQgZm9yIHBvbGljZSBzZXJ2aWNl cyBhdCB0aGUgY2l0eSBkaXZpc2lvbi9ib3JvdWdoL2NpdHkgZGlzdHJpY3Qvd2FyZC9jaG91L2V0 YyBsZXZlbDxicj5zb3MucG9saWNlLkE1IGZvciBwb2xpY2Ugc2VydmljZXMgYXQgdGhlIG5laWdo Ym9yaG9vZC9ibG9jay9ldGMgbGV2ZWw8YnI+PGJyPlRoaXMgd2F5IHdlIGF2b2lkIGhhdmluZyB0 byBwaWNrIGEgdGVybSB0aGF0IGhhcyBubyBhcHBsaWNhYmlsaXR5IGluIGNlcnRhaW4gY291bnRy aWVzLjxicj48YnI+VGhhbngsPGJyPkRhbjxicj48YnI+T24gMTQvMTIvMjAxMiA5OjEyIEFNLCBS b3NlbiwgQnJpYW4gd3JvdGU6PG86cD48L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9 J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byc+SSBoYXZlIG5vIHByb2JsZW0gdXNpbmcgJnF1b3Q7bmF0aW9uYWwmcXVvdDsgaW5zdGVhZCBv ZiAmcXVvdDtmZWRlcmFsJnF1b3Q7LiA8bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8nPiZxdW90O1N0YXRlJnF1b3Q7IGFuZCAmcXVvdDtQcm92aW5jZSZxdW90OyBhcmUgZXF1 aXZhbGVudC4gJm5ic3A7U29tZSBjb3VudHJpZXMgaGF2ZSBvbmUsIHNvbWUgaGF2ZSB0aGUgb3Ro ZXIuICZuYnNwO0kgZG9uJ3QgdGhpbmsgdGhlcmUgYXJlIGFueSB3aXRoIGJvdGguICZuYnNwO1Nv bWUgaGF2ZSBuZWl0aGVyIG9mIGNvdXJzZS48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+SSdkIHByZWZlciBub3QgdG8gaGF2ZSBuYXRpb24tc3BlY2lmaWMgdmFsdWVz LiAmbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZu YnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+QnJpYW48 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz5P biBEZWMgMTQsIDIwMTIsIGF0IDM6NDggQU0sIEl2byBTZWRsYWNlayAmbHQ7PGEgaHJlZj0ibWFp bHRvOml2by5zZWRsYWNla0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5pdm8uc2VkbGFj ZWtAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t OjEyLjBwdCc+Jm5ic3A7PG86cD48L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPkhlbGxvLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi O2NvbG9yOiNDMDUwNEQnPnRoYW5rIHlvdSBmb3IgeW91ciBtYWlsLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQn PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPiZndDsmbmJzcDs8L3NwYW4+SSdkIHN1cHBvcnQgYW5v dGhlciAob3B0aW9uYWwpIGxldmVsIG9mIHBvbGljZSB3aXRoIGF0IGxlYXN0IDQgdmFsdWVzLjxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6 I0MwNTA0RCc+Jmd0OyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPiZndDsmbmJzcDs8L3NwYW4+UGVy aGFwcyAmcXVvdDtsb2NhbCZxdW90Oy8mcXVvdDtyZWdpb25hbCZxdW90Oy8mcXVvdDtwcm92aW5j aWFsJnF1b3Q7LyZxdW90O2ZlZGVyYWwmcXVvdDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiND MDUwNEQnPmlmIEkgdW5kZXJzdG9vZCBjb3JyZWN0bHksIHlvdSBwcm9wb3NlIHRoYXQ6PC9zcGFu PjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6I0MwNTA0RCc+LSB1cm46c2VydmljZTpzb3MubG9jYWwsPC9zcGFuPjxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+LSB1 cm46c2VydmljZTpzb3MucmVnaW9uYWwsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+LSB1cm46c2VydmljZTpz b3MucHJvdmluY2lhbCw8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4tIHVybjpzZXJ2aWNlOnNvcy5mZWRlcmFs PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6I0MwNTA0RCc+YXJlIHJlZ2lzdGVyZWQuIGlmIEkgbWlzdW5kZXJzdG9vZCwgcGxl YXNlIGNvcnJlY3QgbWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFy aWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+ dXJuOnNlcnZpY2U6c29zLmxvY2FsIHdvdWxkIG1hcCB3ZWxsIHRvIHRoZSBlbWVyZ2VuY3kgc2Vy dmljZSBwcm92aWRlZCBieSB0aGUgbXVuaWNpcGFsIHBvbGljZSBpbiB0aGUgQ3plY2ggcmVwdWJs aWMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7Y29sb3I6I0MwNTA0RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+SG93ZXZlciwgdGhl IGVtZXJnZW5jeSBzZXJ2aWNlIHByb3ZpZGVkIGJ5IHRoZSBuYXRpb25hbCBwb2xpY2UgaW4gdGhl IEN6ZWNoIHJlcHVibGljIGlzIG5vdCBlYXNpbHkgbWFwcGVkIHRvIGFueSBvZiB0aGUgdmFsdWVz Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiO2NvbG9yOiNDMDUwNEQnPi0gQ3plY2ggcmVwdWJsaWMgaGFzIHByb3ZpbmNlcyAoJnF1b3Q7 a3JhaiZxdW90OykgYnV0IHRoZSBwcm92aW5jZXMgKHNvIGZhcikgZG8gbm90IGhhdmUgdGhlaXIg b3duIHBvbGljZSBmb3JjZS48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojQzA1MDREJz4tIEN6ZWNoIHJlcHVibGljIGlzIG5v dCBhIGZlZGVyYXRpb24gc28gJnF1b3Q7ZmVkZXJhbCZxdW90OyBkb2VzIG5vdCBmaXQgZWl0aGVy Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiO2NvbG9yOiNDMDUwNEQnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPlBlcmhhcHMgdGhlIGZv bGxvd2luZyBzaG91bGQgYmUgZGVmaW5lZDogdXJuOnNlcnZpY2U6c29zLmxvY2FsLCB1cm46c2Vy dmljZTpzb3MucmVnaW9uYWwsIHVybjpzZXJ2aWNlOnNvcy48Yj48dT5zdGF0ZTwvdT48L2I+LCB1 cm46c2VydmljZTpzb3MuZmVkZXJhbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiNDMDUwNEQnPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiND MDUwNEQnPkFsdGVybmF0aXZlbHksIHN1YnJlZ2lzdHJpZXMgY2FuIGJlIGNyZWF0ZWQgZm9yIGVh Y2ggY291bnRyeSB3aGVyZSB0aGUgcmVndWxhdG9yIG9mIHRoZSBjb3VudHJ5IHdvdWxkIG1hbmFn ZSB0aGUgZW1lcmdlbmN5IHNlcnZpY2UgVVJOcyBmb3IgdGhlIGNvdW50cnkgc3BlY2lmaWMgZW1l cmdlbmN5IHNlcnZpY2VzICgmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL2VuLndpa2lwZWRp YS5vcmcvd2lraS9FbWVyZ2VuY3lfdGVsZXBob25lX251bWJlciIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiO2NvbG9yOnB1cnBsZSc+aHR0cDovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9FbWVyZ2VuY3lf dGVsZXBob25lX251bWJlcjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+Jm5ic3A7c2Vl bXMgdG8gbGlzdCBxdWl0ZSBhIGxvdCBvZiB0aG9zZSApPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6I0MwNTA0RCc+S2luZCByZWdhcmRzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 Y29sb3I6I0MwNTA0RCc+SXZvIFNlZGxhY2VrPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6I0MwNTA0RCc+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6I0MwNTA0RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMzMzMzMzMnPlRoaXMgQ29tbXVuaWNhdGlv biBpcyBDb25maWRlbnRpYWwuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUg YmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDov L3d3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lciIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxl PSJodHRwOi8vd3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyIj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOnB1 cnBsZSc+d3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyPC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9y OiNDMDUwNEQnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxkaXYgc3R5 bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtJz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxiPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIic+Jm5ic3A7Um9zZW4sIEJyaWFuIFs8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5t YWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+XSZuYnNwOzxi cj48Yj5TZW50OjwvYj4mbmJzcDsxMy4gcHJvc2luY2UgMjAxMiAxNTo0MTxicj48Yj5Ubzo8L2I+ Jm5ic3A7SXZvIFNlZGxhY2VrPGJyPjxiPkNjOjwvYj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOmVjcml0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOnB1cnBsZSc+ ZWNyaXRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+PGJyPjxiPlN1YmplY3Q6PC9iPiZuYnNw O1JlOiBbRWNyaXRdIFdoYXQgaXMgdGhlIG1vc3QgYXBwcm9wcmlhdGUgbWV0aG9kIGZvciByZWdp c3RlcmluZyBuZXcgc3ViLXNlcnZpY2VzIG9mIHVybjpzZXJ2aWNlOnNvczwvc3Bhbj48bzpwPjwv bzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNw OzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+VGhhdCBpc3N1 ZSBvY2N1cnMgaW4gc2V2ZXJhbCBvdGhlciBjb3VudHJpZXMuPG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPlRoZXJlIGFyZSBvZnRlbiAzIG9yIG1vcmUg cG9saWNlIGFnZW5jaWVzIHNlcnZpbmcgYW4gYXJlYS4gJm5ic3A7SW4gbXkgaG9tZSwgdGhlcmUg YXJlIGZvdXI6PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPmEpIEEgbG9jYWwgKHRvd25zaGlwKSBwb2xpY2U8bzpwPjwvbzpwPjwvcD48L2Rp dj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+YikgQSBjb3VudHkgcG9saWNl IGFnZW5jeSB0aGF0IHJlc3BvbmRzIHRvIHNvbWUgdW5jb21tb24gZXZlbnRzPG86cD48L286cD48 L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPmMpIEEgc3RhdGUg cG9saWNlIGFnZW5jeSwgd2hpY2ggYWxzbyBoYXMganVyaXNkaWN0aW9uIGluIHNvbWUgY2lyY3Vt c3RhbmNlczxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz5kKSBUaGUgZmVkZXJhbCBwb2xpY2UgKEZCSSk8bzpwPjwvbzpwPjwvcD48L2Rpdj48 L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+ PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPldoaWxlIHdlIGRvIGhh dmUgYSBzaW5nbGUgbnVtYmVyLCBpZiB5b3UgZXhwbGljaXRseSB3YW50ZWQgdGhlIHN0YXRlIHBv bGljZSwgdGhlcmUgaXMgbm8gd2F5IHRvIGdldCB0byB0aGVtLjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwv cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+SSdkIHN1cHBvcnQg YW5vdGhlciAob3B0aW9uYWwpIGxldmVsIG9mIHBvbGljZSB3aXRoIGF0IGxlYXN0IDQgdmFsdWVz LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Jz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byc+UGVyaGFwcyAmcXVvdDtsb2NhbCZxdW90Oy8mcXVvdDtyZWdpb25hbCZxdW90Oy8m cXVvdDtwcm92aW5jaWFsJnF1b3Q7LyZxdW90O2ZlZGVyYWwmcXVvdDs8bzpwPjwvbzpwPjwvcD48 L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286 cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPkJyaWFuPG86 cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz5PbiBEZWMgMTMsIDIwMTIsIGF0IDg6MjIgQU0sIEl2byBTZWRsYWNlayAmbHQ7PGEg aHJlZj0ibWFpbHRvOml2by5zZWRsYWNla0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0nY29sb3I6cHVycGxlJz5pdm8uc2VkbGFjZWtAZXJpY3Nzb24uY29tPC9zcGFu PjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCc+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIic+SGVsbG8sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjwv ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8n PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiInPmluIHRoZSBDemVjaCByZXB1YmxpYywgdGhlIG5hdGlvbmFsIHJlZ3VsYXRvciBk ZWZpbmVkIHR3byBwb2xpY2UgcmVsYXRlZCBlbWVyZ2VuY3kgc2VydmljZXM6PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiJz5BKSBlbWVyZ2VuY3kgc2VydmljZSBwcm92aWRlZCBieSB0aGUgbmF0aW9uYWwgcG9saWNl IChudW1iZXIgMTU4IGluIHRoZSBwdWJsaWMgc3dpdGNoZWQgdGVsZXBob25lIG5ldHdvcmspOyBh bmQ8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiInPkIpIGVtZXJnZW5jeSBzZXJ2aWNlIHByb3ZpZGVkIGJ5IHRoZSBt dW5pY2lwYWwgcG9saWNlIChudW1iZXIgMTU2IGluIHRoZSBwdWJsaWMgc3dpdGNoZWQgdGVsZXBo b25lIG5ldHdvcmspLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w PjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5UaGUg cmVndWxhdGlvbiBpcyZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vYXBsaWthY2UubXZjci5j ei9hcmNoaXYyMDA4L3NiaXJrYS8yMDA3L3NiMDQzLTA3LnBkZiIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6cHVycGxlJz5odHRwOi8vYXBsaWthY2UubXZjci5jei9hcmNoaXYyMDA4L3Ni aXJrYS8yMDA3L3NiMDQzLTA3LnBkZjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7d2hpY2ggbGlz dHMgdGhlIG51bWJlcnMgMTU2IGFuZCAxNTggaW4gc2VjdGlvbiA0LjUuIHdpdGggbm90ZSAyKSB3 aGljaCBzdGF0ZXMgJnF1b3Q7xIzDrXNsbyBqZSBuw6Fyb2Ruw61tIMSNw61zbGVtIHBybyB0w61z xYhvdsOpIHZvbMOhbsOtJnF1b3Q7ICg9IHRoZSBudW1iZXIgaXMgYSBuYXRpb25hbCBudW1iZXIg Zm9yIGVtZXJnZW5jeSBjYWxscykuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2Pjxk aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiInPklzIGl0IGFwcHJvcHJpYXRlIHRvIHJlZ2lzdGVyIHRoZSBmb2xsb3dpbmcgVVJOcyBmb3Ig dGhvc2Ugc2VydmljZXMgd2l0aCBJQU5BPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rp dj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+LSB1cm46c2VydmljZTpz b3MucG9saWNlLm5hdGlvbmFsIC0gVGhlICdwb2xpY2UubmF0aW9uYWwnIHNlcnZpY2UgcmVmZXJz IHRvIHRoZSBwb2xpY2UgZGVwYXJ0bWVudCBvciBvdGhlciBsYXcgZW5mb3JjZW1lbnQgYXV0aG9y aXRpZXMgb2YgdGhlIG5hdGlvbmFsIGdvdmVybm1lbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4tIHVybjpz ZXJ2aWNlOnNvcy5wb2xpY2UubXVuaWNpcGFsIC0gVGhlICdwb2xpY2UubXVuaWNpcGFsJyBzZXJ2 aWNlIHJlZmVycyB0byB0aGUgcG9saWNlIGRlcGFydG1lbnQgb3Igb3RoZXIgbGF3IGVuZm9yY2Vt ZW50IGF1dGhvcml0aWVzIG9mIHRoZSBtdW5pY2lwYWwgYXV0aG9yaXRpZXMuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPk9yIHNob3VsZCB0aG9zZSBiZSByZWdpc3RlcmVk IHdpdGggYSBwcmVmaXggaW5kaWNhdGluZyB0aGF0IHRob3NlIGFyZSBhcHBsaWNhYmxlIHRvIEN6 ZWNoIHJlcHVibGljIG9ubHksIGFzIG90aGVyIGNvdW50cmllcyBtYXkgaGF2ZSBzaW1pbGFyIChi dXQgbm90IG5lY2Vzc2FyaWx5IGlkZW50aWNhbCkgc2VydmljZXM6PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4t IHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UuY3plY2gubmF0aW9uYWwgLSBUaGUgJ3BvbGljZS5jemVj aC5uYXRpb25hbCcgc2VydmljZSByZWZlcnMgdG8gdGhlIHBvbGljZSBkZXBhcnRtZW50IG9yIG90 aGVyIGxhdyBlbmZvcmNlbWVudCBhdXRob3JpdGllcyBvZiB0aGUgbmF0aW9uYWwgZ292ZXJubWVu dC48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiInPi0gdXJuOnNlcnZpY2U6c29zLnBvbGljZS5jemVjaC5tdW5pY2lw YWwgLSBUaGUgJ3BvbGljZS5jemVjaC5tdW5pY2lwYWwnIHNlcnZpY2UgcmVmZXJzIHRvIHRoZSBw b2xpY2UgZGVwYXJ0bWVudCBvciBvdGhlciBsYXcgZW5mb3JjZW1lbnQgYXV0aG9yaXRpZXMgb2Yg bXVuaWNpcGFsIGF1dGhvcml0aWVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48 ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiJz5JIGFzc3VtZSB0aGlzIHF1ZXN0aW9uIGJlbG9uZ3MgdG8gSUFOQSwgYnV0IGFzIHRoZSBl eHBlcnQgcmV2aWV3ZXIgbW9zdCBsaWtlbHkgd2lsbCBiZSBmcm9tIHRoZSBFQ1JJVCwgSSBhbSBz ZW5kaW5nIGl0IGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPktp bmQgcmVnYXJkczwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz5Jdm8gU2Vk bGFjZWs8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiInPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48 L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiJz5UaGlzIENvbW11bmljYXRpb24gaXMgQ29uZmlkZW50aWFsLiBXZSBvbmx5IHNl bmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0 PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly93d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXIi IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOnB1cnBsZSc+d3d3LmVyaWNzc29uLmNvbS9l bWFpbF9kaXNjbGFpbWVyPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQt ZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+RWNyaXQgbWFpbGluZyBsaXN0PGJyPjwvc3Bhbj48 YSBocmVmPSJtYWlsdG86RWNyaXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiI7 Y29sb3I6cHVycGxlJz5FY3JpdEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6IkhlbHZldGljYSIsInNhbnMtc2VyaWYiJz48YnI+PC9z cGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQi IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWls eToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiI7Y29sb3I6cHVycGxlJz5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD48L2Rp dj48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxv OnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQnPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxw cmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwv bzpwPjwvcHJlPjxwcmU+RWNyaXQgbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT48cHJlPjxh IGhyZWY9Im1haWx0bzpFY3JpdEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkVjcml0QGlldGYu b3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+PHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdDwvYT48bzpwPjwvbzpwPjwvcHJlPjwvYmxvY2tx dW90ZT48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rp dj48L2Rpdj48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpw PjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4m bmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48YnI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+RWNyaXQgbWFpbGluZyBsaXN0PGJyPjxh IGhyZWY9Im1haWx0bzpFY3JpdEBpZXRmLm9yZyI+RWNyaXRAaWV0Zi5vcmc8L2E+PGJyPjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0PC9hPjxv OnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_5A55A45AE77F5941B18E5457ECAC8188012140771193SISPE7MB1co_-- From keith.drage@alcatel-lucent.com Mon Feb 18 17:03:56 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B235521E80A2 for ; Mon, 18 Feb 2013 17:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.352 X-Spam-Level: X-Spam-Status: No, score=-108.352 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_FRAUD_X3=1.667, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFMxUxjjiPAN for ; Mon, 18 Feb 2013 17:03:52 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0D92721E8063 for ; Mon, 18 Feb 2013 17:03:51 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1J13oqv016154 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 19 Feb 2013 02:03:50 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 19 Feb 2013 02:03:50 +0100 From: "DRAGE, Keith (Keith)" To: "ecrit@ietf.org" Date: Tue, 19 Feb 2013 02:03:48 +0100 Thread-Topic: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emergency-services-00 Thread-Index: Ac4OAWlhLd8PhQE+SgK5Q/R8/ukyvAANm4TQ Message-ID: References: <7594FB04B1934943A5C02806D1A2204B0D8DCA@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101086378@ESESSMB301.ericsson.se> <076C52A7-194F-4C9B-A607-7C5AA685E8FF@gmx.net> <7594FB04B1934943A5C02806D1A2204B0D933D@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101099B29@ESESSMB301.ericsson.se> <155970D1DA8E174F9E46039E10E2AA35CF313D@XMB103ADS.rim.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE2107016089BFRMRSSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emergency-services-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 01:03:56 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE2107016089BFRMRSSXCHMBSC_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To try and put things in context, I think there are four "problems" with th= e existing sos URN values. draft-holmberg-ecrit-country-specific-emergency-= services-00 attempts to solve only one of these. 1) There are a number of emergency services that exist in multiple = countries where a sos subtype is not defined. My view is that we probably s= hould define values for: - traffic emergency - child protection emergency (this is not the same as= child counselling). For example Italy, among others, has such a value wher= e an immediate response is required. Obviously before we can define these (and in addition to fulfil= ling the IANA registration requirements), we need to come up definitions of= what these really mean. 2) There are a number of emergency services that exist in a single = country. Ideally, for use in networks where service URNs are used, these sh= ould have some form of service URN defined. This is what draft-holmberg-ecr= it-country-specific-emergency-services-00 seeks to resolve. 3) There are a number of countries where a number of distinct polic= e forces exist. For any given location, these tend to be defined on a range= of areas of jurisdiction, e.g. national versus municipal. This has been di= scussed on the list over the end of last year, and there seemed to be some = consensus on defining a range of subtypes for subtype "police". Obviously i= t will not be possible to cover every variation with this, and we probably = need to limit ourselves to values that serve in multiple countries, in the = same way the higher level subtypes do. 4) There are a number of cases were PSAPs cover multiple = subtypes. Where service URNs are being used in isolation, this is not an is= sue. However where service URNs are being created from dialled digits, a pa= rticular local service number in the telephony numbering plan could well ma= p to two or more potential subtypes. Yes, in these cases we could ignore ge= nerating a subtype altogether, but some countries find it desirable to obta= in all the information available from the user. Thus it would be useful to = be able to say sos.fire+medical in these scenarios. Note that all these issues fall under the "sos" definition of emergency ser= vice. Regards Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of R= ichard Barnes Sent: 18 February 2013 17:56 To: John-Luc Bakker Cc: ecrit@ietf.org Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emerg= ency-services-00 Hi John-Luc, We actually already have separate URNs for medical and fire -- "urn:service= :sos.ambulance" and "urn:service:sos.fire" [1]. So that's not an issue. L= oST can map them to the same or different numbers depending on the jurisdic= tion. There is also a "counseling" URN for children, "urn:service:counseli= ng.children". It might make sense to define new URNs for "national gendarmerie" / "nation= al police", and possibly "counter terrorism", since it seems that those exi= st in several countries. But in general, this is the sort of exercise that people should go through = for the various countries. --Richard [1] On Mon, Feb 18, 2013 at 12:39 PM, John-Luc Bakker > wrote: Hi, A few observations on the contents of the Wikipedia page. The first entry shows Algeria having one number for medical AND fire: "14". Should there be one URN for "medical" and "fire" registered with IANA? (A s= econd country with one number for medical AND fire, "15" in their case, is = Morocco). Also, Algeria lists: National Gendarmerie : 1055; Counter Terrorist Unit : 1548; support for chi= ldren : 3033. So, URNs for these may also be needed. However, I question if we should der= ive IANA-registered URNs from any Wikipedia page (which can be edited by ot= hers that national regulators). Kind regards, John-Luc From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Richard Barnes Sent: Monday, February 18, 2013 11:28 AM To: Ivo Sedlacek Cc: ecrit@ietf.org Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emerg= ency-services-00 Yes, I was thinking that the policy would be that an emergency service exis= ts in one country. The purpose of the registry would be just be to encoura= ge deduplication. So, for instance, to encourage the several different cou= ntries that have traffic police numbers* to all use something like "urn:ser= vice:sos.traffic". Or, to choose a better example, once Korea has register= ed "urn:service:sos.espionage", to encourage the second country that establ= ishes a spy reporting service to also use that URN. Alternatively, someone could just go through the list of emergency numbers = on Wikipedia and submit one big registration for the common ones (like traf= fic police). Those would be allowable under the current policy. --Richard * according to wikipedia: EG, SD, CN, IN**, PK, SA, AL, AM, AZ, NZ, CO, EC ** hopefully India could be persuaded to consolidate its three different tr= affic police numbers On Mon, Feb 18, 2013 at 9:00 AM, Ivo Sedlacek > wrote: Hello, thank you for your mail. > It seems to me that the more conservative approach would be to just updat= e the IANA registration policy to be slightly more liberal. By "slightly more liberal", do you propose that the IANA registration polic= y for registration of any sub-service of the service URN with the 'sos' ser= vice type would be relaxed similarly as proposed in the draft (i.e. it is s= ufficient if the emergency service exists in single country only)? That wou= ld be possible. Or do you have other proposal? Thank you for clarification. 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 --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --_000_EDC0A1AE77C57744B664A310A0B23AE2107016089BFRMRSSXCHMBSC_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To try and put things in context, I th= ink there are four “problems” with the existing sos URN values. dra= ft-holmberg-ecrit-country-specific-emergency-services-00 attempts to solve only one of these.

 

1)      =    There are a number of emergency services that exist in multiple countries where a= sos subtype is not defined. My view is that we probably should define values fo= r:

      &n= bsp;     -       &nb= sp;   traffic emergency

      &n= bsp;     -       &nb= sp;   child protection emergency (this is not the same as child counselling). For examp= le Italy, = among others, has such a value where an immediate response is required.

      &n= bsp;     Obviously before we can define these (and in addition to fulfilling the IANA registra= tion requirements), we need to come up definitions of what these really mean.

 

2)      =    There are a number of emergency services that exist in a single country. Ideally,= for use in networks where service URNs are used, these should have some form of service URN defined. This is what draft-holmberg-ecrit-country-specific-eme= rgency-services-00 seeks to resolve.

 

3)      =    There are a number of countries where a number of distinct police forces exist. F= or any given location, these tend to be defined on a range of areas of jurisdiction, e.g. national versus municipal. This has been discussed on th= e list over the end of last year, and there seemed to be some consensus on defining a range of subtypes for subtype “police”. Obviously it will not be possible to cover every variation with this, and we probably ne= ed to limit ourselves to values that serve in multiple countries, in the same = way the higher level subtypes do.

 

4)      =              = There are a number of cases were PSAPs cover multiple subtypes. Where service URNs ar= e being used in isolation, this is not an issue. However where service URNs a= re being created from dialled digits, a particular local service number in the= telephony numbering plan could well map to two or more potential subtypes. Yes, in th= ese cases we could ignore generating a subtype altogether, but some countries f= ind it desirable to obtain all the information available from the user. Thus it would be useful to be able to say sos.fire+medical in these scenarios.=

 

Note that all these issues fall under = the “sos” definition of emergency service.

 

Regards

 

Keith

 

From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: 18 February 2013 17:56=
To: John-Luc Bakker
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] Draft n= ew: draft-holmberg-ecrit-country-specific-emergency-services-00

 

Hi John-Luc,

 

We actually already have separate URNs for medical and fire -- "urn:service:<= span style=3D'font-size:8.5pt;font-family:Arial;color:black'>sos.ambulance"= and "urn:service:<= span style=3D'font-size:8.5pt;font-family:Arial;color:black'>sos.fire" [1].  So that's not an issue.  LoST can map them to the same or differ= ent numbers depending on the jurisdiction.  There is also a "counseling" URN for children, "urn:service:counseling.children".

 

It might make sense to define new URNs= for "national gendarmerie" / "national police", and possibl= y "counter terrorism", since it seems that those exist in several countries.

 

But in general, this is the sort of exercise that people should go through for the various countries.

 

--Richard

 

 

 

 =

On Mon, Feb 18, 2013 at 12:= 39 PM, John-Luc Bakker <jb= akker@rim.com> wrote:

Hi,

 <= o:p>

A few observations on the contents of th= e Wikipedia page.

The first entry shows Algeria= having one number for medical AND f= ire: “14”.

Should there be one URN for “medical” and “fire” registered with IANA? (A secon= d country with one number for medical AND fire, “15” in their case, is Morocco).

 <= o:p>

Also, Algeria lists:<= span lang=3DEN-US>

 <= o:p>

National Gendarmerie : 1055; Counter Terrorist Unit : 1548; suppo= rt for children : 3033.<= /span>

 <= o:p>

So, URNs for these may also be needed. However, I question if we should derive IANA-registered URNs from any Wikip= edia page (which can be edited by others that national regulators).

 <= o:p>

Kind regards,

 <= o:p>

      &nbs= p;        John-Luc

 <= o:p>

From: ecrit-bounces@ietf= .org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Richard Barnes<= br> Sent: Monday, February 18, 2013 11:28 AM
To: Ivo Sedlacek


Cc: ecrit@ietf.org
Subject: Re: [Ecrit] Draft n= ew: draft-holmberg-ecrit-country-specific-emergency-services-00

 

Yes, I was thinking that the policy would be that an emergency service exists in o= ne country.  The purpose of the registry would be just be to encourage deduplication.  So, for instance, to encourage the several different countries that have traffic police numbers* to all use something like "urn:service:sos.traffic".  Or, to choose a better example, = once Korea has registered "urn:service:sos.espionage", to encourage the seco= nd country that establishes a spy reporting service to also use that URN.=

 

Alternatively, someone could just go through the list of emergency numbers on Wikipedia an= d submit one big registration for the common ones (like traffic police).  Those would be allowable under the current policy.<= /font>

 

--Richard 

 

* according to wikipedia: EG, SD, CN, IN**, PK, SA, AL, AM, AZ, N= Z, CO, EC

** hopefully India could be persuaded to consolidate its three different traffic police number= s

 

On Mon, Feb= 18, 2013 at 9:00 AM, Ivo S= edlacek <ivo.sedl= acek@ericsson.com> wrote:

Hello,

thank you for your mail.


> It seems to me that the more conservative approach would be to just up= date the IANA registration policy to be slightly more liberal.=

By "slightly more liberal", do you propose that the IANA registratio= n policy for registration of any sub-service of the service URN with the 'sos= ' service type would be relaxed similarly as proposed in the draft (i.e. it i= s sufficient if the emergency service exists in single country only)? That wo= uld be possible.

Or do you have other proposal?

Thank you for clarification.


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

 

------------------------------------------------= ---------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from you= r system. Use, dissemination, distribution, or reproduction of this transmiss= ion by unintended recipients is not authorized and may be unlawful. =

 

--_000_EDC0A1AE77C57744B664A310A0B23AE2107016089BFRMRSSXCHMBSC_-- From internet-drafts@ietf.org Mon Feb 18 18:26:35 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E921721E8053; Mon, 18 Feb 2013 18:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPhh8aku8f1e; Mon, 18 Feb 2013 18:26:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434E121E8063; Mon, 18 Feb 2013 18:26:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130219022634.26464.62370.idtracker@ietfa.amsl.com> Date: Mon, 18 Feb 2013 18:26:34 -0800 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-06.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 02:26:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Additional Data related to an Emergency Call Author(s) : Brian Rosen Hannes Tschofenig Roger Marshall Randall Gellens Filename : draft-ietf-ecrit-additional-data-06.txt Pages : 46 Date : 2013-02-18 Abstract: When an emergency call is sent to a Public Safety Answering Point (PSAP), the device that sends it, as well as any service provider in the path of the call, or access network through which the call originated may have information about the call which the PSAP may be able to use. This document describes an XML data structure to contains such data and a Uniform Resource Identifier (URI) for conveying the data to the PSAP. The URI may point to either an external resource, or the body of the SIP message. 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-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From dan@mongrain.org Tue Feb 19 06:36:34 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D48221F8D79 for ; Tue, 19 Feb 2013 06:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiVXt4PzkoAc for ; Tue, 19 Feb 2013 06:36:32 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6DA21F89E5 for ; Tue, 19 Feb 2013 06:36:31 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c10so8392840ieb.17 for ; Tue, 19 Feb 2013 06:36:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=L+l2ZPOoVbTdvv2a+stdhP+U6WpOwiBz0GAVtwxDl5E=; b=Y5rymtJWmmlHpVOf9JUaaMOaz2WTL6fc1MgHSJTrpL/Que/NKWsrXvZzzWjoX093tr KCogSs2XLzd85dS2zXmbqhZbFQ47eioINuV3D9O6TtkWHKdGSTNeWa/O36WxxrUN4f12 QabZKPZLCcISIvMiUWraaIuI6yXQCH+habZvexx2Tl9KcUfona8dVrzpkE3s/kEuBz9G Uz1o/pR0QJLlFEkE8Nf4melQAb6Q5JJM2te7KuGpzH6FKUs7J/58ne4XBoBnnW762zyG V4kq6h2khqoKTb9F3RfrKwFoWpqn5ofEKlRPXEXrPZvCteTEK41o95DfQW+3GjGc2Sm8 tYOQ== MIME-Version: 1.0 X-Received: by 10.50.170.36 with SMTP id aj4mr8420988igc.4.1361284588594; Tue, 19 Feb 2013 06:36:28 -0800 (PST) Received: by 10.50.171.41 with HTTP; Tue, 19 Feb 2013 06:36:28 -0800 (PST) X-Originating-IP: [209.87.237.3] In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188012140771193@SISPE7MB1.commscope.com> References: <39B5E4D390E9BD4890E2B3107900610103F703@ESESSMB301.ericsson.se> <9E790F21-21D7-437B-820B-A88355047BBA@neustar.biz> <39B5E4D390E9BD4890E2B3107900610103FBB3@ESESSMB301.ericsson.se> <6E7FEA84-EBE2-4BE0-B8EA-67D5AD8CA9F2@neustar.biz> <50D08D29.2030303@mongrain.org> <39B5E4D390E9BD4890E2B3107900610104BB9D@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610104C240@ESESSMB301.ericsson.se> <5A55A45AE77F5941B18E5457ECAC818801214077118C@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC8188012140771193@SISPE7MB1.commscope.com> Date: Tue, 19 Feb 2013 09:36:28 -0500 Message-ID: From: Dan Mongrain To: "Winterbottom, James" Content-Type: multipart/alternative; boundary=e89a8f234a515767d204d614c4bb X-Gm-Message-State: ALoCoQnBfKgL00MP/en2A5SyyNdWCr811TC9GZtAZOgGsZjeJVydnsABqc0w6pl2CSBCtxkVmd3o Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 14:36:34 -0000 --e89a8f234a515767d204d614c4bb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The problem is that different countries has different names for their political subdivisions. In the US they are states, in Canada they are provinces, etc. Same when you further subdivide. While not privy to the discussions that came up with A1, A2, =E2=80=A6, A5, I have the feeling thi= s nomenclature was picked for the same reason. Why not utilise the same naming scheme for specifying the jurisdiction you want to reach? Thanx, Dan On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James < James.Winterbottom@commscope.com> wrote: > In that case, one might say state in the hierarchy, not A1.**** > > ** ** > > Cheers**** > > James**** > > ** ** > > ** ** > > *From:* Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* Tuesday, 19 February 2013 8:57 AM > *To:* Winterbottom, James > *Cc:* Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org > > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > ** ** > > It might make sense if you wanted to allow the caller to explicitly selec= t > police at a different level of responsibility, e.g., the state police > rather than the local police. **** > > ** ** > > On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James < > James.Winterbottom@commscope.com> wrote:**** > > I think I am missing something here, A1 is part of the location, so why > does it need to be in the URN at all?**** > > As far as I understand current deployments, they use the URN to select a > layer in the GIS that corresponds to the service type, and then use > geographic boundaries within that layer to select the final destination.*= * > ** > > **** > > *From:* ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behalf > Of *Dan Mongrain > *Sent:* Tuesday, 19 February 2013 7:30 AM**** > > > *To:* Ivo Sedlacek > *Cc:* ecrit@ietf.org > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > **** > > Sorry for responding late to this thread, it kinda fell into a crack=E2= =80=A6 > The current thread reminded me to check this old thread=E2=80=A6**** > > **** > > You are indicating that we need to register 77 Service URN (11 service > subtypes * 7 jurisdiction types based on RFC 4119). I do not recommend > that we create so many registrations. Instead, we should allow a service > URN to be suffixed with a jurisdictional scope. So the following Service > URN are all valid:**** > > **** > > urn:service:sos.police**** > > urn:service:sos.police.traffic**** > > urn:service:sos.police.A1**** > > urn:service:sos.police.traffic.A1**** > > **** > > Question is, do we want to leave jurisdictional scope to only be > applicable to police branch or any Service URN? I=E2=80=99d say the latt= er as it > is always up to the LoST service provisioning (based on local policy) to > determine what is locally acceptable.**** > > **** > > Thanx,**** > > Dan**** > > **** > > On Thu, Dec 20, 2012 at 2:53 AM, Ivo Sedlacek > wrote:**** > > Hello,**** > > **** > > thanks for the proposal and for the check of the Canadian usage.**** > > **** > > Let's try to assign the proposed service URNs to the Wikipedia list:**** > > - municipal police (Czech Republic, Poland) -> urn:service:sos.police.A3 = * > *** > > - tourist police (Egypt, Greece) -> urn:service:sos.police.tourist**** > > - traffic police (Egypt, Sudan, India, Pakistan, Saudi Arabia, Albania, > Armenia, Azerbaijan) -> urn:service:sos.police.traffic**** > > - state police (Italy) -> urn:service:sos.police.country**** > > - customs/financial Police (Italy) -> does not match - we probably need > urn:service:sos.police.financial (new)**** > > - gendarmerie (Romania) -> does not match - we probably need > urn:service:sos.police.military (new)**** > > - local police (Spain) -> urn:service:sos.police.A3**** > > - Catalan police (Spain) -> urn:service:sos.police.A1 (a person with > spanish/catalan background should check)**** > > - civil guard (Spain) -> does not match - we probably need > urn:service:sos.police.military (new) (a person with spanish/catalan > background should check)**** > > - Provincial Police (Canada) - urn:service:sos.police.A1**** > > - S=C3=BBret=C3=A9 du Qu=C3=A9bec (Canada) - urn:service:sos.police.A1***= * > > - federal highway police (Brazil) -> urn:service:sos.police.traffic**** > > - federal police (Brazil) -> urn:service:sos.police.country**** > > - civil police (Brazil) -> does not match - we probably need > urn:service:sos.police.civil (new)**** > > - state highway police (Brazil) -> urn:service:sos.police.A1.traffic**** > > - GAULA (Colombia) -> does not match - we probably need > urn:service:sos.police.antikidnapping (new)**** > > **** > > I.e. we would need additionally:**** > > - urn:service:sos.police.financial**** > > - urn:service:sos.police.military**** > > - urn:service:sos.police.civil**** > > - urn:service:sos.police.antikidnapping**** > > **** > > If I understood it correctly, all together, we would need 77 police > related emergency service URNs =3D (7 (specialized police corp below) + 4 > (additional above)) * 7 (nomenclature specified in Civic Addresses (RFC > 4119)). Seems quite a lot.Moreover, a regulator in a country can define a > new type of a police related emergency service - it depends on how the la= w > enforcement is structure in the country. Then the list will grow even mor= e. > Maybe it would really be better to let regulators to manage per-country > sub-registries.**** > > **** > > Kind regards**** > > **** > > Ivo Sedlacek**** > > **** > > **** > > **** > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out at www.ericsson.com/email_disclaimer **** > > **** > > *From:* Dan Mongrain [mailto:dan@mongrain.org] > *Sent:* 19. prosince 2012 16:00 > *To:* Ivo Sedlacek > *Cc:* ecrit@ietf.org**** > > > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > **** > > I also recommend we create purpose keywords in order to reach a > specialized police corp. Such as: > sos.police.drugs > sos.police.traffic > sos.police.firearms > sos.police.alcohol > sos.police.tobacco > sos.police.tourist > sos.police.border > > The above keywords can be utilized with territorial designations in order > to specify a particular service if offered by multiple jurisdictions. Fo= r > example in the US: > sos.police.country.drugs could be used to reach the DEA whereas > sos.police.A3.drugs could be used to reach the narcotics division of the > city police. > > I can answer for Canada: > sos.police.country would be to reach the Royal Canadian Mountain Police > (RCMP) > In the provinces of Ontario and Qu=C3=A9bec which have provincal polices,= then > sos.police.A1 in Ontario would reach the Ontario Provincial Police (OPP) > and sos.police.A1 in Qu=C3=A9bec would reach the Suret=C3=A9 du Qu=C3=A9b= ec (SQ). > In Canada we do not have a police service at the county level (we do have > sheriff departments but they are more for court and jail security). > In Ontario and Qu=C3=A9bec, a city may have its police service otherwise = the > provincial police offers the service. In the rest of Canada, a city may > have its police service otherwise the RCMP offers the service. > > Thanx, > Dan**** > > On Wed, Dec 19, 2012 at 7:02 AM, Ivo Sedlacek > wrote:**** > > Hello,**** > > **** > > thanks.**** > > **** > > both options (Dan's and Brian's) seemed to work for the emergency service= s > of the police forces in the Czech republic.**** > > **** > > For completeness, I also checked the emergency services of the police > forces of other countries. Wikipedia ( > http://en.wikipedia.org/wiki/Emergency_telephone_number) lists the > following on top of emergency services of the regular police forces:**** > > - municipal police (Czech Republic, Poland) -> can map to > urn:service:sos.police.local or urn:service:sos.police.A3 **** > > - tourist police (Egypt, Greece) -> does not seem to fit into any of the > alternatives so far**** > > - traffic police (Egypt, Sudan, India, Pakistan, Saudi Arabia, Albania, > Armenia, Azerbaijan) -> does not seem to fit into any of the alternatives > so far**** > > - state police (Italy) -> can map to urn:service:sos.police.national or > urn:service:sos.police.country**** > > - customs/financial Police (Italy) -> does not seem to fit into any of th= e > alternatives so far**** > > - gendarmerie (Romania) -> does not seem to fit into any of the > alternatives so far**** > > - local police (Spain) -> can map to urn:service:sos.police.local or > urn:service:sos.police.A3**** > > - Catalan police (Spain) -> maybe this could map to > urn:service:sos.police.regional or urn:service:sos.police.A1 but a person > with spanish/catalan background should check.**** > > - civil guard (Spain) -> does not seem to fit into any of the alternative= s > so far**** > > - Provincial Police (Canada) - maybe this could map to > urn:service:sos.police.regional or urn:service:sos.police.A1 but a person > with canadian background should check**** > > - S=C3=BBret=C3=A9 du Qu=C3=A9bec (Canada) - maybe this could map to > urn:service:sos.police.regional or urn:service:sos.police.A1 but a person > with canadian background should check**** > > - federal highway police (Brazil) -> does not seem to fit into any of the > alternatives so far**** > > - federal police (Brazil) -> can map to urn:service:sos.police.national o= r > urn:service:sos.police.country**** > > - civil police (Brazil) -> does not seem to fit into any of the > alternatives so far**** > > - state highway police (Brazil) -> does not seem to fit into any of the > alternatives so far**** > > - GAULA (Colombia) -> does not seem to fit into any of the alternatives s= o > far**** > > **** > > For those emergency services above not fitting into any of the > alternatives, how should they be expressed in an emergency service URN? D= o > we assume IANA will register them too?**** > > **** > > Kind regards**** > > **** > > Ivo Sedlacek**** > > **** > > **** > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out at www.ericsson.com/email_disclaimer **** > > **** > > *From:* ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behalf > Of *Dan Mongrain, eng. > *Sent:* 18. prosince 2012 16:35 > *To:* ecrit@ietf.org**** > > > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > **** > > Instead of trying to come up with the proper nomenclature for the > jurisdiction to be used in the Service URN, why not utilize the > nomenclature specified in Civic Addresses (RFC 4119): > sos.police.country for police services at the country/national/federal/et= c > level > sos.police.A1 for police services at the > state/province/region/prefecture/etc level > sos.police.A2 for police services at the county/parish/gun/district/etc > level > sos.police.A3 for police services at the city/township/shi/etc level > sos.police.A4 for police services at the city division/borough/city > district/ward/chou/etc level > sos.police.A5 for police services at the neighborhood/block/etc level > > This way we avoid having to pick a term that has no applicability in > certain countries. > > Thanx, > Dan > > On 14/12/2012 9:12 AM, Rosen, Brian wrote:**** > > I have no problem using "national" instead of "federal". **** > > "State" and "Province" are equivalent. Some countries have one, some hav= e > the other. I don't think there are any with both. Some have neither of > course.**** > > **** > > I'd prefer not to have nation-specific values. **** > > **** > > Brian**** > > On Dec 14, 2012, at 3:48 AM, Ivo Sedlacek > wrote:**** > > **** > > Hello,**** > > **** > > thank you for your mail.**** > > **** > > > I'd support another (optional) level of police with at least 4 values.*= * > ** > > > **** > > > Perhaps "local"/"regional"/"provincial"/"federal"**** > > **** > > if I understood correctly, you propose that:**** > > - urn:service:sos.local,**** > > - urn:service:sos.regional,**** > > - urn:service:sos.provincial,**** > > - urn:service:sos.federal**** > > are registered. if I misunderstood, please correct me.**** > > **** > > urn:service:sos.local would map well to the emergency service provided by > the municipal police in the Czech republic.**** > > **** > > However, the emergency service provided by the national police in the > Czech republic is not easily mapped to any of the values:**** > > - Czech republic has provinces ("kraj") but the provinces (so far) do not > have their own police force.**** > > - Czech republic is not a federation so "federal" does not fit either.***= * > > **** > > Perhaps the following should be defined: urn:service:sos.local, > urn:service:sos.regional, urn:service:sos.*state*, urn:service:sos.federa= l > **** > > **** > > Alternatively, subregistries can be created for each country where the > regulator of the country would manage the emergency service URNs for the > country specific emergency services ( > http://en.wikipedia.org/wiki/Emergency_telephone_number seems to list > quite a lot of those )**** > > **** > > Kind regards**** > > **** > > Ivo Sedlacek**** > > **** > > **** > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out at www.ericsson.com/email_disclaimer**** > > **** > > *From:* Rosen, Brian [mailto:Brian.Rosen@neustar.biz > ] > *Sent:* 13. prosince 2012 15:41 > *To:* Ivo Sedlacek > *Cc:* ecrit@ietf.org > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > **** > > That issue occurs in several other countries.**** > > There are often 3 or more police agencies serving an area. In my home, > there are four:**** > > a) A local (township) police**** > > b) A county police agency that responds to some uncommon events**** > > c) A state police agency, which also has jurisdiction in some circumstanc= es > **** > > d) The federal police (FBI)**** > > **** > > While we do have a single number, if you explicitly wanted the state > police, there is no way to get to them.**** > > **** > > I'd support another (optional) level of police with at least 4 values.***= * > > **** > > Perhaps "local"/"regional"/"provincial"/"federal"**** > > **** > > Brian**** > > On Dec 13, 2012, at 8:22 AM, Ivo Sedlacek > wrote:**** > > **** > > Hello,**** > > **** > > in the Czech republic, the national regulator defined two police related > emergency services:**** > > A) emergency service provided by the national police (number 158 in the > public switched telephone network); and**** > > B) emergency service provided by the municipal police (number 156 in the > public switched telephone network).**** > > **** > > The regulation is > http://aplikace.mvcr.cz/archiv2008/sbirka/2007/sb043-07.pdf which lists > the numbers 156 and 158 in section 4.5. with note 2) which states "=C4=8C= =C3=ADslo je > n=C3=A1rodn=C3=ADm =C4=8D=C3=ADslem pro t=C3=ADs=C5=88ov=C3=A9 vol=C3=A1n= =C3=AD" (=3D the number is a national number for > emergency calls).**** > > **** > > Is it appropriate to register the following URNs for those services with > IANA?**** > > - urn:service:sos.police.national - The 'police.national' service refers > to the police department or other law enforcement authorities of the > national government.**** > > - urn:service:sos.police.municipal - The 'police.municipal' service refer= s > to the police department or other law enforcement authorities of the > municipal authorities.**** > > **** > > Or should those be registered with a prefix indicating that those are > applicable to Czech republic only, as other countries may have similar (b= ut > not necessarily identical) services:**** > > - urn:service:sos.police.czech.national - The 'police.czech.national' > service refers to the police department or other law enforcement > authorities of the national government.**** > > - urn:service:sos.police.czech.municipal - The 'police.czech.municipal' > service refers to the police department or other law enforcement > authorities of municipal authorities.**** > > **** > > I assume this question belongs to IANA, but as the expert reviewer most > likely will be from the ECRIT, I am sending it here.**** > > **** > > Kind regards**** > > **** > > Ivo Sedlacek**** > > **** > > **** > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out atwww.ericsson.com/email_disclaimer**** > > _______________________________________________ > 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**** > > ** ** > --e89a8f234a515767d204d614c4bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The problem is that diffe= rent countries has different names for their political subdivisions.=C2=A0 In the US they are states, in Canada th= ey are provinces, etc.=C2=A0 Same when you further subdivide.=C2=A0 While not privy to the discussions that came up with A1, A2, =E2=80=A6, A5, I have th= e feeling this nomenclature was picked for the same reason.=C2=A0 Why not utilise the same naming scheme for specifying the jurisdiction you want to reach?

=C2=A0

Thanx,

Dan



On Mon, Feb 18, 2013 at 5:01 PM, Winterb= ottom, James <James.Winterbottom@commscope.com> wrote:

In that case,= one might say state in the hierarchy, not A1.

=C2=A0

Cheers

James

=C2=A0=

=C2=A0

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Tuesday, 19 February 2013 8:57 AM
To: Winterbottom, = James
Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org


Subject: Re: [Ecrit] What is the most appropriate method for reg= istering new sub-services of urn:service:sos

=C2=A0<= /p>

It might make sense if you wanted to allow the calle= r to explicitly select police at a different level of responsibility, e.g.,= the state police rather than the local police. =C2=A0

=C2=A0=

On Mon, Feb 18, 2013 at 4:21 PM, Winter= bottom, James <James.Winterbottom@commscope.com> wrote:<= /p>

I think I am mi= ssing something here, A1 is part of the location, so why does it need to be= in the URN at all?

As far as I understand cu= rrent deployments, they use the URN to select a layer in the GIS that corre= sponds to the service type, and then use geographic boundaries within that = layer to select the final destination.

=C2=A0

From: ecrit-bounces@ietf.org= [mailto:ec= rit-bounces@ietf.org] On Behalf Of Dan Mongrain
Sent: Tuesday, 19 February 2013 7:30 AM


To: Ivo Sedlacek
Cc: ecrit@ietf.org
Su= bject: Re: [Ecrit] What is the most appropriate method for registering = new sub-services of urn:service:sos

=C2=A0

=

Sorry for responding late= to this thread, it kinda fell into a=C2=A0 crack=E2=80=A6=C2=A0 The curren= t thread reminded me to check this old thread=E2=80=A6=

=C2=A0

You are indicating = that we need to register 77 Service URN (11 service subtypes * 7 jurisdicti= on types based on RFC 4119).=C2=A0 I do not recommend that we create so man= y registrations.=C2=A0 Instead, we should allow a service URN to be suffixe= d with a jurisdictional scope.=C2=A0 So the following Service URN are all v= alid:

=C2=A0

urn:service:sos.pol= ice

urn:service:sos.police.tr= affic

urn:service:sos.police.A1

urn:service:sos.police.tr= affic.A1

=C2=A0

Question is, do we want t= o leave jurisdictional scope to only be applicable to police branch or any = Service URN? =C2=A0I=E2=80=99d say the latter as it is always up to the LoS= T service provisioning (based on local policy) to determine what is locally= acceptable.

=C2=A0

Thanx,

Dan<= /p>

=C2=A0

On Thu, Dec 20, 2012 at 2:53 AM, Ivo Sedlacek <ivo.sedlacek@e= ricsson.com> wrote:

Hello,

=C2=A0=

thanks for the proposal= and for the check of the Canadian usage.

=C2=A0=

Let's try to assign= the proposed service URNs to the Wikipedia list:

- municipal police (Czech R= epublic, Poland) -> urn:service:sos.police.A3

<= p class=3D"MsoNormal"> - tourist police (Egypt, Greece) -> urn:service= :sos.police.tourist

- traffic police (Egypt, Sudan, India, Pakistan, Saudi Ara= bia, Albania, Armenia, Azerbaijan) -> urn:service:sos.police.traffic

- state police (Italy) ->= ; urn:service:sos.police.country

- customs/financial Police (Italy) -> does not = match - we probably need urn:service:sos.police.financial (new)

- gendarmerie (Romania) -&g= t; does not match - we probably need urn:service:sos.police.military (new)<= /span>

- local police (Spain) ->= ; urn:service:sos.police.A3

= - Catalan police (Spain) -> urn:service:sos.pol= ice.A1 (a person with spanish/catalan background should check)

- civil guard (Spain) ->= does not match - we probably need urn:service:sos.police.military (new) (a= person with spanish/catalan background should check)<= /p>

- Provincial Police (Canada= ) - urn:service:sos.police.A1

- S=C3=BBret=C3=A9 du Qu=C3=A9bec (Canada) - urn:s= ervice:sos.police.A1

- federal highway police (Brazil) -> urn:service:sos.p= olice.traffic

- federal police (Brazil) -= > urn:service:sos.police.country

- civil police (Brazil) -> does not match - we = probably need urn:service:sos.police.civil (new)

- state highway police (Bra= zil) -> urn:service:sos.police.A1.traffic

- GAULA (Colombia) -> does not match - we proba= bly need urn:service:sos.police.antikidnapping (new)

=C2=A0=

I.e. we would need addi= tionally:

- urn:service:sos.police.fi= nancial

- urn:service:sos.police.military

- urn:service:sos.police.ci= vil

- urn:service:sos.police.antikidnapping

=C2=A0=

If I understood it corr= ectly, all together, we would need 77 police related emergency service URNs= =3D (7 (specialized police corp below) + 4 (additional above)) * 7 (nomenc= lature specified in Civic Addresses (RFC 4119)). Seems quite a lot.Moreover= , a regulator in a country can define a new type of a police related emerge= ncy service - it depends on how the law enforcement is structure in the cou= ntry. Then the list will grow even more. Maybe it would really be better to= let regulators to manage per-country sub-registries.<= /p>

=C2=A0

Kind regards

=C2=A0=

Ivo Sedlacek<= /u>

=C2=A0=

=C2=A0=

=C2=A0=

This Communication is Co= nfidential. We only send and receive email on the basis of the terms set ou= t at www.er= icsson.com/email_disclaimer

=C2=A0=

From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. prosince 2012 16:00
To: Ivo Sedlacek
Cc: ecrit@ietf.org


Subject: Re: [Ecrit= ] What is the most appropriate method for registering new sub-services of u= rn:service:sos

=C2=A0

I also recommend we create = purpose keywords in order to reach a specialized police corp.=C2=A0 Such as= :
sos.police.drugs
sos.police.traffic
sos.police.firearms
sos.police.alcohol
sos.poli= ce.tobacco
sos.police.tourist
sos.police.border

The above keyw= ords can be utilized with territorial designations in order to specify a pa= rticular service if offered by multiple jurisdictions.=C2=A0 For example in= the US:
sos.police.country.drugs could be used to reach the DEA whereas
sos.poli= ce.A3.drugs could be used to reach the narcotics division of the city polic= e.

I can answer for Canada:
sos.police.country would be to reach = the Royal Canadian Mountain Police (RCMP)
In the provinces of Ontario and Qu=C3=A9bec which have provincal polices, t= hen sos.police.A1 in Ontario would reach the Ontario Provincial Police (OPP= ) and sos.police.A1 in Qu=C3=A9bec would reach the Suret=C3=A9 du Qu=C3=A9b= ec (SQ).
In Canada we do not have a police service at the county level (= we do have sheriff departments but they are more for court and jail securit= y).
In Ontario and Qu=C3=A9bec, a city may have its police service otherwise th= e provincial police offers the service.=C2=A0 In the rest of Canada, a city= may have its police service otherwise the RCMP offers the service.

= Thanx,
Dan

On Wed, Dec 19, 2012 at 7:= 02 AM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:

=

Hello,=

=C2=A0=

thanks.

=C2=A0

both options (Dan's and= Brian's) seemed to work for the emergency services of the police force= s in the Czech republic.

=C2=A0=

For completeness, I als= o checked the emergency services of the police forces of other countries. W= ikipedia (http://en.wikipedia.org/wiki/Emergen= cy_telephone_number) lists the followin= g on top of emergency services of the regular police forces:<= u>

- municipal police (Czech R= epublic, Poland) -> can map to urn:service:sos.police.local or urn:servi= ce:sos.police.A3

- tourist police (Egypt, Gr= eece) -> does not seem to fit into any of the alternatives so far=

- traffic police (Egypt, Su= dan, India, Pakistan, Saudi Arabia, Albania, Armenia, Azerbaijan) -> doe= s not seem to fit into any of the alternatives so far<= /p>

- state police (Italy) ->= ; can map to urn:service:sos.police.national or urn:service:sos.police.coun= try

- customs/financial Police = (Italy) -> does not seem to fit into any of the alternatives so far

- gendarmerie (Romania) -&g= t; does not seem to fit into any of the alternatives so far

- local police (Spain) ->= ; can map to urn:service:sos.police.local or urn:service:sos.police.A3

- Catalan police (Spain) -&= gt; maybe this could map to urn:service:sos.police.regional or urn:service:= sos.police.A1 but a person with spanish/catalan background should check.

- civil guard (Spain) ->= does not seem to fit into any of the alternatives so far<= /u>

- Provincial Police (Canada= ) - maybe this could map to urn:service:sos.police.regional or urn:service:= sos.police.A1 but a person with canadian background should check<= /u>

- S=C3=BBret=C3=A9 du Qu=C3= =A9bec (Canada) - maybe this could map to urn:service:sos.police.regional o= r urn:service:sos.police.A1 but a person with canadian background should ch= eck

- federal highway police (B= razil) -> does not seem to fit into any of the alternatives so far

- federal police (Brazil) -= > can map to urn:service:sos.police.national or urn:service:sos.police.c= ountry

- civil police (Brazil) -&g= t; does not seem to fit into any of the alternatives so far

- state highway police (Bra= zil) -> does not seem to fit into any of the alternatives so far<= u>

- GAULA (Colombia) -> do= es not seem to fit into any of the alternatives so far=

=C2=A0=

For those emergency ser= vices above not fitting into any of the alternatives, how should they be ex= pressed in an emergency service URN? Do we assume IANA will register them t= oo?

=C2=A0

Kind regards

=C2=A0=

Ivo Sedlacek<= /u>

=C2=A0=

=C2=A0=

This Communication is C= onfidential. We only send and receive email on the basis of the terms set o= ut at www.e= ricsson.com/email_disclaimer <= /u>

=C2=A0<= u>

From: <= a href=3D"mailto:ecrit-bounces@ietf.org" target=3D"_blank">ecri= t-bounces@ietf.org [mailto:ecrit-bounces@ietf.or= g] On Behalf Of Dan Mongrain, eng.
Sent: 18. prosince 2012 16:35
To: ecrit@ietf.org=


Subject: Re: [Ecrit] What is th= e most appropriate method for registering new sub-services of urn:service:s= os

=C2=A0

Instead of trying to co= me up with the proper nomenclature for the jurisdiction to be used in the S= ervice URN, why not utilize the nomenclature specified in Civic Addresses (= RFC 4119):
sos.police.country for police services at the country/national/federal/etc = level
sos.police.A1 for police services at the state/province/region/pre= fecture/etc level
sos.police.A2 for police services at the county/parish= /gun/district/etc level
sos.police.A3 for police services at the city/township/shi/etc level
sos= .police.A4 for police services at the city division/borough/city district/w= ard/chou/etc level
sos.police.A5 for police services at the neighborhood= /block/etc level

This way we avoid having to pick a term that has no applicability in ce= rtain countries.

Thanx,
Dan

On 14/12/2012 9:12 AM, Rosen, = Brian wrote:

I have no problem using "national" instead= of "federal".

&quo= t;State" and "Province" are equivalent. =C2=A0Some countries= have one, some have the other. =C2=A0I don't think there are any with = both. =C2=A0Some have neither of course.

=C2=A0

I'd prefer not to have nation-specific values. =C2=A0<= u>

=C2=A0

=

Brian

On Dec 1= 4, 2012, at 3:48 AM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:

=C2=A0

Hello,

=C2=A0=

t= hank you for your mail.

=C2=A0=

&= gt;=C2=A0I'd support another (optional) level of police with at = least 4 values.

>=C2=A0

>=C2=A0Perhaps "local"/"regional"/"pr= ovincial"/"federal"

=C2=A0=

i= f I understood correctly, you propose that:

- urn:service:so= s.local,

- urn:service:sos.regional,

- urn:service:so= s.provincial,

- urn:service:sos.federal

are registered. = if I misunderstood, please correct me.

<= p class=3D"MsoNormal"> =C2=A0

urn:service:sos.local would map wel= l to the emergency service provided by the municipal police in the Czech re= public.

=C2=A0=

H= owever, the emergency service provided by the national police in the Czech = republic is not easily mapped to any of the values:

- Czech republic= has provinces ("kraj") but the provinces (so far) do not have th= eir own police force.

- Czech republic= is not a federation so "federal" does not fit either.<= /u>

=C2=A0=

P= erhaps the following should be defined: urn:service:sos.local, urn:service:= sos.regional, urn:service:sos.state, urn:service:sos.federal<= /span>

=C2=A0=

A= lternatively, subregistries can be created for each country where the regul= ator of the country would manage the emergency service URNs for the country= specific emergency services (=C2=A0http://en.wikipedia.org/wiki/Emergency_telephone_number=C2=A0seems to list quite a lot of those )=

=C2=A0=

K= ind regards

=C2=A0=

I= vo Sedlacek

=C2=A0=

= =C2=A0

This Communi= cation is Confidential. We only send and receive email on the basis of the = terms set out at=C2=A0www.ericsson.com/email_disclaimer=

=C2=A0

From:=C2= =A0Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=C2=A0
Sent:=C2=A013. prosince 2012 15:41
To:=C2=A0Ivo SedlacekCc:=C2=A0ecrit@ietf.org
Subject:=C2=A0Re: [Ecrit] What is the most appropriate method for re= gistering new sub-services of urn:service:sos

=C2=A0

That issue occurs in several other countries.

<= div>

There are often 3 or more police agencies servin= g an area. =C2=A0In my home, there are four:

<= div>

a) A local (township) police

<= /div>

b) A county police agency that = responds to some uncommon events

c) A state police agency, which also has jurisdiction in some circumstances=

d) The feder= al police (FBI)

=C2=A0

While = we do have a single number, if you explicitly wanted the state police, ther= e is no way to get to them.

=C2=A0

I'= d support another (optional) level of police with at least 4 values.=

=C2=A0

Perhaps "local"/"regi= onal"/"provincial"/"federal"

=C2=A0

Brian

On Dec 13, 2012, at 8:22 AM, Ivo Sedlacek &l= t;ivo.sedlacek@ericsson.com> wrote:

=C2= =A0

Hello,

=C2=A0<= /u>

in = the Czech republic, the national regulator defined two police related emerg= ency services:

A) emergency serv= ice provided by the national police (number 158 in the public switched tele= phone network); and

B) emergency serv= ice provided by the municipal police (number 156 in the public switched tel= ephone network).

=C2=A0<= /u>

The= regulation is=C2=A0http://= aplikace.mvcr.cz/archiv2008/sbirka/2007/sb043-07.pdf=C2=A0which lists the numbers 156 and 158 in section 4.5. with note 2) wh= ich states "=C4=8C=C3=ADslo je n=C3=A1rodn=C3=ADm =C4=8D=C3=ADslem pro= t=C3=ADs=C5=88ov=C3=A9 vol=C3=A1n=C3=AD" (=3D the number is a nationa= l number for emergency calls).

=C2=A0<= /u>

Is = it appropriate to register the following URNs for those services with IANA?=

- urn:service:sos= .police.national - The 'police.national' service refers to the poli= ce department or other law enforcement authorities of the national governme= nt.

- urn:service:sos= .police.municipal - The 'police.municipal' service refers to the po= lice department or other law enforcement authorities of the municipal autho= rities.

=C2=A0<= /u>

Or = should those be registered with a prefix indicating that those are applicab= le to Czech republic only, as other countries may have similar (but not nec= essarily identical) services:

- urn:service:sos= .police.czech.national - The 'police.czech.national' service refers= to the police department or other law enforcement authorities of the natio= nal government.

- urn:service:sos= .police.czech.municipal - The 'police.czech.municipal' service refe= rs to the police department or other law enforcement authorities of municip= al authorities.

=C2=A0<= /u>

I a= ssume this question belongs to IANA, but as the expert reviewer most likely= will be from the ECRIT, I am sending it here.

=C2=A0<= /u>

Kin= d regards

=C2=A0<= /u>

Ivo= Sedlacek

=C2=A0<= /u>

=C2= =A0

This Communicatio= n is Confidential. We only send and receive email on the basis of the terms= set out atwww.ericsson.com/email_disclaimer

____________________= ___________________________
Ecrit mailing list
Ecrit@ietf= .org
https://www.ietf.org/mailman/listinfo/ecr= it

=C2=A0

=C2=A0

=C2=A0

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

=C2=A0

=C2=A0

<= /div>

=C2=A0


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

=C2=A0


--e89a8f234a515767d204d614c4bb-- From ivo.sedlacek@ericsson.com Tue Feb 19 10:59:08 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5EF21F8E4B for ; Tue, 19 Feb 2013 10:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.511 X-Spam-Level: X-Spam-Status: No, score=-5.511 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_FRAUD_X3=1.667] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2xmWZZucu90 for ; Tue, 19 Feb 2013 10:59:02 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 750D621E8064 for ; Tue, 19 Feb 2013 10:59:01 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-a1-5123cb74e187 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B6.46.19728.47BC3215; Tue, 19 Feb 2013 19:59:00 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.208]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 19:58:59 +0100 From: Ivo Sedlacek To: "DRAGE, Keith (Keith)" , "ecrit@ietf.org" Thread-Topic: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emergency-services-00 Thread-Index: Ac4O0vjOoUmmGN7gQ5uk1LzQzDDi7A== Date: Tue, 19 Feb 2013 18:58:59 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610109A534@ESESSMB301.ericsson.se> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/mixed; boundary="_004_39B5E4D390E9BD4890E2B3107900610109A534ESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA2WSa0hTYRzGec85O7uA8jpN/5gGefnirZJ9kEgxNDH6kOaHQrwNOqi0VOYl oUJNRyharjR1lk5bFpaNmqXZTBxBmTXv4SwrLxOszMDCuzXPuw9S337/h+c85/8+7yuipb8E 7qL0jBxOmSFXeLESpu7U5oXAnH7v2P01c44hRc1WQYi16B0Kp6JVc92CaJ1ulYqh4iWHTnOK 9DxOuS8sRZK2uTLOZr35QuVbhzvpQtRtpMqQWARYBk++3hcSdoXBT3q2DElEUmxCsPZjzT7o EEwYeuhtF4uDQN3+UrDNLjgFem4b+CRnnAj16iVE9CSYVv0UEg6Cu88WeJ3BvvB29AHvd8DH YL3Vwucg7AljGxW8h8ZuMDHbaN/OBaaG+lnCu2B+ZktAeC9cthba/enwQdOOSKYT9NXNMpVI qtkRpdlh0+ywET0TRkb7EOEgGK+uYgn7Q0vTN5pwINRumZj/dQ8wVJfavpXYWIVgq7aN0fCF ddnaq1+myPAIQVfNFk0GHQUDbev2YRTBWK1RuB0mxblgWPrD/4TFoWC5Uc0v7oID4Op7Lb+g Mz4ML0yrNNGjoKy3wsYivuOVlgCNveKOTa39nOGg7ZhHJD4BqlZr+HgxDoPmz4sM0UPhVul1 wb99AY6E1916AWEMOuMATdgTvjc22HVyJdtnAVwqgsnpekZjf1XD+g5Ki3xakfCsPF2Rei74 MbK93N72dd9O9NHsYkK7RYyXm8PJI4MxUpwqz+HOcFwWp0xW5iq4bBOiRGL3QnTRVBCVcjOz P7Bl2Zg24HAvrsNs3lPjv5LVJFFEJJinDhZQFrG5J9qkYlnvyE2Zq+apvqLsPDe5EREffGWm /E7yCdlzvXd5w9GkS9dcZdLjThsec+rflUMjxld5i3FLxbGCriBLq8+CQ3JfhKN67WFJXmJ7 iX++yZhvzfQrNnsx2WnyA360Mlv+F+Vj5BiHAwAA Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emergency-services-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 18:59:08 -0000 --_004_39B5E4D390E9BD4890E2B3107900610109A534ESESSMB301ericsso_ Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B3107900610109A534ESESSMB301ericsso_" --_000_39B5E4D390E9BD4890E2B3107900610109A534ESESSMB301ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, thanks for very good summary. regarding "3) There are a number of countries where a number of dis= tinct police forces exist" - I also submitted to IANA the attached request = for police related emergency services which exist in Poland and the Czech r= epublic. RFC5031 policy is hopefully fulfilled for them since they exist in= two countries. 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 From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: 19. =FAnora 2013 2:04 To: ecrit@ietf.org Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emerg= ency-services-00 To try and put things in context, I think there are four "problems" with th= e existing sos URN values. draft-holmberg-ecrit-country-specific-emergency-= services-00 attempts to solve only one of these. 1) There are a number of emergency services that exist in multiple = countries where a sos subtype is not defined. My view is that we probably s= hould define values for: - traffic emergency - child protection emergency (this is not the same as= child counselling). For example Italy, among others, has such a value wher= e an immediate response is required. Obviously before we can define these (and in addition to fulfil= ling the IANA registration requirements), we need to come up definitions of= what these really mean. 2) There are a number of emergency services that exist in a single = country. Ideally, for use in networks where service URNs are used, these sh= ould have some form of service URN defined. This is what draft-holmberg-ecr= it-country-specific-emergency-services-00 seeks to resolve. 3) There are a number of countries where a number of distinct polic= e forces exist. For any given location, these tend to be defined on a range= of areas of jurisdiction, e.g. national versus municipal. This has been di= scussed on the list over the end of last year, and there seemed to be some = consensus on defining a range of subtypes for subtype "police". Obviously i= t will not be possible to cover every variation with this, and we probably = need to limit ourselves to values that serve in multiple countries, in the = same way the higher level subtypes do. 4) There are a number of cases were PSAPs cover multiple subtyp= es. Where service URNs are being used in isolation, this is not an issue. H= owever where service URNs are being created from dialled digits, a particul= ar local service number in the telephony numbering plan could well map to t= wo or more potential subtypes. Yes, in these cases we could ignore generati= ng a subtype altogether, but some countries find it desirable to obtain all= the information available from the user. Thus it would be useful to be abl= e to say sos.fire+medical in these scenarios. Note that all these issues fall under the "sos" definition of emergency ser= vice. Regards Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Richard Barnes Sent: 18 February 2013 17:56 To: John-Luc Bakker Cc: ecrit@ietf.org Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emerg= ency-services-00 Hi John-Luc, We actually already have separate URNs for medical and fire -- "urn:service= :sos.ambulance" and "urn:service:sos.fire" [1]. So that's not an issue. L= oST can map them to the same or different numbers depending on the jurisdic= tion. There is also a "counseling" URN for children, "urn:service:counseli= ng.children". It might make sense to define new URNs for "national gendarmerie" / "nation= al police", and possibly "counter terrorism", since it seems that those exi= st in several countries. But in general, this is the sort of exercise that people should go through = for the various countries. --Richard [1] On Mon, Feb 18, 2013 at 12:39 PM, John-Luc Bakker > wrote: Hi, A few observations on the contents of the Wikipedia page. The first entry shows Algeria having one number for medical AND fire: "14". Should there be one URN for "medical" and "fire" registered with IANA? (A s= econd country with one number for medical AND fire, "15" in their case, is = Morocco). Also, Algeria lists: National Gendarmerie : 1055; Counter Terrorist Unit : 1548; support for chi= ldren : 3033. So, URNs for these may also be needed. However, I question if we should der= ive IANA-registered URNs from any Wikipedia page (which can be edited by ot= hers that national regulators). Kind regards, John-Luc From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Richard Barnes Sent: Monday, February 18, 2013 11:28 AM To: Ivo Sedlacek Cc: ecrit@ietf.org Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emerg= ency-services-00 Yes, I was thinking that the policy would be that an emergency service exis= ts in one country. The purpose of the registry would be just be to encoura= ge deduplication. So, for instance, to encourage the several different cou= ntries that have traffic police numbers* to all use something like "urn:ser= vice:sos.traffic". Or, to choose a better example, once Korea has register= ed "urn:service:sos.espionage", to encourage the second country that establ= ishes a spy reporting service to also use that URN. Alternatively, someone could just go through the list of emergency numbers = on Wikipedia and submit one big registration for the common ones (like traf= fic police). Those would be allowable under the current policy. --Richard * according to wikipedia: EG, SD, CN, IN**, PK, SA, AL, AM, AZ, NZ, CO, EC ** hopefully India could be persuaded to consolidate its three different tr= affic police numbers On Mon, Feb 18, 2013 at 9:00 AM, Ivo Sedlacek > wrote: Hello, thank you for your mail. > It seems to me that the more conservative approach would be to just updat= e the IANA registration policy to be slightly more liberal. By "slightly more liberal", do you propose that the IANA registration polic= y for registration of any sub-service of the service URN with the 'sos' ser= vice type would be relaxed similarly as proposed in the draft (i.e. it is s= ufficient if the emergency service exists in single country only)? That wou= ld be possible. Or do you have other proposal? Thank you for clarification. 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 --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --_000_39B5E4D390E9BD4890E2B3107900610109A534ESESSMB301ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable --_000_39B5E4D390E9BD4890E2B3107900610109A534ESESSMB301ericsso_-- --_004_39B5E4D390E9BD4890E2B3107900610109A534ESESSMB301ericsso_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Tue, 19 Feb 2013 18:58:59 GMT"; modification-date="Tue, 19 Feb 2013 18:58:59 GMT" Received: from esessmw0256.eemea.ericsson.se (153.88.115.96) by ESESSHC012.ericsson.se (153.88.183.54) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 15 Feb 2013 14:08:40 +0100 Received: from sessmg10.ericsson.net (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.98) with Microsoft SMTP Server id 8.3.279.1; Fri, 15 Feb 2013 14:08:38 +0100 Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLS with cipher AES256-SHA (AES256-SHA/256 bits)) (Client did not present a certificate) by sessmg10.ericsson.net (Symantec Mail Security) with SMTP id 77.1F.02091.4533E115; Fri, 15 Feb 2013 14:08:37 +0100 (CET) Received: from request1.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id r1FD8Ytd023791 for ; Fri, 15 Feb 2013 13:08:34 GMT Received: by request1.lax.icann.org (Postfix, from userid 48) id 4088956055E; Fri, 15 Feb 2013 13:08:34 +0000 (UTC) From: IANA General Enquiries via RT To: Ivo Sedlacek Subject: [IANA #658921] AutoReply: General Request for Assignment Thread-Topic: [IANA #658921] AutoReply: General Request for Assignment Thread-Index: AQHOC32SX1Te3vL8t0WkLkxnvVD9fg== Date: Fri, 15 Feb 2013 13:08:34 +0000 Message-ID: References: <201302151308.r1FD8VQL023785@smtp1.lax.icann.org> In-Reply-To: <201302151308.r1FD8VQL023785@smtp1.lax.icann.org> Reply-To: "iana-questions@iana.org" Content-Language: en-US X-MS-Exchange-Organization-AuthSource: esessmw0256.eemea.ericsson.se X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-brightmail-tracker: H4sIAAAAAAAAA+NgFtrFKsWRWlGSWpSXmKPExsVygEExUDfUWC7QoKFBw6J35TxWB0aPX1+v sgUwRnHZpKTmZJalFunbJXBl3NncwVrQKl6x980y1gbGPuEuRk4OCQETiUczX7JD2GISF+6t Z+ti5OIQEljCJPFt0nRGCOcKo8ST7gawKiGBUomt8x+wgNjCAo4S+w79ZO5i5OBgE7CXeLIl HqJEUeLZiu3MIDangJ3EovvvWSDiMRJTfk4Hs3kFHCQWbH/JCGILCAhI/Jt0gQXiCCmJ+8cf QK0Sl1h5rpEJot5c4sCaOSwgq4QENCSmrbYBCTMKyEicmnSDDcQWEZCVOPzuNitEuaDEyZlP wEYyC8hLNG+dDXYls4CmxPpd+hCbZCXO/G4EK2ERUJXY/ncB4wRG8VlIumch6Z6F0L2AkXkV o2hxanFxbrqhgV5qUWZycXF+nl5easkmRmCUHNzy224H47WHhocYJTmYlER5N+jJBQrxJeWn VGYkFmfEF5XmpBYfYpTmYFES5915e0mAkEB6YklqdmpqQWoRTFaDg0Ng4ctlxxmlWPLy81KV JHjPGwJNESxKTU+tSMvMKUEoZeLgPMQowcGjJMKrZwRUw1tckJhbnJkOkT/FaMwx4/WjF4wc kxY+f8EoBDZOSpx3L8g4AZDSjNI8uGmgJFX/////S4yyUsK8jAwMDEI8QFflZpYg5EFJ7hWj OAejkjDvXZApPJl5JXD7XgGdwgR0yp13siCnlCQipKQaGKVD/IJ/bGC/Jmx65Y+11J6/Mxil GAzaWfNOt2YpbQvz2R+ycFX1yoQug/ylCcFL39wIl3/wu2ayrZ6JlDfXt2jWe/veB6WwKy0W 3Pc9gK3y+SNHa5+Q9bpcDU1mt39p/dJ6Grr8vJTnwVe7bp3nMQ9hnhh9MHtBTcnM5UZTHynO sd6TJ/ciUImlOCPRUIu5qDgRAPaV51ZNAwAA x-auditid: c1b4fb3e-b7f636d00000082b-76-511e3353ea56 Content-Type: text/plain; charset="utf-8" Content-ID: <85C61BF4C1823F449D67435976C87CF2@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 VG8gd2hvbSBpdCBtYXkgY29uY2VybjoNCg0KVGhpcyBpcyBhbiBhdXRvbWF0aWNhbGx5IGdlbmVy YXRlZCBtZXNzYWdlIHRvIG5vdGlmeSB5b3UgdGhhdCB3ZSBoYXZlDQpyZWNlaXZlZCB5b3VyIHJl cXVlc3QsIGFuZCBpdCBoYXMgYmVlbiByZWNvcmRlZCBpbiBvdXIgdGlja2V0aW5nDQpzeXN0ZW0g d2l0aCBhIHJlZmVyZW5jZSBudW1iZXIgb2YgNjU4OTIxLg0KDQpUaGVyZSBpcyBubyBuZWVkIHRv IHJlcGx5IHRvIHRoaXMgbWVzc2FnZSByaWdodCBub3cuIElBTkEgc3RhZmYgd2lsbA0KcmV2aWV3 IHlvdXIgbWVzc2FnZSBzaG9ydGx5Lg0KDQpJZiB0aGlzIG1lc3NhZ2UgaXMgaW4gcmVwbHkgdG8g YSBwcmV2aW91c2x5IHN1Ym1pdHRlZCB0aWNrZXQsIGl0IGlzDQpwb3NzaWJsZSB0aGF0IHRoZSBw cmV2aW91cyB0aWNrZXQgaGFzIGJlZW4gbWFya2VkIGFzIGNsb3NlZC4gQXMgd2UNCnJldmlldyB0 aGlzIHRpY2tldCwgd2Ugd2lsbCBhbHNvIHJldmlldyBwcmV2aW91cyBjb3JyZXNwb25kZW5jZSBh bmQNCnRha2UgYXBwcm9wcmlhdGUgYWN0aW9uLg0KDQpUbyBleHBlZGl0ZSBwcm9jZXNzaW5nLCBh bmQgZW5zdXJlIG91ciBzdGFmZiBjYW4gdmlldyB0aGUgZnVsbCBoaXN0b3J5DQpvZiB0aGlzIHJl cXVlc3QsIHBsZWFzZSBtYWtlIHN1cmUgeW91IGluY2x1ZGUgdGhlIGZvbGxvdyBleGFjdCB0ZXh0 IGluDQp0aGUgc3ViamVjdCBsaW5lIG9mIGFsbCBmdXR1cmUgY29ycmVzcG9uZGVuY2Ugb24gdGhp cyBpc3N1ZToNCg0KICAgICAgICAgW0lBTkEgIzY1ODkyMV0NCg0KWW91IGNhbiBhbHNvIHNpbXBs eSByZXBseSB0byB0aGlzIG1lc3NhZ2UsIGFzIHRoaXMgdGFnIGlzIGFscmVhZHkgaW4NCnRoZSBz dWJqZWN0IGxpbmUuDQoNClRoYW5rIHlvdSwNCg0KVGhlIEludGVybmV0IEFzc2lnbmVkIE51bWJl cnMgQXV0aG9yaXR5DQppYW5hLXF1ZXN0aW9uc0BpYW5hLm9yZw0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoNCkNvbnRhY3QgTmFtZToNCkl2byBTZWRsYWNlaw0KDQpDb250YWN0IEVtYWlsOg0KaXZvLnNl ZGxhY2VrQGVyaWNzc29uLmNvbQ0KDQpUeXBlIG9mIEFzc2lnbm1lbnQ6DQpBc3NpZ25tZW50IG9m IGFuIHNlcnZpY2UgVVJOIHdpdGggdGhlICdzb3MnIHNlcnZpY2UgdHlwZSBhcyBzcGVjaWZpZWQg aW4gUkZDNTAzMSwgc2VjdGlvbiA0LjIuDQoNClRoZSBmb2xsb3dpbmcgc2VydmljZSBVUk5zIGFy ZSBwcm9wb3NlZCB0byBiZSByZWdpc3RlcmVkOg0KLSB1cm46c2VydmljZTpzb3MucG9saWNlLmxv Y2FsIC0gVGhlICdwb2xpY2UubG9jYWwnIHNlcnZpY2UgcmVmZXJzIHRvIHRoZSBlbWVyZ2VuY3kg c2VydmljZSBvZmZlcmVkIGJ5IHRoZSBwb2xpY2UgZGVwYXJ0bWVudCBvciBvdGhlciBsYXcgZW5m b3JjZW1lbnQgYXV0aG9yaXRpZXMgb2YgdGhlIGxvY2FsIG9yIG11bmljaXBhbCBhdXRob3JpdGll cy4NCi0gdXJuOnNlcnZpY2U6c29zLnBvbGljZS5uYXRpb25hbCAtIFRoZSAncG9saWNlLm5hdGlv bmFsJyBzZXJ2aWNlIHJlZmVycyB0byB0aGUgZW1lcmdlbmN5IHNlcnZpY2Ugb2ZmZXJlZCBieSB0 aGUgcG9saWNlIGRlcGFydG1lbnQgb3Igb3RoZXIgbGF3IGVuZm9yY2VtZW50IGF1dGhvcml0aWVz IG9mIHRoZSBuYXRpb25hbCBnb3Zlcm5tZW50Lg0KDQpSZWdpc3RyeToNClNlcnZpY2UgVVJOIExh YmVscywgJ3NvcycgU3ViLVNlcnZpY2VzIGFzIHNob3duIGF0IGh0dHA6Ly93d3cuaWFuYS5vcmcv YXNzaWdubWVudHMvdXJuLXNlcnZpY2VpZC1sYWJlbHMvdXJuLXNlcnZpY2VpZC1sYWJlbHMueG1s DQoNCkRlc2NyaXB0aW9uOg0KSW4gdGhlIEN6ZWNoIHJlcHVibGljIGFuZCBQb2xhbmQsIHRoZXJl IGFyZSB0d28gcHVibGljIHNhZmV0eSBhbnN3ZXJpbmcgcG9pbnRzIChQU0FQKSBvZmZlcmluZyB0 aGUgcG9saWNlIHJlbGF0ZWQgZW1lcmdlbmN5IHNlcnZpY2VzLiBUaGUgUFNBUCBvZiB0aGUgbXVu aWNpcGFsIHBvbGljZSBhbmQgdGhlIFBTQVAgb2YgdGhlIG5hdGlvbmFsIHBvbGljZS4gVGhlcmUg aXMgY3VycmVudGx5IG5vIHdheSBob3cgdG8gZGlzdGluZ3Vpc2ggd2hldGhlciB0aGUgdXNlciB3 aXNoZXMgdG8gY29udGFjdCB0aGUgUFNBUCBvZiB0aGUgbXVuaWNpcGFsIHBvbGljZSBvciB0aGUg UFNBUCBvZiB0aGUgbmF0aW9uYWwgcG9saWNlLg0KDQpJbiBDemVjaCwgdGhlIHJlbGF0ZWQgcmVn dWxhdGlvbiBpcyBodHRwOi8vYXBsaWthY2UubXZjci5jei9zYmlya2EtemFrb251L1ZpZXdGaWxl LmFzcHg/dHlwZT1jJmlkPTUxMzQgcGFnZXMgOSBhbmQgMTAgc2VjdGlvbiA0LjUgd2hpY2ggbGlz dHMgdGhlIG51bWJlciAxNTYgZm9yICJPYmVjbsOtIHBvbGljaWUiICg9IG11bmljaXBhbCBwb2xp Y2UpIGFuZCB0aGUgbnVtYmVycyAxNTggZm9yICJQb2xpY2llIMSMZXNrw6kgcmVwdWJsaWt5IiAo PSBDemVjaCByZXB1YmxpYyBwb2xpY2UpLiBCb3RoIG51bWJlcnMgYXJlIGxpc3RlZCB3aXRoIG5v dGUgMikgd2hpY2ggc3RhdGVzICLEjMOtc2xvIGplIG7DoXJvZG7DrW0gxI3DrXNsZW0gcHJvIHTD rXPFiG92w6kgdm9sw6Fuw60iICg9IHRoZSBudW1iZXIgaXMgYSBuYXRpb25hbCBudW1iZXIgZm9y IGVtZXJnZW5jeSBjYWxscykuDQoNCkluIFBvbGFuZCwgaHR0cDovL3VrZS5nb3YucGwvdGFibGlj ZS1udW1lcm93LWtpZXJvd2FuaWEtYWxhcm1vd2Vnby1ua2EtOTQxMCBsaXN0cyB0aGUgbnVtYmVy IDk4NiBmb3IgInN0cmHFvCBtaWVqc2thIiAoPSBtdW5pY2lwYWwgcG9saWNlKSBhbmQgdGhlIG51 bWJlciA5OTcgZm9yIFBvbGljamEgKD0gcG9saWNlKSBhcyAibnVtZXJ5IGFsYXJtb3dlIiAoPSBl bWVyZ2VuY3kgbnVtYmVycykuDQoNCkFkZGl0aW9uYWwgSW5mbzoNClRoZSByZWdpc3RyeSBpcyBk ZWZpbmVkIGJ5IFJGQzUwMzEsIHNlY3Rpb24gNC4yDQoNCg0K --_004_39B5E4D390E9BD4890E2B3107900610109A534ESESSMB301ericsso_-- From ivo.sedlacek@ericsson.com Tue Feb 19 11:31:05 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856DE21E8086 for ; Tue, 19 Feb 2013 11:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.139 X-Spam-Level: X-Spam-Status: No, score=-6.139 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMv9YZNNbVCC for ; Tue, 19 Feb 2013 11:31:04 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 925BE21E8063 for ; Tue, 19 Feb 2013 11:31:03 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-41-5123d2f64637 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C7.FD.10459.6F2D3215; Tue, 19 Feb 2013 20:31:02 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.208]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 20:31:02 +0100 From: Ivo Sedlacek To: Dan Mongrain , "Winterbottom, James" Thread-Topic: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) Thread-Index: Ac4O16Om7f9V0i28RI+oZZ3Gkvt0cA== Date: Tue, 19 Feb 2013 19:31:01 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610109A5A8@ESESSMB301.ericsson.se> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B3107900610109A5A8ESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvje63S8qBBhc26lrcn9PCYtG46Cmr xfVr2hZT+2wdWDxerb3D7rFkyU8mj8kbZ7F4vNimEMASxWWTkpqTWZZapG+XwJVxYeZ19oIV nxgrPjUvZWxg/PGasYuRk0NCwETi96WZULaYxIV769lAbCGBQ4wSX/aZQthLGCW6H2aB2GwC ehITtxxhBbFFBOIlPs++BmYzCzhJ7Pw7jbmLkYtDWGAao8Sfn7OYQBwRgemMEksP3mKD6NCT uN+5jwnEZhFQlZh1aA4LiM0r4C1x9ep5sDijgKzE1T+9jBBTxSVuPZnPBHGdgMSSPeeZIWxR iZeP/7FC2IoS7U8boOrzJebM28sOMVNQ4uTMJywTGIVnIRk1C0nZLCRlsxg5gOKaEut36UOU KEpM6X7IDmFrSLTOmcuOLL6AkX0VI3tuYmZOernhJkZgJB3c8lt3B+OpcyKHGKU5WJTEecNc LwQICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYDQ87WNgyq6jbZ3F+trx1rfFLLfv95nHyfMp 11SwTS8uC6wM0phR9jqu+vNJkaU5BZ9/Wa1hexwevGSqDM9682tXrM+mT8pw379G6K3grh3B VbP3TTlloinrs2ZfWVSWpsJb3v7ZKYabJ+oliZcuZ68xiWwxK1Bq6xD8k7RxHsO//l9/bWZ/ UmIpzkg01GIuKk4EAFl/fAlyAgAA Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 19:31:05 -0000 --_000_39B5E4D390E9BD4890E2B3107900610109A5A8ESESSMB301ericsso_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIFJpY2hhcmQgLSB0aGVyZSBhcmUgY291bnRyaWVzIHdoZXJlIGJvdGggdGhl IGVtZXJnZW5jeSBzZXJ2aWNlIG9mIHRoZSBuYXRpb25hbCBwb2xpY2UgYW5kIHRoZSBlbWVyZ2Vu Y3kgc2VydmljZSBvZiB0aGUgbXVuaWNpcGFsIHBvbGljZSBhcmUgb2ZmZXJlZCBpbiBhIGdpdmVu IGxvY2F0aW9uLg0KQSB1c2VyIHdvdWxkIGNhbGwgdGhlIG11bmljaXBhbCBwb2xpY2UgZW1lcmdl bmN5IHNlcnZpY2UgdG8gcmVwb3J0IGUuZy4gcGlja3BvY2tldHMuDQpBIHVzZXIgd291bGQgY2Fs bCB0aGUgbmF0aW9uYWwgcG9saWNlIGVtZXJnZW5jeSBzZXJ2aWNlIHRvIHJlcG9ydCBlLmcuIGEg bXVyZGVyLg0KDQoNCkkgc3VibWl0dGVkIHRvIElBTkEgYSByZXF1ZXN0IHRvIHJlZ2lzdGVyOg0K LSB1cm46c2VydmljZTpzb3MucG9saWNlLmxvY2FsIC0gVGhlICdwb2xpY2UubG9jYWwnIHNlcnZp Y2UgcmVmZXJzIHRvIHRoZSBlbWVyZ2VuY3kgc2VydmljZSBvZmZlcmVkIGJ5IHRoZSBwb2xpY2Ug ZGVwYXJ0bWVudCBvciBvdGhlciBsYXcgZW5mb3JjZW1lbnQgYXV0aG9yaXRpZXMgb2YgdGhlIGxv Y2FsIG9yIG11bmljaXBhbCBhdXRob3JpdGllcy4NCi0gdXJuOnNlcnZpY2U6c29zLnBvbGljZS5u YXRpb25hbCAtIFRoZSAncG9saWNlLm5hdGlvbmFsJyBzZXJ2aWNlIHJlZmVycyB0byB0aGUgZW1l cmdlbmN5IHNlcnZpY2Ugb2ZmZXJlZCBieSB0aGUgcG9saWNlIGRlcGFydG1lbnQgb3Igb3RoZXIg bGF3IGVuZm9yY2VtZW50IGF1dGhvcml0aWVzIG9mIHRoZSBuYXRpb25hbCBnb3Zlcm5tZW50Lg0K DQpSRkM1MDMxIHBvbGljeSBpcyBob3BlZnVsbHkgZnVsZmlsbGVkIGZvciB0aGVtIHNpbmNlIHRo ZXkgZXhpc3QgaW4gdHdvIGNvdW50cmllcy4NCg0KSSBhbSBmbGV4aWJsZSB3aGV0aGVyIHRoZSBh Y3R1YWwgVVJOcyBjb250YWluIHRoZSBzdWItc2VydmljZXMgcHJvcG9zZWQgYWJvdmUgKGkuZS4g LmxvY2FsIGFuZCAubmF0aW9uYWwgc3ViLXNlcnZpY2VzKSBvciBzdWJzZXJ2aWNlcyBiYXNlZCBv biBSRkM0MTE5IChpLmUuIC5BMyBhbmQgLmNvdW50cnkgc3ViLXNlcnZpY2VzKS4NCg0KSWYgdGhl IHByZWZlcmVuY2UgaXMgZm9yIHN1YnNlcnZpY2VzIGJhc2VkIG9uIFJGQzQxMTksIGRvIEkgbmVl ZCB0byBtYWtlIGFub3RoZXIgSUFOQSByZWdpc3RyYXRpb24gcmVxdWVzdCBvciBjYW4gd2UgbW9k aWZ5IHRoZSBVUk5zIGFuZCB0aGVpciBkZXNjcmlwdGlvbiBkdXJpbmcgdGhlIGV4cGVydCByZXZp ZXc/DQoNCktpbmQgcmVnYXJkcw0KDQpJdm8gU2VkbGFjZWsNCg0KVGhpcyBDb21tdW5pY2F0aW9u IGlzIENvbmZpZGVudGlhbC4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBi YXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdCB3d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2Ns YWltZXI8aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lcj4NCkZyb206IERh biBNb25ncmFpbiBbbWFpbHRvOmRhbkBtb25ncmFpbi5vcmddDQpTZW50OiAxOS4gw7pub3JhIDIw MTMgMTU6MzYNClRvOiBXaW50ZXJib3R0b20sIEphbWVzDQpDYzogUmljaGFyZCBCYXJuZXM7IEl2 byBTZWRsYWNlazsgZWNyaXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRWNyaXRdIFdoYXQgaXMg dGhlIG1vc3QgYXBwcm9wcmlhdGUgbWV0aG9kIGZvciByZWdpc3RlcmluZyBuZXcgc3ViLXNlcnZp Y2VzIG9mIHVybjpzZXJ2aWNlOnNvcw0KDQpUaGUgcHJvYmxlbSBpcyB0aGF0IGRpZmZlcmVudCBj b3VudHJpZXMgaGFzIGRpZmZlcmVudCBuYW1lcyBmb3IgdGhlaXIgcG9saXRpY2FsIHN1YmRpdmlz aW9ucy4gIEluIHRoZSBVUyB0aGV5IGFyZSBzdGF0ZXMsIGluIENhbmFkYSB0aGV5IGFyZSBwcm92 aW5jZXMsIGV0Yy4gIFNhbWUgd2hlbiB5b3UgZnVydGhlciBzdWJkaXZpZGUuICBXaGlsZSBub3Qg cHJpdnkgdG8gdGhlIGRpc2N1c3Npb25zIHRoYXQgY2FtZSB1cCB3aXRoIEExLCBBMiwg4oCmLCBB NSwgSSBoYXZlIHRoZSBmZWVsaW5nIHRoaXMgbm9tZW5jbGF0dXJlIHdhcyBwaWNrZWQgZm9yIHRo ZSBzYW1lIHJlYXNvbi4gIFdoeSBub3QgdXRpbGlzZSB0aGUgc2FtZSBuYW1pbmcgc2NoZW1lIGZv ciBzcGVjaWZ5aW5nIHRoZSBqdXJpc2RpY3Rpb24geW91IHdhbnQgdG8gcmVhY2g/DQoNClRoYW54 LA0KRGFuDQoNCk9uIE1vbiwgRmViIDE4LCAyMDEzIGF0IDU6MDEgUE0sIFdpbnRlcmJvdHRvbSwg SmFtZXMgPEphbWVzLldpbnRlcmJvdHRvbUBjb21tc2NvcGUuY29tPG1haWx0bzpKYW1lcy5XaW50 ZXJib3R0b21AY29tbXNjb3BlLmNvbT4+IHdyb3RlOg0KSW4gdGhhdCBjYXNlLCBvbmUgbWlnaHQg c2F5IHN0YXRlIGluIHRoZSBoaWVyYXJjaHksIG5vdCBBMS4NCg0KQ2hlZXJzDQpKYW1lcw0KDQoN CkZyb206IFJpY2hhcmQgQmFybmVzIFttYWlsdG86cmxiQGlwdi5zeDxtYWlsdG86cmxiQGlwdi5z eD5dDQpTZW50OiBUdWVzZGF5LCAxOSBGZWJydWFyeSAyMDEzIDg6NTcgQU0NClRvOiBXaW50ZXJi b3R0b20sIEphbWVzDQpDYzogRGFuIE1vbmdyYWluOyBJdm8gU2VkbGFjZWs7IGVjcml0QGlldGYu b3JnPG1haWx0bzplY3JpdEBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtFY3JpdF0gV2hhdCBp cyB0aGUgbW9zdCBhcHByb3ByaWF0ZSBtZXRob2QgZm9yIHJlZ2lzdGVyaW5nIG5ldyBzdWItc2Vy dmljZXMgb2YgdXJuOnNlcnZpY2U6c29zDQoNCkl0IG1pZ2h0IG1ha2Ugc2Vuc2UgaWYgeW91IHdh bnRlZCB0byBhbGxvdyB0aGUgY2FsbGVyIHRvIGV4cGxpY2l0bHkgc2VsZWN0IHBvbGljZSBhdCBh IGRpZmZlcmVudCBsZXZlbCBvZiByZXNwb25zaWJpbGl0eSwgZS5nLiwgdGhlIHN0YXRlIHBvbGlj ZSByYXRoZXIgdGhhbiB0aGUgbG9jYWwgcG9saWNlLg0KDQpPbiBNb24sIEZlYiAxOCwgMjAxMyBh dCA0OjIxIFBNLCBXaW50ZXJib3R0b20sIEphbWVzIDxKYW1lcy5XaW50ZXJib3R0b21AY29tbXNj b3BlLmNvbTxtYWlsdG86SmFtZXMuV2ludGVyYm90dG9tQGNvbW1zY29wZS5jb20+PiB3cm90ZToN CkkgdGhpbmsgSSBhbSBtaXNzaW5nIHNvbWV0aGluZyBoZXJlLCBBMSBpcyBwYXJ0IG9mIHRoZSBs b2NhdGlvbiwgc28gd2h5IGRvZXMgaXQgbmVlZCB0byBiZSBpbiB0aGUgVVJOIGF0IGFsbD8NCkFz IGZhciBhcyBJIHVuZGVyc3RhbmQgY3VycmVudCBkZXBsb3ltZW50cywgdGhleSB1c2UgdGhlIFVS TiB0byBzZWxlY3QgYSBsYXllciBpbiB0aGUgR0lTIHRoYXQgY29ycmVzcG9uZHMgdG8gdGhlIHNl cnZpY2UgdHlwZSwgYW5kIHRoZW4gdXNlIGdlb2dyYXBoaWMgYm91bmRhcmllcyB3aXRoaW4gdGhh dCBsYXllciB0byBzZWxlY3QgdGhlIGZpbmFsIGRlc3RpbmF0aW9uLg0KDQpGcm9tOiBlY3JpdC1i b3VuY2VzQGlldGYub3JnPG1haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmVj cml0LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBC ZWhhbGYgT2YgRGFuIE1vbmdyYWluDQpTZW50OiBUdWVzZGF5LCAxOSBGZWJydWFyeSAyMDEzIDc6 MzAgQU0NCg0KVG86IEl2byBTZWRsYWNlaw0KQ2M6IGVjcml0QGlldGYub3JnPG1haWx0bzplY3Jp dEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRWNyaXRdIFdoYXQgaXMgdGhlIG1vc3QgYXBwcm9w cmlhdGUgbWV0aG9kIGZvciByZWdpc3RlcmluZyBuZXcgc3ViLXNlcnZpY2VzIG9mIHVybjpzZXJ2 aWNlOnNvcw0KDQpTb3JyeSBmb3IgcmVzcG9uZGluZyBsYXRlIHRvIHRoaXMgdGhyZWFkLCBpdCBr aW5kYSBmZWxsIGludG8gYSAgY3JhY2vigKYgIFRoZSBjdXJyZW50IHRocmVhZCByZW1pbmRlZCBt ZSB0byBjaGVjayB0aGlzIG9sZCB0aHJlYWTigKYNCg0KWW91IGFyZSBpbmRpY2F0aW5nIHRoYXQg d2UgbmVlZCB0byByZWdpc3RlciA3NyBTZXJ2aWNlIFVSTiAoMTEgc2VydmljZSBzdWJ0eXBlcyAq IDcganVyaXNkaWN0aW9uIHR5cGVzIGJhc2VkIG9uIFJGQyA0MTE5KS4gIEkgZG8gbm90IHJlY29t bWVuZCB0aGF0IHdlIGNyZWF0ZSBzbyBtYW55IHJlZ2lzdHJhdGlvbnMuICBJbnN0ZWFkLCB3ZSBz aG91bGQgYWxsb3cgYSBzZXJ2aWNlIFVSTiB0byBiZSBzdWZmaXhlZCB3aXRoIGEganVyaXNkaWN0 aW9uYWwgc2NvcGUuICBTbyB0aGUgZm9sbG93aW5nIFNlcnZpY2UgVVJOIGFyZSBhbGwgdmFsaWQ6 DQoNCnVybjpzZXJ2aWNlOnNvcy5wb2xpY2UNCnVybjpzZXJ2aWNlOnNvcy5wb2xpY2UudHJhZmZp Yw0KdXJuOnNlcnZpY2U6c29zLnBvbGljZS5BMQ0KdXJuOnNlcnZpY2U6c29zLnBvbGljZS50cmFm ZmljLkExDQoNClF1ZXN0aW9uIGlzLCBkbyB3ZSB3YW50IHRvIGxlYXZlIGp1cmlzZGljdGlvbmFs IHNjb3BlIHRvIG9ubHkgYmUgYXBwbGljYWJsZSB0byBwb2xpY2UgYnJhbmNoIG9yIGFueSBTZXJ2 aWNlIFVSTj8gIEnigJlkIHNheSB0aGUgbGF0dGVyIGFzIGl0IGlzIGFsd2F5cyB1cCB0byB0aGUg TG9TVCBzZXJ2aWNlIHByb3Zpc2lvbmluZyAoYmFzZWQgb24gbG9jYWwgcG9saWN5KSB0byBkZXRl cm1pbmUgd2hhdCBpcyBsb2NhbGx5IGFjY2VwdGFibGUuDQoNClRoYW54LA0KRGFuDQoNCg== --_000_39B5E4D390E9BD4890E2B3107900610109A5A8ESESSMB301ericsso_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu TXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFt ZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6I0MwNTA0RDsNCglm b250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3 Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPkkgYWdyZWUgd2l0aCBS aWNoYXJkIC0gdGhlcmUgYXJlIGNvdW50cmllcyB3aGVyZSBib3RoIHRoZSBlbWVyZ2VuY3kgc2Vy dmljZSBvZiB0aGUgbmF0aW9uYWwgcG9saWNlIGFuZCB0aGUgZW1lcmdlbmN5IHNlcnZpY2Ugb2Yg dGhlIG11bmljaXBhbCBwb2xpY2UgYXJlIG9mZmVyZWQNCiBpbiBhIGdpdmVuIGxvY2F0aW9uLiA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPkEgdXNlciB3b3VsZCBjYWxsIHRoZSBtdW5pY2lw YWwgcG9saWNlIGVtZXJnZW5jeSBzZXJ2aWNlIHRvIHJlcG9ydCBlLmcuIHBpY2twb2NrZXRzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+QSB1c2VyIHdvdWxkIGNhbGwgdGhlIG5hdGlvbmFs IHBvbGljZSBlbWVyZ2VuY3kgc2VydmljZSB0byByZXBvcnQgZS5nLiBhIG11cmRlci48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiNDMDUwNEQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj5JIHN1Ym1pdHRlZCB0byBJQU5BIGEg cmVxdWVzdCB0byByZWdpc3Rlcjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPi0gdXJuOnNl cnZpY2U6c29zLnBvbGljZS5sb2NhbCAtIFRoZSAncG9saWNlLmxvY2FsJyBzZXJ2aWNlIHJlZmVy cyB0byB0aGUgZW1lcmdlbmN5IHNlcnZpY2Ugb2ZmZXJlZCBieSB0aGUgcG9saWNlIGRlcGFydG1l bnQgb3Igb3RoZXIgbGF3IGVuZm9yY2VtZW50IGF1dGhvcml0aWVzDQogb2YgdGhlIGxvY2FsIG9y IG11bmljaXBhbCBhdXRob3JpdGllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPi0gdXJu OnNlcnZpY2U6c29zLnBvbGljZS5uYXRpb25hbCAtIFRoZSAncG9saWNlLm5hdGlvbmFsJyBzZXJ2 aWNlIHJlZmVycyB0byB0aGUgZW1lcmdlbmN5IHNlcnZpY2Ugb2ZmZXJlZCBieSB0aGUgcG9saWNl IGRlcGFydG1lbnQgb3Igb3RoZXIgbGF3IGVuZm9yY2VtZW50IGF1dGhvcml0aWVzDQogb2YgdGhl IG5hdGlvbmFsIGdvdmVybm1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPlJGQzUwMzEgcG9saWN5IGlzIGhvcGVmdWxseSBm dWxmaWxsZWQgZm9yIHRoZW0gc2luY2UgdGhleSBleGlzdCBpbiB0d28gY291bnRyaWVzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDRE Ij5JIGFtIGZsZXhpYmxlIHdoZXRoZXIgdGhlIGFjdHVhbCBVUk5zIGNvbnRhaW4gdGhlIHN1Yi1z ZXJ2aWNlcyBwcm9wb3NlZCBhYm92ZSAoaS5lLiAubG9jYWwgYW5kIC5uYXRpb25hbCBzdWItc2Vy dmljZXMpIG9yIHN1YnNlcnZpY2VzIGJhc2VkIG9uIFJGQzQxMTkgKGkuZS4gLkEzDQogYW5kIC5j b3VudHJ5IHN1Yi1zZXJ2aWNlcykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPklmIHRoZSBwcmVmZXJlbmNlIGlzIGZvciBzdWJz ZXJ2aWNlcyBiYXNlZCBvbiBSRkM0MTE5LCBkbyBJIG5lZWQgdG8gbWFrZSBhbm90aGVyIElBTkEg cmVnaXN0cmF0aW9uIHJlcXVlc3Qgb3IgY2FuIHdlIG1vZGlmeSB0aGUgVVJOcyBhbmQgdGhlaXIg ZGVzY3JpcHRpb24gZHVyaW5nDQogdGhlIGV4cGVydCByZXZpZXc/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojQzA1MDREIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPktpbmQgcmVnYXJk czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj QzA1MDREIj5Jdm8gU2VkbGFjZWs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMzMzMzMzIj5UaGlzIENvbW11bmljYXRpb24gaXMgQ29uZmlkZW50 aWFsLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0 ZXJtcyBzZXQgb3V0IGF0DQo8YSBocmVmPSJodHRwOi8vd3d3LmVyaWNzc29uLmNvbS9lbWFpbF9k aXNjbGFpbWVyIiB0aXRsZT0iaHR0cDovL3d3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1l ciI+DQp3d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXI8L2E+IDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBEYW4gTW9u Z3JhaW4gW21haWx0bzpkYW5AbW9uZ3JhaW4ub3JnXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDE5LiDD um5vcmEgMjAxMyAxNTozNjxicj4NCjxiPlRvOjwvYj4gV2ludGVyYm90dG9tLCBKYW1lczxicj4N CjxiPkNjOjwvYj4gUmljaGFyZCBCYXJuZXM7IEl2byBTZWRsYWNlazsgZWNyaXRAaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtFY3JpdF0gV2hhdCBpcyB0aGUgbW9zdCBhcHByb3By aWF0ZSBtZXRob2QgZm9yIHJlZ2lzdGVyaW5nIG5ldyBzdWItc2VydmljZXMgb2YgdXJuOnNlcnZp Y2U6c29zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgcHJvYmxlbSBpcyB0aGF0IGRpZmZlcmVudCBj b3VudHJpZXMgaGFzIGRpZmZlcmVudCBuYW1lcyBmb3IgdGhlaXIgcG9saXRpY2FsIHN1YmRpdmlz aW9ucy4mbmJzcDsgSW4NCiB0aGUgVVMgdGhleSBhcmUgc3RhdGVzLCBpbiBDYW5hZGEgdGhleSBh cmUgcHJvdmluY2VzLCBldGMuJm5ic3A7IFNhbWUgd2hlbiB5b3UgZnVydGhlciBzdWJkaXZpZGUu Jm5ic3A7IFdoaWxlIG5vdCBwcml2eSB0byB0aGUgZGlzY3Vzc2lvbnMgdGhhdCBjYW1lIHVwIHdp dGggQTEsIEEyLCDigKYsIEE1LCBJIGhhdmUgdGhlIGZlZWxpbmcgdGhpcyBub21lbmNsYXR1cmUg d2FzIHBpY2tlZCBmb3IgdGhlIHNhbWUgcmVhc29uLiZuYnNwOyBXaHkgbm90IHV0aWxpc2UgdGhl IHNhbWUNCiBuYW1pbmcgc2NoZW1lIGZvciBzcGVjaWZ5aW5nIHRoZSBqdXJpc2RpY3Rpb24geW91 IHdhbnQgdG8gcmVhY2g/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbngsPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+RGFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEZlYiAxOCwgMjAxMyBhdCA1OjAxIFBN LCBXaW50ZXJib3R0b20sIEphbWVzICZsdDs8YSBocmVmPSJtYWlsdG86SmFtZXMuV2ludGVyYm90 dG9tQGNvbW1zY29wZS5jb20iIHRhcmdldD0iX2JsYW5rIj5KYW1lcy5XaW50ZXJib3R0b21AY29t bXNjb3BlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5JbiB0aGF0IGNhc2UsIG9uZSBtaWdodCBzYXkgc3RhdGUgaW4gdGhlIGhpZXJhcmNo eSwgbm90IEExLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNoZWVyczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkphbWVzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gUmljaGFyZCBCYXJuZXMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86cmxiQGlw di5zeCIgdGFyZ2V0PSJfYmxhbmsiPnJsYkBpcHYuc3g8L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+ IFR1ZXNkYXksIDE5IEZlYnJ1YXJ5IDIwMTMgODo1NyBBTTxicj4NCjxiPlRvOjwvYj4gV2ludGVy Ym90dG9tLCBKYW1lczxicj4NCjxiPkNjOjwvYj4gRGFuIE1vbmdyYWluOyBJdm8gU2VkbGFjZWs7 IDxhIGhyZWY9Im1haWx0bzplY3JpdEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KZWNyaXRA aWV0Zi5vcmc8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtFY3JpdF0gV2hhdCBpcyB0 aGUgbW9zdCBhcHByb3ByaWF0ZSBtZXRob2QgZm9yIHJlZ2lzdGVyaW5nIG5ldyBzdWItc2Vydmlj ZXMgb2YgdXJuOnNlcnZpY2U6c29zPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBtaWdodCBtYWtlIHNlbnNl IGlmIHlvdSB3YW50ZWQgdG8gYWxsb3cgdGhlIGNhbGxlciB0byBleHBsaWNpdGx5IHNlbGVjdCBw b2xpY2UgYXQgYSBkaWZmZXJlbnQgbGV2ZWwgb2YgcmVzcG9uc2liaWxpdHksIGUuZy4sIHRoZSBz dGF0ZSBwb2xpY2UgcmF0aGVyIHRoYW4gdGhlIGxvY2FsIHBvbGljZS4gJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gTW9uLCBGZWIgMTgsIDIwMTMg YXQgNDoyMSBQTSwgV2ludGVyYm90dG9tLCBKYW1lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkphbWVz LldpbnRlcmJvdHRvbUBjb21tc2NvcGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+SmFtZXMuV2ludGVy Ym90dG9tQGNvbW1zY29wZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayBJIGFtIG1pc3Npbmcgc29tZXRoaW5nIGhlcmUsIEEx IGlzIHBhcnQgb2YgdGhlIGxvY2F0aW9uLCBzbyB3aHkgZG9lcyBpdCBuZWVkIHRvIGJlIGluIHRo ZQ0KIFVSTiBhdCBhbGw/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMgZmFyIGFz IEkgdW5kZXJzdGFuZCBjdXJyZW50IGRlcGxveW1lbnRzLCB0aGV5IHVzZSB0aGUgVVJOIHRvIHNl bGVjdCBhIGxheWVyIGluIHRoZSBHSVMgdGhhdCBjb3JyZXNwb25kcw0KIHRvIHRoZSBzZXJ2aWNl IHR5cGUsIGFuZCB0aGVuIHVzZSBnZW9ncmFwaGljIGJvdW5kYXJpZXMgd2l0aGluIHRoYXQgbGF5 ZXIgdG8gc2VsZWN0IHRoZSBmaW5hbCBkZXN0aW5hdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEg aHJlZj0ibWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5lY3Jp dC1ib3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzplY3JpdC1ib3Vu Y2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZWNyaXQtYm91bmNlc0BpZXRmLm9yZzwvYT5d DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkRhbiBNb25ncmFpbjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVz ZGF5LCAxOSBGZWJydWFyeSAyMDEzIDc6MzAgQU08L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGI+VG86PC9iPiBJdm8gU2Vk bGFjZWs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzplY3JpdEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmVjcml0QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W0Vjcml0XSBXaGF0IGlzIHRoZSBtb3N0IGFwcHJvcHJpYXRlIG1ldGhvZCBmb3IgcmVnaXN0ZXJp bmcgbmV3IHN1Yi1zZXJ2aWNlcyBvZiB1cm46c2VydmljZTpzb3M8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvcnJ5IGZvciByZXNwb25kaW5nIGxh dGUgdG8gdGhpcyB0aHJlYWQsIGl0IGtpbmRhIGZlbGwgaW50byBhJm5ic3A7IGNyYWNr4oCmJm5i c3A7IFRoZSBjdXJyZW50IHRocmVhZCByZW1pbmRlZA0KIG1lIHRvIGNoZWNrIHRoaXMgb2xkIHRo cmVhZOKApjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPllvdSBhcmUgaW5kaWNhdGluZyB0aGF0IHdlIG5lZWQgdG8g cmVnaXN0ZXIgNzcgU2VydmljZSBVUk4gKDExIHNlcnZpY2Ugc3VidHlwZXMgKiA3IGp1cmlzZGlj dGlvbg0KIHR5cGVzIGJhc2VkIG9uIFJGQyA0MTE5KS4mbmJzcDsgSSBkbyBub3QgcmVjb21tZW5k IHRoYXQgd2UgY3JlYXRlIHNvIG1hbnkgcmVnaXN0cmF0aW9ucy4mbmJzcDsgSW5zdGVhZCwgd2Ug c2hvdWxkIGFsbG93IGEgc2VydmljZSBVUk4gdG8gYmUgc3VmZml4ZWQgd2l0aCBhIGp1cmlzZGlj dGlvbmFsIHNjb3BlLiZuYnNwOyBTbyB0aGUgZm9sbG93aW5nIFNlcnZpY2UgVVJOIGFyZSBhbGwg dmFsaWQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+dXJuOnNlcnZpY2U6c29zLnBvbGljZTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPnVybjpzZXJ2aWNlOnNvcy5wb2xpY2UudHJhZmZpYzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnVybjpzZXJ2aWNlOnNvcy5wb2xpY2UuQTE8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj51cm46c2VydmljZTpzb3MucG9saWNlLnRyYWZmaWMu QTE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5RdWVzdGlvbiBpcywgZG8gd2Ugd2FudCB0byBsZWF2ZSBqdXJpc2Rp Y3Rpb25hbCBzY29wZSB0byBvbmx5IGJlIGFwcGxpY2FibGUgdG8gcG9saWNlIGJyYW5jaCBvciBh bnkNCiBTZXJ2aWNlIFVSTj8gJm5ic3A7SeKAmWQgc2F5IHRoZSBsYXR0ZXIgYXMgaXQgaXMgYWx3 YXlzIHVwIHRvIHRoZSBMb1NUIHNlcnZpY2UgcHJvdmlzaW9uaW5nIChiYXNlZCBvbiBsb2NhbCBw b2xpY3kpIHRvIGRldGVybWluZSB3aGF0IGlzIGxvY2FsbHkgYWNjZXB0YWJsZS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5UaGFueCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EYW48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_39B5E4D390E9BD4890E2B3107900610109A5A8ESESSMB301ericsso_-- From brian.rosen@neustar.biz Tue Feb 19 11:35:38 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E166E21E80AE for ; Tue, 19 Feb 2013 11:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.008 X-Spam-Level: X-Spam-Status: No, score=-6.008 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+WMiCUiAcVG for ; Tue, 19 Feb 2013 11:35:36 -0800 (PST) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1F721F8868 for ; Tue, 19 Feb 2013 11:35:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1361302723; x=1676653161; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=6fW0fnambjCTElLBszE1vBuqCGI26wDp1u2XncxXveg=; b=fxEXUjf1gKF6nAtbFM6EoFZ4hVhLLcPS5wWyu5J8dI0dRrSKuKf2s+Rl3wzGe1 CUIcFy7o04/V2X8nUMSD2XMQ== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.19968156; Tue, 19 Feb 2013 14:38:42 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Tue, 19 Feb 2013 14:35:27 -0500 From: "Rosen, Brian" To: Ivo Sedlacek Date: Tue, 19 Feb 2013 14:35:27 -0500 Thread-Topic: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) Thread-Index: Ac4O2EUi/ZB80VdjRt2g2eOZqlfufw== Message-ID: <40D97C8F-0564-467F-8D41-E41501CF1BBF@neustar.biz> References: <39B5E4D390E9BD4890E2B3107900610109A5A8@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B3107900610109A5A8@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 9c/2sPhvs31hrWvrbttV3g== Content-Type: multipart/alternative; boundary="_000_40D97C8F0564467F8D41E41501CF1BBFneustarbiz_" MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 19:35:38 -0000 --_000_40D97C8F0564467F8D41E41501CF1BBFneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The problem is the word "local". What is "local" to you can be ambiguous in other areas. This is the advantage of the proposal by Dan Mongrain - we can precisely sp= ecify the authority level. If there is no specific agency at the level r= equested, the server can return the next highest level service that exists = at the location in the query. Brian On Feb 19, 2013, at 2:31 PM, Ivo Sedlacek > wrote: I agree with Richard - there are countries where both the emergency service= of the national police and the emergency service of the municipal police a= re offered in a given location. A user would call the municipal police emergency service to report e.g. pic= kpockets. A user would call the national police emergency service to report e.g. a mu= rder. I submitted to IANA a request to register: - urn:service:sos.police.local - The 'police.local' service refers to the e= mergency service offered by the police department or other law enforcement = authorities of the local or municipal authorities. - urn:service:sos.police.national - The 'police.national' service refers to= the emergency service offered by the police department or other law enforc= ement authorities of the national government. RFC5031 policy is hopefully fulfilled for them since they exist in two coun= tries. I am flexible whether the actual URNs contain the sub-services proposed abo= ve (i.e. .local and .national sub-services) or subservices based on RFC4119= (i.e. .A3 and .country sub-services). If the preference is for subservices based on RFC4119, do I need to make an= other IANA registration request or can we modify the URNs and their descrip= tion during the expert review? 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 15:36 To: Winterbottom, James Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos The problem is that different countries has different names for their polit= ical subdivisions. In the US they are states, in Canada they are provinces= , etc. Same when you further subdivide. While not privy to the discussion= s that came up with A1, A2, =85, A5, I have the feeling this nomenclature w= as picked for the same reason. Why not utilise the same naming scheme for = specifying the jurisdiction you want to reach? Thanx, Dan On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James > wrote: In that case, one might say state in the hierarchy, not A1. Cheers James From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Tuesday, 19 February 2013 8:57 AM To: Winterbottom, James Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos It might make sense if you wanted to allow the caller to explicitly select = police at a different level of responsibility, e.g., the state police rathe= r than the local police. On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James > wrote: I think I am missing something here, A1 is part of the location, so why doe= s it need to be in the URN at all? As far as I understand current deployments, they use the URN to select a la= yer in the GIS that corresponds to the service type, and then use geographi= c boundaries within that layer to select the final destination. From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Dan Mongrain Sent: Tuesday, 19 February 2013 7:30 AM To: Ivo Sedlacek Cc: ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos Sorry for responding late to this thread, it kinda fell into a crack=85 T= he current thread reminded me to check this old thread=85 You are indicating that we need to register 77 Service URN (11 service subt= ypes * 7 jurisdiction types based on RFC 4119). I do not recommend that we= create so many registrations. Instead, we should allow a service URN to b= e suffixed with a jurisdictional scope. So the following Service URN are a= ll valid: urn:service:sos.police urn:service:sos.police.traffic urn:service:sos.police.A1 urn:service:sos.police.traffic.A1 Question is, do we want to leave jurisdictional scope to only be applicable= to police branch or any Service URN? I=92d say the latter as it is always= up to the LoST service provisioning (based on local policy) to determine w= hat is locally acceptable. Thanx, Dan _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_40D97C8F0564467F8D41E41501CF1BBFneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The problem is the word "local".

What is "local"= to you can be ambiguous in other areas.

This is t= he advantage of the proposal by Dan Mongrain - we can precisely specify the= authority level.    If there is no specific agency at the level = requested, the server can return the next highest level service that exists= at the location in the query.

Brian
On Feb 19, 2013, at 2:31 PM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:
I agree with Richard - there a= re countries where both the emergency service of the national police and th= e emergency service of the municipal police are offered in a given location= .
A user woul= d call the municipal police emergency service to report e.g. pickpockets.
A user would c= all the national police emergency service to report e.g. a murder.
 
 
I submitted to IANA a request to register:
- urn:service:sos.police.= local - The 'police.local' service refers to the emergency service offered = by the police department or other law enforcement authorities of the local = or municipal authorities.
- urn:service:sos.police.national - The 'police.national' serv= ice refers to the emergency service offered by the police department or oth= er law enforcement authorities of the national government.
 
RFC5031 policy is hopefully fulfilled for them= since they exist in two countries.
 
I am flexible whether the actual URNs contain the sub-services propos= ed above (i.e. .local and .national sub-services) or subservices based on R= FC4119 (i.e. .A3 and .country sub-services).
 
<= span style=3D"font-size: 10pt; font-family: Arial, sans-serif; color: rgb(1= 92, 80, 77); ">If the preference is for subservices based on RFC4119, do I = need to make another IANA registration request or can we modify the URNs an= d their description during the expert review?
 
= Kind regards
=  
I= vo Sedlacek
&= nbsp;
This Communication i= s Confidential. We only send and receive email on the basis of the terms se= t out at www.eric= sson.com/email_disclaimer
From= : Dan Mongrain [mailto= :dan@mongrain.org]&nbs= p;
Sent: 19. =FAnora 2013 15:36
To:=  Winterbottom, James
Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org
Subject: Re: [Ecrit] What is th= e most appropriate method for registering new sub-services of urn:service:s= os
 
The problem is that different countri= es has different names for their political subdivisions.  In the US th= ey are states, in Canada they are provinces, etc.  Same when you furth= er subdivide.  While not privy to the discussions that came up with A1= , A2, =85, A5, I have the feeling this nomenclature was picked for the same= reason.  Why not utilise the same naming scheme for specifying the ju= risdiction you want to reach?
 
Thanx,
Dan

=  

On Mon, Feb 18, 2013 at 5:= 01 PM, Winterbottom, James <James.Winterbottom@commscope.com> wrote:
<= div style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; font-family: 'Times= New Roman', serif; ">In that case, one might say state i= n the hierarchy, not A1.
 
Cheers
James
&n= bsp;
From:&nb= sp;Richard Barnes [mailto:rlb@ipv.sx]=  
Sent: Tuesday, 19 February 2013 8:57 A= M
To: Winterbot= tom, James
Cc: = Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org

Subject: Re: [Ecrit] What is the most appropriate method for= registering new sub-services of urn:service:sos
 
It might make sense if you wanted to allow the caller to explicitly s= elect police at a different level of responsibility, e.g., the state police= rather than the local police.  

 

James.Winterbottom@commscope.com> = wrote:
I thin= k I am missing something here, A1 is part of the location, so why does it n= eed to be in the URN at all?
= As far as I understand current deployments, they use the = URN to select a layer in the GIS that corresponds to the service type, and = then use geographic boundaries within that layer to select the final destin= ation.
&nbs= p;
______________________________________________= _
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

= --_000_40D97C8F0564467F8D41E41501CF1BBFneustarbiz_-- From ivo.sedlacek@ericsson.com Tue Feb 19 11:59:57 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC2B21F8A25 for ; Tue, 19 Feb 2013 11:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.158 X-Spam-Level: X-Spam-Status: No, score=-6.158 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izZr44q0pF5W for ; Tue, 19 Feb 2013 11:59:55 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C96E421F8878 for ; Tue, 19 Feb 2013 11:59:54 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-5f-5123d9b9d98c Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C1.FF.10459.9B9D3215; Tue, 19 Feb 2013 20:59:53 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.208]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 20:59:53 +0100 From: Ivo Sedlacek To: Richard Barnes Thread-Topic: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emergency-services-00 Thread-Index: AQHODf0/A3wa29S18kCqq1n2b0WMoZiBmjIA Date: Tue, 19 Feb 2013 19:59:52 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610109A62C@ESESSMB301.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B0D8DCA@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101086378@ESESSMB301.ericsson.se> <076C52A7-194F-4C9B-A607-7C5AA685E8FF@gmx.net> <7594FB04B1934943A5C02806D1A2204B0D933D@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101099B29@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B3107900610109A62CESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+Jvje7Om8qBBhO/6ls0LnrKarF05z1W i6l9tg7MHos37WfzWLLkJ5PH5I2zWAKYo7hsUlJzMstSi/TtErgylv1vZS1o9q/YcyiggfGZ SxcjJ4eEgInE7G03WCBsMYkL99azdTFycQgJHGKUOH7uOCuEs4RR4uCq38wgVWwCehITtxxh BbFFBOQlTl9/AFbELNDFKHHy6UcmkISwQKzEukUPGSGK4iSWTJoPZRtJ/N11HqiGg4NFQFXi Y6cSSJhXwFvi8L6/UMsaWSQ27odYxikQKPFy8Rcwm1FAVuLqn16wOcwC4hK3nsxngjhbQGLJ nvPMELaoxMvH/1ghbEWJ9qcNUPX5EnOXbmODWCYocXLmE5YJjKKzkIyahaRsFpIyiLiexI2p U9ggbG2JZQtfM0PYuhIz/h1iQRZfwMi+ipE9NzEzJ73ccBMjMM4Obvmtu4Px1DmRQ4zSHCxK 4rxhrhcChATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTBqmNqG3+CYeG7Frq2LpTn/O9blnZl7 heXUtjk7v249uszsRog64+EN627cb1s1M6btCttEdjObX4am4q6f23hvz1Hb0Z0+f5HD1FA3 nrTG7eET8jeY7T8j/Xu25a6lK5eEnL7n92jKpTeum57XfPeJMUh3sd3fYvYu49U7pT1Jcon/ 373welv7U4mlOCPRUIu5qDgRAAwHaNeBAgAA Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emergency-services-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 19:59:57 -0000 --_000_39B5E4D390E9BD4890E2B3107900610109A62CESESSMB301ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, > Yes, I was thinking that the policy would be that an emergency service ex= ists in one country. If the WG decides this is the best way forward, it would be OK for me. 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 From: Richard Barnes [mailto:rlb@ipv.sx] Sent: 18. =FAnora 2013 18:28 To: Ivo Sedlacek Cc: Christer Holmberg; Hannes Tschofenig; ecrit@ietf.org Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emerg= ency-services-00 Yes, I was thinking that the policy would be that an emergency service exis= ts in one country. The purpose of the registry would be just be to encoura= ge deduplication. So, for instance, to encourage the several different cou= ntries that have traffic police numbers* to all use something like "urn:ser= vice:sos.traffic". Or, to choose a better example, once Korea has register= ed "urn:service:sos.espionage", to encourage the second country that establ= ishes a spy reporting service to also use that URN. Alternatively, someone could just go through the list of emergency numbers = on Wikipedia and submit one big registration for the common ones (like traf= fic police). Those would be allowable under the current policy. --Richard * according to wikipedia: EG, SD, CN, IN**, PK, SA, AL, AM, AZ, NZ, CO, EC ** hopefully India could be persuaded to consolidate its three different tr= affic police numbers On Mon, Feb 18, 2013 at 9:00 AM, Ivo Sedlacek > wrote: Hello, thank you for your mail. > It seems to me that the more conservative approach would be to just updat= e the IANA registration policy to be slightly more liberal. By "slightly more liberal", do you propose that the IANA registration polic= y for registration of any sub-service of the service URN with the 'sos' ser= vice type would be relaxed similarly as proposed in the draft (i.e. it is s= ufficient if the emergency service exists in single country only)? That wou= ld be possible. Or do you have other proposal? Thank you for clarification. 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 --_000_39B5E4D390E9BD4890E2B3107900610109A62CESESSMB301ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

> Yes, I was thinking that the policy would be that an emergency servi= ce exists in one country.  =

 

If the WG decides this is t= he best way forward, it would be OK for me.

 

Kind regards

 

Ivo Sedlacek

 

This Communication is Confid= ential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: 18. =FAnora 2013 18:28
To: Ivo Sedlacek
Cc: Christer Holmberg; Hannes Tschofenig; ecrit@ietf.org
Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specifi= c-emergency-services-00

 

Yes, I was thinking that the policy would be that an= emergency service exists in one country.  The purpose of the registry= would be just be to encourage deduplication.  So, for instance, to en= courage the several different countries that have traffic police numbers* to all use something like "urn:service:s= os.traffic".  Or, to choose a better example, once Korea has regi= stered "urn:service:sos.espionage", to encourage the second count= ry that establishes a spy reporting service to also use that URN.

 

Alternatively, someone could just go through the lis= t of emergency numbers on Wikipedia and submit one big registration for the= common ones (like traffic police).  Those would be allowable under th= e current policy.

 

--Richard 

 

* according to wikipedia: EG, SD, CN, IN**, PK, SA, = AL, AM, AZ, NZ, CO, EC

** hopefully India could be persuaded to consolidate= its three different traffic police numbers

 

On Mon, Feb 18, 2013 at 9:00 AM, Ivo Sedlacek <ivo.sedlacek@e= ricsson.com> wrote:

Hello,

thank you for your mail.


> It seems to me that the more conservative approach would be to just up= date the IANA registration policy to be slightly more liberal.

By "slightly more liberal", do you propose= that the IANA registration policy for registration of any sub-service of t= he service URN with the 'sos' service type would be relaxed similarly as pr= oposed in the draft (i.e. it is sufficient if the emergency service exists in single country only)? That would be possib= le.

Or do you have other proposal?

Thank you for clarification.


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

 

--_000_39B5E4D390E9BD4890E2B3107900610109A62CESESSMB301ericsso_-- From dan@mongrain.org Tue Feb 19 12:12:26 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF92521F8890 for ; Tue, 19 Feb 2013 12:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+8RBUNcsvlO for ; Tue, 19 Feb 2013 12:12:25 -0800 (PST) Received: from mail-ia0-x235.google.com (mail-ia0-x235.google.com [IPv6:2607:f8b0:4001:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 615E521F881D for ; Tue, 19 Feb 2013 12:12:25 -0800 (PST) Received: by mail-ia0-f181.google.com with SMTP id e16so6145530iaa.26 for ; Tue, 19 Feb 2013 12:12:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=dZ8o0ZCFVngkJaZMvnW5IvkeU4mZZeD5w8HGZZRq79k=; b=Qo8TxSxHbrnrZ7Zy/xSUDdh37PiWC3+vVjSuVXwDR97yIE8Svdt1BfLQbq2SPpCWd+ IR6P5jovq6oKG984lNxsoij6cvT3XGyqD9nq5VhR04IkzFOoPZR5eK2RnV/McQji/Jiz iXrEuUpEcXMGm+fFoYyknLE83v5KPylSs9PUREbqR2OqwHxQ+kX/8sVmPolhemKq9H9f iP0yZuASj1y/NWJ+3UBPJ0BB+1tH7DjNItPLTVm9iTwogczb2Oc1yp8C5Jreh9ErG+Do c3oRMGEiDduy6BwtFuMabPpHbR7y/b5jEEiLcQfMCpM9GIos5SgxL9BulZqRlZeh0qUq 3HnA== MIME-Version: 1.0 X-Received: by 10.50.37.212 with SMTP id a20mr9214249igk.88.1361304739065; Tue, 19 Feb 2013 12:12:19 -0800 (PST) Received: by 10.50.171.41 with HTTP; Tue, 19 Feb 2013 12:12:18 -0800 (PST) X-Originating-IP: [209.87.237.3] In-Reply-To: <39B5E4D390E9BD4890E2B3107900610109A5A8@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B3107900610109A5A8@ESESSMB301.ericsson.se> Date: Tue, 19 Feb 2013 15:12:18 -0500 Message-ID: From: Dan Mongrain To: Ivo Sedlacek Content-Type: multipart/alternative; boundary=f46d04446b21672ed604d61975ee X-Gm-Message-State: ALoCoQlFHSHQ0Y00oTjlEM3o21nlfP8G/+H9DyaThbtfW5vxH0me/vVhiRbhJgsopo8x6z9YX8s+ Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 20:12:26 -0000 --f46d04446b21672ed604d61975ee Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thing is, when there is no city police, local would give you county police (sheriff department) but in a city with a city police department local would give you city police. In the latter case, so how do I get the county police (or state police, there can be up to 4 police services for a given location in the US). Note that these examples are US based, but we do have 3 levels of police services in Canada and I am sure other countries have the same issue. There is also the terminology. There is no "national" police in the US or Canada but there is a federal police. Keeping the RFC 4119 terminology removes any "local" interpretation issues. Dan On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek wr= ote: > I agree with Richard - there are countries where both the emergency > service of the national police and the emergency service of the municipal > police are offered in a given location. **** > > A user would call the municipal police emergency service to report e.g. > pickpockets.**** > > A user would call the national police emergency service to report e.g. a > murder.**** > > ** ** > > ** ** > > I submitted to IANA a request to register:**** > > - urn:service:sos.police.local - The 'police.local' service refers to the > emergency service offered by the police department or other law enforceme= nt > authorities of the local or municipal authorities.**** > > - urn:service:sos.police.national - The 'police.national' service refers > to the emergency service offered by the police department or other law > enforcement authorities of the national government.**** > > ** ** > > RFC5031 policy is hopefully fulfilled for them since they exist in two > countries.**** > > ** ** > > I am flexible whether the actual URNs contain the sub-services proposed > above (i.e. .local and .national sub-services) or subservices based on > RFC4119 (i.e. .A3 and .country sub-services).**** > > ** ** > > If the preference is for subservices based on RFC4119, do I need to make > another IANA registration request or can we modify the URNs and their > description during the expert review?**** > > ** ** > > Kind regards**** > > ** ** > > Ivo Sedlacek**** > > ** ** > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out at www.ericsson.com/email_disclaimer **** > > *From:* Dan Mongrain [mailto:dan@mongrain.org] > *Sent:* 19. =FAnora 2013 15:36 > *To:* Winterbottom, James > *Cc:* Richard Barnes; Ivo Sedlacek; ecrit@ietf.org > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > ** ** > > The problem is that different countries has different names for their > political subdivisions. In the US they are states, in Canada they are > provinces, etc. Same when you further subdivide. While not privy to the > discussions that came up with A1, A2, =85, A5, I have the feeling this > nomenclature was picked for the same reason. Why not utilise the same > naming scheme for specifying the jurisdiction you want to reach?**** > > **** > > Thanx,**** > > Dan**** > > ** ** > > On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James < > James.Winterbottom@commscope.com> wrote:**** > > In that case, one might say state in the hierarchy, not A1.**** > > **** > > Cheers**** > > James**** > > **** > > **** > > *From:* Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* Tuesday, 19 February 2013 8:57 AM > *To:* Winterbottom, James > *Cc:* Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org**** > > > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > **** > > It might make sense if you wanted to allow the caller to explicitly selec= t > police at a different level of responsibility, e.g., the state police > rather than the local police. **** > > **** > > On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James < > James.Winterbottom@commscope.com> wrote:**** > > I think I am missing something here, A1 is part of the location, so why > does it need to be in the URN at all?**** > > As far as I understand current deployments, they use the URN to select a > layer in the GIS that corresponds to the service type, and then use > geographic boundaries within that layer to select the final destination.*= * > ** > > **** > > *From:* ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behalf > Of *Dan Mongrain > *Sent:* Tuesday, 19 February 2013 7:30 AM**** > > > *To:* Ivo Sedlacek > *Cc:* ecrit@ietf.org > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > **** > > Sorry for responding late to this thread, it kinda fell into a crack=85 > The current thread reminded me to check this old thread=85**** > > **** > > You are indicating that we need to register 77 Service URN (11 service > subtypes * 7 jurisdiction types based on RFC 4119). I do not recommend > that we create so many registrations. Instead, we should allow a service > URN to be suffixed with a jurisdictional scope. So the following Service > URN are all valid:**** > > **** > > urn:service:sos.police**** > > urn:service:sos.police.traffic**** > > urn:service:sos.police.A1**** > > urn:service:sos.police.traffic.A1**** > > **** > > Question is, do we want to leave jurisdictional scope to only be > applicable to police branch or any Service URN? I=92d say the latter as = it > is always up to the LoST service provisioning (based on local policy) to > determine what is locally acceptable.**** > > **** > > Thanx,**** > > Dan**** > > ** ** > --f46d04446b21672ed604d61975ee Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Thing is, when there is no city police, l= ocal would give you county police (sheriff department) but in a city with a city police department loc= al would give you city police.=A0 In the latter case, so how do I get the county police (or state police, there can be up t= o 4 police services for a given location in the US).=A0 Note= that these examples are US based, but we do have 3 levels of police services in Canada and I am sure other countries have the same issue.

=A0

There is also the terminology.=A0 There is no "national" police i= n the US or Canada but there is a federal police.=A0 Keeping the RFC 4119 t= erminology removes any "local" interpretation issues.

Dan<= br>
On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlace= k <ivo.sedlacek@ericsson.com> wrote:

I agree with Richard - ther= e are countries where both the emergency service of the national police and= the emergency service of the municipal police are offered in a given location.

A user would call the munic= ipal police emergency service to report e.g. pickpockets.

A user would call the natio= nal police emergency service to report e.g. a murder.<= /p>

=A0

=A0

I submitted to IANA a reque= st to register:

- urn:service:sos.police.lo= cal - The 'police.local' service refers to the emergency service of= fered by the police department or other law enforcement authorities of the local or municipal authorities.

- urn:service:sos.police.na= tional - The 'police.national' service refers to the emergency serv= ice offered by the police department or other law enforcement authorities of the national government.

=A0

RFC5031 policy is hopefully= fulfilled for them since they exist in two countries.=

=A0

I am flexible whether the a= ctual URNs contain the sub-services proposed above (i.e. .local and .nation= al sub-services) or subservices based on RFC4119 (i.e. .A3 and .country sub-services).

=A0

If the preference is for su= bservices based on RFC4119, do I need to make another IANA registration req= uest or can we modify the URNs and their description during the expert review?

=A0

Kind regards<= /span>

=A0

Ivo Sedlacek<= /span>

=A0

This Communication is Confid= ential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: Dan Mong= rain [mailto:dan@mong= rain.org]
Sent: 19. =FAnora 2013 15:36
To: Winterbottom, James
Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org
Subject: Re: [Ecrit] What is the most appropriate method for registe= ring new sub-services of urn:service:sos

=A0

The problem is that diffe= rent countries has different names for their political subdivisions.=A0 In the US they are states, in Canada they are provinces, etc.=A0 Same when yo= u further subdivide.=A0 While not privy to the discussions that came up wit= h A1, A2, =85, A5, I have the feeling this nomenclature was picked for the = same reason.=A0 Why not utilise the same naming scheme for specifying the jurisdiction you want to reach?=

=A0<= /p>

Thanx,

Dan<= /p>

=A0

On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James= <= James.Winterbottom@commscope.com> wrote:

In that case, one might s= ay state in the hierarchy, not A1.

=A0<= /p>

Cheers

James

=A0<= /p>

=A0<= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Tuesday, 19 February 2013 8:57 AM
To: Winterbottom, James
Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org


Subject: Re: [Ecrit] What is the most appropriate method for registe= ring new sub-services of urn:service:sos

=A0

It might make sense if you wanted to allow the calle= r to explicitly select police at a different level of responsibility, e.g.,= the state police rather than the local police. =A0

=A0

On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James= <= James.Winterbottom@commscope.com> wrote:

I think I am missing some= thing here, A1 is part of the location, so why does it need to be in the URN at all?

As far as I understand cu= rrent deployments, they use the URN to select a layer in the GIS that corre= sponds to the service type, and then use geographic boundaries within that layer = to select the final destination.

=A0<= /p>

From: ecrit-bounces@i= etf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Dan Mongrain
Sent: Tuesday, 19 February 2013 7:30 AM


To: Ivo Sedlacek
Cc: ecrit@ietf.o= rg
Subject: Re: [Ecrit] What is the most appropriate method for registe= ring new sub-services of urn:service:sos

=A0

Sorry for responding late= to this thread, it kinda fell into a=A0 crack=85=A0 The current thread rem= inded me to check this old thread=85

=A0<= /p>

You are indicating that w= e need to register 77 Service URN (11 service subtypes * 7 jurisdiction types based on RFC 4119).=A0 I do not recommend that we create so many reg= istrations.=A0 Instead, we should allow a service URN to be suffixed with a= jurisdictional scope.=A0 So the following Service URN are all valid:

=A0<= /p>

urn:service:sos.police

urn:service:sos.police.tr= affic

urn:service:sos.police.A1=

urn:service:sos.police.tr= affic.A1

=A0<= /p>

Question is, do we want t= o leave jurisdictional scope to only be applicable to police branch or any Service URN? =A0I=92d say the latter as it is always up to the LoST servic= e provisioning (based on local policy) to determine what is locally accepta= ble.

=A0<= /p>

Thanx,

Dan<= /p>

=A0


--f46d04446b21672ed604d61975ee-- From ivo.sedlacek@ericsson.com Tue Feb 19 12:31:44 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E12921F8DF6 for ; Tue, 19 Feb 2013 12:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.17 X-Spam-Level: X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utfC4MP-YxUS for ; Tue, 19 Feb 2013 12:31:39 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id ED4DF21F8BE8 for ; Tue, 19 Feb 2013 12:31:37 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-9f-5123e128c43d Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F0.EC.19728.821E3215; Tue, 19 Feb 2013 21:31:36 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.208]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 21:31:36 +0100 From: Ivo Sedlacek To: Dan Mongrain Thread-Topic: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) Thread-Index: AQHODt1tdiHHy2UVREyyoMwBpRaXz5iBn86A Date: Tue, 19 Feb 2013 20:31:35 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610109A6A7@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B3107900610109A5A8@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B3107900610109A6A7ESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvja7GQ+VAg31t1hb357SwWDQuespq cf2atsXUPlsHFo9Xa++weyxZ8pPJY/LGWSweL7YpBLBEcdmkpOZklqUW6dslcGW8nNLNWvBs DlPF+WkXmRoYu/8zdjFyckgImEg8mtLLDGGLSVy4t56ti5GLQ0jgEKPEqq0P2CGcJYwSu7/s ZwKpYhPQk5i45QgriC0ioCzRNfUeWDezQJ3EhI3TGUEahAWmMUr8+TmLCcQREZjOKLH04C02 iA4jiXf3b4NNYhFQlZh6YTpYN6+At8SMB0dZINZNYpSYvPkEUIKDg1MgUOLZvQyQGkYBWYmr f3oZIbaJS9x6Mp8J4m4BiSV7zkP9ICrx8vE/VpBWCQFFieX9chDl+RLf50xnhVglKHFy5hOW CYyis5BMmoWkbBaSMoi4nsSNqVPYIGxtiWULXzND2LoSM/4dYkEWX8DIvoqRPTcxMye93GgT IzD6Dm75rbqD8c45kUOM0hwsSuK84a4XAoQE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwpmp6 Setw+u+MN6ttrfFW0plzOfH1/O2rur0eu+7tlFq+PS7rmKLPLYsvTR2Pi4UvsEd93CVxizta 5U7BxVtnpzwUeSR0OfEEr06fU5HZktqmdma1xRct5l+r451s2//7kTzDckETyTSTlfdVdomv 8LlxPnll5+qHByY/9ZHRa+x/wfPnUPhMJZbijERDLeai4kQAAmvtYYwCAAA= Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 20:31:44 -0000 --_000_39B5E4D390E9BD4890E2B3107900610109A6A7ESESSMB301ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, If we go with RFC4119 based sub-services, would the IANA registration reque= st be as follows? - urn:service:sos.police.A3 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of a city, township, shi (JP). - urn:service:sos.police.country - The 'police.national' service refers to = the emergency service offered by the police department or other law enforce= ment authorities of the government of a country. Does anyone see any issue in that? If WG prefers this, it is OK for me. > In the latter case, so how do I get the county police (or state police, t= here can be up to 4 police services for a given location in the US). If I got it correctly, you propose that we also add - urn:service:sos.police.A2 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of county, parish, gun (JP), district (IN)" - urn:service:sos.police.A1 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of national subdivisions (state, region, provin= ce, prefecture)" While I have no problem with that, I am not aware of a regulation establish= ing such emergency service so I cannot argue to IANA that the RFC5031 polic= y is satisfied for those URNs. 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 21:12 To: Ivo Sedlacek Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) Thing is, when there is no city police, local would give you county police = (sheriff department) but in a city with a city police department local woul= d give you city police. In the latter case, so how do I get the county pol= ice (or state police, there can be up to 4 police services for a given loca= tion in the US). Note that these examples are US based, but we do have 3 l= evels of police services in Canada and I am sure other countries have the s= ame issue. There is also the terminology. There is no "national" police in the US or = Canada but there is a federal police. Keeping the RFC 4119 terminology rem= oves any "local" interpretation issues. Dan On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek > wrote: I agree with Richard - there are countries where both the emergency service= of the national police and the emergency service of the municipal police a= re offered in a given location. A user would call the municipal police emergency service to report e.g. pic= kpockets. A user would call the national police emergency service to report e.g. a mu= rder. I submitted to IANA a request to register: - urn:service:sos.police.local - The 'police.local' service refers to the e= mergency service offered by the police department or other law enforcement = authorities of the local or municipal authorities. - urn:service:sos.police.national - The 'police.national' service refers to= the emergency service offered by the police department or other law enforc= ement authorities of the national government. RFC5031 policy is hopefully fulfilled for them since they exist in two coun= tries. I am flexible whether the actual URNs contain the sub-services proposed abo= ve (i.e. .local and .national sub-services) or subservices based on RFC4119= (i.e. .A3 and .country sub-services). If the preference is for subservices based on RFC4119, do I need to make an= other IANA registration request or can we modify the URNs and their descrip= tion during the expert review? 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 15:36 To: Winterbottom, James Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos The problem is that different countries has different names for their polit= ical subdivisions. In the US they are states, in Canada they are provinces= , etc. Same when you further subdivide. While not privy to the discussion= s that came up with A1, A2, ..., A5, I have the feeling this nomenclature w= as picked for the same reason. Why not utilise the same naming scheme for = specifying the jurisdiction you want to reach? Thanx, Dan On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James > wrote: In that case, one might say state in the hierarchy, not A1. Cheers James From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Tuesday, 19 February 2013 8:57 AM To: Winterbottom, James Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos It might make sense if you wanted to allow the caller to explicitly select = police at a different level of responsibility, e.g., the state police rathe= r than the local police. On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James > wrote: I think I am missing something here, A1 is part of the location, so why doe= s it need to be in the URN at all? As far as I understand current deployments, they use the URN to select a la= yer in the GIS that corresponds to the service type, and then use geographi= c boundaries within that layer to select the final destination. From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Dan Mongrain Sent: Tuesday, 19 February 2013 7:30 AM To: Ivo Sedlacek Cc: ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos Sorry for responding late to this thread, it kinda fell into a crack... T= he current thread reminded me to check this old thread... You are indicating that we need to register 77 Service URN (11 service subt= ypes * 7 jurisdiction types based on RFC 4119). I do not recommend that we= create so many registrations. Instead, we should allow a service URN to b= e suffixed with a jurisdictional scope. So the following Service URN are a= ll valid: urn:service:sos.police urn:service:sos.police.traffic urn:service:sos.police.A1 urn:service:sos.police.traffic.A1 Question is, do we want to leave jurisdictional scope to only be applicable= to police branch or any Service URN? I'd say the latter as it is always u= p to the LoST service provisioning (based on local policy) to determine wha= t is locally acceptable. Thanx, Dan --_000_39B5E4D390E9BD4890E2B3107900610109A6A7ESESSMB301ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

If we go with RFC4119 based= sub-services, would the IANA registration request be as follows?

 

- urn:service:sos.police= .A3 - The 'police.loc= al' service refers to the emergency service offered by the police department or other law enforcement authorities of the authorities of a city, township, shi (JP)= .

- urn:service:sos.police= .country - The 'polic= e.national' service refers to the emergency service offered by the police department or other law enforcement authorities of the governme= nt of a country.

 

Does anyone see any issue i= n that?

 

If WG prefers this, it is O= K for me.

 

> In the latter case, so how do I get the county police (= or state police, there can be up to 4 police services for a given location = in the US). 

 

If I got it correctly, you = propose that we also add

- urn:service:sos.police= .A2 - The 'police.local' service refers to the emergency service offere= d by the police department or other law enforcement authorities of the authorities of= county, parish, gun (JP), district (IN)"

- urn:service:sos.police= .A1 - The 'police.local' service refers to the emergency service offere= d by the police department or other law enforcement authorities of the authorities of= national subdivisions (state, region, province, prefecture)"=

 

While I have no problem wit= h that, I am not aware of a regulation establishing such emergency service = so I cannot argue to IANA that the RFC5031 policy is satisfied for those URNs.

 

Kind regards

 

Ivo Sedlacek

 

 

 

 

This Communication is Confid= ential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: Dan Mong= rain [mailto:dan@mongrain.org]
Sent: 19. =FAnora 2013 21:12
To: Ivo Sedlacek
Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: Re: [Ecrit] What is the most appropriate method for registe= ring new sub-services of urn:service:sos (trimming due too large message re= port)

 

Thing is, when there is no city police, local would g= ive you county police (sheriff department) but in a city with a city police department local would give you city police.  In the la= tter case, so how do I get the county police (or state police, there can be= up to 4 police services for a given location in the US).  Note that t= hese examples are US based, but we do have 3 levels of police services in Canada and I am sure other countries have t= he same issue.

 

There is also the ter= minology.  There is no "national" police in the US or Canada= but there is a federal police.  Keeping the RFC 4119 terminology remo= ves any "local" interpretation issues.

Dan

On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek <ivo.sedlacek@e= ricsson.com> wrote:

I agree with Richard - there are countrie= s where both the emergency service of the national police and the emergency service of the municipal police are offered in a given l= ocation.

A user would call the municipal police em= ergency service to report e.g. pickpockets.

A user would call the national police eme= rgency service to report e.g. a murder.

 

 

I submitted to IANA a request to register= :

- urn:service:sos.police.local - The 'pol= ice.local' service refers to the emergency service offered by the police department or other law enforcement authorities of the local= or municipal authorities.

- urn:service:sos.police.national - The '= police.national' service refers to the emergency service offered by the police department or other law enforcement authorities of the natio= nal government.

 

RFC5031 policy is hopefully fulfilled for= them since they exist in two countries.

 

I am flexible whether the actual URNs con= tain the sub-services proposed above (i.e. .local and .national sub-services) or subservices based on RFC4119 (i.e. .A3 and .country sub-s= ervices).

 

If the preference is for subservices base= d on RFC4119, do I need to make another IANA registration request or can we modify the URNs and their description during the expert = review?

 

Kind regards

 

Ivo Sedlacek

 

This Communication is Confidential. We onl= y send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: Dan Mongrain [mailto:<= a href=3D"mailto:dan@mongrain.org" target=3D"_blank">dan@mongrain.org]
Sent: 19. =FAnora 2013 15:36
To: Winterbottom, James
Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org
Subject: Re: [Ecrit] What is the most appropriate method for registe= ring new sub-services of urn:service:sos

 

The problem is that different countries= has different names for their political subdivisions.  In the US they are states, in Canada they are provinces, etc.  Same when= you further subdivide.  While not privy to the discussions that came = up with A1, A2, …, A5, I have the feeling this nomenclature was picke= d for the same reason.  Why not utilise the same naming scheme for specifying the jurisdiction you want to reach?

 

Thanx,

Dan

 

On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James <James.Winter= bottom@commscope.com> wrote:

In that case, one might say state in th= e hierarchy, not A1.

 

Cheers

James

 

 

From: Richard Barnes [mailto= :rlb@ipv.sx]
Sent: Tuesday, 19 February 2013 8:57 AM
To: Winterbottom, James
Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org


Subject: Re: [Ecrit] What is the most appropriate method for registe= ring new sub-services of urn:service:sos

 

It might make sense if you wanted to allow the caller to explicitl= y select police at a different level of responsibility, e.g., the state pol= ice rather than the local police.  

 

On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James <James.Winter= bottom@commscope.com> wrote:

I think I am missing something here, A1= is part of the location, so why does it need to be in the URN at all?

As far as I understand current deployme= nts, they use the URN to select a layer in the GIS that corresponds to the service type, and then use geographic boundaries within that layer = to select the final destination.

 

From: ecrit-bounces@i= etf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Dan Mongrain
Sent: Tuesday, 19 February 2013 7:30 AM


To: Ivo Sedlacek
Cc: ecrit@ietf.o= rg
Subject: Re: [Ecrit] What is the most appropriate method for registe= ring new sub-services of urn:service:sos

 

Sorry for responding late to this threa= d, it kinda fell into a  crack…  The current thread reminde= d me to check this old thread…

 

You are indicating that we need to regi= ster 77 Service URN (11 service subtypes * 7 jurisdiction types based on RFC 4119).  I do not recommend that we create so many = registrations.  Instead, we should allow a service URN to be suffixed = with a jurisdictional scope.  So the following Service URN are all val= id:

 

urn:service:sos.police

urn:service:sos.police.traffic

urn:service:sos.police.A1

urn:service:sos.police.traffic.A1

 

Question is, do we want to leave jurisd= ictional scope to only be applicable to police branch or any Service URN?  I’d say the latter as it is always up to the LoST= service provisioning (based on local policy) to determine what is locally = acceptable.

 

Thanx,

Dan

 

 

--_000_39B5E4D390E9BD4890E2B3107900610109A6A7ESESSMB301ericsso_-- From prvs=47628ea07b=jbakker@rim.com Tue Feb 19 13:23:48 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3DE21F88B9 for ; Tue, 19 Feb 2013 13:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIEbL+lSeWP3 for ; Tue, 19 Feb 2013 13:23:46 -0800 (PST) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 91DE321F8815 for ; Tue, 19 Feb 2013 13:23:45 -0800 (PST) X-AuditID: 0a41282f-b7f606d000004b92-ec-5123ed54ad74 Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) by mhs060cnc.rim.net (SBG) with SMTP id 59.16.19346.45DE3215; Tue, 19 Feb 2013 15:23:32 -0600 (CST) Received: from XMB103ADS.rim.net ([fe80::e54b:97d9:3777:f8dc]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.02.0328.009; Tue, 19 Feb 2013 15:23:31 -0600 From: John-Luc Bakker To: Ivo Sedlacek , Richard Barnes Thread-Topic: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emergency-services-00 Thread-Index: AQHODtuz+Bk1QMyOgk2MRrpL35kZQ5iBpjcA Date: Tue, 19 Feb 2013 21:23:31 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA35CF5168@XMB103ADS.rim.net> References: <7594FB04B1934943A5C02806D1A2204B0D8DCA@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101086378@ESESSMB301.ericsson.se> <076C52A7-194F-4C9B-A607-7C5AA685E8FF@gmx.net> <7594FB04B1934943A5C02806D1A2204B0D933D@ESESSMB209.ericsson.se> <39B5E4D390E9BD4890E2B31079006101099B29@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610109A62C@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B3107900610109A62C@ESESSMB301.ericsson.se> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.254] Content-Type: multipart/alternative; boundary="_000_155970D1DA8E174F9E46039E10E2AA35CF5168XMB103ADSrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMKsWRmVeSWpSXmKPExsXC5ZyvpRvyVjnQYOFKYYvGRU9ZLXpXzmO1 mNpn68Ds8evrVTaPJUt+MnlM3jiLJYA5qoHRJimxpCw4Mz1P384mMS8vvySxJFUhJbU42VbJ JzU9MUchoCizLDG5UsElszg5JzEzN7VISSEzxVbJREmhICcxOTU3Na/EVimxoCA1L0XJjksB A9gAlWXmKaTmJeenZOal2yp5BvvrWliYWuoaKtnpJnTyZLTNXslc0DqVseLbzBWsDYwXmxm7 GDk5JARMJH7Mvs4OYYtJXLi3nq2LkYtDSGAlo8TFE2/ZIZytjBKn73WCdbAJqEtsXbGdGcQW EfCU+LxmNyuIzSygKnGu8TELiC0sECuxbtFDRoiaOIklk+ZD2UYSO1efYAKxWYDqOx4fAIvz CrhJvN3UzQqx7DCLxP1Fu8BO4hTwkTjY9xxsKKOArMTus9eZIJaJS9x6Mp8J4mwBiSV7zjND 2KISLx//Y4WwFSWWnTjJBlGfKzHv3j2oZYISJ2c+YZnAKDoLyahZSMpmISmDiOtJ3Jg6hQ3C 1pZYtvA1M4StKzHj3yEWZPEFjOyrGAVzM4oNzAyS85L1ijJz9fJSSzYxghKOo4b+Dsa37y0O MQpwMCrx8H57oBwoxJpYVlyZe4hRgoNZSYRXdxlQiDclsbIqtSg/vqg0J7X4EGMQMLgmMktx J+cDk2FeSbyxgQGRHCVxXpFA0UAhgXRgmstOTS1ILYIZysTBCbKUS0qkGJisUosSS0sy4kEp Nb4YmFSlGhita6ZkXjnOvHDvjWWvmdsY5+Y/OWRmceu74eU5E/0ffrX1DzYLsTwz12vyL/sO ef61u182BXNO+pEw4/a6Zfyd/tsPF9Re/ZNlvzU8yqi2f55a8LHFS9OM67Yem7xKwGVpRsnW aa46732sDc1fckyfZ+QQXimjsTP/n92Op9O+vqv3fPl3idxFJZbijERDLeai4kQAF8HztIYD AAA= Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emergency-services-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 21:23:49 -0000 --_000_155970D1DA8E174F9E46039E10E2AA35CF5168XMB103ADSrimnet_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Hi all, If we consider "urn:service:sos.espionage", and assume that in some jurisdic= tion the reporting of espionage is not seen as a specific "sos" sub service,= i.e. not requiring an immediate response, then note that RFC 5031 includes: For any given service URN, service-identifiers can be removed right-to-left; the resulting URN is still valid, referring to a more generic service. So, that would reduce "urn:service:sos.espionage" to "urn:service:sos". For= this URN, RFC 5031 includes: urn:service:sos The generic 'sos' service reaches a public safety answering point (PSAP), which in turn dispatches aid appropriate to the emergency. It encompasses all of the services listed below. Would this mean that in that jurisdiction PSAPs would get a higher load due= to the fact that the IANA registry includes "urn:service:sos.espionage", e= ven though in that jurisdiction this is not considered an emergency? For UAs that support and adhere to LOST, this may not be an issue as the UE= should not have mapped the service identifier to "urn:service:sos.espionage= ". It would nevertheless be useful if the network is able to reject such req= uests due to the regulatory requirements in place in the jurisdiction. Regards, John-Luc From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Iv= o Sedlacek Sent: Tuesday, February 19, 2013 2:00 PM To: Richard Barnes Cc: ecrit@ietf.org Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emerge= ncy-services-00 Hello, > Yes, I was thinking that the policy would be that an emergency service exi= sts in one country. If the WG decides this is the best way forward, it would be OK for me. Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the ba= sis of the terms set out at www.ericsson.com/email_disclaimer From: Richard Barnes [mailto:rlb@ipv.sx] Sent: 18. =FAnora 2013 18:28 To: Ivo Sedlacek Cc: Christer Holmberg; Hannes Tschofenig; ecrit@ietf.org Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific-emerge= ncy-services-00 Yes, I was thinking that the policy would be that an emergency service exist= s in one country. The purpose of the registry would be just be to encourage= deduplication. So, for instance, to encourage the several different countr= ies that have traffic police numbers* to all use something like "urn:service= :sos.traffic". Or, to choose a better example, once Korea has registered "u= rn:service:sos.espionage", to encourage the second country that establishes= a spy reporting service to also use that URN. Alternatively, someone could just go through the list of emergency numbers o= n Wikipedia and submit one big registration for the common ones (like traffi= c police). Those would be allowable under the current policy. --Richard * according to wikipedia: EG, SD, CN, IN**, PK, SA, AL, AM, AZ, NZ, CO, EC ** hopefully India could be persuaded to consolidate its three different tra= ffic police numbers On Mon, Feb 18, 2013 at 9:00 AM, Ivo Sedlacek > wrote: Hello, thank you for your mail. > It seems to me that the more conservative approach would be to just update= the IANA registration policy to be slightly more liberal. By "slightly more liberal", do you propose that the IANA registration policy= for registration of any sub-service of the service URN with the 'sos' servi= ce type would be relaxed similarly as proposed in the draft (i.e. it is suff= icient if the emergency service exists in single country only)? That would b= e possible. Or do you have other proposal? Thank you for clarification. Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the ba= sis of the terms set out at www.ericsson.com/email_disclaimer --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_155970D1DA8E174F9E46039E10E2AA35CF5168XMB103ADSrimnet_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable

Hi all,

 

If we consider “urn:service:sos.espionage”, and assume tha= t in some jurisdiction the reporting of espionage is not seen as a specific “sos” sub= service, i.e. not requiring an immediate response, then note that RFC 5031= includes:

  

  For any given service URN, service-identifiers can be remove=
d 
  right-to-left; the resulting URN is still valid, referr=
ing to 
  a more generic service.

 

So, that would reduce ̶= 0;urn:service:sos.espionage” to ̶= 0;urn:service:sos”. For this URN, RFC 5031 includes:

 

   urn:service:sos&n= bsp; The generic 'sos' service reaches a public safety

     = answering point (PSAP), which in turn dispatches aid appropriate=

     = to the emergency.  It encompasses all of the services listed

     = below.

 

Would this mean that in tha= t jurisdiction PSAPs would get a higher load due to the fact that the IANA r= egistry includes  “urn:service:sos.espionage”, even though in that jurisdiction this is not considered an emergency? =

 

For UAs that support and ad= here to LOST, this may not be an issue as the UE should not have mapped the= service identifier to “urn:service:sos.espionage”. It would nevertheless be useful if the network is able to reject such reque= sts due to the regulatory requirements in place in the jurisdiction.

 

Regards,<= /p>

 

    &nb= sp;          John-Luc

 

From: ecrit-bounc= es@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Ivo Sedlacek
Sent: Tuesday, February 19, 2013 2:00 PM
To: Richard Barnes
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific= -emergency-services-00

 

Hello,

 

> Yes, I was thinking that the policy would be that an emergency servic= e exists in one country.  

 

If the WG decides this is the= best way forward, it would be OK for me.

 

Kind regards

 

Ivo Sedlacek

 

This Communication is Confiden= tial. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: Richard Bar= nes [mailto:rlb@ipv.sx]
Sent: 18. =FAnora 2013 18:28
To: Ivo Sedlacek
Cc: Christer Holmberg; Hannes Tschofenig; ecrit@ietf.org
Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specific= -emergency-services-00

 

Yes, I was thinking that the policy would be that an= emergency service exists in one country.  The purpose of the registry= would be just be to encourage deduplication.  So, for instance, to enc= ourage the several different countries that have traffic police numbers* to all use something like "urn:service:so= s.traffic".  Or, to choose a better example, once Korea has regist= ered "urn:service:sos.espionage", to encourage the second country= that establishes a spy reporting service to also use that URN.

 

Alternatively, someone could just go through the list= of emergency numbers on Wikipedia and submit one big registration for the c= ommon ones (like traffic police).  Those would be allowable under the c= urrent policy.

 

--Richard 

 

* according to wikipedia: EG, SD, CN, IN**, PK, SA, A= L, AM, AZ, NZ, CO, EC

** hopefully India could be persuaded to consolidate= its three different traffic police numbers

 

On Mon, Feb 18, 2013 at 9:00 AM, Ivo Sedlacek <ivo.sedlacek@er= icsson.com> wrote:

Hello,

thank you for your mail.


> It seems to me that the more conservative approach would be to just upd= ate the IANA registration policy to be slightly more liberal.

By "slightly more liberal", do you propose= that the IANA registration policy for registration of any sub-service of th= e service URN with the 'sos' service type would be relaxed similarly as prop= osed in the draft (i.e. it is sufficient if the emergency service exists in single country only)? That would be possibl= e.

Or do you have other proposal?

Thank you for clarification.


Kind regards

 Ivo Sedlacek

This Communication is Confidential. We only send and receive email on the ba= sis of the terms set out at www.e= ricsson.com/email_disclaimer

 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_155970D1DA8E174F9E46039E10E2AA35CF5168XMB103ADSrimnet_-- From James.Winterbottom@commscope.com Tue Feb 19 15:29:43 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F12821F87B9 for ; Tue, 19 Feb 2013 15:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxBbcXILuZ6z for ; Tue, 19 Feb 2013 15:29:31 -0800 (PST) Received: from cdcsmgw01.commscope.com (cdcsmgw01.commscope.com [198.135.207.232]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBDA21F87B6 for ; Tue, 19 Feb 2013 15:29:30 -0800 (PST) X-AuditID: 0a0404e8-b7fa46d000004284-f6-51240ad5fc78 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Messaging Gateway) with SMTP id B5.FE.17028.5DA04215; Tue, 19 Feb 2013 17:29:25 -0600 (CST) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 19 Feb 2013 17:29:29 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 20 Feb 2013 07:29:26 +0800 From: "Winterbottom, James" To: Ivo Sedlacek , Dan Mongrain Date: Wed, 20 Feb 2013 07:29:15 +0800 Thread-Topic: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) Thread-Index: AQHODt1tdiHHy2UVREyyoMwBpRaXz5iBn86AgAA0BgA= Message-ID: <5A55A45AE77F5941B18E5457ECAC81880121407712CD@SISPE7MB1.commscope.com> References: <39B5E4D390E9BD4890E2B3107900610109A5A8@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610109A6A7@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B3107900610109A6A7@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC81880121407712CDSISPE7MB1co_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA01Sa0hTYRjmOzvbjstTx6ntSxBtGohjXsDArCQKaYRBK6gwSOd23Abuwo6a RuAyM7K8YN5aolbqLIppUSrNH03BmmklecFEw0vNLZoEIpOyztnR8t/zvs/7PM/38r0YR+jj hmFafR5p0ityxTwBKjgbopaOC6LlCeveiOS5plI0+eqDJW5yxaNmbnJd5eEjqGx9dZwna2vz IbI73RZU5noZeQrNEBxSkbnaAtIUn5ol0FRN/uAbm5qRQm+tm28G42akHARgkEiC13vecFi8 G36YtfHKgQATEq8ArLH3ArboAtA+0r3J2ACc2Jjwy3lEKhywTfnlIcRJ2Fo3gjKYQxyFfb/r /X2U2Ac3Oqs4jDiYqAfwl8+CMEUI0QBg++tp2hajixQ4OegX4MRp+ND5gsumfQJwcGmZzxAB RDqsfF4GGAzox645nyBsmghOL7ZsLkTANvv7zYVC4fLCBpedD4UzN2yAnTdA58J3HhsWBN/e XfS/WkhIYUnfKrcaiCzbbC3bJJZtErYfB6fqankslsCO+x4Oi6WwccOBbu+3Av5jIFKqlJRO fSkhMU5p0OkopcFIMugZYH4aRV29YLhL4gAEBsSBeExLlFzIVRRQRToH2IMh4lD8Jj9aLtyZ bVAVaRSUJtOUn0tSDgAxjjgEP86lOVylKLpMmgxbVAyGEcOLc04QhuoNelIM8Wj6loRBJlJN FuZoc+lD2xpFsADGKpC2SmNmcMqo0FFaNcs7gQRrnZh3Aeya9ZsLCP12YSJcyIwSzKgmX//P zQ1E9ArBOGTYQPqe//m46QiEjnhqjWIi8hT/qTAzyMZOiDrgmep7Y6Oj/UUZ7binfyJlDdgy DpSeL7a7bxs9PjjG9yat3NKFd1qjustLEM/nYxL5iqhrVl1etmt/RG+gd2hghk/sTTJfyano qWnM+xgujb341dp2ISX+S1Cf5eef9Mw0Z1akK161A4/AooYaDr5bP1csnu9HBlrEKKVRJMZy TJTiL31WO1yMAwAA Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 23:29:43 -0000 --_000_5A55A45AE77F5941B18E5457ECAC81880121407712CDSISPE7MB1co_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am okay with this, providing that the fallback order is clearly defined. That is, does an A3 fall back to an A2 or A1, or just back to sos? From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] Sent: Wednesday, 20 February 2013 7:32 AM To: Dan Mongrain Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org Subject: RE: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) Hello, If we go with RFC4119 based sub-services, would the IANA registration reque= st be as follows? - urn:service:sos.police.A3 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of a city, township, shi (JP). - urn:service:sos.police.country - The 'police.national' service refers to = the emergency service offered by the police department or other law enforce= ment authorities of the government of a country. Does anyone see any issue in that? If WG prefers this, it is OK for me. > In the latter case, so how do I get the county police (or state police, t= here can be up to 4 police services for a given location in the US). If I got it correctly, you propose that we also add - urn:service:sos.police.A2 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of county, parish, gun (JP), district (IN)" - urn:service:sos.police.A1 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of national subdivisions (state, region, provin= ce, prefecture)" While I have no problem with that, I am not aware of a regulation establish= ing such emergency service so I cannot argue to IANA that the RFC5031 polic= y is satisfied for those URNs. 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 21:12 To: Ivo Sedlacek Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) Thing is, when there is no city police, local would give you county police = (sheriff department) but in a city with a city police department local woul= d give you city police. In the latter case, so how do I get the county pol= ice (or state police, there can be up to 4 police services for a given loca= tion in the US). Note that these examples are US based, but we do have 3 l= evels of police services in Canada and I am sure other countries have the s= ame issue. There is also the terminology. There is no "national" police in the US or = Canada but there is a federal police. Keeping the RFC 4119 terminology rem= oves any "local" interpretation issues. Dan On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek > wrote: I agree with Richard - there are countries where both the emergency service= of the national police and the emergency service of the municipal police a= re offered in a given location. A user would call the municipal police emergency service to report e.g. pic= kpockets. A user would call the national police emergency service to report e.g. a mu= rder. I submitted to IANA a request to register: - urn:service:sos.police.local - The 'police.local' service refers to the e= mergency service offered by the police department or other law enforcement = authorities of the local or municipal authorities. - urn:service:sos.police.national - The 'police.national' service refers to= the emergency service offered by the police department or other law enforc= ement authorities of the national government. RFC5031 policy is hopefully fulfilled for them since they exist in two coun= tries. I am flexible whether the actual URNs contain the sub-services proposed abo= ve (i.e. .local and .national sub-services) or subservices based on RFC4119= (i.e. .A3 and .country sub-services). If the preference is for subservices based on RFC4119, do I need to make an= other IANA registration request or can we modify the URNs and their descrip= tion during the expert review? 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 15:36 To: Winterbottom, James Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos The problem is that different countries has different names for their polit= ical subdivisions. In the US they are states, in Canada they are provinces= , etc. Same when you further subdivide. While not privy to the discussion= s that came up with A1, A2, ..., A5, I have the feeling this nomenclature w= as picked for the same reason. Why not utilise the same naming scheme for = specifying the jurisdiction you want to reach? Thanx, Dan On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James > wrote: In that case, one might say state in the hierarchy, not A1. Cheers James From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Tuesday, 19 February 2013 8:57 AM To: Winterbottom, James Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos It might make sense if you wanted to allow the caller to explicitly select = police at a different level of responsibility, e.g., the state police rathe= r than the local police. On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James > wrote: I think I am missing something here, A1 is part of the location, so why doe= s it need to be in the URN at all? As far as I understand current deployments, they use the URN to select a la= yer in the GIS that corresponds to the service type, and then use geographi= c boundaries within that layer to select the final destination. From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Dan Mongrain Sent: Tuesday, 19 February 2013 7:30 AM To: Ivo Sedlacek Cc: ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos Sorry for responding late to this thread, it kinda fell into a crack... T= he current thread reminded me to check this old thread... You are indicating that we need to register 77 Service URN (11 service subt= ypes * 7 jurisdiction types based on RFC 4119). I do not recommend that we= create so many registrations. Instead, we should allow a service URN to b= e suffixed with a jurisdictional scope. So the following Service URN are a= ll valid: urn:service:sos.police urn:service:sos.police.traffic urn:service:sos.police.A1 urn:service:sos.police.traffic.A1 Question is, do we want to leave jurisdictional scope to only be applicable= to police branch or any Service URN? I'd say the latter as it is always u= p to the LoST service provisioning (based on local policy) to determine wha= t is locally acceptable. Thanx, Dan --_000_5A55A45AE77F5941B18E5457ECAC81880121407712CDSISPE7MB1co_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I am okay= with this, providing that the fallback order is clearly defined.

That is, does an A3 fall back to an= A2 or A1, or just back to sos?

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

 

 

From: Ivo Sedlacek [mailto:ivo.sedlacek@ericss= on.com]
Sent: Wednesday, 20 February 2013 7:32 AM
To: = Dan Mongrain
Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.= org
Subject: RE: [Ecrit] What is the most appropriate method for = registering new sub-services of urn:service:sos (trimming due too large mes= sage report)

&nb= sp;

Hello,

 

If = we go with RFC4119 based sub-services, would the IANA registration request = be as follows?

 =

- urn:service:sos.police.A3=  - The 'police.local' servi= ce refers to the emergency service offered by the police department or othe= r law enforcement authorities of the authorities of a city, township, shi (JP).

- urn:service:sos.police.country - The 'police.national' servic= e refers to the emergency service offered by the police department or other= law enforcement authorities of the government of a country.

 

Does a= nyone see any issue in that?

 

If WG prefers this, = it is OK for me.

 =

> In the latter case, so how = do I get the county police (or state police, there can be up to 4 police se= rvices for a given location in the US). 

 

If I got it correctly, you propose that we also add

- urn:service:sos.police.A2 - The= 'police.local' service refers to the emergency service offered by the poli= ce department or other law enforcement authorities of the authorities of county, parish, gun (JP), = district (IN)"

- ur= n:service:sos.police.A1 - The 'police.local' service refers to the e= mergency service offered by the police department or other law enforcement = authorities of the authorities of national subdivisions (state, region, province, prefecture)&q= uot;

 

While I have no problem with that, I am not = aware of a regulation establishing such emergency service so I cannot argue= to IANA that the RFC5031 policy is satisfied for those URNs.

 

Kind regards

 

Ivo Sedlacek=

 

 

 

 

This Communication is Confidential. We only send and recei= ve email on the basis of the terms set out at = www.ericsson.com/email_disclaimer

From: Dan Mongrain [mailto:dan@mong= rain.org]
Sent: 19. =FAnora 2013 21:12
To: Ivo Sed= lacek
Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: Re: [Ecrit] What is t= he most appropriate method for registering new sub-services of urn:service:= sos (trimming due too large message report)

 

Thing is, when there is no city police, l= ocal would give you county police (sheriff department) but in a city with a= city police department local would give you city police.  In the latt= er case, so how do I get the county police (or state police, there can be u= p to 4 police services for a given location in the US).  Note that the= se examples are US based, but we do have 3 levels of police services in Can= ada and I am sure other countries have the same issue.

 

There is also the terminology.  There is no "= national" police in the US or Canada but there is a federal police.&nb= sp; Keeping the RFC 4119 terminology removes any "local" interpre= tation issues.

Dan

 

= --_000_5A55A45AE77F5941B18E5457ECAC81880121407712CDSISPE7MB1co_-- From keith.drage@alcatel-lucent.com Tue Feb 19 16:18:19 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0701B21F8551 for ; Tue, 19 Feb 2013 16:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.835 X-Spam-Level: X-Spam-Status: No, score=-106.835 tagged_above=-999 required=5 tests=[AWL=-1.187, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msd4K7fz48Q0 for ; Tue, 19 Feb 2013 16:18:12 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5439821F8830 for ; Tue, 19 Feb 2013 16:18:12 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1K0I7E0016775 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Feb 2013 01:18:08 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 20 Feb 2013 01:18:07 +0100 From: "DRAGE, Keith (Keith)" To: "Winterbottom, James" , Ivo Sedlacek , Dan Mongrain Date: Wed, 20 Feb 2013 01:18:06 +0100 Thread-Topic: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) Thread-Index: AQHODt1tdiHHy2UVREyyoMwBpRaXz5iBn86AgAA0BgCAAAV0sA== Message-ID: References: <39B5E4D390E9BD4890E2B3107900610109A5A8@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610109A6A7@ESESSMB301.ericsson.se> <5A55A45AE77F5941B18E5457ECAC81880121407712CD@SISPE7MB1.commscope.com> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880121407712CD@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE21070160C11FRMRSSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 00:18:19 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE21070160C11FRMRSSXCHMBSC_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The answer to James's question depends on how you code it (and also what yo= u mean by fallback). On any service URN, you ignore any subtypes from the point you stop underst= anding it. So if the coding is sos.police.A2, and you do not understand A2, then the s= ervice URN would be handled as if it was sos.police, not as sos.police.A1. = And if police was not understood then it would be handled as sos. If you wanted something that went back to the next larger regional coverage= , then you would have to code successive subtypes in sequence. But I would also ask for an element of sanity in this discussion, rather th= an total flexibility. For example while a national administration may have multiple levels of pol= ice force, not all of them are either reachable directly as an emergency se= rvice provider, nor are they necessarily an emergency service provider. If = they are neither of these, then they presumably do not need a special and d= istinct service URN. It would therefore nice to see a current use case that is anything but a ch= oice of two, i.e. countrywide (following the ITU-T E.164 definition of coun= try) versus one more local variant. This restricted model certainly covers = Ivo's examples of Czeck Republic and Poland, and I believe it also covers t= he other example I know of which is Italy. While the USA has multiple levels of police force, on the PSTN, it only app= ears to have one level of access to citizen to authority emergency service,= which is 911. I see no reason why a change to voice over IP would cause a = change to this. I would also stress that it is important to have global expectations of wha= t you get when you use a service URN. If there is not care excercised with = assigning semantics and values, A3 in one country could result in the fores= try police and in another country the financial police responding. Note that read the scope of RFC 5031 as being for end user accessing the em= ergency service. While it might be possible to apply RFC 5031 to further ne= twork operations after the PSAP has been reached, e.g. to reach a subsidiar= y PSAP, I read that as outside the scope of RFC 5031. Nor do I necessarily = believe in that scenario that service URNs are necessarily the best solutio= n for routeing, as the first PSAP should know the particular office they wa= nt to reach rather than just the type of emergency service. Regards Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of W= interbottom, James Sent: 19 February 2013 23:29 To: Ivo Sedlacek; Dan Mongrain Cc: ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) I am okay with this, providing that the fallback order is clearly defined. That is, does an A3 fall back to an A2 or A1, or just back to sos? From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] Sent: Wednesday, 20 February 2013 7:32 AM To: Dan Mongrain Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org Subject: RE: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) Hello, If we go with RFC4119 based sub-services, would the IANA registration reque= st be as follows? - urn:service:sos.police.A3 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of a city, township, shi (JP). - urn:service:sos.police.country - The 'police.national' service refers to = the emergency service offered by the police department or other law enforce= ment authorities of the government of a country. Does anyone see any issue in that? If WG prefers this, it is OK for me. > In the latter case, so how do I get the county police (or state police, t= here can be up to 4 police services for a given location in the US). If I got it correctly, you propose that we also add - urn:service:sos.police.A2 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of county, parish, gun (JP), district (IN)" - urn:service:sos.police.A1 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of national subdivisions (state, region, provin= ce, prefecture)" While I have no problem with that, I am not aware of a regulation establish= ing such emergency service so I cannot argue to IANA that the RFC5031 polic= y is satisfied for those URNs. 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 21:12 To: Ivo Sedlacek Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) Thing is, when there is no city police, local would give you county police = (sheriff department) but in a city with a city police department local woul= d give you city police. In the latter case, so how do I get the county pol= ice (or state police, there can be up to 4 police services for a given loca= tion in the US). Note that these examples are US based, but we do have 3 l= evels of police services in Canada and I am sure other countries have the s= ame issue. There is also the terminology. There is no "national" police in the US or = Canada but there is a federal police. Keeping the RFC 4119 terminology rem= oves any "local" interpretation issues. Dan On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek > wrote: I agree with Richard - there are countries where both the emergency service= of the national police and the emergency service of the municipal police a= re offered in a given location. A user would call the municipal police emergency service to report e.g. pic= kpockets. A user would call the national police emergency service to report e.g. a mu= rder. I submitted to IANA a request to register: - urn:service:sos.police.local - The 'police.local' service refers to the e= mergency service offered by the police department or other law enforcement = authorities of the local or municipal authorities. - urn:service:sos.police.national - The 'police.national' service refers to= the emergency service offered by the police department or other law enforc= ement authorities of the national government. RFC5031 policy is hopefully fulfilled for them since they exist in two coun= tries. I am flexible whether the actual URNs contain the sub-services proposed abo= ve (i.e. .local and .national sub-services) or subservices based on RFC4119= (i.e. .A3 and .country sub-services). If the preference is for subservices based on RFC4119, do I need to make an= other IANA registration request or can we modify the URNs and their descrip= tion during the expert review? 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 15:36 To: Winterbottom, James Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos The problem is that different countries has different names for their polit= ical subdivisions. In the US they are states, in Canada they are provinces= , etc. Same when you further subdivide. While not privy to the discussion= s that came up with A1, A2, ..., A5, I have the feeling this nomenclature w= as picked for the same reason. Why not utilise the same naming scheme for = specifying the jurisdiction you want to reach? Thanx, Dan On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James > wrote: In that case, one might say state in the hierarchy, not A1. Cheers James From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Tuesday, 19 February 2013 8:57 AM To: Winterbottom, James Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos It might make sense if you wanted to allow the caller to explicitly select = police at a different level of responsibility, e.g., the state police rathe= r than the local police. On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James > wrote: I think I am missing something here, A1 is part of the location, so why doe= s it need to be in the URN at all? As far as I understand current deployments, they use the URN to select a la= yer in the GIS that corresponds to the service type, and then use geographi= c boundaries within that layer to select the final destination. From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Dan Mongrain Sent: Tuesday, 19 February 2013 7:30 AM To: Ivo Sedlacek Cc: ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos Sorry for responding late to this thread, it kinda fell into a crack... T= he current thread reminded me to check this old thread... You are indicating that we need to register 77 Service URN (11 service subt= ypes * 7 jurisdiction types based on RFC 4119). I do not recommend that we= create so many registrations. Instead, we should allow a service URN to b= e suffixed with a jurisdictional scope. So the following Service URN are a= ll valid: urn:service:sos.police urn:service:sos.police.traffic urn:service:sos.police.A1 urn:service:sos.police.traffic.A1 Question is, do we want to leave jurisdictional scope to only be applicable= to police branch or any Service URN? I'd say the latter as it is always u= p to the LoST service provisioning (based on local policy) to determine wha= t is locally acceptable. Thanx, Dan --_000_EDC0A1AE77C57744B664A310A0B23AE21070160C11FRMRSSXCHMBSC_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The answer to James’s question depends on how you code it (and also what you mean by fallback).=

 

On any service URN, you ignore any sub= types from the point you stop understanding it.

 

So if the coding is sos.police.A2, and= you do not understand A2, then the service URN would be handled as if it was sos.police, not as sos.police.A1. And if police was not understood then it would be handled as sos.

 

If you wanted something that went back= to the next larger regional coverage, then you would have to code successive subtypes in sequence.

 

But I would also ask for an element of sanity in this discussion, rather than total flexibility.=

 

For example while a national administr= ation may have multiple levels of police force, not all of them are either reacha= ble directly as an emergency service provider, nor are they necessarily an emergency service provider. If they are neither of these, then they presuma= bly do not need a special and distinct service URN.

 

It would therefore nice to see a curre= nt use case that is anything but a choice of two, i.e. countrywide (following the = ITU-T E.164 definition of country) versus one= more local variant. This restricted model certainly covers Ivo’s examples = of Czeck Republic and Poland, and I beli= eve it also covers the other example I know of which is Italy.

 

While the USA has multiple levels of po= lice force, on the PSTN, it only appears to have one level of access to citizen = to authority emergency service, which is 911. I see no reason why a change to voice over IP would cause a change to this.

 

I would also stress that it is importa= nt to have global expectations of what you get when you use a service URN. If there is not care excercised with assigning semantics and values, A3 in one country could result in the forestry police and in another country the financial police responding.

 

Note that read the scope of RFC 5031 a= s being for end user accessing the emergency service. While it might be possi= ble to apply RFC 5031 to further network operations after the PSAP has been reached, e.g. to reach a subsidiary PSAP, I read that as outside the scope = of RFC 5031. Nor do I necessarily believe in that scenario that service URNs a= re necessarily the best solution for routeing, as the first PSAP should know t= he particular office they want to reach rather than just the type of emergency service.

 

Regards

 

Keith

 

From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James
Sent: 19 February 2013 23:29=
To: Ivo Sedlacek; Dan Mongra= in
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

 

I am okay with= this, providing that the fallback order is clearly defined.

That is, does = an A3 fall back to an A2 or A1, or just back to sos?

 

 

 

From:= Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com]
Sent: Wednesday, 20 February= 2013 7:32 AM
To: Dan Mongrain
Cc: Winterbottom, James; Ric= hard Barnes; ecrit@ietf.org
Subject: RE: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

 

Hello,

 

If we go with RF= C4119 based sub-services, would the IANA registration request be as follows?

 

- urn:service:sos.police.A3 <= /span>- The 'police.local' service refers to the emergency service offered by the police department or other law enforcement authorities of the authorities of a city, township, shi (JP)= .

- urn:service:sos.police.country&n= bsp;- The 'police.national' service refers to the emergency service offered by th= e police department or other law enforcement authorities of the government of a country.

 

Does anyone see = any issue in that?

 

If WG prefers th= is, it is OK for me.

 

> In the latter case, so how do I get the county police (or state police, there = can be up to 4 police services for a given location in the US).&nb= sp;

 

If I got it corr= ectly, you propose that we also add

- urn:service:sos.police.A2 - The 'police.local' service refers to the emergency service offered by the police department or other law enforcement authorities of the authorities of county, parish, gun (JP), district (IN)"<= /p>

- urn:service:sos.police.A1 - The 'police.local' service refers to the emergency service offered by the police department or other law enforcement authorities of the authorities of national subdivisions (state, region, province, prefecture)"<= /o:p>

 

While I have no problem with that, I am not aware of a regulation establishing such emergen= cy service so I cannot argue to IANA that the RFC5031 policy is satisfied for those URNs.

 

Kind regards

 

Ivo Sedlacek

 

 

 

 

This Communicatio= n is Confidential. We only send and receive email on the basis of the terms set = out at www.ericsson.com/email_d= isclaimer

From:= Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19. =FAnora 2013 21:12=
To: Ivo Sedlacek
Cc: Winterbottom, James; Ric= hard Barnes; ecrit@ietf.org
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

 

Thing is, when there is no city police, local would give you county police (sheri= ff department) but in a city with a city police department local would give yo= u city police.  In the latter case, so how do I get the county police (o= r state police, there can be up to 4 police services for a given location in = the US).&nb= sp; Note that these examples are US based, but we do have 3 levels of police service= s in Canada and I am sure other countries have the same issue.

 <= o:p>

Ther= e is also the terminology.  There is no "national" police in the US or Canada but there is a federal police.  Keeping the RFC 4119 terminology removes any "local"= ; interpretation issues.

Dan

On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek <ivo.sedlacek@er= icsson.com> wrote:

I agree with Richard - there are countries where both the emergency service of the national police and the emergency service of the municipal police are offered in a given location.

A user would call the municipal police emergency service to report e.g. pickpockets.

A user would call the national police emergency service to report e.g. a murder.=

 

 

I submitted to IANA a request to register:=

- urn:service:sos.police.local - The 'police.local' service refers to the emergency service offered by the polic= e department or other law enforcement authorities of the local or municipal authorities.

- urn:service:sos.police.national - The 'police.national' service refers to the emergency service offered by the po= lice department or other law enforcement authorities of the national government.=

 

RFC5031 policy is hopefully fulfilled for = them since they exist in two countries.

 

I am flexible whether the actual URNs cont= ain the sub-services proposed above (i.e. .local and .national sub-services) or subservices based on RFC4119 (i.e. .A3 and .country sub-services).

 

If the preference is for subservices based= on RFC4119, do I need to make another IANA registration request or can we modi= fy the URNs and their description during the expert review?

 

Kind regards

 

Ivo Sedlacek

 

This Communication is Confidential. We onl= y send and receive email on the basis of the terms set out at www.ericsson.com/email_d= isclaimer

From: Dan Mongrain [m= ailto:dan@mongrain.org] Sent: 19. =FAnora 2013 15:36=
To: Winterbottom, James
Cc: Richard Barnes; Ivo Sedl= acek; ecrit@ietf.org
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos=

 

The problem is that different countries = has different names for their political subdivisions.  In the US they are states, in Canada = they are provinces, etc.  Same when you further subdivide.  While not priv= y to the discussions that came up with A1, A2, …, A5, I have the feeling t= his nomenclature was picked for the same reason.  Why not utilise the same naming scheme for specifying the jurisdiction you want to reach?

 <= o:p>

Thanx,<= o:p>

Dan

 

On Mon, Feb= 18, 2013 at 5:01 PM, Wint= erbottom, James <James.Winterbottom@commscope.com> wrote:

In that case, one might say state in the hierarchy, not A1.

 <= o:p>

Cheers<= o:p>

James

 <= o:p>

 <= o:p>

From: Richard Barnes = [mailto:rlb@ipv.sx]
Sent: Tuesday, 19 February 2= 013 8:57 AM
To: Winterbottom, James
Cc: Dan Mongrain; Ivo Sedlac= ek; ecrit@ietf.org<= /font>


Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos=

 

It might make sense if you wanted to allow the caller to explicitly select pol= ice at a different level of responsibility, e.g., the state police rather than = the local police.  

 

On Mon, Feb= 18, 2013 at 4:21 PM, Wint= erbottom, James <James.Winterbottom@commscope.com> wrote:

I think I am missing something here, A1 = is part of the location, so why does it need to be in the URN at all?

As far as I understand current deploymen= ts, they use the URN to select a layer in the GIS<= /st1:stockticker> that corresponds to the service type, and then use geographic boundaries wi= thin that layer to select the final destination.

 <= o:p>

From: ecrit-bounces@ietf= .org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Dan Mongrain Sent: Tuesday, 19 February 2= 013 7:30 AM


To: Ivo Sedlacek
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos=

 

Sorry for responding late to this thread= , it kinda fell into a  crack…  The current thread reminded me t= o check this old thread…

 <= o:p>

You are indicating that we need to regis= ter 77 Service URN (11 service subtypes * 7 jurisdiction types based on RFC 4119).  I do not recommend that we create so many registrations.  Instead, we should allow a service URN to be suffixed with a jurisdictional scope.  So the following Service URN are all valid:

 <= o:p>

urn:service:sos.police

urn:service:sos.police.traffic

urn:service:sos.police.A1<= span lang=3DEN-US>

urn:service:sos.police.traffic.A1=

 <= o:p>

Question is, do we want to leave jurisdictional scope to only be applicable to police branch or any Service = URN?  I’d say the latter as it is always up to the LoST service provisioning (based on local policy) to determine what is locally acceptabl= e.

 <= o:p>

Thanx,<= o:p>

Dan

 

 

--_000_EDC0A1AE77C57744B664A310A0B23AE21070160C11FRMRSSXCHMBSC_-- From James.Winterbottom@commscope.com Tue Feb 19 16:28:54 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D7A21F886F for ; Tue, 19 Feb 2013 16:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnArzTbz-aBi for ; Tue, 19 Feb 2013 16:28:48 -0800 (PST) Received: from cdcsmgw01.commscope.com (cdcsmgw01.commscope.com [198.135.207.232]) by ietfa.amsl.com (Postfix) with ESMTP id 2A45621F86F4 for ; Tue, 19 Feb 2013 16:28:48 -0800 (PST) X-AuditID: 0a0404e8-b7fa46d000004284-c2-512418ba481f Received: from CDCE10HC1.commscope.com ( [10.86.28.21]) by cdcsmgw01.commscope.com (Symantec Messaging Gateway) with SMTP id 43.CF.17028.AB814215; Tue, 19 Feb 2013 18:28:42 -0600 (CST) Received: from SISPE7HC1.commscope.com (10.97.4.12) by CDCE10HC1.commscope.com (10.86.28.21) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 19 Feb 2013 18:28:46 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 20 Feb 2013 08:28:43 +0800 From: "Winterbottom, James" To: "DRAGE, Keith (Keith)" , Ivo Sedlacek , Dan Mongrain Date: Wed, 20 Feb 2013 08:28:40 +0800 Thread-Topic: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) Thread-Index: AQHODt1tdiHHy2UVREyyoMwBpRaXz5iBn86AgAA0BgCAAAV0sIAACYUg Message-ID: <5A55A45AE77F5941B18E5457ECAC81880121407712DC@SISPE7MB1.commscope.com> References: <39B5E4D390E9BD4890E2B3107900610109A5A8@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610109A6A7@ESESSMB301.ericsson.se> <5A55A45AE77F5941B18E5457ECAC81880121407712CD@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC81880121407712DCSISPE7MB1co_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNKsWRmVeSWpSXmKPExsXCFSYjqrtLQiXQ4MdrPYv7c1pYLBoXPWW1 6F05j9XiaeNZRgcWj9Zne1k9fn29yuaxZMlPJo8X2xQCWKK4bFJSczLLUov07RK4MtZ2rWAt WNDLXDF130HGBsZjj5i6GDk5JARMJO5c+s4MYYtJXLi3nq2LkYtDSGAXo8SS98eYIZwNjBIP 2rZAZdYxSjQd2sEI0sImYCdxeP0NsCoRgQ5GiSlXD4MlmAVUJc41PmYBsVmA7HmHPoMVCQtM Y5T483MWE0THdEaJpQdvsYFUiQi4SZz8sA7I5uDgFQiS+Po4E2LdZyaJ5d8hpnIKJEj8PjQd bCoj0LXfT61hgtgmLnHryXyojwQkluw5D/WRqMTLx/9YIepFJe60r4e6Ll/i4tzrYDavgKDE yZlPwGYKCehKNO38yjqBUXwWkrGzkLTMQtICEdeTuDF1ChuErS2xbOFrZghbV2LGv0MsyOIL GNlXMYonpyQX56aXGxjqJefn5hYn5xekglibGEFxzcLyYgfj6Q3ahxgFOBiVeHg15isHCrEm lhVX5h5ilORgUhLlfSWiEijEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhNedFSjHm5JYWZValA+T 0uDgEDj95P4pRimWvPy8VCUJ3m5xoDLBotT01Iq0zBxgUoMpZeLgBBnFAzRqKUgNb3FBYm5x ZjpE/hSjNseCa49eMHI0L3/+glEIbJyUOO8OkFIBkNKM0jy4aa8YxYFeEOaNEwXK8gBTNNyc V0ArmIBWrF2uDLKiJBEhJdXAGN6rMT/R4nl3V879O1Va9/vf2fxwSctVWR54kyf+UnOmz3eX 6pq3BW98GSSlr0VKay9P9Dl5KPrjClsugTU3/hzadlnw36RXfefnvahg2FCVtXuLqQOLwp8K tod3849rf22RDZhYGvczfOcyM6HYHS4vlvAaxB88a9kyszRsnmXM9Bv6PZ97lViKMxINtZiL ihMBTFSIL44DAAA= Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 00:28:54 -0000 --_000_5A55A45AE77F5941B18E5457ECAC81880121407712DCSISPE7MB1co_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I tend agree with a lot of what you say here Keith . My question was, as you say, is this police service hierarchical, so should= it be defined as urn:service:sos.police.A1.A2.A3? I think that the need for a citizen to make this determination is not neede= d, and if it is the triage PSAP making the determination then it is out of = scope for RFC5031. Cheers James From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] Sent: Wednesday, 20 February 2013 11:18 AM To: Winterbottom, James; Ivo Sedlacek; Dan Mongrain Cc: ecrit@ietf.org Subject: RE: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) The answer to James's question depends on how you code it (and also what yo= u mean by fallback). On any service URN, you ignore any subtypes from the point you stop underst= anding it. So if the coding is sos.police.A2, and you do not understand A2, then the s= ervice URN would be handled as if it was sos.police, not as sos.police.A1. = And if police was not understood then it would be handled as sos. If you wanted something that went back to the next larger regional coverage= , then you would have to code successive subtypes in sequence. But I would also ask for an element of sanity in this discussion, rather th= an total flexibility. For example while a national administration may have multiple levels of pol= ice force, not all of them are either reachable directly as an emergency se= rvice provider, nor are they necessarily an emergency service provider. If = they are neither of these, then they presumably do not need a special and d= istinct service URN. It would therefore nice to see a current use case that is anything but a ch= oice of two, i.e. countrywide (following the ITU-T E.164 definition of coun= try) versus one more local variant. This restricted model certainly covers = Ivo's examples of Czeck Republic and Poland, and I believe it also covers t= he other example I know of which is Italy. While the USA has multiple levels of police force, on the PSTN, it only app= ears to have one level of access to citizen to authority emergency service,= which is 911. I see no reason why a change to voice over IP would cause a = change to this. I would also stress that it is important to have global expectations of wha= t you get when you use a service URN. If there is not care excercised with = assigning semantics and values, A3 in one country could result in the fores= try police and in another country the financial police responding. Note that read the scope of RFC 5031 as being for end user accessing the em= ergency service. While it might be possible to apply RFC 5031 to further ne= twork operations after the PSAP has been reached, e.g. to reach a subsidiar= y PSAP, I read that as outside the scope of RFC 5031. Nor do I necessarily = believe in that scenario that service URNs are necessarily the best solutio= n for routeing, as the first PSAP should know the particular office they wa= nt to reach rather than just the type of emergency service. Regards Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Winterbottom, James Sent: 19 February 2013 23:29 To: Ivo Sedlacek; Dan Mongrain Cc: ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) I am okay with this, providing that the fallback order is clearly defined. That is, does an A3 fall back to an A2 or A1, or just back to sos? From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] Sent: Wednesday, 20 February 2013 7:32 AM To: Dan Mongrain Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org Subject: RE: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) Hello, If we go with RFC4119 based sub-services, would the IANA registration reque= st be as follows? - urn:service:sos.police.A3 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of a city, township, shi (JP). - urn:service:sos.police.country - The 'police.national' service refers to = the emergency service offered by the police department or other law enforce= ment authorities of the government of a country. Does anyone see any issue in that? If WG prefers this, it is OK for me. > In the latter case, so how do I get the county police (or state police, t= here can be up to 4 police services for a given location in the US). If I got it correctly, you propose that we also add - urn:service:sos.police.A2 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of county, parish, gun (JP), district (IN)" - urn:service:sos.police.A1 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of national subdivisions (state, region, provin= ce, prefecture)" While I have no problem with that, I am not aware of a regulation establish= ing such emergency service so I cannot argue to IANA that the RFC5031 polic= y is satisfied for those URNs. 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 21:12 To: Ivo Sedlacek Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) Thing is, when there is no city police, local would give you county police = (sheriff department) but in a city with a city police department local woul= d give you city police. In the latter case, so how do I get the county pol= ice (or state police, there can be up to 4 police services for a given loca= tion in the US). Note that these examples are US based, but we do have 3 l= evels of police services in Canada and I am sure other countries have the s= ame issue. There is also the terminology. There is no "national" police in the US or = Canada but there is a federal police. Keeping the RFC 4119 terminology rem= oves any "local" interpretation issues. Dan On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek > wrote: I agree with Richard - there are countries where both the emergency service= of the national police and the emergency service of the municipal police a= re offered in a given location. A user would call the municipal police emergency service to report e.g. pic= kpockets. A user would call the national police emergency service to report e.g. a mu= rder. I submitted to IANA a request to register: - urn:service:sos.police.local - The 'police.local' service refers to the e= mergency service offered by the police department or other law enforcement = authorities of the local or municipal authorities. - urn:service:sos.police.national - The 'police.national' service refers to= the emergency service offered by the police department or other law enforc= ement authorities of the national government. RFC5031 policy is hopefully fulfilled for them since they exist in two coun= tries. I am flexible whether the actual URNs contain the sub-services proposed abo= ve (i.e. .local and .national sub-services) or subservices based on RFC4119= (i.e. .A3 and .country sub-services). If the preference is for subservices based on RFC4119, do I need to make an= other IANA registration request or can we modify the URNs and their descrip= tion during the expert review? 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 15:36 To: Winterbottom, James Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos The problem is that different countries has different names for their polit= ical subdivisions. In the US they are states, in Canada they are provinces= , etc. Same when you further subdivide. While not privy to the discussion= s that came up with A1, A2, ..., A5, I have the feeling this nomenclature w= as picked for the same reason. Why not utilise the same naming scheme for = specifying the jurisdiction you want to reach? Thanx, Dan On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James > wrote: In that case, one might say state in the hierarchy, not A1. Cheers James From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Tuesday, 19 February 2013 8:57 AM To: Winterbottom, James Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos It might make sense if you wanted to allow the caller to explicitly select = police at a different level of responsibility, e.g., the state police rathe= r than the local police. On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James > wrote: I think I am missing something here, A1 is part of the location, so why doe= s it need to be in the URN at all? As far as I understand current deployments, they use the URN to select a la= yer in the GIS that corresponds to the service type, and then use geographi= c boundaries within that layer to select the final destination. From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Dan Mongrain Sent: Tuesday, 19 February 2013 7:30 AM To: Ivo Sedlacek Cc: ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos Sorry for responding late to this thread, it kinda fell into a crack... T= he current thread reminded me to check this old thread... You are indicating that we need to register 77 Service URN (11 service subt= ypes * 7 jurisdiction types based on RFC 4119). I do not recommend that we= create so many registrations. Instead, we should allow a service URN to b= e suffixed with a jurisdictional scope. So the following Service URN are a= ll valid: urn:service:sos.police urn:service:sos.police.traffic urn:service:sos.police.A1 urn:service:sos.police.traffic.A1 Question is, do we want to leave jurisdictional scope to only be applicable= to police branch or any Service URN? I'd say the latter as it is always u= p to the LoST service provisioning (based on local policy) to determine wha= t is locally acceptable. Thanx, Dan --_000_5A55A45AE77F5941B18E5457ECAC81880121407712DCSISPE7MB1co_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

On Tue, F= eb 19, 2013 at 2:31 PM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:<= /o:p>

I agree with Richard - there are countries w= here both the emergency service of the national police and the emergency se= rvice of the municipal police are offered in a given location. =

A user would call the municipal police emergency serv= ice to report e.g. pickpockets.

A user wou= ld call the national police emergency service to report e.g. a murder.

 

 =

I submitted to IANA a request to register= :

- urn:service:sos.police.local - The 'po= lice.local' service refers to the emergency service offered by the police d= epartment or other law enforcement authorities of the local or municipal au= thorities.

- urn:service:sos.police.nation= al - The 'police.national' service refers to the emergency service offered = by the police department or other law enforcement authorities of the nation= al government.

 

RFC5031 policy is hopefully fulfilled for them since they exis= t in two countries.

 

I am flexible whether the actual URNs contain the sub-ser= vices proposed above (i.e. .local and .national sub-services) or subservice= s based on RFC4119 (i.e. .A3 and .country sub-services).<= /p>

 

If the preference is= for subservices based on RFC4119, do I need to make another IANA registrat= ion request or can we modify the URNs and their description during the expe= rt review?

 

Kind regards

 

Ivo Sedlacek

 

This Communication is Confidential. We only s= end and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19. =FAno= ra 2013 15:36
To: Winterbottom, James
Cc: Richard Barne= s; Ivo Sedlacek; ecrit@= ietf.org
Subject: Re: [Ecrit] What is the most appropriate me= thod for registering new sub-services of urn:service:sos<= /p>

 

The problem is that different = countries has different names for their political subdivisions.  In th= e US they are states, in Canada they are provinces, etc.  Same when yo= u further subdivide.  While not privy to the discussions that came up = with A1, A2, …, A5, I have the feeling this nomenclature was picked f= or the same reason.  Why not utilise the same naming scheme for specif= ying the jurisdiction you want to reach?

 

Thanx,

Dan

 

On Mon= , Feb 18, 2013 at 5:01 PM, Winterbottom, James <James.Winterbottom@commscope.= com> wrote:

In that case, one = might say state in the hierarchy, not A1.

 

Cheers

James

 

 

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Tuesday, 19 February 2013 8:57 AM
To: Winter= bottom, James
Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org


Subject: Re: [Ecrit] What is the most appropriate= method for registering new sub-services of urn:service:sos

<= /div>

 

It might= make sense if you wanted to allow the caller to explicitly select police a= t a different level of responsibility, e.g., the state police rather than t= he local police.  

 

On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James <James.Winterbot= tom@commscope.com> wrote:

I th= ink I am missing something here, A1 is part of the location, so why does it= need to be in the URN at all?

As far as= I understand current deployments, they use the URN to select a layer in th= e GIS that corresponds to the service type, and then use geographic boundar= ies within that layer to select the final destination.

 

From: ecrit-bounces@ietf.org [mailto:ecrit= -bounces@ietf.org] On Behalf Of Dan Mongrain
Sent: Tue= sday, 19 February 2013 7:30 AM


To: Ivo Sedlacek
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] What is the = most appropriate method for registering new sub-services of urn:service:sos=

 

Sorry for responding late to this thread, it kinda fell into a&nb= sp; crack…  The current thread reminded me to check this old thr= ead…

 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>You are indicating that we need to register 77 Service URN (11= service subtypes * 7 jurisdiction types based on RFC 4119).  I do not= recommend that we create so many registrations.  Instead, we should a= llow a service URN to be suffixed with a jurisdictional scope.  So the= following Service URN are all valid:

&n= bsp;

urn:service:sos.police<= /o:p>

urn:service:sos.police.traffic

=

urn:service:sos.police.A1

= urn:service:sos.police.traffic.A1

&nbs= p;

Question is, do we want to leave juri= sdictional scope to only be applicable to police branch or any Service URN?=  I’d say the latter as it is always up to the LoST service prov= isioning (based on local policy) to determine what is locally acceptable.

 

Thanx,

Dan

<= /div>

 

Hello,

 

thanks for very good summar= y.

 

regarding "3)      &nbs= p;  There are a number of countries where a number of distinct police forces exist" - I = also submitted to IANA the attached request for police related emergency se= rvices which exist in Poland and the Czech republic. RFC5031 policy is hopefully fulfilled for them since they exist in two countries.<= o:p>

 

Kind regards

 

Ivo Sedlacek

 

This Communication is Confid= ential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_discla= imer

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith)
Sent: 19. =FAnora 2013 2:04
To: ecrit@ietf.org
Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specifi= c-emergency-services-00

 

To try and put = things in context, I think there are four “problems” with the e= xisting sos URN values. draft-holmberg-ecrit-country-specific-emergency-ser= vices-00 attempts to solve only one of these.

 

1)  &= nbsp;      There are a number of emergency service= s that exist in multiple countries where a sos subtype is not defined. My v= iew is that we probably should define values for:

  &nb= sp;         -   &nbs= p;       traffic emergency<= /p>

  &nb= sp;         -   &nbs= p;       child protection emergency (this is = not the same as child counselling). For example Italy, among others, has su= ch a value where an immediate response is required.

  &nb= sp;         Obviously before we can= define these (and in addition to fulfilling the IANA registration requirem= ents), we need to come up definitions of what these really mean.

 

2)  &= nbsp;      There are a number of emergency service= s that exist in a single country. Ideally, for use in networks where servic= e URNs are used, these should have some form of service URN defined. This is what draft-holmberg-= ecrit-country-specific-emergency-services-00 seeks to resolve.

 

3)  &= nbsp;      There are a number of countries where a= number of distinct police forces exist. For any given location, these tend= to be defined on a range of areas of jurisdiction, e.g. national versus municipal. This has been di= scussed on the list over the end of last year, and there seemed to be some = consensus on defining a range of subtypes for subtype “police”.= Obviously it will not be possible to cover every variation with this, and we probably need to limit ourselves to valu= es that serve in multiple countries, in the same way the higher level subty= pes do.

 

4)&nb= sp;            There a= re a number of cases were PSAPs cover multiple subtypes. Where service URNs= are being used in isolation, this is not an issue. However where service URNs are being created from dialled digits, a particular loc= al service number in the telephony numbering plan could well map to two or = more potential subtypes. Yes, in these cases we could ignore generating a s= ubtype altogether, but some countries find it desirable to obtain all the information available from the user. T= hus it would be useful to be able to say sos.fire+medical in these scen= arios.

 

Note that all t= hese issues fall under the “sos” definition of emergency servic= e.

 

Regards

 

Keith

 

From: ecrit-bounces@= ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: 18 February 2013 17:56
To: John-Luc Bakker
Cc: ecrit@ietf.= org
Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specifi= c-emergency-services-00

 

Hi John-Luc,<= /p>

 

We actually already have separa= te URNs for medical and fire -- "urn:service:sos.ambulance" and "urn:service:sos.fire" [1].  So that's not an issue.  LoST can map them to the same or = different numbers depending on the jurisdiction.  There is also a &quo= t;counseling" URN for children, "urn:service:counseling.children&= quot;.

 

It might make s= ense to define new URNs for "national gendarmerie" / "nation= al police", and possibly "counter terrorism", since it seems= that those exist in several countries.

 

But in general,= this is the sort of exercise that people should go through for the various= countries.

 

--Richard

 

 

 

=  

On Mon, Feb 18, 2013 at 12:39 P= M, John-Luc Bakker <jbakker@rim.com> wrote:

Hi,

 

A few observations on the contents of t= he Wikipedia page.

The first entry shows Algeria having on= e number for medical AND fire: “14”.

Should there be one URN for “medi= cal” and “fire” registered with IANA? (A second country w= ith one number for medical AND fire, “15” in their case, is Morocco).<= /span>

 

Also, Algeria lists:<= /p>

 

National Gendarmerie : 1055; Counter Terrorist Unit : 1548; support for children : <= b>3033.

 

So, URNs for these may also be needed. = However, I question if we should derive IANA-registered URNs from any Wikipedia page (which can be edited by others that national regul= ators).

 

Kind regards,

 

      &nb= sp;        John-Luc

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces= @ietf.org] On Behalf Of Richard Barnes
Sent: Monday, February 18, 2013 11:28 AM
To: Ivo Sedlacek


Cc: ecrit@ietf.o= rg
Subject: Re: [Ecrit] Draft new: draft-holmberg-ecrit-country-specifi= c-emergency-services-00

 

Yes, I was thinking that the policy would be that an emergency ser= vice exists in one country.  The purpose of the registry would be just= be to encourage deduplication.  So, for instance, to encourage the several different countries that have traffic p= olice numbers* to all use something like "urn:service:sos.traffic"= ;.  Or, to choose a better example, once Korea has registered "ur= n:service:sos.espionage", to encourage the second country that establishes a spy reporting service to also use that URN.<= /p>

 

Alternatively, someone could just go through the list of emergency= numbers on Wikipedia and submit one big registration for the common ones (= like traffic police).  Those would be allowable under the current policy.

 

--Richard 

 

* according to wikipedia: EG, SD, CN, IN**, PK, SA, AL, AM, AZ, NZ= , CO, EC

** hopefully India could be persuaded to consolidate its three dif= ferent traffic police numbers

 

 

----------------------------------------------------= -----------------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient is prohibited. If you have rec= eived this transmission in error, please immediately reply to the sender an= d delete this information from your system. Use, dissemination, distributio= n, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

 

= --_000_7C40F45327B245AB95A6E7B56AACDBD5neustarbiz_-- From mlinsner@cisco.com Wed Feb 20 12:16:41 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A5B21E8030 for ; Wed, 20 Feb 2013 12:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.893 X-Spam-Level: X-Spam-Status: No, score=-8.893 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjtNaSf7-UMY for ; Wed, 20 Feb 2013 12:16:31 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8487621F889C for ; Wed, 20 Feb 2013 12:16:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=69423; q=dns/txt; s=iport; t=1361391390; x=1362600990; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=Pyf5Be2wXEaS+1IG2/6NHM0JoeEl4aCR+sSnuOz+pTs=; b=fYQj5stNrr2aXZ17F+aA8V+2lh1m5wGEadVOxUAfo5/4d5J9ZIv2mqAg Pu8tOdwgl/MxLJ9BptPfbabnk60nqDMgZIo1aDoLbkgOxlNambdcfyKIF yOW0gVsEwTb6xSgn5t7RRpVFRIJEPUMzxk4E5rZtgUYxNtxbi5cSGPuPm o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFABYtJVGtJXG+/2dsb2JhbABFgkNyvSoWbBZzgh8BAQEDAQEBARcBIgwdBQMLBQ4IEQMBAQEBIAECBC4fCQgGCgQFCRKHcQYMsBOQQo0zCoEmGQEGAQYBAwYBAgSDOgOIMDaJTTqDP4VyimmBUoFTgVQ X-IronPort-AV: E=Sophos;i="4.84,703,1355097600"; d="scan'208,217";a="179103078" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 20 Feb 2013 20:16:28 +0000 Received: from [10.116.195.124] (rtp-mlinsner-87111.cisco.com [10.116.195.124]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1KKGOpW017647; Wed, 20 Feb 2013 20:16:25 GMT User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Wed, 20 Feb 2013 15:16:24 -0500 From: Marc Linsner To: "Rosen, Brian" Message-ID: Thread-Topic: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) In-Reply-To: <7C40F453-27B2-45AB-95A6-E7B56AACDBD5@neustar.biz> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3444218186_1567595" Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:16:41 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3444218186_1567595 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable What if I don't want A2 (I don't trust Butler County sheriff), if no A3 (Mars) give me A1 (PA)? What I proposed allows the requestor to tailor the request to match his desire. The fallback is multiple requests. -Marc- From: "Rosen, Brian" Date: Wednesday, February 20, 2013 2:56 PM To: Marc Linsner Cc: Dan Mongrain , "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) > To me, this doesn't make sense. >=20 > Suppose I have a local police department in cities, but a provincial poli= ce > department in rural areas, as well as a national police. I ask for > sos.police.A3. If location was in a city, I should get sos.police.A3 >=20 > But if I was in a rural area, a request for sos.police.A3 should return a > response of sos.police.A2. >=20 > That may or may not be the same as sos.police >=20 > Brian >=20 > On Feb 20, 2013, at 2:47 PM, Marc Linsner wrote: >=20 >> I understood you as requesting urn:service:sos.police.A4. >>=20 >> My point was that if the LoST service had no entry for A4, it could simp= ly >> check the Ax tree submitted in the location section of the request. So = if >> the location included A1 & A4, the LoST service, finding nothing for A4 = would >> then check A1 (not A3 or A2). This way the service would be matching th= e >> hierarchy of the given location vs. an arbitrary hierarchy that may be >> different from the requestors desire. >>=20 >> Carry on=8A >>=20 >> -Marc- >>=20 >> From: Dan Mongrain >> Date: Wednesday, February 20, 2013 12:30 PM >> To: Marc Linsner >> Cc: "Winterbottom, James" , >> "ecrit@ietf.org" >> Subject: Re: [Ecrit] What is the most appropriate method for registerin= g new >> sub-services of urn:service:sos (trimming due too large message report) >>=20 >>> I do not understand your comment. What I am proposing is that requests= do >>> not specify a search pattern in the case a requested jurisdiction is no= t >>> found. It should not be to the requester which submits >>> urn:service:sos.police.country.A1.A2.A3.A4 to specify what to do if the= re is >>> nothing configured for the A4 layer. It must be up to the LoST service= to >>> apply whatever policy it has in this case. If we allow this, then do w= e >>> allow urn:service:sos.police.fire? Give me fire first but if not found= give >>> me police? >>>=20 >>> The Service URN should specify the "desired" service in a findService >>> request and the LoST service provides a response based on local policie= s. >>> All I am proposing is that one can specify a jurisdiction in the case t= here >>> are more then one service provider for a location. >>>=20 >>> Thanx, >>> Dan >>>=20 >>> On Wed, Feb 20, 2013 at 8:48 AM, Marc Linsner wrot= e: >>>> The findService request includes location information. Why wouldn't t= he >>>> LoST server simple walk the A1-A6 tree included with the location? If >>>> location is geo, reverse geocode it. >>>>=20 >>>> What am I missing? >>>>=20 >>>> -Marc- >>>>=20 >>>> From: Dan Mongrain >>>> Date: Tuesday, February 19, 2013 11:55 PM >>>> To: "Winterbottom, James" >>>> Cc: "ecrit@ietf.org" >>>> Subject: Re: [Ecrit] What is the most appropriate method for register= ing >>>> new sub-services of urn:service:sos (trimming due too large message re= port) >>>>=20 >>>>> What I meant is that if a jurisdictional scope aware LoST service rec= eives >>>>> a request for urn:service:sos.police.A4 and nothing is configured, it >>>>> looks for urn:service:sos.police.A3 then urn:service:sos.police.A2, e= tc. >>>>> until it finds a configured service. If nothing is found for >>>>> urn:service:sos.police.country then it pops the last element and look= s for >>>>> urn:service:sos.police (but then again, it is no longer jurisdictiona= l >>>>> scope aware). >>>>>=20 >>>>> I disagree that one needs to formulate the request as >>>>> urn:service:sos.police.country.A1.A2.A3.A4 in order for this to happe= n. >>>>> There must be only a single jurisdictional scope appended to a Servic= e >>>>> URN. >>>>>=20 >>>>> I do not think we need a .A6 jurisdictional scope (street level). .A= 5 >>>>> (neighborhood, would point to a precinct for example) provides enough >>>>> granularity in my opinion. >>>>>=20 >>>>> Thanx, >>>>> Dan >>>>>=20 >>>>>=20 >>>>> On Tue, Feb 19, 2013 at 11:29 PM, Winterbottom, James >>>>> wrote: >>>>>> I am sorry, I am finding this confusing. >>>>>> =20 >>>>>> RFC5139 puts a hierarchy on A1 through A6. If you want this hierarch= y to >>>>>> work then A1 through A6 can=B9t be at the same level if you expect A3 = to >>>>>> fallback to A2 or A1 in the case of a service not existing or a serv= ice >>>>>> failure of some kind. If they exist at the same level then if A3 doe= sn=B9t >>>>>> exist you will go to urn:service:sos.police unless you impose the >>>>>> hierarchy in the urn. >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> From: Dan Mongrain [mailto:dan@mongrain.org] >>>>>> Sent: Wednesday, 20 February 2013 3:23 PM >>>>>> To: DRAGE, Keith (Keith) >>>>>> Cc: Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org >>>>>> Subject: Re: [Ecrit] What is the most appropriate method for registe= ring >>>>>> new sub-services of urn:service:sos (trimming due too large message >>>>>> report) >>>>>> =20 >>>>>> My recommendation for handling unknown Service URN depends if LoST >>>>>> service implements jurisdictional scope or not. If it does not, it = pops >>>>>> the last element and evaluates until a service is found. If it >>>>>> implements jurisdictional scope, the last element is a jurisdictiona= l >>>>>> scope and it is not found, then you return the next highest level >>>>>> defined. >>>>>>=20 >>>>>> While it may be true that citizens typically dial 9-1-1 to request f= or >>>>>> help, police services such as state or provincial polices advertises >>>>>> numbers to call them directly (star code to dial using a mobile phon= e for >>>>>> example) especially to report accidents on freeways. We need an >>>>>> equivalent Service URN. >>>>>>=20 >>>>>> Also while RFC5031's scope is citizen to authorities (I am not sure = I >>>>>> agree with this) I do not want to re-invent the wheel to signal call= s >>>>>> within an Emergency Services IP Network (ESInet). When I transfer a= call >>>>>> from one PSAP to another, the mechanism to determine where to send t= he >>>>>> call is the same, using LoST. For a PSAP that covers a large area >>>>>> spanning multiple counties and the calltaker needs to transfer the c= all >>>>>> to the appropriate sheriff department for the caller's location, the= y >>>>>> only need a single transfer target (urn:service:sos.police.A2). It = is >>>>>> not true that the calltaker always knows the actual destination of t= he >>>>>> call, especially when the calltaker is only a call screener. >>>>>>=20 >>>>>> Thanx, >>>>>> Dan >>>>>>=20 >>>>>> On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) >>>>>> wrote: >>>>>> The answer to James=B9s question depends on how you code it (and also = what >>>>>> you mean by fallback). >>>>>> =20 >>>>>> On any service URN, you ignore any subtypes from the point you stop >>>>>> understanding it. >>>>>> =20 >>>>>> So if the coding is sos.police.A2, and you do not understand A2, the= n the >>>>>> service URN would be handled as if it was sos.police, not as >>>>>> sos.police.A1. And if police was not understood then it would be han= dled >>>>>> as sos. >>>>>> =20 >>>>>> If you wanted something that went back to the next larger regional >>>>>> coverage, then you would have to code successive subtypes in sequenc= e. >>>>>> =20 >>>>>> But I would also ask for an element of sanity in this discussion, ra= ther >>>>>> than total flexibility. >>>>>> =20 >>>>>> For example while a national administration may have multiple levels= of >>>>>> police force, not all of them are either reachable directly as an >>>>>> emergency service provider, nor are they necessarily an emergency se= rvice >>>>>> provider. If they are neither of these, then they presumably do not = need >>>>>> a special and distinct service URN. >>>>>> =20 >>>>>> It would therefore nice to see a current use case that is anything b= ut a >>>>>> choice of two, i.e. countrywide (following the ITU-T E.164 definitio= n of >>>>>> country) versus one more local variant. This restricted model certai= nly >>>>>> covers Ivo=B9s examples of Czeck Republic and Poland, and I believe it= also >>>>>> covers the other example I know of which is Italy. >>>>>> =20 >>>>>> While the USA has multiple levels of police force, on the PSTN, it o= nly >>>>>> appears to have one level of access to citizen to authority emergenc= y >>>>>> service, which is 911. I see no reason why a change to voice over IP >>>>>> would cause a change to this. >>>>>> =20 >>>>>> I would also stress that it is important to have global expectations= of >>>>>> what you get when you use a service URN. If there is not care excerc= ised >>>>>> with assigning semantics and values, A3 in one country could result = in >>>>>> the forestry police and in another country the financial police >>>>>> responding. >>>>>> =20 >>>>>> Note that read the scope of RFC 5031 as being for end user accessing= the >>>>>> emergency service. While it might be possible to apply RFC 5031 to >>>>>> further network operations after the PSAP has been reached, e.g. to = reach >>>>>> a subsidiary PSAP, I read that as outside the scope of RFC 5031. Nor= do I >>>>>> necessarily believe in that scenario that service URNs are necessari= ly >>>>>> the best solution for routeing, as the first PSAP should know the >>>>>> particular office they want to reach rather than just the type of >>>>>> emergency service. >>>>>> =20 >>>>>> Regards >>>>>> =20 >>>>>> Keith >>>>>> =20 >>>>>>=20 >>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Beha= lf Of >>>>>> Winterbottom, James >>>>>> Sent: 19 February 2013 23:29 >>>>>> To: Ivo Sedlacek; Dan Mongrain >>>>>> Cc: ecrit@ietf.org >>>>>> Subject: Re: [Ecrit] What is the most appropriate method for registe= ring >>>>>> new sub-services of urn:service:sos (trimming due too large message >>>>>> report) >>>>>> =20 >>>>>> I am okay with this, providing that the fallback order is clearly >>>>>> defined. >>>>>> That is, does an A3 fall back to an A2 or A1, or just back to sos? >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] >>>>>> Sent: Wednesday, 20 February 2013 7:32 AM >>>>>> To: Dan Mongrain >>>>>> Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org >>>>>> Subject: RE: [Ecrit] What is the most appropriate method for registe= ring >>>>>> new sub-services of urn:service:sos (trimming due too large message >>>>>> report) >>>>>> =20 >>>>>> Hello, >>>>>> =20 >>>>>> If we go with RFC4119 based sub-services, would the IANA registratio= n >>>>>> request be as follows? >>>>>> =20 >>>>>> - urn:service:sos.police.A3 - The 'police.local' service refers to t= he >>>>>> emergency service offered by the police department or other law >>>>>> enforcement authorities of the authorities of a city, township, shi = (JP). >>>>>> - urn:service:sos.police.country - The 'police.national' service ref= ers >>>>>> to the emergency service offered by the police department or other l= aw >>>>>> enforcement authorities of the government of a country. >>>>>> =20 >>>>>> Does anyone see any issue in that? >>>>>> =20 >>>>>> If WG prefers this, it is OK for me. >>>>>> =20 >>>>>>> > In the latter case, so how do I get the county police (or state >>>>>>> police, there can be up to 4 police services for a given location i= n the >>>>>>> US). =20 >>>>>> =20 >>>>>> If I got it correctly, you propose that we also add >>>>>> - urn:service:sos.police.A2 - The 'police.local' service refers to t= he >>>>>> emergency service offered by the police department or other law >>>>>> enforcement authorities of the authorities of county, parish, gun (J= P), >>>>>> district (IN)" >>>>>> - urn:service:sos.police.A1 - The 'police.local' service refers to t= he >>>>>> emergency service offered by the police department or other law >>>>>> enforcement authorities of the authorities of national subdivisions >>>>>> (state, region, province, prefecture)" >>>>>> =20 >>>>>> While I have no problem with that, I am not aware of a regulation >>>>>> establishing such emergency service so I cannot argue to IANA that t= he >>>>>> RFC5031 policy is satisfied for those URNs. >>>>>> =20 >>>>>> Kind regards >>>>>> =20 >>>>>> Ivo Sedlacek >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> This Communication is Confidential. We only send and receive email o= n the >>>>>> basis of the terms set out at www.ericsson.com/email_disclaimer >>>>>> >>>>>> From: Dan Mongrain [mailto:dan@mongrain.org] >>>>>> Sent: 19. =FAnora 2013 21:12 >>>>>> To: Ivo Sedlacek >>>>>> Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org >>>>>> Subject: Re: [Ecrit] What is the most appropriate method for registe= ring >>>>>> new sub-services of urn:service:sos (trimming due too large message >>>>>> report) >>>>>> =20 >>>>>> Thing is, when there is no city police, local would give you county >>>>>> police (sheriff department) but in a city with a city police departm= ent >>>>>> local would give you city police. In the latter case, so how do I g= et >>>>>> the county police (or state police, there can be up to 4 police serv= ices >>>>>> for a given location in the US). Note that these examples are US ba= sed, >>>>>> but we do have 3 levels of police services in Canada and I am sure o= ther >>>>>> countries have the same issue. >>>>>> =20 >>>>>> There is also the terminology. There is no "national" police in the= US >>>>>> or Canada but there is a federal police. Keeping the RFC 4119 >>>>>> terminology removes any "local" interpretation issues. >>>>>>=20 >>>>>> Dan >>>>>>=20 >>>>>> On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek >>>>>> wrote: >>>>>> I agree with Richard - there are countries where both the emergency >>>>>> service of the national police and the emergency service of the muni= cipal >>>>>> police are offered in a given location. >>>>>> A user would call the municipal police emergency service to report e= .g. >>>>>> pickpockets. >>>>>> A user would call the national police emergency service to report e.= g. a >>>>>> murder. >>>>>> =20 >>>>>> =20 >>>>>> I submitted to IANA a request to register: >>>>>> - urn:service:sos.police.local - The 'police.local' service refers t= o the >>>>>> emergency service offered by the police department or other law >>>>>> enforcement authorities of the local or municipal authorities. >>>>>> - urn:service:sos.police.national - The 'police.national' service re= fers >>>>>> to the emergency service offered by the police department or other l= aw >>>>>> enforcement authorities of the national government. >>>>>> =20 >>>>>> RFC5031 policy is hopefully fulfilled for them since they exist in t= wo >>>>>> countries. >>>>>> =20 >>>>>> I am flexible whether the actual URNs contain the sub-services propo= sed >>>>>> above (i.e. .local and .national sub-services) or subservices based = on >>>>>> RFC4119 (i.e. .A3 and .country sub-services). >>>>>> =20 >>>>>> If the preference is for subservices based on RFC4119, do I need to = make >>>>>> another IANA registration request or can we modify the URNs and thei= r >>>>>> description during the expert review? >>>>>> =20 >>>>>> Kind regards >>>>>> =20 >>>>>> Ivo Sedlacek >>>>>> =20 >>>>>> This Communication is Confidential. We only send and receive email o= n the >>>>>> basis of the terms set out at www.ericsson.com/email_disclaimer >>>>>> >>>>>> From: Dan Mongrain [mailto:dan@mongrain.org] >>>>>> Sent: 19. =FAnora 2013 15:36 >>>>>> To: Winterbottom, James >>>>>> Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org >>>>>> Subject: Re: [Ecrit] What is the most appropriate method for registe= ring >>>>>> new sub-services of urn:service:sos >>>>>> =20 >>>>>> The problem is that different countries has different names for thei= r >>>>>> political subdivisions. In the US they are states, in Canada they a= re >>>>>> provinces, etc. Same when you further subdivide. While not privy t= o the >>>>>> discussions that came up with A1, A2, =8A, A5, I have the feeling this >>>>>> nomenclature was picked for the same reason. Why not utilise the sa= me >>>>>> naming scheme for specifying the jurisdiction you want to reach? >>>>>> =20 >>>>>> Thanx, >>>>>> Dan >>>>>> =20 >>>>>>=20 >>>>>> On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James >>>>>> wrote: >>>>>> In that case, one might say state in the hierarchy, not A1. >>>>>> =20 >>>>>> Cheers >>>>>> James >>>>>> =20 >>>>>> =20 >>>>>> From: Richard Barnes [mailto:rlb@ipv.sx] >>>>>> Sent: Tuesday, 19 February 2013 8:57 AM >>>>>> To: Winterbottom, James >>>>>> Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org >>>>>>=20 >>>>>> Subject: Re: [Ecrit] What is the most appropriate method for registe= ring >>>>>> new sub-services of urn:service:sos >>>>>> =20 >>>>>> It might make sense if you wanted to allow the caller to explicitly >>>>>> select police at a different level of responsibility, e.g., the stat= e >>>>>> police rather than the local police. >>>>>> =20 >>>>>>=20 >>>>>> On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James >>>>>> wrote: >>>>>> I think I am missing something here, A1 is part of the location, so = why >>>>>> does it need to be in the URN at all? >>>>>> As far as I understand current deployments, they use the URN to sele= ct a >>>>>> layer in the GIS that corresponds to the service type, and then use >>>>>> geographic boundaries within that layer to select the final destinat= ion. >>>>>> =20 >>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Beha= lf Of >>>>>> Dan Mongrain >>>>>> Sent: Tuesday, 19 February 2013 7:30 AM >>>>>>=20 >>>>>> To: Ivo Sedlacek >>>>>> Cc: ecrit@ietf.org >>>>>> Subject: Re: [Ecrit] What is the most appropriate method for registe= ring >>>>>> new sub-services of urn:service:sos >>>>>> =20 >>>>>> Sorry for responding late to this thread, it kinda fell into a crac= k=8A >>>>>> The current thread reminded me to check this old thread=8A >>>>>> =20 >>>>>> You are indicating that we need to register 77 Service URN (11 servi= ce >>>>>> subtypes * 7 jurisdiction types based on RFC 4119). I do not recomm= end >>>>>> that we create so many registrations. Instead, we should allow a se= rvice >>>>>> URN to be suffixed with a jurisdictional scope. So the following Se= rvice >>>>>> URN are all valid: >>>>>> =20 >>>>>> urn:service:sos.police >>>>>> urn:service:sos.police.traffic >>>>>> urn:service:sos.police.A1 >>>>>> urn:service:sos.police.traffic.A1 >>>>>> =20 >>>>>> Question is, do we want to leave jurisdictional scope to only be >>>>>> applicable to police branch or any Service URN? I=B9d say the latter = as it >>>>>> is always up to the LoST service provisioning (based on local policy= ) to >>>>>> determine what is locally acceptable. >>>>>> =20 >>>>>> Thanx, >>>>>> Dan >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>=20 >>>>> _______________________________________________ Ecrit mailing list >>>>> Ecrit@ietf.orghttps://www.ietf.org/mailman/listinfo/ecrit >>>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 --B_3444218186_1567595 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
What if I don't want A2 (I d= on't trust Butler County sheriff), if no A3 (Mars) give me A1 (PA)?

I tend ag= ree with a lot of what you say here Keith .

 

My question was, as you say, is this police service hierarchical, so shoul= d it be defined as urn:service:sos.police.A1.A2.A3?

 

= I think that the need for a citizen to make this determination is no= t needed, and if it is the triage PSAP making the determination then it is = out of scope for RFC5031.

=  

Cheers

James

 

 

 

 

&nb= sp;

 

From: DRAGE, Keith (Keith) [mailto:keith.= drage@alcatel-lucent.com]
Sent: Wednesday, 20 February 2013 11:1= 8 AM
To: Winterbottom, James; Ivo Sedlacek; Dan Mongrain
Cc= : ecrit@ietf.org
Subject: RE: [Ecrit] What is the most approp= riate method for registering new sub-services of urn:service:sos (trimming = due too large message report)

 

The answe= r to James’s question depends on how you code it (and also what you m= ean by fallback).

=  

On any se= rvice URN, you ignore any subtypes from the point you stop understanding it= .

 

So if the coding is sos.pol= ice.A2, and you do not understand A2, then the service URN would be handled= as if it was sos.police, not as sos.police.A1. And if police was not under= stood then it would be handled as sos.

 

If you wanted something that went back to the next larger regiona= l coverage, then you would have to code successive subtypes in sequence.

 

But I would also ask for an ele= ment of sanity in this discussion, rather than total flexibility.

 

For example while a national administr= ation may have multiple levels of police force, not all of them are either = reachable directly as an emergency service provider, nor are they necessari= ly an emergency service provider. If they are neither of these, then they p= resumably do not need a special and distinct service URN.

 

It would therefore nice to see a current use = case that is anything but a choice of two, i.e. countrywide (following the = ITU-T E.164 definition of country) versus one more local variant. This rest= ricted model certainly covers Ivo’s examples of Czeck Republic and Po= land, and I believe it also covers the other example I know of which is Ita= ly.

 

While the USA has multipl= e levels of police force, on the PSTN, it only appears to have one level of= access to citizen to authority emergency service, which is 911. I see no r= eason why a change to voice over IP would cause a change to this.

 

I would also stress that it is importa= nt to have global expectations of what you get when you use a service URN. = If there is not care excercised with assigning semantics and values, A3 in = one country could result in the forestry police and in another country the = financial police responding.

 

= Note that read the scope of RFC 5031 as being for end user accessing the em= ergency service. While it might be possible to apply RFC 5031 to further ne= twork operations after the PSAP has been reached, e.g. to reach a subsidiar= y PSAP, I read that as outside the scope of RFC 5031. Nor do I necessarily = believe in that scenario that service URNs are necessarily the best solutio= n for routeing, as the first PSAP should know the particular office they wa= nt to reach rather than just the type of emergency service.

 

Regards

 

Keith

 

From: ecrit= -bounces@ietf.org [mailto:ecr= it-bounces@ietf.org] On Behalf Of Winterbottom, James
Sent= : 19 February 2013 23:29
To: Ivo Sedlacek; Dan Mongrain
Cc: ecrit@ietf.org
Subject= : Re: [Ecrit] What is the most appropriate method for registering new s= ub-services of urn:service:sos (trimming due too large message report)

 <= /o:p>

I am okay with this, providing = that the fallback order is clearly defined.

That is, does an A3 fall back to an A2 or A1, or just b= ack to sos?

 

 

 

From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com]
Sent: Wednesday, 20 Febru= ary 2013 7:32 AM
To: Dan Mongrain
Cc: Winterbottom, Jam= es; Richard Barnes; ecrit@ietf.orgSubject: RE: [Ecrit] What is the most appropriate method for regist= ering new sub-services of urn:service:sos (trimming due too large message r= eport)

 

Hello,

 

If we go = with RFC4119 based sub-services, would the IANA registration request be as = follows?

 <= /o:p>

- urn:service:sos.police.A3 - The 'police.local' service ref= ers to the emergency service offered by the police department or other law = enforcement authorities of the authorities of a city, township, shi (JP).

=

- urn:service:sos.police.country - The 'police.national' service refe= rs to the emergency service offered by the police department or other law e= nforcement authorities of the government of a country.

 

Does anyone se= e any issue in that?

&= nbsp;

If WG prefers this, it is O= K for me.

 <= /span>

> In the latter case, so how do I ge= t the county police (or state police, there can be up to 4 police services = for a given location in the US). 

 

If I got it correctly, you propose that we also add

- urn:service:sos.police.A2 - The 'polic= e.local' service refers to the emergency service offered by the police depa= rtment or other law enforcement authorities of the authorities of county, parish, gun (JP), distr= ict (IN)"

- urn:ser= vice:sos.police.A1 - The 'police.local' service refers to the emerge= ncy service offered by the police department or other law enforcement autho= rities of the authorities <= u>of national subdivisions (state, region, province, prefecture)"<= o:p>

 

=

While I have no problem with that, I am not aware= of a regulation establishing such emergency service so I cannot argue to I= ANA that the RFC5031 policy is satisfied for those URNs.<= /p>

 

Kind regards

&= nbsp;

Ivo Sedlacek

 

 

 

 

This Communication is Confidential. We only send and receive ema= il on the basis of the terms set out at www.er= icsson.com/email_disclaimer

= From:= Dan Mongrain [mailto:dan@mongrain.o= rg]
Sent: 19. =FAnora 2013 21:12
To: Ivo Sedlacek<= br>Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: Re: [Ecrit] What is the mos= t appropriate method for registering new sub-services of urn:service:sos (t= rimming due too large message report)

 

Thing is, when there is no city police, local wou= ld give you county police (sheriff department) but in a city with a city po= lice department local would give you city police.  In the latter case,= so how do I get the county police (or state police, there can be up to 4 p= olice services for a given location in the US).  Note that these examp= les are US based, but we do have 3 levels of police services in Canada and = I am sure other countries have the same issue.

=  

There is also the terminology.  There is no "national= " police in the US or Canada but there is a federal police.  Keep= ing the RFC 4119 terminology removes any "local" interpretation i= ssues.

Dan

On Tue, Feb 19, 2= 013 at 2:31 PM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:

I agree with Richard - there are countries where bot= h the emergency service of the national police and the emergency service of= the municipal police are offered in a given location.

A user would call the municipal police emergency service to r= eport e.g. pickpockets.

A user would call = the national police emergency service to report e.g. a murder.<= /o:p>

 

 <= o:p>

I submitted to IANA a request to register:=

- urn:service:sos.police.local - The 'police.loc= al' service refers to the emergency service offered by the police departmen= t or other law enforcement authorities of the local or municipal authoritie= s.

- urn:service:sos.police.national - The= 'police.national' service refers to the emergency service offered by the p= olice department or other law enforcement authorities of the national gover= nment.

 

= RFC5031 policy is hopefully fulfilled for them since they exist in two= countries.

 

I am flexible whether the actual URNs contain the sub-services pr= oposed above (i.e. .local and .national sub-services) or subservices based = on RFC4119 (i.e. .A3 and .country sub-services).

 

If the preference is for sub= services based on RFC4119, do I need to make another IANA registration requ= est or can we modify the URNs and their description during the expert revie= w?

 

Kind regards

 

=

Ivo Sedlacek

 

This Communication is Confidential. We only send and = receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19. =FAnora 2013 = 15:36
To: Winterbottom, James
Cc: Richard Barnes; Ivo S= edlacek; ecrit@ietf.org=
Subject: Re: [Ecrit] What is the most appropriate method for= registering new sub-services of urn:service:sos

 

The problem is that different countrie= s has different names for their political subdivisions.  In the US the= y are states, in Canada they are provinces, etc.  Same when you furthe= r subdivide.  While not privy to the discussions that came up with A1,= A2, …, A5, I have the feeling this nomenclature was picked for the s= ame reason.  Why not utilise the same naming scheme for specifying the= jurisdiction you want to reach?

 <= /span>

Thanx,

Dan

 

On Mon, Feb 18= , 2013 at 5:01 PM, Winterbottom, James <James.Winterbottom@commscope.com&= gt; wrote:

In that case, one might sa= y state in the hierarchy, not A1.

&nbs= p;

Cheers

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>James

 

=

 

From: Richard Barne= s [mailto:rlb@ipv.sx] <= br>Sent: Tuesday, 19 February 2013 8:57 AM
To: Winterbotto= m, James
Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org


Subject: Re: [Ecrit] What is the most appropriate meth= od for registering new sub-services of urn:service:sos

=

 

It might make= sense if you wanted to allow the caller to explicitly select police at a d= ifferent level of responsibility, e.g., the state police rather than the lo= cal police.  

 

On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James <James.Winterbottom@c= ommscope.com> wrote:

I think I= am missing something here, A1 is part of the location, so why does it need= to be in the URN at all?

As far as I = understand current deployments, they use the URN to select a layer in the G= IS that corresponds to the service type, and then use geographic boundaries= within that layer to select the final destination.

 

From: ecrit-bounces@ietf.org [ma= ilto:ecrit-boun= ces@ietf.org] On Behalf Of Dan Mongrain
Sent: Tuesday,= 19 February 2013 7:30 AM


To:<= /b> Ivo Sedlacek
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] What is the most = appropriate method for registering new sub-services of urn:service:sos=

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>Sorry for responding late to this thread, it kinda fell into a  = crack…  The current thread reminded me to check this old thread&= #8230;

 

You are indicating that we need to register 77 Service URN (11 ser= vice subtypes * 7 jurisdiction types based on RFC 4119).  I do not rec= ommend that we create so many registrations.  Instead, we should allow= a service URN to be suffixed with a jurisdictional scope.  So the fol= lowing Service URN are all valid:

&nbs= p;

urn:service:sos.police

urn:service:sos.police.traffic

urn:service:sos.police.A1

ur= n:service:sos.police.traffic.A1

 

Question is, do we want to leave jurisdic= tional scope to only be applicable to police branch or any Service URN? &nb= sp;I’d say the latter as it is always up to the LoST service provisio= ning (based on local policy) to determine what is locally acceptable.

 

Tha= nx,

Dan

 

 

<= /div>= --_000_5A55A45AE77F5941B18E5457ECAC81880121407712DCSISPE7MB1co_-- From keith.drage@alcatel-lucent.com Tue Feb 19 17:07:43 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003CB21F882F for ; Tue, 19 Feb 2013 17:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.756 X-Spam-Level: X-Spam-Status: No, score=-108.756 tagged_above=-999 required=5 tests=[AWL=0.892, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pv6bTX4dzxJP for ; Tue, 19 Feb 2013 17:07:36 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6A22821F882E for ; Tue, 19 Feb 2013 17:07:35 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1K17TCd022516 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Feb 2013 02:07:29 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 20 Feb 2013 02:07:29 +0100 From: "DRAGE, Keith (Keith)" To: "Winterbottom, James" , "ecrit@ietf.org" Date: Wed, 20 Feb 2013 02:07:28 +0100 Thread-Topic: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) Thread-Index: AQHODt1tdiHHy2UVREyyoMwBpRaXz5iBn86AgAA0BgCAAAV0sIAACYUggAALIKA= Message-ID: References: <39B5E4D390E9BD4890E2B3107900610109A5A8@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610109A6A7@ESESSMB301.ericsson.se> <5A55A45AE77F5941B18E5457ECAC81880121407712CD@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC81880121407712DC@SISPE7MB1.commscope.com> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880121407712DC@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE21070160C13FRMRSSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 01:07:43 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE21070160C13FRMRSSXCHMBSC_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My understanding of at least the real life examples given so far is that th= e different police forces have different responsibilities. Therefore if the= subtype is not understood one should go straight from sos.police.A2 to sos= .police, rather than to A1. Even if some country doesn't follow this and does have hierarchical respons= ibilities, then it is going to confuse roaming users, in either direction. Note that in general all countries need to have a means of handling emergen= cy calls without subtypes, so going straight up to sos.police will still be= handled. Keith ________________________________ From: Winterbottom, James [mailto:James.Winterbottom@commscope.com] Sent: 20 February 2013 00:29 To: DRAGE, Keith (Keith); Ivo Sedlacek; Dan Mongrain Cc: ecrit@ietf.org Subject: RE: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) I tend agree with a lot of what you say here Keith . My question was, as you say, is this police service hierarchical, so should= it be defined as urn:service:sos.police.A1.A2.A3? I think that the need for a citizen to make this determination is not neede= d, and if it is the triage PSAP making the determination then it is out of = scope for RFC5031. Cheers James From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] Sent: Wednesday, 20 February 2013 11:18 AM To: Winterbottom, James; Ivo Sedlacek; Dan Mongrain Cc: ecrit@ietf.org Subject: RE: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) The answer to James's question depends on how you code it (and also what yo= u mean by fallback). On any service URN, you ignore any subtypes from the point you stop underst= anding it. So if the coding is sos.police.A2, and you do not understand A2, then the s= ervice URN would be handled as if it was sos.police, not as sos.police.A1. = And if police was not understood then it would be handled as sos. If you wanted something that went back to the next larger regional coverage= , then you would have to code successive subtypes in sequence. But I would also ask for an element of sanity in this discussion, rather th= an total flexibility. For example while a national administration may have multiple levels of pol= ice force, not all of them are either reachable directly as an emergency se= rvice provider, nor are they necessarily an emergency service provider. If = they are neither of these, then they presumably do not need a special and d= istinct service URN. It would therefore nice to see a current use case that is anything but a ch= oice of two, i.e. countrywide (following the ITU-T E.164 definition of coun= try) versus one more local variant. This restricted model certainly covers = Ivo's examples of Czeck Republic and Poland, and I believe it also covers t= he other example I know of which is Italy. While the USA has multiple levels of police force, on the PSTN, it only app= ears to have one level of access to citizen to authority emergency service,= which is 911. I see no reason why a change to voice over IP would cause a = change to this. I would also stress that it is important to have global expectations of wha= t you get when you use a service URN. If there is not care excercised with = assigning semantics and values, A3 in one country could result in the fores= try police and in another country the financial police responding. Note that read the scope of RFC 5031 as being for end user accessing the em= ergency service. While it might be possible to apply RFC 5031 to further ne= twork operations after the PSAP has been reached, e.g. to reach a subsidiar= y PSAP, I read that as outside the scope of RFC 5031. Nor do I necessarily = believe in that scenario that service URNs are necessarily the best solutio= n for routeing, as the first PSAP should know the particular office they wa= nt to reach rather than just the type of emergency service. Regards Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Winterbottom, James Sent: 19 February 2013 23:29 To: Ivo Sedlacek; Dan Mongrain Cc: ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) I am okay with this, providing that the fallback order is clearly defined. That is, does an A3 fall back to an A2 or A1, or just back to sos? From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] Sent: Wednesday, 20 February 2013 7:32 AM To: Dan Mongrain Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org Subject: RE: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) Hello, If we go with RFC4119 based sub-services, would the IANA registration reque= st be as follows? - urn:service:sos.police.A3 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of a city, township, shi (JP). - urn:service:sos.police.country - The 'police.national' service refers to = the emergency service offered by the police department or other law enforce= ment authorities of the government of a country. Does anyone see any issue in that? If WG prefers this, it is OK for me. > In the latter case, so how do I get the county police (or state police, t= here can be up to 4 police services for a given location in the US). If I got it correctly, you propose that we also add - urn:service:sos.police.A2 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of county, parish, gun (JP), district (IN)" - urn:service:sos.police.A1 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of national subdivisions (state, region, provin= ce, prefecture)" While I have no problem with that, I am not aware of a regulation establish= ing such emergency service so I cannot argue to IANA that the RFC5031 polic= y is satisfied for those URNs. 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 21:12 To: Ivo Sedlacek Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) Thing is, when there is no city police, local would give you county police = (sheriff department) but in a city with a city police department local woul= d give you city police. In the latter case, so how do I get the county pol= ice (or state police, there can be up to 4 police services for a given loca= tion in the US). Note that these examples are US based, but we do have 3 l= evels of police services in Canada and I am sure other countries have the s= ame issue. There is also the terminology. There is no "national" police in the US or = Canada but there is a federal police. Keeping the RFC 4119 terminology rem= oves any "local" interpretation issues. Dan On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek > wrote: I agree with Richard - there are countries where both the emergency service= of the national police and the emergency service of the municipal police a= re offered in a given location. A user would call the municipal police emergency service to report e.g. pic= kpockets. A user would call the national police emergency service to report e.g. a mu= rder. I submitted to IANA a request to register: - urn:service:sos.police.local - The 'police.local' service refers to the e= mergency service offered by the police department or other law enforcement = authorities of the local or municipal authorities. - urn:service:sos.police.national - The 'police.national' service refers to= the emergency service offered by the police department or other law enforc= ement authorities of the national government. RFC5031 policy is hopefully fulfilled for them since they exist in two coun= tries. I am flexible whether the actual URNs contain the sub-services proposed abo= ve (i.e. .local and .national sub-services) or subservices based on RFC4119= (i.e. .A3 and .country sub-services). If the preference is for subservices based on RFC4119, do I need to make an= other IANA registration request or can we modify the URNs and their descrip= tion during the expert review? 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 15:36 To: Winterbottom, James Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos The problem is that different countries has different names for their polit= ical subdivisions. In the US they are states, in Canada they are provinces= , etc. Same when you further subdivide. While not privy to the discussion= s that came up with A1, A2, ..., A5, I have the feeling this nomenclature w= as picked for the same reason. Why not utilise the same naming scheme for = specifying the jurisdiction you want to reach? Thanx, Dan On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James > wrote: In that case, one might say state in the hierarchy, not A1. Cheers James From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Tuesday, 19 February 2013 8:57 AM To: Winterbottom, James Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos It might make sense if you wanted to allow the caller to explicitly select = police at a different level of responsibility, e.g., the state police rathe= r than the local police. On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James > wrote: I think I am missing something here, A1 is part of the location, so why doe= s it need to be in the URN at all? As far as I understand current deployments, they use the URN to select a la= yer in the GIS that corresponds to the service type, and then use geographi= c boundaries within that layer to select the final destination. From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Dan Mongrain Sent: Tuesday, 19 February 2013 7:30 AM To: Ivo Sedlacek Cc: ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos Sorry for responding late to this thread, it kinda fell into a crack... T= he current thread reminded me to check this old thread... You are indicating that we need to register 77 Service URN (11 service subt= ypes * 7 jurisdiction types based on RFC 4119). I do not recommend that we= create so many registrations. Instead, we should allow a service URN to b= e suffixed with a jurisdictional scope. So the following Service URN are a= ll valid: urn:service:sos.police urn:service:sos.police.traffic urn:service:sos.police.A1 urn:service:sos.police.traffic.A1 Question is, do we want to leave jurisdictional scope to only be applicable= to police branch or any Service URN? I'd say the latter as it is always u= p to the LoST service provisioning (based on local policy) to determine wha= t is locally acceptable. Thanx, Dan --_000_EDC0A1AE77C57744B664A310A0B23AE21070160C13FRMRSSXCHMBSC_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

My understanding of at least the real = life examples given so far is that the different police forces have different responsibilities. Therefore if the subtype is not understood one should go straight from sos.police.A2 to sos.police, rather than to A1.

 

Even if some country doesn’t fol= low this and does have hierarchical responsibilities, then it is going to confuse roaming users, in either direction.

 

Note that in general all countries nee= d to have a means of handling emergency calls without subtypes, so going straigh= t up to sos.police will still be handled.

 

Keith

 

From:= Winterbottom, James [mailto:James.Winterbottom@commscope.com]
Sent: 20 February 2013 00:29=
To: DRAGE, Keith (Keith); Iv= o Sedlacek; Dan Mongrain
Cc: ecrit@ietf.org
Subject: RE: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

 

I tend agree w= ith a lot of what you say here Keith .

 

My question wa= s, as you say, is this police service hierarchical, so should it be defined as urn:service:sos.police.A1.A2.A3?

 

I think that t= he need for a citizen to make this determination is not needed, and if it is t= he triage PSAP making the determination then it is out of scope for RFC5031.

 

Cheers

James

 

 

 

 

 

 

 

From:= DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]
Sent: Wednesday, 20 February= 2013 11:18 AM
To: Winterbottom, James; Ivo Sedlacek; Dan Mongrain
Cc: ecrit@ietf.org
Subject: RE: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

 

The answer to James’s question d= epends on how you code it (and also what you mean by fallback).

 

On any service URN, you ignore any subtypes from the point you stop understanding it.=

 

So if the coding is sos.police.A2, and= you do not understand A2, then the service URN would be handled as if it was sos.police, not as sos.police.A1. And if police was not understood then it would be handled as sos.

 

If you wanted something that went back= to the next larger regional coverage, then you would have to code successive subtypes in sequence.

 

But I would also ask for an element of sanity in this discussion, rather than total flexibility.=

 

For example while a national administration may have multiple levels of police force, not all of them ar= e either reachable directly as an emergency service provider, nor are they necessarily an emergency service provider. If they are neither of these, th= en they presumably do not need a special and distinct service URN. =

 

It would therefore nice to see a curre= nt use case that is anything but a choice of two, i.e. countrywide (following = the ITU-T E.164 definition of country) versus one= more local variant. This restricted model certainly covers Ivo’s examples = of Czeck Republic and Poland, and I beli= eve it also covers the other example I know of which is Italy.

 

While the USA has multiple levels of po= lice force, on the PSTN, it only appears to have one level of access to citizen = to authority emergency service, which is 911. I see no reason why a change to voice over IP would cause a change to this.

 

I would also stress that it is importa= nt to have global expectations of what you get when you use a service URN. If there is not care excercised with assigning semantics and values, A3 in one country could result in the forestry police and in another country the financial police responding.

 

Note that read the scope of RFC 5031 a= s being for end user accessing the emergency service. While it might be possi= ble to apply RFC 5031 to further network operations after the PSAP has been reached, e.g. to reach a subsidiary PSAP, I read that as outside the scope = of RFC 5031. Nor do I necessarily believe in that scenario that service URNs a= re necessarily the best solution for routeing, as the first PSAP should know t= he particular office they want to reach rather than just the type of emergency service.

 

Regards

 

Keith

 

From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] <= b>On Behalf Of Winterbottom, James
Sent: 19 February 2013 23:29=
To: Ivo Sedlacek; Dan Mongra= in
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

 

I am okay with= this, providing that the fallback order is clearly defined.

That is, does = an A3 fall back to an A2 or A1, or just back to sos?

 

 

 

From:= Ivo Sedlacek [mailto:ivo.sedla= cek@ericsson.com]
Sent: Wednesday, 20 February= 2013 7:32 AM
To: Dan Mongrain
Cc: Winterbottom, James; Ric= hard Barnes; ecrit@ietf.org
Subject: RE: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

 

Hello,

 

If we go with RF= C4119 based sub-services, would the IANA registration request be as follows?

 

- urn:service:sos.police.A3 <= /span>- The 'police.local' service refers to the emergency service offered by the police department or other law enforcement authorities of the authorities of a city, township, shi (JP)= .

- urn:service:sos.police.country&n= bsp;- The 'police.national' service refers to the emergency service offered by th= e police department or other law enforcement authorities of the government of a country.

 

Does anyone see = any issue in that?

 

If WG prefers th= is, it is OK for me.

 

> In the latter case, so how do I get the county police (or state police, there = can be up to 4 police services for a given location in the US).&nb= sp;

 

If I got it corr= ectly, you propose that we also add

- urn:service:sos.police.A2 - The 'police.local' service refers to the emergency service offered by the police department or other law enforcement authorities of the authorities of county, parish, gun (JP), district (IN)"<= /p>

- urn:service:sos.police.A1 - The 'police.local' service refers to the emergency service offered by the police department or other law enforcement authorities of the authorities of national subdivisions (state, region, province, prefecture)"<= /o:p>

 

While I have no problem with that, I am not aware of a regulation establishing such emergen= cy service so I cannot argue to IANA that the RFC5031 policy is satisfied for those URNs.

 

Kind regards

 

Ivo Sedlacek

 

 

 

 

This Communicatio= n is Confidential. We only send and receive email on the basis of the terms set = out at www.ericsson.com/email_d= isclaimer

From:= Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19. =FAnora 2013 21:12=
To: Ivo Sedlacek
Cc: Winterbottom, James; Ric= hard Barnes; ecrit@ietf.org
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

 

Thing is, when there is no city police, local would give you county police (sheri= ff department) but in a city with a city police department local would give yo= u city police.  In the latter case, so how do I get the county police (o= r state police, there can be up to 4 police services for a given location in = the US).&nb= sp; Note that these examples are US based, but we do have 3 levels of police service= s in Canada and I am sure other countries have the same issue.

 <= o:p>

Ther= e is also the terminology.  There is no "national" police in the US or Canada but there is a federal police.  Keeping the RFC 4119 terminology removes any "local"= ; interpretation issues.

Dan

On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek <ivo.sedlacek@er= icsson.com> wrote:

I agree with Richard - there are countries where both the emergency service of the national police and the emergency service of the municipal police are offered in a given location.

A user would call the municipal police emergency service to report e.g. pickpockets.

A user would call the national police emergency service to report e.g. a murder.=

 

 

I submitted to IANA a request to register:=

- urn:service:sos.police.local - The 'police.local' service refers to the emergency service offered by the polic= e department or other law enforcement authorities of the local or municipal authorities.

- urn:service:sos.police.national - The 'police.national' service refers to the emergency service offered by the po= lice department or other law enforcement authorities of the national government.=

 

RFC5031 policy is hopefully fulfilled for = them since they exist in two countries.

 

I am flexible whether the actual URNs cont= ain the sub-services proposed above (i.e. .local and .national sub-services) or subservices based on RFC4119 (i.e. .A3 and .country sub-services).

 

If the preference is for subservices based= on RFC4119, do I need to make another IANA registration request or can we modi= fy the URNs and their description during the expert review?

 

Kind regards

 

Ivo Sedlacek

 

This Communication is Confidential. We onl= y send and receive email on the basis of the terms set out at www.ericsson.com/email_d= isclaimer

From: Dan Mongrain [m= ailto:dan@mongrain.org] Sent: 19. =FAnora 2013 15:36=
To: Winterbottom, James
Cc: Richard Barnes; Ivo Sedl= acek; ecrit@ietf.org
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos=

 

The problem is that different countries = has different names for their political subdivisions.  In the US they are states, in Canada = they are provinces, etc.  Same when you further subdivide.  While not priv= y to the discussions that came up with A1, A2, …, A5, I have the feeling t= his nomenclature was picked for the same reason.  Why not utilise the same naming scheme for specifying the jurisdiction you want to reach?

 <= o:p>

Thanx,<= o:p>

Dan

 

On Mon, Feb= 18, 2013 at 5:01 PM, Wint= erbottom, James <James.Winterbottom@commscope.com> wrote:

In that case, one might say state in the hierarchy, not A1.

 <= o:p>

Cheers<= o:p>

James

 <= o:p>

 <= o:p>

From: Richard Barnes = [mailto:rlb@ipv.sx]
Sent: Tuesday, 19 February 2= 013 8:57 AM
To: Winterbottom, James
Cc: Dan Mongrain; Ivo Sedlac= ek; ecrit@ietf.org<= /font>


Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos=

 

It might make sense if you wanted to allow the caller to explicitly select pol= ice at a different level of responsibility, e.g., the state police rather than = the local police.  

 

On Mon, Feb= 18, 2013 at 4:21 PM, Wint= erbottom, James <James.Winterbottom@commscope.com> wrote:

I think I am missing something here, A1 = is part of the location, so why does it need to be in the URN at all?

As far as I understand current deploymen= ts, they use the URN to select a layer in the GIS<= /st1:stockticker> that corresponds to the service type, and then use geographic boundaries wi= thin that layer to select the final destination.

 <= o:p>

From: ecrit-bounces@ietf= .org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Dan Mongrain Sent: Tuesday, 19 February 2= 013 7:30 AM


To: Ivo Sedlacek
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos=

 

Sorry for responding late to this thread= , it kinda fell into a  crack…  The current thread reminded me t= o check this old thread…

 <= o:p>

You are indicating that we need to regis= ter 77 Service URN (11 service subtypes * 7 jurisdiction types based on RFC 4119).  I do not recommend that we create so many registrations.  Instead, we should allow a service URN to be suffixed with a jurisdictional scope.  So the following Service URN are all valid:

 <= o:p>

urn:service:sos.police

urn:service:sos.police.traffic

urn:service:sos.police.A1<= span lang=3DEN-US>

urn:service:sos.police.traffic.A1=

 <= o:p>

Question is, do we want to leave jurisdictional scope to only be applicable to police branch or any Service = URN?  I’d say the latter as it is always up to the LoST service provi= sioning (based on local policy) to determine what is locally acceptable.

 <= o:p>

Thanx,<= o:p>

Dan

 

 

--_000_EDC0A1AE77C57744B664A310A0B23AE21070160C13FRMRSSXCHMBSC_-- From dan@mongrain.org Tue Feb 19 19:38:37 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 393A221F8802 for ; Tue, 19 Feb 2013 19:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyN3KQ9MulbR for ; Tue, 19 Feb 2013 19:38:35 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5CA21F87B6 for ; Tue, 19 Feb 2013 19:38:35 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c10so9502851ieb.31 for ; Tue, 19 Feb 2013 19:38:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=irHTcKnScG40Bb+SrlDcn+JHEx4wjUL2XV/7H1Hq+Vw=; b=oWkivjBvScND40XvQzQVTuGpcstay8C+Tb+wHx+yG0FxwyEpqabLpwbiQO+mMiTK4X wnUqA2ZgecFjAXksobloKHMJEFRb0tcjnK23sn5/FDWxZwwmm5rWM9qzYGcTZg8axqYq jnflzLExD+bUHxA0r2AOhWU7wd1Nau1snuzrCYy1gSGldRQ2CuPaAKiZDGRSL4CTp1Zc rmLO8G1aZd8X0iMDOs49kEe3ZTNJ0VXUIqnylVB4RLvddtfm2VhvMnamL52RPlk9p71H LZXHW+kC4taZW2R1IoZetRgGdzdjlmgdq7kYxeds6LUPT54LQtWKBdT/66JU4f1LUDfk vX/Q== MIME-Version: 1.0 X-Received: by 10.42.98.76 with SMTP id r12mr8472688icn.10.1361331514923; Tue, 19 Feb 2013 19:38:34 -0800 (PST) Received: by 10.50.171.41 with HTTP; Tue, 19 Feb 2013 19:38:34 -0800 (PST) X-Originating-IP: [96.23.59.4] In-Reply-To: <39B5E4D390E9BD4890E2B3107900610109A6A7@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B3107900610109A5A8@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610109A6A7@ESESSMB301.ericsson.se> Date: Tue, 19 Feb 2013 22:38:34 -0500 Message-ID: From: Dan Mongrain To: Ivo Sedlacek Content-Type: multipart/alternative; boundary=90e6ba614a965e598c04d61fb1db X-Gm-Message-State: ALoCoQk8CsLkB2djDbiQtfq1+sO+7ckGwd2S/mTN55VRBGnRkflDZk+QcgjZ75O2r9F3MN9Sre5b Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 03:38:37 -0000 --90e6ba614a965e598c04d61fb1db Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I would not refer to .country, .A1, .A2, ..., .A5 as RFC4119 based sub-services but as Service URN jurisdictional qualifiers that can be appended to any valid Service URN that specifies a scope to be used for the search. The jurisdictional qualifiers are used for: .country for services at the country/national/federal/etc level .A1 for services at the state/province/region/prefecture/etc level .A2 for services at the county/parish/gun/district/etc level .A3 for services at the city/township/shi/etc level .A4 for services at the city division/borough/city district/ward/chou/etc level .A5 for services at the neighborhood/block/etc level Thanx, Dan On Tue, Feb 19, 2013 at 3:31 PM, Ivo Sedlacek wr= ote: > Hello,**** > > ** ** > > If we go with RFC4119 based sub-services, would the IANA registration > request be as follows?**** > > **** > > - urn:service:sos.police*.A3* - The 'police.local' service refers to the > emergency service offered by the police department or other law enforceme= nt > authorities of the authorities *of a city, township, shi (JP)*.**** > > - urn:service:sos.police*.country* - The 'police.national' service refers > to the emergency service offered by the police department or other law > enforcement authorities of the government *of a country*.**** > > ** ** > > Does anyone see any issue in that?**** > > ** ** > > If WG prefers this, it is OK for me.**** > > ** ** > > > In the latter case, so how do I get the county police (or state police, > there can be up to 4 police services for a given location in the US). **= * > * > > ** ** > > If I got it correctly, you propose that we also add **** > > - urn:service:sos.police*.A2* - The 'police.local' service refers to the > emergency service offered by the police department or other law enforceme= nt > authorities of the authorities *of county, parish, gun (JP), district (IN= ) > *"**** > > - urn:service:sos.police*.A1* - The 'police.local' service refers to the > emergency service offered by the police department or other law enforceme= nt > authorities of the authorities *of national subdivisions (state, region, > province, prefecture)*"**** > > ** ** > > While I have no problem with that, I am not aware of a regulation > establishing such emergency service so I cannot argue to IANA that the > RFC5031 policy is satisfied for those URNs.**** > > ** ** > > Kind regards**** > > ** ** > > Ivo Sedlacek**** > > ** ** > > ** ** > > ** ** > > ** ** > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out at www.ericsson.com/email_disclaimer **** > > *From:* Dan Mongrain [mailto:dan@mongrain.org] > *Sent:* 19. =FAnora 2013 21:12 > *To:* Ivo Sedlacek > *Cc:* Winterbottom, James; Richard Barnes; ecrit@ietf.org > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos (trimming due too large > message report)**** > > ** ** > > Thing is, when there is no city police, local would give you county polic= e > (sheriff department) but in a city with a city police department local > would give you city police. In the latter case, so how do I get the coun= ty > police (or state police, there can be up to 4 police services for a given > location in the US). Note that these examples are US based, but we do ha= ve > 3 levels of police services in Canada and I am sure other countries have > the same issue.**** > > **** > > There is also the terminology. There is no "national" police in the US o= r > Canada but there is a federal police. Keeping the RFC 4119 terminology > removes any "local" interpretation issues. > > Dan**** > > On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek > wrote:**** > > I agree with Richard - there are countries where both the emergency > service of the national police and the emergency service of the municipal > police are offered in a given location. **** > > A user would call the municipal police emergency service to report e.g. > pickpockets.**** > > A user would call the national police emergency service to report e.g. a > murder.**** > > **** > > **** > > I submitted to IANA a request to register:**** > > - urn:service:sos.police.local - The 'police.local' service refers to the > emergency service offered by the police department or other law enforceme= nt > authorities of the local or municipal authorities.**** > > - urn:service:sos.police.national - The 'police.national' service refers > to the emergency service offered by the police department or other law > enforcement authorities of the national government.**** > > **** > > RFC5031 policy is hopefully fulfilled for them since they exist in two > countries.**** > > **** > > I am flexible whether the actual URNs contain the sub-services proposed > above (i.e. .local and .national sub-services) or subservices based on > RFC4119 (i.e. .A3 and .country sub-services).**** > > **** > > If the preference is for subservices based on RFC4119, do I need to make > another IANA registration request or can we modify the URNs and their > description during the expert review?**** > > **** > > Kind regards**** > > **** > > Ivo Sedlacek**** > > **** > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out at www.ericsson.com/email_disclaimer **** > > *From:* Dan Mongrain [mailto:dan@mongrain.org] > *Sent:* 19. =FAnora 2013 15:36 > *To:* Winterbottom, James > *Cc:* Richard Barnes; Ivo Sedlacek; ecrit@ietf.org > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > **** > > The problem is that different countries has different names for their > political subdivisions. In the US they are states, in Canada they are > provinces, etc. Same when you further subdivide. While not privy to the > discussions that came up with A1, A2, =85, A5, I have the feeling this > nomenclature was picked for the same reason. Why not utilise the same > naming scheme for specifying the jurisdiction you want to reach?**** > > **** > > Thanx,**** > > Dan**** > > **** > > On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James < > James.Winterbottom@commscope.com> wrote:**** > > In that case, one might say state in the hierarchy, not A1.**** > > **** > > Cheers**** > > James**** > > **** > > **** > > *From:* Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* Tuesday, 19 February 2013 8:57 AM > *To:* Winterbottom, James > *Cc:* Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org**** > > > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > **** > > It might make sense if you wanted to allow the caller to explicitly selec= t > police at a different level of responsibility, e.g., the state police > rather than the local police. **** > > **** > > On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James < > James.Winterbottom@commscope.com> wrote:**** > > I think I am missing something here, A1 is part of the location, so why > does it need to be in the URN at all?**** > > As far as I understand current deployments, they use the URN to select a > layer in the GIS that corresponds to the service type, and then use > geographic boundaries within that layer to select the final destination.*= * > ** > > **** > > *From:* ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behalf > Of *Dan Mongrain > *Sent:* Tuesday, 19 February 2013 7:30 AM**** > > > *To:* Ivo Sedlacek > *Cc:* ecrit@ietf.org > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > **** > > Sorry for responding late to this thread, it kinda fell into a crack=85 > The current thread reminded me to check this old thread=85**** > > **** > > You are indicating that we need to register 77 Service URN (11 service > subtypes * 7 jurisdiction types based on RFC 4119). I do not recommend > that we create so many registrations. Instead, we should allow a service > URN to be suffixed with a jurisdictional scope. So the following Service > URN are all valid:**** > > **** > > urn:service:sos.police**** > > urn:service:sos.police.traffic**** > > urn:service:sos.police.A1**** > > urn:service:sos.police.traffic.A1**** > > **** > > Question is, do we want to leave jurisdictional scope to only be > applicable to police branch or any Service URN? I=92d say the latter as = it > is always up to the LoST service provisioning (based on local policy) to > determine what is locally acceptable.**** > > **** > > Thanx,**** > > Dan**** > > **** > > ** ** > --90e6ba614a965e598c04d61fb1db Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I would not refer to .country, .A1, .A2, ..., .A5 as RFC4119 based sub-serv= ices but as Service URN jurisdictional qualifiers that can be appended to a= ny valid Service URN that specifies a scope to be used for the search.=A0 T= he jurisdictional qualifiers are used for:

.country for services at the country/national/federal/etc level
.A1 for services at the state/province/region/prefecture/etc level
.A2 for services at the county/parish/gun/district/etc level
.A3 for services at the city/township/shi/etc level
.A4 for services at the city division/borough/city district/ward/chou/etc level
.A5 for services at the neighborhood/block/= etc level

Thanx,
Dan

On Tue, Feb 19, 2013= at 3:31 PM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:

Hello,=

=A0

If we go with RFC4119 based= sub-services, would the IANA registration request be as follows?=

=A0

- urn:service:sos.police= .A3=A0- The 'police.local' service refers to the e= mergency service offered by the police department or other law enforcement authorities of the authorities= =A0of a city, township, shi (JP).

- urn:service:sos.police= .country=A0- The 'police.national' service refers = to the emergency service offered by the police department or other law enforcement authorities of the governme= nt=A0of a country.

=A0

Does anyone see any issue i= n that?

=A0

If WG prefers this, it is O= K for me.

=A0

> In the latter case, so how do I get the county police (= or state police, there can be up to 4 police services for a given location = in the US).=A0

=A0

If I got it correctly= , you propose that we also add

- urn:service:sos.police= .A2 - The 'police.local' service refers to the emergency servic= e offered by the police department or other law enforcement authorities of the authorities=A0of county, parish, gun (JP), district= (IN)"

- urn:service:sos.police= .A1 - The 'police.local' service refers to the emergency servic= e offered by the police department or other law enforcement authorities of the authorities=A0of national subdivisions (state, regi= on, province, prefecture)"

=A0

While I have no problem wit= h that, I am not aware of a regulation establishing such emergency service = so I cannot argue to IANA that the RFC5031 policy is satisfied for those URNs.

=A0

Kind regards<= /span>

=A0

Ivo Sedlacek<= /span>

=A0

=A0

=A0

=A0

This Communication is Confid= ential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: Da= n Mongrain [mailto:da= n@mongrain.org]
Sent: 19. =FAnora 2013 21:12
To: Ivo Sedlacek
Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: Re: [Ecrit] What is the most appropriate method for registe= ring new sub-services of urn:service:sos (trimming due too large message re= port)

=A0

Thing is, when there is no city police,= local would give you county police (sheriff department) but in a city with a city police department local would give you city police.=A0 In the latte= r case, so how do I get the county police (or state police, there can be up= to 4 police services for a given location in the US).=A0 Note that these e= xamples are US based, but we do have 3 levels of police services in Canada and I am sure other countries have t= he same issue.

=A0<= /p>

There is also the ter= minology.=A0 There is no "national" police in the US or Canada bu= t there is a federal police.=A0 Keeping the RFC 4119 terminology removes an= y "local" interpretation issues.

Dan

On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek <ivo.sedlacek@e= ricsson.com> wrote:

I agree with Richard - ther= e are countries where both the emergency service of the national police and the emergency service of the municipal police are offered in a given l= ocation.

A user would call the munic= ipal police emergency service to report e.g. pickpockets.<= /u>

A user would call the natio= nal police emergency service to report e.g. a murder.<= /p>

=A0

=A0

I submitted to IANA a reque= st to register:

- urn:service:sos.police.lo= cal - The 'police.local' service refers to the emergency service of= fered by the police department or other law enforcement authorities of the local= or municipal authorities.

- urn:service:sos.police.na= tional - The 'police.national' service refers to the emergency serv= ice offered by the police department or other law enforcement authorities of the natio= nal government.

=A0

RFC5031 policy is hopefully= fulfilled for them since they exist in two countries.=

=A0

I am flexible whether the a= ctual URNs contain the sub-services proposed above (i.e. .local and .nation= al sub-services) or subservices based on RFC4119 (i.e. .A3 and .country sub-s= ervices).

=A0

If the preference is for su= bservices based on RFC4119, do I need to make another IANA registration request or can we modify the URNs and their description during the expert = review?

=A0

Kind regards<= u>

=A0

Ivo Sedlacek<= u>

=A0

This Communication is Confid= ential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: Dan Mong= rain [mailto:dan@mong= rain.org]
Sent: 19. =FAnora 2013 15:36
To: Winterbottom, James
Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org
Subject: Re: [Ecrit] What is the most appropriate method for registe= ring new sub-services of urn:service:sos

=A0

The problem is that diffe= rent countries has different names for their political subdivisions.=A0 In the US they are states, in Canada they are provinces, etc.=A0 Same when yo= u further subdivide.=A0 While not privy to the discussions that came up wit= h A1, A2, =85, A5, I have the feeling this nomenclature was picked for the = same reason.=A0 Why not utilise the same naming scheme for specifying the jurisdiction you want to reach?=

=A0<= /p>

Thanx,

Dan<= /p>

=A0

On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James= <= James.Winterbottom@commscope.com> wrote:

In that case, one might s= ay state in the hierarchy, not A1.

=A0<= /p>

Cheers

James

=A0<= /p>

=A0<= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Tuesday, 19 February 2013 8:57 AM
To: Winterbottom, James
Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org


Subject: Re: [Ecrit] What is the most appropriate method for registe= ring new sub-services of urn:service:sos

=A0

It might make sense if you wanted to allow the calle= r to explicitly select police at a different level of responsibility, e.g.,= the state police rather than the local police. =A0

=A0

On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James= <= James.Winterbottom@commscope.com> wrote:

I think I am missing some= thing here, A1 is part of the location, so why does it need to be in the URN at all?

As far as I understand cu= rrent deployments, they use the URN to select a layer in the GIS that corre= sponds to the service type, and then use geographic boundaries within that layer = to select the final destination.

=A0<= /p>

From: ecrit-bounces@i= etf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Dan Mongrain
Sent: Tuesday, 19 February 2013 7:30 AM


To: Ivo Sedlacek
Cc: ecrit@ietf.o= rg
Subject: Re: [Ecrit] What is the most appropriate method for registe= ring new sub-services of urn:service:sos

=A0

Sorry for responding late= to this thread, it kinda fell into a=A0 crack=85=A0 The current thread rem= inded me to check this old thread=85

=A0<= /p>

You are indicating that w= e need to register 77 Service URN (11 service subtypes * 7 jurisdiction types based on RFC 4119).=A0 I do not recommend that we create so many reg= istrations.=A0 Instead, we should allow a service URN to be suffixed with a= jurisdictional scope.=A0 So the following Service URN are all valid:

=A0<= /p>

urn:service:sos.police

urn:service:sos.police.tr= affic

urn:service:sos.police.A1=

urn:service:sos.police.tr= affic.A1

=A0<= /p>

Question is, do we want t= o leave jurisdictional scope to only be applicable to police branch or any Service URN? =A0I=92d say the latter as it is always up to the LoST servic= e provisioning (based on local policy) to determine what is locally accepta= ble.

=A0<= /p>

Thanx,

Dan<= /p>

=A0

=A0


--90e6ba614a965e598c04d61fb1db-- From James.Winterbottom@commscope.com Tue Feb 19 19:42:28 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA45421F880B for ; Tue, 19 Feb 2013 19:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMAxneeOTYC9 for ; Tue, 19 Feb 2013 19:42:23 -0800 (PST) Received: from cdcsmgw02.commscope.com (cdcsmgw02.commscope.com [198.135.207.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1307521F8803 for ; Tue, 19 Feb 2013 19:42:22 -0800 (PST) X-AuditID: 0a0404e9-b7f396d00000367a-d9-5124461efcae Received: from CDCE10HC1.commscope.com ( [10.86.28.21]) by cdcsmgw02.commscope.com (Symantec Messaging Gateway) with SMTP id 15.51.13946.E1644215; Tue, 19 Feb 2013 21:42:22 -0600 (CST) Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC1.commscope.com (10.86.28.21) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 19 Feb 2013 21:42:21 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 20 Feb 2013 11:42:20 +0800 From: "Winterbottom, James" To: Dan Mongrain , Ivo Sedlacek Date: Wed, 20 Feb 2013 11:42:18 +0800 Thread-Topic: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) Thread-Index: Ac4PG8UwGP7nc9T6SQiJXf5kToIarQAAExSw Message-ID: <5A55A45AE77F5941B18E5457ECAC8188012140771339@SISPE7MB1.commscope.com> References: <39B5E4D390E9BD4890E2B3107900610109A5A8@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610109A6A7@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC8188012140771339SISPE7MB1co_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0gUURzFuTOz67g5cV21vZlYrArSoplGGJWIvfwStBHR44Ouu5O7sg+b UVNB8VFJhmW+slVqzcemqGtl5quwFYmMSJHSNtEwyxcFBVorrTTjpPntd+85/3Pmz1wSlzpF vqTOmEIzRpVeLpYQktN+PiH+RwOVYa0dnpGT1ZeJyNz7X0SRRY13RZHlNw5GE7HLi+/EsXV1 Tiy29KGZiJ3t2HGCOCc5oKH1ujSa2RUVL9FaFobw5Oe9WHrTRBeRA9qrsULgTiK4B5mtTjeB t6ChCZu4EEhIKewG6GPtS1w4tAFkuV626pJCG0BLpWd4FsMo1G8bw3n2hsfRg8oREc84jEFd rorVewIGocc/PxB8kBesAOiP04zxB294G6D6Fw6xMB2OFhyTBM8UPIl6nA1AqK7CUM/czKrg DpVovL0I8Ay4j/012IwJdTLkmL73byGI6nrf4gL7oLnPKyLB74PGC2xA8JvQtaUrbkKZJ3p1 Z5oQVgtBeV2LomIgM2+INW8YMW8YEe5D0Vh5mVhgBWqoWcAFDkGVK3Zi470FuDUBmVqjZg2J l8LCQ9Umg4FVm5Jpnh4B/k8TxFwneNOmsANIArkHlVMToJSKVGlshsEOtpKY3IeyHg5USjcn mDQZWhWrjWNS9TRrB4jE5d5UfgynURpVRibNmNakYJKEr6cnB4EvYTQZaTmiZvkIT4ZOpNMv 6PTcQ1uzYqQ7H+XBRbl4D8UmqwysLlHQB4GCtLyfmgVkvnVmFkhX43xlVMARzgp5qzbVuJ42 D2TcCl6UH696cO95PWeeq8C4ihZrAF+Rovov+eaAgFLouBnf16E1dm83JlT9CFpuHlOPFfe0 KBxPk6OD/HWu/ikLo3C66vc1RjTe2vbMevaTLC77YvDvr2LwfW9JbfbAcGu7LkROjCpz3UcH xoPy5g8Nx2inZ065+ryeNO0/D491RhRkZWbVrOi/JSaNgKtMElXSynTXbkqyGePkBKtV7d6J M6zqL2V/HAuMAwAA Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 03:42:28 -0000 --_000_5A55A45AE77F5941B18E5457ECAC8188012140771339SISPE7MB1co_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dan, To be clear then, if you ask for urn:service:sos:police.A4 and it doesn't e= xist but A3 does, too bad you go straight to urn:service:sos:police ? Cheers James From: Dan Mongrain [mailto:dan@mongrain.org] Sent: Wednesday, 20 February 2013 2:39 PM To: Ivo Sedlacek Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) I would not refer to .country, .A1, .A2, ..., .A5 as RFC4119 based sub-serv= ices but as Service URN jurisdictional qualifiers that can be appended to a= ny valid Service URN that specifies a scope to be used for the search. The= jurisdictional qualifiers are used for: .country for services at the country/national/federal/etc level .A1 for services at the state/province/region/prefecture/etc level .A2 for services at the county/parish/gun/district/etc level .A3 for services at the city/township/shi/etc level .A4 for services at the city division/borough/city district/ward/chou/etc l= evel .A5 for services at the neighborhood/block/etc level Thanx, Dan On Tue, Feb 19, 2013 at 3:31 PM, Ivo Sedlacek > wrote: Hello, If we go with RFC4119 based sub-services, would the IANA registration reque= st be as follows? - urn:service:sos.police.A3 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of a city, township, shi (JP). - urn:service:sos.police.country - The 'police.national' service refers to = the emergency service offered by the police department or other law enforce= ment authorities of the government of a country. Does anyone see any issue in that? If WG prefers this, it is OK for me. > In the latter case, so how do I get the county police (or state police, t= here can be up to 4 police services for a given location in the US). If I got it correctly, you propose that we also add - urn:service:sos.police.A2 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of county, parish, gun (JP), district (IN)" - urn:service:sos.police.A1 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of national subdivisions (state, region, provin= ce, prefecture)" While I have no problem with that, I am not aware of a regulation establish= ing such emergency service so I cannot argue to IANA that the RFC5031 polic= y is satisfied for those URNs. 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 21:12 To: Ivo Sedlacek Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) Thing is, when there is no city police, local would give you county police = (sheriff department) but in a city with a city police department local woul= d give you city police. In the latter case, so how do I get the county pol= ice (or state police, there can be up to 4 police services for a given loca= tion in the US). Note that these examples are US based, but we do have 3 l= evels of police services in Canada and I am sure other countries have the s= ame issue. There is also the terminology. There is no "national" police in the US or = Canada but there is a federal police. Keeping the RFC 4119 terminology rem= oves any "local" interpretation issues. Dan On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek > wrote: I agree with Richard - there are countries where both the emergency service= of the national police and the emergency service of the municipal police a= re offered in a given location. A user would call the municipal police emergency service to report e.g. pic= kpockets. A user would call the national police emergency service to report e.g. a mu= rder. I submitted to IANA a request to register: - urn:service:sos.police.local - The 'police.local' service refers to the e= mergency service offered by the police department or other law enforcement = authorities of the local or municipal authorities. - urn:service:sos.police.national - The 'police.national' service refers to= the emergency service offered by the police department or other law enforc= ement authorities of the national government. RFC5031 policy is hopefully fulfilled for them since they exist in two coun= tries. I am flexible whether the actual URNs contain the sub-services proposed abo= ve (i.e. .local and .national sub-services) or subservices based on RFC4119= (i.e. .A3 and .country sub-services). If the preference is for subservices based on RFC4119, do I need to make an= other IANA registration request or can we modify the URNs and their descrip= tion during the expert review? 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 15:36 To: Winterbottom, James Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos The problem is that different countries has different names for their polit= ical subdivisions. In the US they are states, in Canada they are provinces= , etc. Same when you further subdivide. While not privy to the discussion= s that came up with A1, A2, ..., A5, I have the feeling this nomenclature w= as picked for the same reason. Why not utilise the same naming scheme for = specifying the jurisdiction you want to reach? Thanx, Dan On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James > wrote: In that case, one might say state in the hierarchy, not A1. Cheers James From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Tuesday, 19 February 2013 8:57 AM To: Winterbottom, James Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos It might make sense if you wanted to allow the caller to explicitly select = police at a different level of responsibility, e.g., the state police rathe= r than the local police. On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James > wrote: I think I am missing something here, A1 is part of the location, so why doe= s it need to be in the URN at all? As far as I understand current deployments, they use the URN to select a la= yer in the GIS that corresponds to the service type, and then use geographi= c boundaries within that layer to select the final destination. From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Dan Mongrain Sent: Tuesday, 19 February 2013 7:30 AM To: Ivo Sedlacek Cc: ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos Sorry for responding late to this thread, it kinda fell into a crack... T= he current thread reminded me to check this old thread... You are indicating that we need to register 77 Service URN (11 service subt= ypes * 7 jurisdiction types based on RFC 4119). I do not recommend that we= create so many registrations. Instead, we should allow a service URN to b= e suffixed with a jurisdictional scope. So the following Service URN are a= ll valid: urn:service:sos.police urn:service:sos.police.traffic urn:service:sos.police.A1 urn:service:sos.police.traffic.A1 Question is, do we want to leave jurisdictional scope to only be applicable= to police branch or any Service URN? I'd say the latter as it is always u= p to the LoST service provisioning (based on local policy) to determine wha= t is locally acceptable. Thanx, Dan --_000_5A55A45AE77F5941B18E5457ECAC8188012140771339SISPE7MB1co_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Dan,

 

To be clear then, if you ask for urn:service:s= os:police.A4 and it doesn’t exist but A3 does, too bad you go straigh= t to urn:service:sos:police ?

 

 

Cheers

James

 

From: Dan Mongra= in [mailto:dan@mongrain.org]
Sent: Wednesday, 20 February 2013 2= :39 PM
To: Ivo Sedlacek
Cc: Winterbottom, James; Richar= d Barnes; ecrit@ietf.org
Subject: Re: [Ecrit] What is the most ap= propriate method for registering new sub-services of urn:service:sos (trimm= ing due too large message report)

 

I would not refer to .country, .A1, .A2, ..., .A5 as RFC4119 based sub= -services but as Service URN jurisdictional qualifiers that can be appended= to any valid Service URN that specifies a scope to be used for the search.=   The jurisdictional qualifiers are used for:

.country for services at the country/nation= al/federal/etc level
.A1 for services at the state/province/region/prefe= cture/etc level
.A2 for services at the county/parish/gun/district/etc l= evel
.A3 for services at the city/township/shi/etc level
.A4 for serv= ices at the city division/borough/city district/ward/chou/etc level
.A5 = for services at the neighborhood/block/etc level

Thanx,
D= an

On Tue, Feb 19, 2013 at 3:31 PM,= Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:

Hello,

 

If we go with RFC4119 based sub-services, would the IANA regis= tration request be as follows?

 

- urn:service:sos.police.A3 - The = 'police.local' service refers to the emergency service offered by the polic= e department or other law enforcement authorities of the authorities <= u>of a city, township, shi (JP).

- urn= :service:sos.police.country - The 'police.national' service ref= ers to the emergency service offered by the police department or other law = enforcement authorities of the government of a country.<= o:p>

 

Does anyo= ne see any issue in that?

 <= o:p>

If WG prefers this, it is OK for me.<= /o:p>

 

> In t= he latter case, so how do I get the county police (or state police, there c= an be up to 4 police services for a given location in the US). 

 

I= f I got it correctly, you propose that we also add

- urn:service:sos.police.A2 - The 'police.local' service r= efers to the emergency service offered by the police department or other la= w enforcement authorities of the authorities of county, parish, gun= (JP), district (IN)"

- urn:servi= ce:sos.police.A1 - The 'police.local' service refers to the emergenc= y service offered by the police department or other law enforcement authori= ties of the authorities of national subdivisions (state, region, pr= ovince, prefecture)"

 

While I have no problem with that, I am not awa= re of a regulation establishing such emergency service so I cannot argue to= IANA that the RFC5031 policy is satisfied for those URNs.

 

Kind regards<= /span>

 

Iv= o Sedlacek

 

 

 

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#C050= 4D'> 

This Communication is Confidenti= al. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_discla= imer

From: Dan Mongrain [mailto:dan@mongrain.org]
<= b>Sent: 19. =FAnora 2013 21:12
To: Ivo Sedlacek
Cc:= Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: Re: [Ecrit] What is th= e most appropriate method for registering new sub-services of urn:service:s= os (trimming due too large message report)

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'> 

Thing is, when there is no city police, local wo= uld give you county police (sheriff department) but in a city with a city p= olice department local would give you city police.  In the latter case= , so how do I get the county police (or state police, there can be up to 4 = police services for a given location in the US).  Note that these exam= ples are US based, but we do have 3 levels of police services in Canada and= I am sure other countries have the same issue.

 

There is also the terminology.  T= here is no "national" police in the US or Canada but there is a f= ederal police.  Keeping the RFC 4119 terminology removes any "loc= al" interpretation issues.

Dan

On Tue= , Feb 19, 2013 at 2:31 PM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:

I agree with Richard - there are countrie= s where both the emergency service of the national police and the emergency= service of the municipal police are offered in a given location.

A user would call the municipal police emergency s= ervice to report e.g. pickpockets.

A user= would call the national police emergency service to report e.g. a murder.<= /span>

 

&n= bsp;

I submitted to IANA a request to regi= ster:

- urn:service:sos.police.local - The= 'police.local' service refers to the emergency service offered by the poli= ce department or other law enforcement authorities of the local or municipa= l authorities.

- urn:service:sos.police.na= tional - The 'police.national' service refers to the emergency service offe= red by the police department or other law enforcement authorities of the na= tional government.

 

RFC5031 policy is hopefully fulfilled for them since they = exist in two countries.

 =

I am flexible whether the actual URNs contain the sub= -services proposed above (i.e. .local and .national sub-services) or subser= vices based on RFC4119 (i.e. .A3 and .country sub-services).

 

If the prefere= nce is for subservices based on RFC4119, do I need to make another IANA reg= istration request or can we modify the URNs and their description during th= e expert review?

 <= /p>

Kind regards

 <= o:p>

Ivo Sedlacek

&nb= sp;

This Communication is Confidential. We = only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer =

From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19.= =FAnora 2013 15:36
To: Winterbottom, James
Cc: Richard= Barnes; Ivo Sedlacek; = ecrit@ietf.org
Subject: Re: [Ecrit] What is the most appropri= ate method for registering new sub-services of urn:service:sos<= /o:p>

 

The problem is that diff= erent countries has different names for their political subdivisions. = In the US they are states, in Canada they are provinces, etc.  Same w= hen you further subdivide.  While not privy to the discussions that ca= me up with A1, A2, …, A5, I have the feeling this nomenclature was pi= cked for the same reason.  Why not utilise the same naming scheme for = specifying the jurisdiction you want to reach?

=  

Thanx,

Dan

 

= On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James <James.Winterbottom@comm= scope.com> wrote:

In that case= , one might say state in the hierarchy, not A1.

 

Cheers<= /p>

James

 

 

From: Ri= chard Barnes [mailto:rlb@ip= v.sx]
Sent: Tuesday, 19 February 2013 8:57 AM
To: = Winterbottom, James
Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org=


Subject: Re: [Ecrit] What is the most appro= priate method for registering new sub-services of urn:service:sos

 

I= t might make sense if you wanted to allow the caller to explicitly select p= olice at a different level of responsibility, e.g., the state police rather= than the local police.  

 <= /p>

On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James <James.Wi= nterbottom@commscope.com> wrote:

I think I am missing something here, A1 is part of the location, so why = does it need to be in the URN at all?

As= far as I understand current deployments, they use the URN to select a laye= r in the GIS that corresponds to the service type, and then use geographic = boundaries within that layer to select the final destination.

 

From: ecrit-bounces@ietf.o= rg [mailto:= ecrit-bounces@ietf.org] On Behalf Of Dan Mongrain
Sent: Tuesday, 19 February 2013 7:30 AM

<= br>To: Ivo Sedlacek
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:servic= e:sos

 

Sorry for responding late to this thread, it kinda fell int= o a  crack…  The current thread reminded me to check this o= ld thread…

 

You are indicating that we need to register 77 Service U= RN (11 service subtypes * 7 jurisdiction types based on RFC 4119).  I = do not recommend that we create so many registrations.  Instead, we sh= ould allow a service URN to be suffixed with a jurisdictional scope.  = So the following Service URN are all valid:

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

urn:service:sos.police

urn:service:sos.police.traffic

urn:service:sos.police.A1

urn:service:sos.police.traffic.A1

 

Question is, do we want to leav= e jurisdictional scope to only be applicable to police branch or any Servic= e URN?  I’d say the latter as it is always up to the LoST servic= e provisioning (based on local policy) to determine what is locally accepta= ble.

 

= Thanx,

Dan

<= /div>

&= nbsp;

 

 

= --_000_5A55A45AE77F5941B18E5457ECAC8188012140771339SISPE7MB1co_-- From dan@mongrain.org Tue Feb 19 20:22:52 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFE321F8881 for ; Tue, 19 Feb 2013 20:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.125 X-Spam-Level: X-Spam-Status: No, score=-0.125 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MrZA2hm4UGC for ; Tue, 19 Feb 2013 20:22:50 -0800 (PST) Received: from mail-ia0-x22f.google.com (ia-in-x022f.1e100.net [IPv6:2607:f8b0:4001:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 837AF21F886B for ; Tue, 19 Feb 2013 20:22:50 -0800 (PST) Received: by mail-ia0-f175.google.com with SMTP id r4so6723305iaj.20 for ; Tue, 19 Feb 2013 20:22:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=WGO4+D9xh1Myq4mq8/zHSs1zt5l6Q7zQTlb3qpr8W0c=; b=S8yGsYO4/79USmSPAMZR1FJ2IgbJ47X2nSXNtfOyOCXTzTjGZ//j4e4NomYYUpVgMg MjmWjnqGyGOvFLh3W5zcvLpGrAFbOijWDoKR+FoHERLe/zVvM+YQ1ERP56oH0yhfXWTX bg1VzO2PXQ9hRay5+V8uuEUMpmgMCEnp5sYoBuJix8GWUcufjdnL4/KT9CwGtpHYQd4x A6+CwzkrdmUgZiQygyH9qHgTX8Ckr9Lp4/xW03y0elIg0olwDxKJdIic0jH8feeJpP8Y yw2GqNRW69hqZ6q4wEpZTAa7fsd0oRe5I2PjOOVRze4g1niGcQZtAMsuby+ipSv2H10N Sbjw== MIME-Version: 1.0 X-Received: by 10.50.181.134 with SMTP id dw6mr9566585igc.68.1361334169980; Tue, 19 Feb 2013 20:22:49 -0800 (PST) Received: by 10.50.171.41 with HTTP; Tue, 19 Feb 2013 20:22:49 -0800 (PST) X-Originating-IP: [96.23.59.4] In-Reply-To: References: <39B5E4D390E9BD4890E2B3107900610109A5A8@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610109A6A7@ESESSMB301.ericsson.se> <5A55A45AE77F5941B18E5457ECAC81880121407712CD@SISPE7MB1.commscope.com> Date: Tue, 19 Feb 2013 23:22:49 -0500 Message-ID: From: Dan Mongrain To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=14dae9340fc39f4ebe04d6204f2f X-Gm-Message-State: ALoCoQkiaAc8ANDYR2eIZhgu/Uz5IWeOhyt63fHyS7BJW25Au8poAnr2r1YNPI5BFkdF+/3bfkXI Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 04:22:52 -0000 --14dae9340fc39f4ebe04d6204f2f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable My recommendation for handling unknown Service URN depends if LoST service implements jurisdictional scope or not. If it does not, it pops the last element and evaluates until a service is found. If it implements jurisdictional scope, the last element is a jurisdictional scope and it is not found, then you return the next highest level defined. While it may be true that citizens typically dial 9-1-1 to request for help, police services such as state or provincial polices advertises numbers to call them directly (star code to dial using a mobile phone for example) especially to report accidents on freeways. We need an equivalent Service URN. Also while RFC5031's scope is citizen to authorities (I am not sure I agree with this) I do not want to re-invent the wheel to signal calls within an Emergency Services IP Network (ESInet). When I transfer a call from one PSAP to another, the mechanism to determine where to send the call is the same, using LoST. For a PSAP that covers a large area spanning multiple counties and the calltaker needs to transfer the call to the appropriate sheriff department for the caller's location, they only need a single transfer target (urn:service:sos.police.A2). It is not true that the calltaker always knows the actual destination of the call, especially when the calltaker is only a call screener. Thanx, Dan On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > ** ** ** ** ** ** ** > > The answer to James=92s question depends on how you code it (and also wha= t > you mean by fallback).**** > > ** ** > > On any service URN, you ignore any subtypes from the point you stop > understanding it.**** > > ** ** > > So if the coding is sos.police.A2, and you do not understand A2, then the > service URN would be handled as if it was sos.police, not as sos.police.A= 1. > And if police was not understood then it would be handled as sos.**** > > ** ** > > If you wanted something that went back to the next larger regional > coverage, then you would have to code successive subtypes in sequence.***= * > > ** ** > > But I would also ask for an element of sanity in this discussion, rather > than total flexibility.**** > > ** ** > > For example while a national administration may have multiple levels of > police force, not all of them are either reachable directly as an emergen= cy > service provider, nor are they necessarily an emergency service provider. > If they are neither of these, then they presumably do not need a special > and distinct service URN. **** > > ** ** > > It would therefore nice to see a current use case that is anything but a > choice of two, i.e. countrywide (following the **ITU**-T E.164 definition > of country) versus one more local variant. This restricted model certainl= y > covers Ivo=92s examples of **Czeck** **Republic** and **Poland**, and I > believe it also covers the other example I know of which is ****Italy****= . > **** > > ** ** > > While the ****USA**** has multiple levels of police force, on the PSTN, > it only appears to have one level of access to citizen to authority > emergency service, which is 911. I see no reason why a change to voice ov= er > IP would cause a change to this.**** > > ** ** > > I would also stress that it is important to have global expectations of > what you get when you use a service URN. If there is not care excercised > with assigning semantics and values, A3 in one country could result in th= e > forestry police and in another country the financial police responding.**= * > * > > ** ** > > Note that read the scope of RFC 5031 as being for end user accessing the > emergency service. While it might be possible to apply RFC 5031 to furthe= r > network operations after the PSAP has been reached, e.g. to reach a > subsidiary PSAP, I read that as outside the scope of RFC 5031. Nor do I > necessarily believe in that scenario that service URNs are necessarily th= e > best solution for routeing, as the first PSAP should know the particular > office they want to reach rather than just the type of emergency service.= * > *** > > ** ** > > Regards**** > > ** ** > > Keith**** > > ** ** > ------------------------------ > > *From:* ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behalf > Of *Winterbottom, James > *Sent:* 19 February 2013 23:29 > *To:* Ivo Sedlacek; Dan Mongrain > *Cc:* ecrit@ietf.org > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos (trimming due too large > message report)**** > > ** ** > > I am okay with this, providing that the fallback order is clearly defined= . > **** > > That is, does an A3 fall back to an A2 or A1, or just back to sos?**** > > ** ** > > ** ** > > ** ** > > *From:* Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] > *Sent:* Wednesday, 20 February 2013 **7:32 AM** > *To:* Dan Mongrain > *Cc:* Winterbottom, James; Richard Barnes; ecrit@ietf.org > *Subject:* RE: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos (trimming due too large > message report)**** > > ** ** > > Hello,**** > > ** ** > > If we go with RFC4119 based sub-services, would the IANA registration > request be as follows?**** > > **** > > - urn:service:sos.police*.A3* - The 'police.local' service refers to the > emergency service offered by the police department or other law enforceme= nt > authorities of the authorities *of a city, township, shi (JP)*.**** > > - urn:service:sos.police*.country* - The 'police.national' service refers > to the emergency service offered by the police department or other law > enforcement authorities of the government *of a country*.**** > > ** ** > > Does anyone see any issue in that?**** > > ** ** > > If WG prefers this, it is OK for me.**** > > ** ** > > > In the latter case, so how do I get the county police (or state police, > there can be up to 4 police services for a given location in the ****US**= * > *). **** > > ** ** > > If I got it correctly, you propose that we also add **** > > - urn:service:sos.police*.A2* - The 'police.local' service refers to the > emergency service offered by the police department or other law enforceme= nt > authorities of the authorities *of county, parish, gun (JP), district (IN= ) > *"**** > > - urn:service:sos.police*.A1* - The 'police.local' service refers to the > emergency service offered by the police department or other law enforceme= nt > authorities of the authorities *of national subdivisions (state, region, > province, prefecture)*"**** > > ** ** > > While I have no problem with that, I am not aware of a regulation > establishing such emergency service so I cannot argue to IANA that the > RFC5031 policy is satisfied for those URNs.**** > > ** ** > > Kind regards**** > > ** ** > > Ivo Sedlacek**** > > ** ** > > ** ** > > ** ** > > ** ** > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out at www.ericsson.com/email_disclaimer **** > > *From:* Dan Mongrain [mailto:dan@mongrain.org ] > *Sent:* 19. =FAnora 2013 21:12 > *To:* Ivo Sedlacek > *Cc:* Winterbottom, James; Richard Barnes; ecrit@ietf.org > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos (trimming due too large > message report)**** > > ** ** > > Thing is, when there is no city police, local would give you county polic= e > (sheriff department) but in a city with a city police department local > would give you city police. In the latter case, so how do I get the coun= ty > police (or state police, there can be up to 4 police services for a given > location in the ****US****). Note that these examples are US based, but > we do have 3 levels of police services in ****Canada**** and I am sure > other countries have the same issue.**** > > **** > > There is also the terminology. There is no "national" police in the **US= * > * or ****Canada**** but there is a federal police. Keeping the RFC 4119 > terminology removes any "local" interpretation issues. > > Dan**** > > On Tue, **Feb 19, 2013** at **2:31 PM**, Ivo Sedlacek < > ivo.sedlacek@ericsson.com> wrote:**** > > I agree with Richard - there are countries where both the emergency > service of the national police and the emergency service of the municipal > police are offered in a given location. **** > > A user would call the municipal police emergency service to report e.g. > pickpockets.**** > > A user would call the national police emergency service to report e.g. a > murder.**** > > **** > > **** > > I submitted to IANA a request to register:**** > > - urn:service:sos.police.local - The 'police.local' service refers to the > emergency service offered by the police department or other law enforceme= nt > authorities of the local or municipal authorities.**** > > - urn:service:sos.police.national - The 'police.national' service refers > to the emergency service offered by the police department or other law > enforcement authorities of the national government.**** > > **** > > RFC5031 policy is hopefully fulfilled for them since they exist in two > countries.**** > > **** > > I am flexible whether the actual URNs contain the sub-services proposed > above (i.e. .local and .national sub-services) or subservices based on > RFC4119 (i.e. .A3 and .country sub-services).**** > > **** > > If the preference is for subservices based on RFC4119, do I need to make > another IANA registration request or can we modify the URNs and their > description during the expert review?**** > > **** > > Kind regards**** > > **** > > Ivo Sedlacek**** > > **** > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out at www.ericsson.com/email_disclaimer **** > > *From:* Dan Mongrain [mailto:dan@mongrain.org] > *Sent:* 19. =FAnora 2013 15:36 > *To:* Winterbottom, James > *Cc:* Richard Barnes; Ivo Sedlacek; ecrit@ietf.org > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > **** > > The problem is that different countries has different names for their > political subdivisions. In the **US** they are states, in ****Canada****= they are provinces, etc. Same when you further subdivide. While not privy > to the discussions that came up with A1, A2, =85, A5, I have the feeling = this > nomenclature was picked for the same reason. Why not utilise the same > naming scheme for specifying the jurisdiction you want to reach?**** > > **** > > Thanx,**** > > Dan**** > > **** > > On Mon, **Feb 18, 2013** at **5:01 PM**, Winterbottom, James < > James.Winterbottom@commscope.com> wrote:**** > > In that case, one might say state in the hierarchy, not A1.**** > > **** > > Cheers**** > > James**** > > **** > > **** > > *From:* Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* Tuesday, 19 February 2013 **8:57 AM** > *To:* Winterbottom, James > *Cc:* Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org**** > > > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > **** > > It might make sense if you wanted to allow the caller to explicitly selec= t > police at a different level of responsibility, e.g., the state police > rather than the local police. **** > > **** > > On Mon, **Feb 18, 2013** at **4:21 PM**, Winterbottom, James < > James.Winterbottom@commscope.com> wrote:**** > > I think I am missing something here, A1 is part of the location, so why > does it need to be in the URN at all?**** > > As far as I understand current deployments, they use the URN to select a > layer in the **GIS** that corresponds to the service type, and then use > geographic boundaries within that layer to select the final destination.*= * > ** > > **** > > *From:* ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behalf > Of *Dan Mongrain > *Sent:* Tuesday, 19 February 2013 **7:30 AM****** > > > *To:* Ivo Sedlacek > *Cc:* ecrit@ietf.org > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > **** > > Sorry for responding late to this thread, it kinda fell into a crack=85 > The current thread reminded me to check this old thread=85**** > > **** > > You are indicating that we need to register 77 Service URN (11 service > subtypes * 7 jurisdiction types based on RFC 4119). I do not recommend > that we create so many registrations. Instead, we should allow a service > URN to be suffixed with a jurisdictional scope. So the following Service > URN are all valid:**** > > **** > > urn:service:sos.police**** > > urn:service:sos.police.traffic**** > > urn:service:sos.police.A1**** > > urn:service:sos.police.traffic.A1**** > > **** > > Question is, do we want to leave jurisdictional scope to only be > applicable to police branch or any Service URN? I=92d say the latter as = it > is always up to the LoST service provisioning (based on local policy) to > determine what is locally acceptable.**** > > **** > > Thanx,**** > > Dan**** > > **** > > ** ** > --14dae9340fc39f4ebe04d6204f2f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable My recommendation for handling unknown Service URN depends if LoST service = implements jurisdictional scope or not.=A0 If it does not, it pops the last= element and evaluates until a service is found.=A0 If it implements jurisd= ictional scope, the last element is a jurisdictional scope and it is not fo= und, then you return the next highest level defined.

While it may be true that citizens typically dial 9-1-1 to request for = help, police services such as state or provincial polices advertises number= s to call them directly (star code to dial using a mobile phone for example= ) especially to report accidents on freeways.=A0 We need an equivalent Serv= ice URN.

Also while RFC5031's scope is citizen to authorities (I am not sure= I agree with this) I do not want to re-invent the wheel to signal calls wi= thin an Emergency Services IP Network (ESInet).=A0 When I transfer a call f= rom one PSAP to another, the mechanism to determine where to send the call = is the same, using LoST.=A0 For a PSAP that covers a large area spanning mu= ltiple counties and the calltaker needs to transfer the call to the appropr= iate sheriff department for the caller's location, they only need a sin= gle transfer target (urn:service:sos.police.A2).=A0 It is not true that the= calltaker always knows the actual destination of the call, especially when= the calltaker is only a call screener.

Thanx,
Dan


--14dae9340fc39f4ebe04d6204f2f-- From James.Winterbottom@commscope.com Tue Feb 19 20:30:11 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5127A21F883A for ; Tue, 19 Feb 2013 20:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rkb11I7nf-Ij for ; Tue, 19 Feb 2013 20:30:04 -0800 (PST) Received: from cdcsmgw01.commscope.com (cdcsmgw01.commscope.com [198.135.207.232]) by ietfa.amsl.com (Postfix) with ESMTP id B621321F886A for ; Tue, 19 Feb 2013 20:30:03 -0800 (PST) X-AuditID: 0a0404e8-b7fa46d000004284-bb-51245145cd81 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw01.commscope.com (Symantec Messaging Gateway) with SMTP id 7D.13.17028.54154215; Tue, 19 Feb 2013 22:29:58 -0600 (CST) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 19 Feb 2013 22:30:01 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 20 Feb 2013 12:29:59 +0800 From: "Winterbottom, James" To: Dan Mongrain , "DRAGE, Keith (Keith)" Date: Wed, 20 Feb 2013 12:29:57 +0800 Thread-Topic: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) Thread-Index: Ac4PIfPVTZaqVVxuQN6Lj2Xg304NeAAAIC/g Message-ID: <5A55A45AE77F5941B18E5457ECAC8188012140771351@SISPE7MB1.commscope.com> References: <39B5E4D390E9BD4890E2B3107900610109A5A8@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610109A6A7@ESESSMB301.ericsson.se> <5A55A45AE77F5941B18E5457ECAC81880121407712CD@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC8188012140771351SISPE7MB1co_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA01Sa0hTURz33Me8G7txndqOI6SmgSlOjYgFYmqR80PmCgIL09t2dYLbbNc3 Zb6GYGlhaSmRpuaj8oGR2AtJv9SklDBdKtrDt36IykxR6d5dNb/9zv/3On/OIVDZCq4gkkyp jMVEJytFEkxy1i3B/4TWWxvY1ChVT9wrxNR5tVO4uqT5Pq6eynsPQjGNdfo1rlld+iTS1Nev IJrZzr3R2DlJsJ5JTkpnLAEh8RJD2aIdpDweQjPzW7qRXGCrR4uBmIDUIVhbYncW8G44MN4m 4rGMegng3GhKMZBwuB3AicVBXDi0Avh2qsvhEFEhsLfN7khyoy5A29dpDhMESmlh53o2P8ao /bBs+LrD60pVALi2UoXwBzfqDoAP34yIBPNBOJZXiPGYpE7DP+XWzbYXKCxcmAE8IeZSe6+t OtoAd9dl2xOExyglhyOT1YiwAwXrX/Vv7uYO575v4ILeHY4VtQFBb4ZLhQ2oUOYC31VOYsLO /jD/+RJ+E8irdsRW7bBU7bAIcxW0l98WCdgPNjxYQAXsD+9u9GA75zXA+RGQ6/Q61piYERik 0pmNRlZnTmF41AH4l8aw2S7Q1+7XAygCKKWkT7WXVobT6WyWsQd4EIjSnYyN8tbKdl0067MM NGuIs6QlM2wPgASqdCMLwjmO1NNZ2YzFvEX5EATVNzlhAwrMZDYxSkiqozmZi4VJZDITkpK5 j7YlRQgxHyXloiJ5Dcmm0EY2KVHgbcCPqBn6NguIgsaZWSBzxCnk5NNTnJTipYY003baPJBz K7iSfnyQlPvP2znzXAXCVbQ0evEVqfR/SpELoEdvdauva2BcS97EeuXJ0I6FL7/3iCMyI6Jq 8MvNMxWaKeqvp2fYkYHmeCb26OGfHjdU9sjYQWnGx2PB3THWS3pdeypz/IMTaf11Jszp/NrV 8FvqNKQ9xrran1Nnt+8TqxUH1FdGS4tM484qmoKlAcOqstHI5c8/njXVReeYlRhroIN8UQtL /wNLcCWNjAMAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 04:30:11 -0000 --_000_5A55A45AE77F5941B18E5457ECAC8188012140771351SISPE7MB1co_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am sorry, I am finding this confusing. RFC5139 puts a hierarchy on A1 through A6. If you want this hierarchy to wo= rk then A1 through A6 can't be at the same level if you expect A3 to fallba= ck to A2 or A1 in the case of a service not existing or a service failure o= f some kind. If they exist at the same level then if A3 doesn't exist you w= ill go to urn:service:sos.police unless you impose the hierarchy in the ur= n. From: Dan Mongrain [mailto:dan@mongrain.org] Sent: Wednesday, 20 February 2013 3:23 PM To: DRAGE, Keith (Keith) Cc: Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) My recommendation for handling unknown Service URN depends if LoST service = implements jurisdictional scope or not. If it does not, it pops the last e= lement and evaluates until a service is found. If it implements jurisdicti= onal scope, the last element is a jurisdictional scope and it is not found,= then you return the next highest level defined. While it may be true that citizens typically dial 9-1-1 to request for help= , police services such as state or provincial polices advertises numbers to= call them directly (star code to dial using a mobile phone for example) es= pecially to report accidents on freeways. We need an equivalent Service UR= N. Also while RFC5031's scope is citizen to authorities (I am not sure I agree= with this) I do not want to re-invent the wheel to signal calls within an = Emergency Services IP Network (ESInet). When I transfer a call from one PS= AP to another, the mechanism to determine where to send the call is the sam= e, using LoST. For a PSAP that covers a large area spanning multiple count= ies and the calltaker needs to transfer the call to the appropriate sheriff= department for the caller's location, they only need a single transfer tar= get (urn:service:sos.police.A2). It is not true that the calltaker always = knows the actual destination of the call, especially when the calltaker is = only a call screener. Thanx, Dan On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) > wrote: The answer to James's question depends on how you code it (and also what yo= u mean by fallback). On any service URN, you ignore any subtypes from the point you stop underst= anding it. So if the coding is sos.police.A2, and you do not understand A2, then the s= ervice URN would be handled as if it was sos.police, not as sos.police.A1. = And if police was not understood then it would be handled as sos. If you wanted something that went back to the next larger regional coverage= , then you would have to code successive subtypes in sequence. But I would also ask for an element of sanity in this discussion, rather th= an total flexibility. For example while a national administration may have multiple levels of pol= ice force, not all of them are either reachable directly as an emergency se= rvice provider, nor are they necessarily an emergency service provider. If = they are neither of these, then they presumably do not need a special and d= istinct service URN. It would therefore nice to see a current use case that is anything but a ch= oice of two, i.e. countrywide (following the ITU-T E.164 definition of coun= try) versus one more local variant. This restricted model certainly covers = Ivo's examples of Czeck Republic and Poland, and I believe it also covers t= he other example I know of which is Italy. While the USA has multiple levels of police force, on the PSTN, it only app= ears to have one level of access to citizen to authority emergency service,= which is 911. I see no reason why a change to voice over IP would cause a = change to this. I would also stress that it is important to have global expectations of wha= t you get when you use a service URN. If there is not care excercised with = assigning semantics and values, A3 in one country could result in the fores= try police and in another country the financial police responding. Note that read the scope of RFC 5031 as being for end user accessing the em= ergency service. While it might be possible to apply RFC 5031 to further ne= twork operations after the PSAP has been reached, e.g. to reach a subsidiar= y PSAP, I read that as outside the scope of RFC 5031. Nor do I necessarily = believe in that scenario that service URNs are necessarily the best solutio= n for routeing, as the first PSAP should know the particular office they wa= nt to reach rather than just the type of emergency service. Regards Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Winterbottom, = James Sent: 19 February 2013 23:29 To: Ivo Sedlacek; Dan Mongrain Cc: ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) I am okay with this, providing that the fallback order is clearly defined. That is, does an A3 fall back to an A2 or A1, or just back to sos? From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] Sent: Wednesday, 20 February 2013 7:32 AM To: Dan Mongrain Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org Subject: RE: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) Hello, If we go with RFC4119 based sub-services, would the IANA registration reque= st be as follows? - urn:service:sos.police.A3 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of a city, township, shi (JP). - urn:service:sos.police.country - The 'police.national' service refers to = the emergency service offered by the police department or other law enforce= ment authorities of the government of a country. Does anyone see any issue in that? If WG prefers this, it is OK for me. > In the latter case, so how do I get the county police (or state police, t= here can be up to 4 police services for a given location in the US). If I got it correctly, you propose that we also add - urn:service:sos.police.A2 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of county, parish, gun (JP), district (IN)" - urn:service:sos.police.A1 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of national subdivisions (state, region, provin= ce, prefecture)" While I have no problem with that, I am not aware of a regulation establish= ing such emergency service so I cannot argue to IANA that the RFC5031 polic= y is satisfied for those URNs. 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 21:12 To: Ivo Sedlacek Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) Thing is, when there is no city police, local would give you county police = (sheriff department) but in a city with a city police department local woul= d give you city police. In the latter case, so how do I get the county pol= ice (or state police, there can be up to 4 police services for a given loca= tion in the US). Note that these examples are US based, but we do have 3 l= evels of police services in Canada and I am sure other countries have the s= ame issue. There is also the terminology. There is no "national" police in the US or = Canada but there is a federal police. Keeping the RFC 4119 terminology rem= oves any "local" interpretation issues. Dan On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek > wrote: I agree with Richard - there are countries where both the emergency service= of the national police and the emergency service of the municipal police a= re offered in a given location. A user would call the municipal police emergency service to report e.g. pic= kpockets. A user would call the national police emergency service to report e.g. a mu= rder. I submitted to IANA a request to register: - urn:service:sos.police.local - The 'police.local' service refers to the e= mergency service offered by the police department or other law enforcement = authorities of the local or municipal authorities. - urn:service:sos.police.national - The 'police.national' service refers to= the emergency service offered by the police department or other law enforc= ement authorities of the national government. RFC5031 policy is hopefully fulfilled for them since they exist in two coun= tries. I am flexible whether the actual URNs contain the sub-services proposed abo= ve (i.e. .local and .national sub-services) or subservices based on RFC4119= (i.e. .A3 and .country sub-services). If the preference is for subservices based on RFC4119, do I need to make an= other IANA registration request or can we modify the URNs and their descrip= tion during the expert review? 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 15:36 To: Winterbottom, James Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos The problem is that different countries has different names for their polit= ical subdivisions. In the US they are states, in Canada they are provinces= , etc. Same when you further subdivide. While not privy to the discussion= s that came up with A1, A2, ..., A5, I have the feeling this nomenclature w= as picked for the same reason. Why not utilise the same naming scheme for = specifying the jurisdiction you want to reach? Thanx, Dan On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James > wrote: In that case, one might say state in the hierarchy, not A1. Cheers James From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Tuesday, 19 February 2013 8:57 AM To: Winterbottom, James Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos It might make sense if you wanted to allow the caller to explicitly select = police at a different level of responsibility, e.g., the state police rathe= r than the local police. On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James > wrote: I think I am missing something here, A1 is part of the location, so why doe= s it need to be in the URN at all? As far as I understand current deployments, they use the URN to select a la= yer in the GIS that corresponds to the service type, and then use geographi= c boundaries within that layer to select the final destination. From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Dan Mongrain Sent: Tuesday, 19 February 2013 7:30 AM To: Ivo Sedlacek Cc: ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos Sorry for responding late to this thread, it kinda fell into a crack... T= he current thread reminded me to check this old thread... You are indicating that we need to register 77 Service URN (11 service subt= ypes * 7 jurisdiction types based on RFC 4119). I do not recommend that we= create so many registrations. Instead, we should allow a service URN to b= e suffixed with a jurisdictional scope. So the following Service URN are a= ll valid: urn:service:sos.police urn:service:sos.police.traffic urn:service:sos.police.A1 urn:service:sos.police.traffic.A1 Question is, do we want to leave jurisdictional scope to only be applicable= to police branch or any Service URN? I'd say the latter as it is always u= p to the LoST service provisioning (based on local policy) to determine wha= t is locally acceptable. Thanx, Dan --_000_5A55A45AE77F5941B18E5457ECAC8188012140771351SISPE7MB1co_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I am sorr= y, I am finding this confusing.

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

RFC5139 puts = a hierarchy on A1 through A6. If you want this hierarchy to work then A1 th= rough A6 can’t be at the same level if you expect A3 to fallback to A= 2 or A1 in the case of a service not existing or a service failure of some = kind. If they exist at the same level then if A3 doesn’t exist you wi= ll go to urn:service:sos.police=A0 unless you impose the hierarchy in the u= rn.

 

 

 

 

 

From: Dan Mongrain [mailto:dan@mongrain.or= g]
Sent: Wednesday, 20 February 2013 3:23 PM
To: DRAGE= , Keith (Keith)
Cc: Winterbottom, James; Ivo Sedlacek; ecrit@ietf= .org
Subject: Re: [Ecrit] What is the most appropriate method for= registering new sub-services of urn:service:sos (trimming due too large me= ssage report)

 

My recommendati= on for handling unknown Service URN depends if LoST service implements juri= sdictional scope or not.  If it does not, it pops the last element and= evaluates until a service is found.  If it implements jurisdictional = scope, the last element is a jurisdictional scope and it is not found, then= you return the next highest level defined.

While it may be true tha= t citizens typically dial 9-1-1 to request for help, police services such a= s state or provincial polices advertises numbers to call them directly (sta= r code to dial using a mobile phone for example) especially to report accid= ents on freeways.  We need an equivalent Service URN.

Also whil= e RFC5031's scope is citizen to authorities (I am not sure I agree with thi= s) I do not want to re-invent the wheel to signal calls within an Emergency= Services IP Network (ESInet).  When I transfer a call from one PSAP t= o another, the mechanism to determine where to send the call is the same, u= sing LoST.  For a PSAP that covers a large area spanning multiple coun= ties and the calltaker needs to transfer the call to the appropriate sherif= f department for the caller's location, they only need a single transfer ta= rget (urn:service:sos.police.A2).  It is not true that the calltaker a= lways knows the actual destination of the call, especially when the calltak= er is only a call screener.

Thanx,
Dan

On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) <keith.drag= e@alcatel-lucent.com> wrote:

The answer to James’s question depends on how you code it (and= also what you mean by fallback).

 

On any service URN, you ignore any subtypes fr= om the point you stop understanding it.

 

So if the coding is sos.police.A2, and y= ou do not understand A2, then the service URN would be handled as if it was= sos.police, not as sos.police.A1. And if police was not understood then it= would be handled as sos.

 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>If you wanted something that went back to the next lar= ger regional coverage, then you would have to code successive subtypes in s= equence.

 

But I would also ask for an element of sanity in this discussion, rat= her than total flexibility.

=

 

For example while a national administration may have= multiple levels of police force, not all of them are either reachable dire= ctly as an emergency service provider, nor are they necessarily an emergenc= y service provider. If they are neither of these, then they presumably do n= ot need a special and distinct service URN. =

 

It would therefore nice to see a cu= rrent use case that is anything but a choice of two, i.e. countrywide (foll= owing the ITU-T E.164 definition of country) versus one more local variant.= This restricted model certainly covers Ivo’s examples of Czeck Repub= lic and Poland, and I believe it also covers the other example I know of wh= ich is Italy.

 

While the USA has multiple levels of police force, on the PSTN, it= only appears to have one level of access to citizen to authority emergency= service, which is 911. I see no reason why a change to voice over IP would= cause a change to this.

 

I would also stress that it is important to have global= expectations of what you get when you use a service URN. If there is not c= are excercised with assigning semantics and values, A3 in one country could= result in the forestry police and in another country the financial police = responding.

 

Note that read the scope of RFC 5031 as being for end user accessing= the emergency service. While it might be possible to apply RFC 5031 to fur= ther network operations after the PSAP has been reached, e.g. to reach a su= bsidiary PSAP, I read that as outside the scope of RFC 5031. Nor do I neces= sarily believe in that scenario that service URNs are necessarily the best = solution for routeing, as the first PSAP should know the particular office = they want to reach rather than just the type of emergency service.

 <= span lang=3DEN-GB>

Regards

 

Keith

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Be= half Of Winterbottom, James
Sent: 19 February 2013 23:29
<= b>To: Ivo Sedlacek; Dan Mongrain
Cc: ecrit@ietf.org
Subject: Re: [Ecri= t] What is the most appropriate method for registering new sub-services of = urn:service:sos (trimming due too large message report)

 

I am okay with this, providing that the fallback= order is clearly defined.

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>That is, does an A3 fall back to an A2 or A1, or just back to = sos?

 

 

 

From: Ivo Sedlacek [mail= to:ivo.sedla= cek@ericsson.com]
Sent: Wednesday, 20 February 2013 7:32 AM<= br>To: Dan Mongrain
Cc: Winterbottom, James; Richard Barne= s; ecrit@ietf.orgSubject: RE: [Ecrit] What is the most appropriate method for regis= tering new sub-services of urn:service:sos (trimming due too large message = report)

&= nbsp;

Hello,

 

If we go with RFC4119 based sub-ser= vices, would the IANA registration request be as follows?

 =

- urn:service:sos.police.A3 -= The 'police.local' service refers to the emergency service offered by the = police department or other law enforcement authorities of the authorities&n= bsp;of a city, township, shi (JP).

- urn:service:sos.police.country - Th= e 'police.national' service refers to the emergency service offered by the = police department or other law enforcement authorities of the government&nb= sp;of a country.

 

D= oes anyone see any issue in that?

 

If WG prefers this, it is OK for me.

 

> In the latter case, so how do I get the county po= lice (or state police, there can be up to 4 police services for a given loc= ation in the US). 

 

= If I got it correctly, you propose that we also add

- urn:service:sos.police.A2 - T= he 'police.local' service refers to the emergency service offered by the po= lice department or other law enforcement authorities of the authorities&nbs= p;of county, parish, gun (JP), district (IN)"

- urn:service:sos.police.A1 - The 'police.local' service refers to the emergency service offered by = the police department or other law enforcement authorities of the authoriti= es of national subdivisions (state, region, province, prefecture)"

 =

While I have n= o problem with that, I am not aware of a regulation establishing such emerg= ency service so I cannot argue to IANA that the RFC5031 policy is satisfied= for those URNs.

 

Kind r= egards

 

Ivo Sedlacek

 

 

 <= /p>

 

This Communication is Confidential. We only send and receive email on = the basis of the terms set out at www.ericsson.com/email_disclaimer =

From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19. =FAn= ora 2013 21:12
To: Ivo Sedlacek
Cc: Winterbottom, James= ; Richard Barnes; ecrit= @ietf.org
Subject: Re: [Ecrit] What is the most appropriate m= ethod for registering new sub-services of urn:service:sos (trimming due too= large message report)

 

Thing is, when there is no= city police, local would give you county police (sheriff department) but i= n a city with a city police department local would give you city police.&nb= sp; In the latter case, so how do I get the county police (or state police,= there can be up to 4 police services for a given location in the US). = ; Note that these examples are US based, but we do have 3 levels of police = services in Canada and I am sure other countries have the same issue.

 

There is also the terminology.  Th= ere is no "national" police in the US or Canada but there is a fe= deral police.  Keeping the RFC 4119 terminology removes any "loca= l" interpretation issues.

Dan

On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek <ivo.sedlacek@erics= son.com> wrote:

I agree with Richard - there are countries where both the emergen= cy service of the national police and the emergency service of the municipa= l police are offered in a given location.

A user would call the municipal police emergency= service to report e.g. pickpockets.

A user would call the national police emergency servic= e to report e.g. a murder.

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'> 

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#C050= 4D'> 

I sub= mitted to IANA a request to register:<= /span>

- urn:service:sos.police.local - The 'police.local' s= ervice refers to the emergency service offered by the police department or = other law enforcement authorities of the local or municipal authorities.

- urn:service:sos.= police.national - The 'police.national' service refers to the emergency ser= vice offered by the police department or other law enforcement authorities = of the national government.

=

 

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#C050= 4D'>RFC5031 policy is hopefully fulfilled for them since they exist in two = countries.

 = ;

I am flexible = whether the actual URNs contain the sub-services proposed above (i.e. .loca= l and .national sub-services) or subservices based on RFC4119 (i.e. .A3 and= .country sub-services).

 

= If the preference is for subservices based on RFC4119, do I need to make an= other IANA registration request or can we modify the URNs and their descrip= tion during the expert review?<= /p>

 

Kind regards

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#C050= 4D'> 

Ivo S= edlacek

 =

This Communicat= ion is Confidential. We only send and receive email on the basis of the ter= ms set out at www.ericsson= .com/email_disclaimer

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19. =FAnora 2013 15:36To: Winterbottom, James
Cc: Richard Barnes; Ivo Sedlacek= ; ecrit@ietf.orgSubject: Re: [Ecrit] What is the most appropriate method for regist= ering new sub-services of urn:service:sos

 

= The problem is that different countries has different names for thei= r political subdivisions.  In the US they are states, in Canada they a= re provinces, etc.  Same when you further subdivide.  While not p= rivy to the discussions that came up with A1, A2, …, A5, I have the f= eeling this nomenclature was picked for the same reason.  Why not util= ise the same naming scheme for specifying the jurisdiction you want to reac= h?

 

Thanx,

Dan

 

<= div>

On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James <James.Winter= bottom@commscope.com> wrote:

In that case, one might say state in the hierarchy= , not A1.

&nbs= p;

Cheers

James

 

 <= o:p>

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Tuesd= ay, 19 February 2013 8:57 AM
To: Winterbottom, James
Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org


Subject: Re: [Ecrit] What is the most appropriate= method for registering new sub-services of urn:service:sos

 

It might make sense if you want= ed to allow the caller to explicitly select police at a different level of = responsibility, e.g., the state police rather than the local police.  =

 

On Mon, Feb 18, 2013 at 4:21 PM, Winte= rbottom, James <James.Winterbottom@commscope.com> wrote:

I think I am missing som= ething here, A1 is part of the location, so why does it need to be in the U= RN at all?

As = far as I understand current deployments, they use the URN to select a layer= in the GIS that corresponds to the service type, and then use geographic b= oundaries within that layer to select the final destination.

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On Behalf Of Dan Mongrain
Sent: Tuesday, 19 February= 2013 7:30 AM


To: Ivo Sedlacek
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] Wha= t is the most appropriate method for registering new sub-services of urn:se= rvice:sos

 

Sorr= y for responding late to this thread, it kinda fell into a  crack̷= 0;  The current thread reminded me to check this old thread…

 

You are indicating that = we need to register 77 Service URN (11 service subtypes * 7 jurisdiction ty= pes based on RFC 4119).  I do not recommend that we create so many reg= istrations.  Instead, we should allow a service URN to be suffixed wit= h a jurisdictional scope.  So the following Service URN are all valid:=

 

urn:service:sos.pol= ice

urn:servic= e:sos.police.traffic

= urn:service:sos.police.A1

urn:service:sos.police.traffic.A1

 

Question is, do we want to leave jurisdicti= onal scope to only be applicable to police branch or any Service URN?  = ;I’d say the latter as it is always up to the LoST service provisioni= ng (based on local policy) to determine what is locally acceptable.<= span lang=3DEN-GB>

 

Thanx,

Dan<= /o:p>

 

 

 

= --_000_5A55A45AE77F5941B18E5457ECAC8188012140771351SISPE7MB1co_-- From dan@mongrain.org Tue Feb 19 20:55:38 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC7E21F8830 for ; Tue, 19 Feb 2013 20:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.025 X-Spam-Level: X-Spam-Status: No, score=0.025 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-HbTZ5eDl6a for ; Tue, 19 Feb 2013 20:55:36 -0800 (PST) Received: from mail-ia0-x22a.google.com (mail-ia0-x22a.google.com [IPv6:2607:f8b0:4001:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 188EB21F880F for ; Tue, 19 Feb 2013 20:55:35 -0800 (PST) Received: by mail-ia0-f170.google.com with SMTP id k20so6889118iak.15 for ; Tue, 19 Feb 2013 20:55:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=zLrPSeiVoLuAkEnCS6hNDJj23GpKTUinYivKtkdCsoU=; b=ckhLqmvDViUw3UgrChPRnwRioGnJ6Pnz/zB//62IvUIl1V9MtQZ/vz9rHCFQ2khsPP oP0I07Chgip5+S1neI6gHC1+Z58WT+jpuRa8M9aZItganCAlktvE1gYugpHMjynXJcyN YuizyxfovZn5XiThjD+V4NcFLkf7u/qfqmehtU1sqhSwEs9fBMLwPGK3kL0ctXxKE70J XKZ/211jpg65c8h0DJCHqnS8bhHm0tGtOFSU1UacB7bagwN0nxYalD4g3CZT/4QlN83v ZyaKA99E2uCtAROosoad1CAlxnIkr4AN4H/gTSsfYc3LKqrmuM13NhBC+Cgb8r/MwdHn 8PEQ== MIME-Version: 1.0 X-Received: by 10.50.237.71 with SMTP id va7mr5827202igc.88.1361336135255; Tue, 19 Feb 2013 20:55:35 -0800 (PST) Received: by 10.50.171.41 with HTTP; Tue, 19 Feb 2013 20:55:35 -0800 (PST) X-Originating-IP: [96.23.59.4] In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188012140771351@SISPE7MB1.commscope.com> References: <39B5E4D390E9BD4890E2B3107900610109A5A8@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610109A6A7@ESESSMB301.ericsson.se> <5A55A45AE77F5941B18E5457ECAC81880121407712CD@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC8188012140771351@SISPE7MB1.commscope.com> Date: Tue, 19 Feb 2013 23:55:35 -0500 Message-ID: From: Dan Mongrain To: "Winterbottom, James" Content-Type: multipart/alternative; boundary=f46d0447a243c306f304d620c454 X-Gm-Message-State: ALoCoQmFZj58EhPkSmIaRoFKV8avWpbqLEwiokWC0ElD972WX2cxmq37gj8VJMHnBfCmRmNQIiM4 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 04:55:38 -0000 --f46d0447a243c306f304d620c454 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable What I meant is that if a jurisdictional scope aware LoST service receives a request for urn:service:sos.police.A4 and nothing is configured, it looks for urn:service:sos.police.A3 then urn:service:sos.police.A2, etc. until it finds a configured service. If nothing is found for urn:service:sos.police.country then it pops the last element and looks for urn:service:sos.police (but then again, it is no longer jurisdictional scope aware). I disagree that one needs to formulate the request as urn:service:sos.police.country.A1.A2.A3.A4 in order for this to happen. There must be only a single jurisdictional scope appended to a Service URN. I do not think we need a .A6 jurisdictional scope (street level). .A5 (neighborhood, would point to a precinct for example) provides enough granularity in my opinion. Thanx, Dan On Tue, Feb 19, 2013 at 11:29 PM, Winterbottom, James < James.Winterbottom@commscope.com> wrote: > I am sorry, I am finding this confusing.**** > > ** ** > > RFC5139 puts a hierarchy on A1 through A6. If you want this hierarchy to > work then A1 through A6 can=92t be at the same level if you expect A3 to > fallback to A2 or A1 in the case of a service not existing or a service > failure of some kind. If they exist at the same level then if A3 doesn=92= t > exist you will go to urn:service:sos.police unless you impose the > hierarchy in the urn.**** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > *From:* Dan Mongrain [mailto:dan@mongrain.org] > *Sent:* Wednesday, 20 February 2013 3:23 PM > *To:* DRAGE, Keith (Keith) > *Cc:* Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos (trimming due too large > message report)**** > > ** ** > > My recommendation for handling unknown Service URN depends if LoST servic= e > implements jurisdictional scope or not. If it does not, it pops the last > element and evaluates until a service is found. If it implements > jurisdictional scope, the last element is a jurisdictional scope and it i= s > not found, then you return the next highest level defined. > > While it may be true that citizens typically dial 9-1-1 to request for > help, police services such as state or provincial polices advertises > numbers to call them directly (star code to dial using a mobile phone for > example) especially to report accidents on freeways. We need an equivale= nt > Service URN. > > Also while RFC5031's scope is citizen to authorities (I am not sure I > agree with this) I do not want to re-invent the wheel to signal calls > within an Emergency Services IP Network (ESInet). When I transfer a call > from one PSAP to another, the mechanism to determine where to send the ca= ll > is the same, using LoST. For a PSAP that covers a large area spanning > multiple counties and the calltaker needs to transfer the call to the > appropriate sheriff department for the caller's location, they only need = a > single transfer target (urn:service:sos.police.A2). It is not true that > the calltaker always knows the actual destination of the call, especially > when the calltaker is only a call screener. > > Thanx, > Dan**** > > On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) < > keith.drage@alcatel-lucent.com> wrote:**** > > The answer to James=92s question depends on how you code it (and also wha= t > you mean by fallback).**** > > **** > > On any service URN, you ignore any subtypes from the point you stop > understanding it.**** > > **** > > So if the coding is sos.police.A2, and you do not understand A2, then the > service URN would be handled as if it was sos.police, not as sos.police.A= 1. > And if police was not understood then it would be handled as sos.**** > > **** > > If you wanted something that went back to the next larger regional > coverage, then you would have to code successive subtypes in sequence.***= * > > **** > > But I would also ask for an element of sanity in this discussion, rather > than total flexibility.**** > > **** > > For example while a national administration may have multiple levels of > police force, not all of them are either reachable directly as an emergen= cy > service provider, nor are they necessarily an emergency service provider. > If they are neither of these, then they presumably do not need a special > and distinct service URN. **** > > **** > > It would therefore nice to see a current use case that is anything but a > choice of two, i.e. countrywide (following the ITU-T E.164 definition of > country) versus one more local variant. This restricted model certainly > covers Ivo=92s examples of Czeck Republic and Poland, and I believe it al= so > covers the other example I know of which is Italy.**** > > **** > > While the USA has multiple levels of police force, on the PSTN, it only > appears to have one level of access to citizen to authority emergency > service, which is 911. I see no reason why a change to voice over IP woul= d > cause a change to this.**** > > **** > > I would also stress that it is important to have global expectations of > what you get when you use a service URN. If there is not care excercised > with assigning semantics and values, A3 in one country could result in th= e > forestry police and in another country the financial police responding.**= * > * > > **** > > Note that read the scope of RFC 5031 as being for end user accessing the > emergency service. While it might be possible to apply RFC 5031 to furthe= r > network operations after the PSAP has been reached, e.g. to reach a > subsidiary PSAP, I read that as outside the scope of RFC 5031. Nor do I > necessarily believe in that scenario that service URNs are necessarily th= e > best solution for routeing, as the first PSAP should know the particular > office they want to reach rather than just the type of emergency service.= * > *** > > **** > > Regards**** > > **** > > Keith**** > > **** > ------------------------------ > > *From:* ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behalf > Of *Winterbottom, James > *Sent:* 19 February 2013 23:29 > *To:* Ivo Sedlacek; Dan Mongrain > *Cc:* ecrit@ietf.org > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos (trimming due too large > message report)**** > > **** > > I am okay with this, providing that the fallback order is clearly defined= . > **** > > That is, does an A3 fall back to an A2 or A1, or just back to sos?**** > > **** > > **** > > **** > > *From:* Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] > *Sent:* Wednesday, 20 February 2013 7:32 AM > *To:* Dan Mongrain > *Cc:* Winterbottom, James; Richard Barnes; ecrit@ietf.org > *Subject:* RE: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos (trimming due too large > message report)**** > > **** > > Hello,**** > > **** > > If we go with RFC4119 based sub-services, would the IANA registration > request be as follows?**** > > **** > > - urn:service:sos.police*.A3* - The 'police.local' service refers to the > emergency service offered by the police department or other law enforceme= nt > authorities of the authorities *of a city, township, shi (JP)*.**** > > - urn:service:sos.police*.country* - The 'police.national' service refers > to the emergency service offered by the police department or other law > enforcement authorities of the government *of a country*.**** > > **** > > Does anyone see any issue in that?**** > > **** > > If WG prefers this, it is OK for me.**** > > **** > > > In the latter case, so how do I get the county police (or state police, > there can be up to 4 police services for a given location in the US). **= * > * > > **** > > If I got it correctly, you propose that we also add **** > > - urn:service:sos.police*.A2* - The 'police.local' service refers to the > emergency service offered by the police department or other law enforceme= nt > authorities of the authorities *of county, parish, gun (JP), district (IN= ) > *"**** > > - urn:service:sos.police*.A1* - The 'police.local' service refers to the > emergency service offered by the police department or other law enforceme= nt > authorities of the authorities *of national subdivisions (state, region, > province, prefecture)*"**** > > **** > > While I have no problem with that, I am not aware of a regulation > establishing such emergency service so I cannot argue to IANA that the > RFC5031 policy is satisfied for those URNs.**** > > **** > > Kind regards**** > > **** > > Ivo Sedlacek**** > > **** > > **** > > **** > > **** > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out at www.ericsson.com/email_disclaimer **** > > *From:* Dan Mongrain [mailto:dan@mongrain.org ] > *Sent:* 19. =FAnora 2013 21:12 > *To:* Ivo Sedlacek > *Cc:* Winterbottom, James; Richard Barnes; ecrit@ietf.org > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos (trimming due too large > message report)**** > > **** > > Thing is, when there is no city police, local would give you county polic= e > (sheriff department) but in a city with a city police department local > would give you city police. In the latter case, so how do I get the coun= ty > police (or state police, there can be up to 4 police services for a given > location in the US). Note that these examples are US based, but we do ha= ve > 3 levels of police services in Canada and I am sure other countries have > the same issue.**** > > **** > > There is also the terminology. There is no "national" police in the US o= r > Canada but there is a federal police. Keeping the RFC 4119 terminology > removes any "local" interpretation issues. > > Dan**** > > On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek > wrote:**** > > I agree with Richard - there are countries where both the emergency > service of the national police and the emergency service of the municipal > police are offered in a given location. **** > > A user would call the municipal police emergency service to report e.g. > pickpockets.**** > > A user would call the national police emergency service to report e.g. a > murder.**** > > **** > > **** > > I submitted to IANA a request to register:**** > > - urn:service:sos.police.local - The 'police.local' service refers to the > emergency service offered by the police department or other law enforceme= nt > authorities of the local or municipal authorities.**** > > - urn:service:sos.police.national - The 'police.national' service refers > to the emergency service offered by the police department or other law > enforcement authorities of the national government.**** > > **** > > RFC5031 policy is hopefully fulfilled for them since they exist in two > countries.**** > > **** > > I am flexible whether the actual URNs contain the sub-services proposed > above (i.e. .local and .national sub-services) or subservices based on > RFC4119 (i.e. .A3 and .country sub-services).**** > > **** > > If the preference is for subservices based on RFC4119, do I need to make > another IANA registration request or can we modify the URNs and their > description during the expert review?**** > > **** > > Kind regards**** > > **** > > Ivo Sedlacek**** > > **** > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out at www.ericsson.com/email_disclaimer **** > > *From:* Dan Mongrain [mailto:dan@mongrain.org] > *Sent:* 19. =FAnora 2013 15:36 > *To:* Winterbottom, James > *Cc:* Richard Barnes; Ivo Sedlacek; ecrit@ietf.org > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > **** > > The problem is that different countries has different names for their > political subdivisions. In the US they are states, in Canada they are > provinces, etc. Same when you further subdivide. While not privy to the > discussions that came up with A1, A2, =85, A5, I have the feeling this > nomenclature was picked for the same reason. Why not utilise the same > naming scheme for specifying the jurisdiction you want to reach?**** > > **** > > Thanx,**** > > Dan**** > > **** > > On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James < > James.Winterbottom@commscope.com> wrote:**** > > In that case, one might say state in the hierarchy, not A1.**** > > **** > > Cheers**** > > James**** > > **** > > **** > > *From:* Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* Tuesday, 19 February 2013 8:57 AM > *To:* Winterbottom, James > *Cc:* Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org**** > > > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > **** > > It might make sense if you wanted to allow the caller to explicitly selec= t > police at a different level of responsibility, e.g., the state police > rather than the local police. **** > > **** > > On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James < > James.Winterbottom@commscope.com> wrote:**** > > I think I am missing something here, A1 is part of the location, so why > does it need to be in the URN at all?**** > > As far as I understand current deployments, they use the URN to select a > layer in the GIS that corresponds to the service type, and then use > geographic boundaries within that layer to select the final destination.*= * > ** > > **** > > *From:* ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behalf > Of *Dan Mongrain > *Sent:* Tuesday, 19 February 2013 7:30 AM**** > > > *To:* Ivo Sedlacek > *Cc:* ecrit@ietf.org > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > **** > > Sorry for responding late to this thread, it kinda fell into a crack=85 > The current thread reminded me to check this old thread=85**** > > **** > > You are indicating that we need to register 77 Service URN (11 service > subtypes * 7 jurisdiction types based on RFC 4119). I do not recommend > that we create so many registrations. Instead, we should allow a service > URN to be suffixed with a jurisdictional scope. So the following Service > URN are all valid:**** > > **** > > urn:service:sos.police**** > > urn:service:sos.police.traffic**** > > urn:service:sos.police.A1**** > > urn:service:sos.police.traffic.A1**** > > **** > > Question is, do we want to leave jurisdictional scope to only be > applicable to police branch or any Service URN? I=92d say the latter as = it > is always up to the LoST service provisioning (based on local policy) to > determine what is locally acceptable.**** > > **** > > Thanx,**** > > Dan**** > > **** > > **** > > ** ** > --f46d0447a243c306f304d620c454 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable What I meant is that if a jurisdictional scope aware LoST service receives = a request for urn:service:sos.police.A4 and nothing is configured, it looks= for urn:service:sos.police.A3 then urn:service:sos.police.A2, etc. until i= t finds a configured service.=A0 If nothing is found for urn:service:sos.po= lice.country then it pops the last element and looks for urn:service:sos.po= lice (but then again, it is no longer jurisdictional scope aware).

I disagree that one needs to formulate the request as urn:service:sos.p= olice.country.A1.A2.A3.A4 in order for this to happen.=A0 There must be onl= y a single jurisdictional scope appended to a Service URN.

I do not = think we need a .A6 jurisdictional scope (street level).=A0 .A5 (neighborho= od, would point to a precinct for example) provides enough granularity in m= y opinion.

Thanx,
Dan


On Tue, Feb 19, 201= 3 at 11:29 PM, Winterbottom, James <James.Winterbottom@comm= scope.com> wrote:

I am sorry, I am finding this confusing.<= /u>

=A0<= /p>

RFC5139 puts a hierarc= hy on A1 through A6. If you want this hierarchy to work then A1 through A6 = can=92t be at the same level if you expect A3 to fallback to A2 or A1 in th= e case of a service not existing or a service failure of some kind. If they= exist at the same level then if A3 doesn=92t exist you will go to urn:serv= ice:sos.police=A0 unless you impose the hierarchy in the urn.=

=A0<= /p>

=A0

=A0<= /p>

=A0

=A0<= /p>

From: Dan Mong= rain [mailto:dan@mong= rain.org]
Sent: Wednesday, 20 February 2013 3:23 PM
To: DRAGE, Keith= (Keith)
Cc: Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org
Subject: Re= : [Ecrit] What is the most appropriate method for registering new sub-servi= ces of urn:service:sos (trimming due too large message report)

=A0

My recommendation for handling unknown Service= URN depends if LoST service implements jurisdictional scope or not.=A0 If = it does not, it pops the last element and evaluates until a service is foun= d.=A0 If it implements jurisdictional scope, the last element is a jurisdic= tional scope and it is not found, then you return the next highest level de= fined.

While it may be true that citizens typically dial 9-1-1 to request for = help, police services such as state or provincial polices advertises number= s to call them directly (star code to dial using a mobile phone for example= ) especially to report accidents on freeways.=A0 We need an equivalent Serv= ice URN.

Also while RFC5031's scope is citizen to authorities (I am not sure= I agree with this) I do not want to re-invent the wheel to signal calls wi= thin an Emergency Services IP Network (ESInet).=A0 When I transfer a call f= rom one PSAP to another, the mechanism to determine where to send the call = is the same, using LoST.=A0 For a PSAP that covers a large area spanning mu= ltiple counties and the calltaker needs to transfer the call to the appropr= iate sheriff department for the caller's location, they only need a sin= gle transfer target (urn:service:sos.police.A2).=A0 It is not true that the= calltaker always knows the actual destination of the call, especially when= the calltaker is only a call screener.

Thanx,
Dan

On Tue, Feb = 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com&g= t; wrote:

The a= nswer to James=92s question depends on how you code it (and also what you m= ean by fallback).

=A0

On any service URN, you ignore any subtypes from = the point you stop understanding it.<= /u>

=A0

So if the coding is sos.police.A2, and you do not= understand A2, then the service URN would be handled as if it was sos.poli= ce, not as sos.police.A1. And if police was not understood then it would be= handled as sos.

=A0

If you wanted something that went back to the nex= t larger regional coverage, then you would have to code successive subtypes= in sequence.

=A0

But I would also ask for an element of sanity in = this discussion, rather than total flexibility.=

=A0

For example while a national administration may h= ave multiple levels of police force, not all of them are either reachable d= irectly as an emergency service provider, nor are they necessarily an emerg= ency service provider. If they are neither of these, then they presumably d= o not need a special and distinct service URN. =

=A0

It would therefore nice to see a current use case= that is anything but a choice of two, i.e. countrywide (following the ITU-= T E.164 definition of country) versus one more local variant. This restrict= ed model certainly covers Ivo=92s examples of Czeck Republic and Poland, an= d I believe it also covers the other example I know of which is Italy.

=A0

While the USA has multiple levels of police force= , on the PSTN, it only appears to have one level of access to citizen to au= thority emergency service, which is 911. I see no reason why a change to vo= ice over IP would cause a change to this.

=A0

I would also stress that it is important to have = global expectations of what you get when you use a service URN. If there is= not care excercised with assigning semantics and values, A3 in one country= could result in the forestry police and in another country the financial p= olice responding.

=A0

Note that read the scope of RFC 5031 as being for= end user accessing the emergency service. While it might be possible to ap= ply RFC 5031 to further network operations after the PSAP has been reached,= e.g. to reach a subsidiary PSAP, I read that as outside the scope of RFC 5= 031. Nor do I necessarily believe in that scenario that service URNs are ne= cessarily the best solution for routeing, as the first PSAP should know the= particular office they want to reach rather than just the type of emergenc= y service.

=A0

Regards=

=A0

Keith

=A0

=

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James
Sent: 19 February 2013 23:29
To: Ivo Sedlacek; Dan Mongrai= n
Cc: ecrit@i= etf.org
Subject: Re: [Ecrit] What is the most appropriate met= hod for registering new sub-services of urn:service:sos (trimming due too l= arge message report)

=A0<= /p>

I am okay with this, p= roviding that the fallback order is clearly defined.

That is, does an A3 fall = back to an A2 or A1, or just back to sos?

=A0

=A0

=A0

From: Ivo Sedl= acek [mailto:ivo.sedlacek@ericsson.com]
Sent: Wednesday, 20 February 2013 7:32 AM
To: Dan Mongrain=
Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: RE: [Ecr= it] What is the most appropriate method for registering new sub-services of= urn:service:sos (trimming due too large message report)

=A0

Hello,

=A0

=A0

- urn:service:sos.police= .country=A0- The 'police.national' service refers to the emerge= ncy service offered by the police department or other law enforcement autho= rities of the government=A0of a country.=

=A0

<= /u>

=A0

=A0

In the latter case, so how do I get the county p= olice (or state police, there can be up to 4 police services for a given lo= cation in the US).=A0

=A0

- urn:service:sos.police= .A2 - The 'police.local' service refers to the emergency servic= e offered by the police department or other law enforcement authorities of = the authorities=A0of county, parish, gun (JP), district (IN)"

- urn:service:sos.police= .A1 - The 'police.local' service refers to the emergency servic= e offered by the police department or other law enforcement authorities of = the authorities=A0of national subdivisions (state, region, province, pre= fecture)"

=A0

<= /span>

=A0

=A0

=A0

=A0

=A0

This Communication is Confid= ential. We only send and receive email on the basis of the terms set out at= www.ericsson.com/email_disc= laimer

From: Dan Mong= rain [mailto:dan@mong= rain.org]
Sent: 19. =FAnora 2013 21:12
To: Ivo Sedlacek
Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: Re: [Ecrit] What is t= he most appropriate method for registering new sub-services of urn:service:= sos (trimming due too large message report)<= /u>

=A0

Thing is, when there is no city police, lo= cal would give you county police (sheriff department) but in a city with a = city police department local would give you city police.=A0 In the latter c= ase, so how do I get the county police (or state police, there can be up to= 4 police services for a given location in the US).=A0 Note that these exam= ples are US based, but we do have 3 levels of police services in Canada and= I am sure other countries have the same issue.=

=A0

There is also the terminology.=A0 There is no "national" police i= n the US or Canada but there is a federal police.=A0 Keeping the RFC 4119 t= erminology removes any "local" interpretation issues.

Dan<= span lang=3D"EN-GB">

On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek &= lt;ivo.sedla= cek@ericsson.com> wrote:

I agree with Richard -= there are countries where both the emergency service of the national polic= e and the emergency service of the municipal police are offered in a given = location.

A user would call the munic= ipal police emergency service to report e.g. pickpockets.

A user would call the natio= nal police emergency service to report e.g. a murder.

=A0

I submitted to IANA a reque= st to register:

- urn:service:sos.police.local - The 'police.l= ocal' service refers to the emergency service offered by the police dep= artment or other law enforcement authorities of the local or municipal auth= orities.

- urn:service:sos.police.na= tional - The 'police.national' service refers to the emergency serv= ice offered by the police department or other law enforcement authorities o= f the national government.=

=A0

=A0

=

=A0

<= /span>

=A0

=A0

=A0

This Communication is Confidential. We only send and receive email on the = basis of the terms set out at www.ericsson.com/email_disclaimer =

From: Dan Mong= rain [mailto:dan@mong= rain.org]
Sent: 19. =FAnora 2013 15:36
To: Winterbottom, James
Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org
Subject: Re: [Ecrit] What is t= he most appropriate method for registering new sub-services of urn:service:= sos

=A0

The problem is that differen= t countries has different names for their political subdivisions.=A0 In the= US they are states, in Canada they are provinces, etc.=A0 Same when you fu= rther subdivide.=A0 While not privy to the discussions that came up with A1= , A2, =85, A5, I have the feeling this nomenclature was picked for the same= reason.=A0 Why not utilise the same naming scheme for specifying the juris= diction you want to reach?=

=A0

Thanx,

Dan

=A0

On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James <James.Winterbottom@co= mmscope.com> wrote:

In that case, o= ne might say state in the hierarchy, not A1.=

=A0

Cheers

James

=A0

=A0

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Tuesday, 19 February 2013 8:57 AM
To: Winterbottom, = James
Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org<= /u>


Subject: Re: [Ecrit] What is th= e most appropriate method for registering new sub-services of urn:service:s= os

=A0

It might make sense if you wanted to allow the cal= ler to explicitly select police at a different level of responsibility, e.g= ., the state police rather than the local police. =A0<= u>

=A0

On Mon, = Feb 18, 2013 at 4:21 PM, Winterbottom, James <James.Winterbottom@commscope.co= m> wrote:

I think I am mi= ssing something here, A1 is part of the location, so why does it need to be= in the URN at all?

As far as I understand cu= rrent deployments, they use the URN to select a layer in the GIS that corre= sponds to the service type, and then use geographic boundaries within that = layer to select the final destination.

=A0

From: ecrit-bounces@ietf.org= [mailto:ec= rit-bounces@ietf.org] On Behalf Of Dan Mongrain
Sent: Tuesday, 19 February 2013 7:30 AM<= u>


To: Ivo= Sedlacek
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] What is the most appropriate method for registe= ring new sub-services of urn:service:sos=

=A0

Sorry for responding late= to this thread, it kinda fell into a=A0 crack=85=A0 The current thread rem= inded me to check this old thread=85<= /u>

=A0

You are indicating that we need to register 77 Service URN (11 servic= e subtypes * 7 jurisdiction types based on RFC 4119).=A0 I do not recommend= that we create so many registrations.=A0 Instead, we should allow a servic= e URN to be suffixed with a jurisdictional scope.=A0 So the following Servi= ce URN are all valid:

=A0

urn:service:sos.police

urn:service:sos.police.tr= affic

urn:service:sos.police.A1

urn:service:sos.police.traffic.A1

=A0

Question is, do we want to leave jurisdictional scope to only be appl= icable to police branch or any Service URN? =A0I=92d say the latter as it i= s always up to the LoST service provisioning (based on local policy) to det= ermine what is locally acceptable.

=A0

Thanx,

Dan

=A0=

=A0

=A0

On Tue, Feb 19, 2013 at= 7:18 PM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.co= m> wrote:

The answer to James=92s quest= ion depends on how you code it (and also what you mean by fallback).<= /u>

=A0

On any service URN, you ignor= e any subtypes from the point you stop understanding it.

=A0

So if the coding is sos.polic= e.A2, and you do not understand A2, then the service URN would be handled as if it was sos.police, not as sos.police.A1. And if police was not understood then it would be handled as sos.

=A0

If you wanted something that = went back to the next larger regional coverage, then you would have to code successive subtypes in sequence.

=A0

But I would also ask for an e= lement of sanity in this discussion, rather than total flexibility.

=A0

For example while a national = administration may have multiple levels of police force, not all of them are either reacha= ble directly as an emergency service provider, nor are they necessarily an emergency service provider. If they are neither of these, then they presuma= bly do not need a special and distinct service URN.

=A0

It would therefore nice to se= e a current use case that is anything but a choice of two, i.e. countrywide (following the = ITU-T E.164 definition of country) versus one more local variant. This restricted model certainly covers Ivo=92s examples of <= u>Czeck Republic and Poland, and I believe it also covers the other example I know of which is Italy= .

=A0

While the USA has multiple levels of police force, on the PSTN, it only appears to have one level of access to citizen = to authority emergency service, which is 911. I see no reason why a change to voice over IP would cause a change to this.

=A0

I would also stress that it i= s important to have global expectations of what you get when you use a service URN. If there is not care excercised with assigning semantics and values, A3 in one country could result in the forestry police and in another country the financial police responding.

=A0

Note that read the scope of R= FC 5031 as being for end user accessing the emergency service. While it might be possi= ble to apply RFC 5031 to further network operations after the PSAP has been reached, e.g. to reach a subsidiary PSAP, I read that as outside the scope = of RFC 5031. Nor do I necessarily believe in that scenario that service URNs a= re necessarily the best solution for routeing, as the first PSAP should know t= he particular office they want to reach rather than just the type of emergency service.

=A0

Regards<= /font>

=A0

Keith

=A0

From: ecrit-bounces@i= etf.org [mailto:ecrit-bounces@ietf.org] On Beh= alf Of Winterbottom, James
Sent: 19 February 2013 23:29=
To: Ivo Sedlacek; Dan Mongra= in
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)<= u>

=A0

I am= okay with this, providing that the fallback order is clearly defined.<= /font>

That= is, does an A3 fall back to an A2 or A1, or just back to sos?<= /p>

<= /u>=A0

<= /u>=A0

<= /u>=A0

From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com]
Sent: Wednesday, 20 February= 2013 7:32 AM
To: Dan Mongrain
Cc: Winterbottom, James; Ric= hard Barnes; ecrit@ietf.org<= /a>
Subject: RE: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

=A0

Hello,=

=A0

If we = go with RFC4119 based sub-services, would the IANA registration request be as follows?

=A0

- urn:service:sos.police.A3=A0- The 'police.local' service refers to the emergency service offered = by the police department or other law enforcement authorities of the authorities=A0of a city, township, shi (JP).

- urn:service:sos.police.country=A0- The 'police.national' service refers to the emergency service offer= ed by the police department or other law enforcement authorities of the government=A0of a country.=

=A0

Does a= nyone see any issue in that?

=A0

If WG = prefers this, it is OK for me.

=A0

> <= /span>In the latter case, so how do I get the county police (or state police, there = can be up to 4 police services for a given location in the US<= /u>).=A0 <= u>

=A0

If I g= ot it correctly, you propose that we also add

- urn:service:sos.police.A2 - The 'police.local' service refer= s to the emergency service offered by the police department or other law enforcement authorities of the authorities=A0of county, parish, gun (JP), district (IN)"

- urn:service:sos.police.A1 - The 'police.local' service refer= s to the emergency service offered by the police department or other law enforcement authorities of the authorities=A0of national subdivisions (state, region, province, prefecture)"

=A0

While = I have no problem with that, I am not aware of a regulation establishing such emergen= cy service so I cannot argue to IANA that the RFC5031 policy is satisfied for those URNs.

=A0

Kind r= egards

=A0

Ivo Se= dlacek

=A0

=A0

=A0

=A0

This Communication is Confidential. We only send and receive email on the basis of the terms set = out at www.ericsson.com/email_di= sclaimer

From: Dan Mongrain [mailto:= dan@mongrain.org]
Sent: 19. =FAnora 2013 21:12=
To: Ivo Sedlacek
Cc: Winterbottom, James; Ric= hard Barnes; ecrit@ietf.org<= /a>
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

=A0

Thing is, when there is no city police, local would give you county police (sheri= ff department) but in a city with a city police department local would give yo= u city police.=A0 In the latter case, so how do I get the county police (or state police, there can be up to 4 police services for a given location in = the US).=A0 Note that these examples are US based, but we do have 3 levels of police service= s in Canada and I am sure other countries have the same issue.

=A0<= /span>

There = is also the terminology.=A0 There is no "national" police in the U= S or Canada but there is a federal police.=A0 Keeping the RFC 4119 terminology removes any "local" interpretation issues.

Dan

On Tue, Feb 19, 2013 at= 2:31 PM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:

I agre= e with Richard - there are countries where both the emergency service of the national police and the emergency service of the municipal police are offered in a given location.

A user= would call the municipal police emergency service to report e.g. pickpockets.

A user= would call the national police emergency service to report e.g. a murder.

=A0

=A0

I subm= itted to IANA a request to register:<= /u>

- urn:= service:sos.police.local - The 'police.local' service refers to the emergency service offered by t= he police department or other law enforcement authorities of the local or municipal authorities.

- urn:= service:sos.police.national - The 'police.national' service refers to the emergency service offered b= y the police department or other law enforcement authorities of the national government.=

=A0

RFC503= 1 policy is hopefully fulfilled for them since they exist in two countries.

=A0

I am f= lexible whether the actual URNs contain the sub-services proposed above (i.e. .local and .national sub-services) or subservices based on RFC4119 (i.e. .A3 and .country sub-services).

=A0

If the= preference is for subservices based on RFC4119, do I need to make another IANA registration request or can we modi= fy the URNs and their description during the expert review?

=A0

Kind r= egards

=A0

Ivo Se= dlacek

=A0

This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19. =FAnora 2013 15:36=
To: Winterbottom, James
Cc: Richard Barnes; Ivo Sedl= acek; ecrit@ietf.org
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos=

=A0

The = problem is that different countries has different names for their political subdivisions.=A0 In the US they are states, in Canada they are provinces, etc.=A0 Same when you further subdivide.=A0 While not privy to the discussions that came up with A1, A2, =85, A5, I have the feeling this nomenclature was picked for the same reason.=A0 Why not utilise the same naming scheme for specifying the jurisdiction you want to reach?

=A0<= /span>

Than= x,

Dan<= /span>

=A0=

On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James <James.Winterbottom@commscope.com> wrote:

In t= hat case, one might say state in the hierarchy, not A1.<= /p>

=A0<= /span>

Chee= rs

Jame= s

=A0<= /span>

=A0<= /span>

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Tuesday, 19 February 2= 013 8:57 AM
To: Winterbottom, James
Cc: Dan Mongrain; Ivo Sedlac= ek; ecrit@ietf.org<= /span>


Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos=

=A0

It might make sense if you wanted to allow the caller to explicitly select pol= ice at a different level of responsibility, e.g., the state police rather than = the local police. =A0

=A0=

On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James <James.Winterbottom@commscope.com> wrote:

I th= ink I am missing something here, A1 is part of the location, so why does it need to be in the URN at all?

As f= ar as I understand current deployments, they use the URN to select a layer in the GIS that corresponds to the service type, and then use geographic boundaries wi= thin that layer to select the final destination.

=A0<= /span>

From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Dan Mongrain Sent: Tuesday, 19 February 2= 013 7:30 AM<= /span>


To: Ivo Sedlacek
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos=

=A0

Sorr= y for responding late to this thread, it kinda fell into a=A0 crack=85=A0 The current thread reminded me to check this old thread=85

=A0<= /span>

You = are indicating that we need to register 77 Service URN (11 service subtypes * 7 jurisdiction types based on RFC 4119).=A0 I do not recommend that we create so many registrations.=A0 Instead, we should allow a service URN to be suffixed with a jurisdictional scope.=A0 So the following Service URN are all valid:

=A0<= /span>

urn:= service:sos.police<= /p>

urn:= service:sos.police.traffic=

urn:= service:sos.police.A1

urn:= service:sos.police.traffic.A1<= /u>

=A0<= /span>

Ques= tion is, do we want to leave jurisdictional scope to only be applicable to police branch or any Service = URN? =A0I=92d say the latter as it is always up to the LoST service provisioning (based on local policy) to determine what is locally acceptabl= e.

=A0<= /span>

Than= x,

Dan<= /span>

=A0

=A0


--f46d0447a243c306f304d620c454-- From James.Winterbottom@commscope.com Tue Feb 19 20:57:01 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17C421F880F for ; Tue, 19 Feb 2013 20:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ojWYqqiVGdY for ; Tue, 19 Feb 2013 20:56:54 -0800 (PST) Received: from cdcsmgw01.commscope.com (cdcsmgw01.commscope.com [198.135.207.232]) by ietfa.amsl.com (Postfix) with ESMTP id ABAD021F8830 for ; Tue, 19 Feb 2013 20:56:53 -0800 (PST) X-AuditID: 0a0404e8-b7fa46d000004284-71-5124578f0b56 Received: from CDCE10HC1.commscope.com ( [10.86.28.21]) by cdcsmgw01.commscope.com (Symantec Messaging Gateway) with SMTP id E2.73.17028.F8754215; Tue, 19 Feb 2013 22:56:47 -0600 (CST) Received: from SISPE7HC1.commscope.com (10.97.4.12) by CDCE10HC1.commscope.com (10.86.28.21) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 19 Feb 2013 22:56:51 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 20 Feb 2013 12:56:47 +0800 From: "Winterbottom, James" To: Dan Mongrain Date: Wed, 20 Feb 2013 12:56:46 +0800 Thread-Topic: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) Thread-Index: Ac4PJodRdp9rFCWHRNCv5zhcpFOcKQAAB98w Message-ID: <5A55A45AE77F5941B18E5457ECAC818801214077135D@SISPE7MB1.commscope.com> References: <39B5E4D390E9BD4890E2B3107900610109A5A8@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610109A6A7@ESESSMB301.ericsson.se> <5A55A45AE77F5941B18E5457ECAC81880121407712CD@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC8188012140771351@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC818801214077135DSISPE7MB1co_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNKsWRmVeSWpSXmKPExsXCFSYjqtsfrhJocPKMgcX9OS0sFo2LnrJa 9K6cx2rxtPEsowOLR+uzvawev75eZfNYsuQnk8eLbQoBLFFcNimpOZllqUX6dglcGXtefWMs WP+QuaJp/272BsaetcxdjJwcEgImEqv2zYKyxSQu3FvP1sXIxSEksItRYtKtr8wQzgZGiWed P6Ay6xglXi25zwbSwiZgJ3F4/Q2wdhEBZYmuqffAOpgFuhglOlfsBStiEVCVuPvxBFi3sMA0 Rok/P2cxgTgiAtMZJZYevMUG0W4k8XTyDjCbVyBI4sGEVWBjhQROsUhcPBoCYnMKBEocePEa LM4IdO33U2uYQGxmAXGJW0/mM0F8ISCxZM95qI9EJV4+/scKUS8qcad9PSNEfb7EsjVzGCF2 CUqcnPmEBWKXrkTTzq+sExjFZyEZOwtJyywkLRBxPYkbU6ewQdjaEssWvmaGsHUlZvw7xIIs voCRfRWjeHJKcnFuermBoV5yfm5ucXJ+QSqItYkRFNcsLC92MJ7eoH2IUYCDUYmHV2O+cqAQ a2JZcWXuIUZJDiYlUd74EJVAIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8zU5AOd6UxMqq1KJ8 mJQGB4fA6Sf3TzFKseTl56UqSfAyhQGVCRalpqdWpGXmAJMaTCkTByfIKB6gUb9DQUYVFyTm FmemQ+RPMWpzLLj26AUjR/Py5y8YhcDGSYnzXgYpFQApzSjNg5v2ilEc6AVhXkaQZTzAFA03 5xXQCiagFWuXK4OsKElESEk1MFqISap2J3u8u/TwWz9zfYDsy+2n7k882Mi+cYNJa+jjfUGP S2Oy1D0bOLXfyPPEKazNSW7+zVW/7aLG7SC+D1LsDvz/XiW4JdZnanM8i9OT2/Xfcq4W87cv PKyizBOuvperfrl53XcTQQb/omP2QfoLzibrLWIzf5WvHPxBJyk81vmU2ZJwJZbijERDLeai 4kQAuXZ8cI4DAAA= Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 04:57:01 -0000 --_000_5A55A45AE77F5941B18E5457ECAC818801214077135DSISPE7MB1co_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for the clarification, I personally disagree with that position. From: Dan Mongrain [mailto:dan@mongrain.org] Sent: Wednesday, 20 February 2013 3:56 PM To: Winterbottom, James Cc: DRAGE, Keith (Keith); Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) What I meant is that if a jurisdictional scope aware LoST service receives = a request for urn:service:sos.police.A4 and nothing is configured, it looks= for urn:service:sos.police.A3 then urn:service:sos.police.A2, etc. until i= t finds a configured service. If nothing is found for urn:service:sos.poli= ce.country then it pops the last element and looks for urn:service:sos.poli= ce (but then again, it is no longer jurisdictional scope aware). I disagree that one needs to formulate the request as urn:service:sos.polic= e.country.A1.A2.A3.A4 in order for this to happen. There must be only a si= ngle jurisdictional scope appended to a Service URN. I do not think we need a .A6 jurisdictional scope (street level). .A5 (nei= ghborhood, would point to a precinct for example) provides enough granulari= ty in my opinion. Thanx, Dan On Tue, Feb 19, 2013 at 11:29 PM, Winterbottom, James > wrote: I am sorry, I am finding this confusing. RFC5139 puts a hierarchy on A1 through A6. If you want this hierarchy to wo= rk then A1 through A6 can't be at the same level if you expect A3 to fallba= ck to A2 or A1 in the case of a service not existing or a service failure o= f some kind. If they exist at the same level then if A3 doesn't exist you w= ill go to urn:service:sos.police unless you impose the hierarchy in the ur= n. From: Dan Mongrain [mailto:dan@mongrain.org] Sent: Wednesday, 20 February 2013 3:23 PM To: DRAGE, Keith (Keith) Cc: Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) My recommendation for handling unknown Service URN depends if LoST service = implements jurisdictional scope or not. If it does not, it pops the last e= lement and evaluates until a service is found. If it implements jurisdicti= onal scope, the last element is a jurisdictional scope and it is not found,= then you return the next highest level defined. While it may be true that citizens typically dial 9-1-1 to request for help= , police services such as state or provincial polices advertises numbers to= call them directly (star code to dial using a mobile phone for example) es= pecially to report accidents on freeways. We need an equivalent Service UR= N. Also while RFC5031's scope is citizen to authorities (I am not sure I agree= with this) I do not want to re-invent the wheel to signal calls within an = Emergency Services IP Network (ESInet). When I transfer a call from one PS= AP to another, the mechanism to determine where to send the call is the sam= e, using LoST. For a PSAP that covers a large area spanning multiple count= ies and the calltaker needs to transfer the call to the appropriate sheriff= department for the caller's location, they only need a single transfer tar= get (urn:service:sos.police.A2). It is not true that the calltaker always = knows the actual destination of the call, especially when the calltaker is = only a call screener. Thanx, Dan On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) > wrote: The answer to James's question depends on how you code it (and also what yo= u mean by fallback). On any service URN, you ignore any subtypes from the point you stop underst= anding it. So if the coding is sos.police.A2, and you do not understand A2, then the s= ervice URN would be handled as if it was sos.police, not as sos.police.A1. = And if police was not understood then it would be handled as sos. If you wanted something that went back to the next larger regional coverage= , then you would have to code successive subtypes in sequence. But I would also ask for an element of sanity in this discussion, rather th= an total flexibility. For example while a national administration may have multiple levels of pol= ice force, not all of them are either reachable directly as an emergency se= rvice provider, nor are they necessarily an emergency service provider. If = they are neither of these, then they presumably do not need a special and d= istinct service URN. It would therefore nice to see a current use case that is anything but a ch= oice of two, i.e. countrywide (following the ITU-T E.164 definition of coun= try) versus one more local variant. This restricted model certainly covers = Ivo's examples of Czeck Republic and Poland, and I believe it also covers t= he other example I know of which is Italy. While the USA has multiple levels of police force, on the PSTN, it only app= ears to have one level of access to citizen to authority emergency service,= which is 911. I see no reason why a change to voice over IP would cause a = change to this. I would also stress that it is important to have global expectations of wha= t you get when you use a service URN. If there is not care excercised with = assigning semantics and values, A3 in one country could result in the fores= try police and in another country the financial police responding. Note that read the scope of RFC 5031 as being for end user accessing the em= ergency service. While it might be possible to apply RFC 5031 to further ne= twork operations after the PSAP has been reached, e.g. to reach a subsidiar= y PSAP, I read that as outside the scope of RFC 5031. Nor do I necessarily = believe in that scenario that service URNs are necessarily the best solutio= n for routeing, as the first PSAP should know the particular office they wa= nt to reach rather than just the type of emergency service. Regards Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Winterbottom, = James Sent: 19 February 2013 23:29 To: Ivo Sedlacek; Dan Mongrain Cc: ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) I am okay with this, providing that the fallback order is clearly defined. That is, does an A3 fall back to an A2 or A1, or just back to sos? From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] Sent: Wednesday, 20 February 2013 7:32 AM To: Dan Mongrain Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org Subject: RE: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) Hello, If we go with RFC4119 based sub-services, would the IANA registration reque= st be as follows? - urn:service:sos.police.A3 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of a city, township, shi (JP). - urn:service:sos.police.country - The 'police.national' service refers to = the emergency service offered by the police department or other law enforce= ment authorities of the government of a country. Does anyone see any issue in that? If WG prefers this, it is OK for me. > In the latter case, so how do I get the county police (or state police, t= here can be up to 4 police services for a given location in the US). If I got it correctly, you propose that we also add - urn:service:sos.police.A2 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of county, parish, gun (JP), district (IN)" - urn:service:sos.police.A1 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of national subdivisions (state, region, provin= ce, prefecture)" While I have no problem with that, I am not aware of a regulation establish= ing such emergency service so I cannot argue to IANA that the RFC5031 polic= y is satisfied for those URNs. 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 21:12 To: Ivo Sedlacek Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) Thing is, when there is no city police, local would give you county police = (sheriff department) but in a city with a city police department local woul= d give you city police. In the latter case, so how do I get the county pol= ice (or state police, there can be up to 4 police services for a given loca= tion in the US). Note that these examples are US based, but we do have 3 l= evels of police services in Canada and I am sure other countries have the s= ame issue. There is also the terminology. There is no "national" police in the US or = Canada but there is a federal police. Keeping the RFC 4119 terminology rem= oves any "local" interpretation issues. Dan On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek > wrote: I agree with Richard - there are countries where both the emergency service= of the national police and the emergency service of the municipal police a= re offered in a given location. A user would call the municipal police emergency service to report e.g. pic= kpockets. A user would call the national police emergency service to report e.g. a mu= rder. I submitted to IANA a request to register: - urn:service:sos.police.local - The 'police.local' service refers to the e= mergency service offered by the police department or other law enforcement = authorities of the local or municipal authorities. - urn:service:sos.police.national - The 'police.national' service refers to= the emergency service offered by the police department or other law enforc= ement authorities of the national government. RFC5031 policy is hopefully fulfilled for them since they exist in two coun= tries. I am flexible whether the actual URNs contain the sub-services proposed abo= ve (i.e. .local and .national sub-services) or subservices based on RFC4119= (i.e. .A3 and .country sub-services). If the preference is for subservices based on RFC4119, do I need to make an= other IANA registration request or can we modify the URNs and their descrip= tion during the expert review? 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 15:36 To: Winterbottom, James Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos The problem is that different countries has different names for their polit= ical subdivisions. In the US they are states, in Canada they are provinces= , etc. Same when you further subdivide. While not privy to the discussion= s that came up with A1, A2, ..., A5, I have the feeling this nomenclature w= as picked for the same reason. Why not utilise the same naming scheme for = specifying the jurisdiction you want to reach? Thanx, Dan On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James > wrote: In that case, one might say state in the hierarchy, not A1. Cheers James From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Tuesday, 19 February 2013 8:57 AM To: Winterbottom, James Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos It might make sense if you wanted to allow the caller to explicitly select = police at a different level of responsibility, e.g., the state police rathe= r than the local police. On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James > wrote: I think I am missing something here, A1 is part of the location, so why doe= s it need to be in the URN at all? As far as I understand current deployments, they use the URN to select a la= yer in the GIS that corresponds to the service type, and then use geographi= c boundaries within that layer to select the final destination. From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Dan Mongrain Sent: Tuesday, 19 February 2013 7:30 AM To: Ivo Sedlacek Cc: ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos Sorry for responding late to this thread, it kinda fell into a crack... T= he current thread reminded me to check this old thread... You are indicating that we need to register 77 Service URN (11 service subt= ypes * 7 jurisdiction types based on RFC 4119). I do not recommend that we= create so many registrations. Instead, we should allow a service URN to b= e suffixed with a jurisdictional scope. So the following Service URN are a= ll valid: urn:service:sos.police urn:service:sos.police.traffic urn:service:sos.police.A1 urn:service:sos.police.traffic.A1 Question is, do we want to leave jurisdictional scope to only be applicable= to police branch or any Service URN? I'd say the latter as it is always u= p to the LoST service provisioning (based on local policy) to determine wha= t is locally acceptable. Thanx, Dan --_000_5A55A45AE77F5941B18E5457ECAC818801214077135DSISPE7MB1co_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

From: Dan= Mongrain <dan@mongrain.org>
= Date: Tuesday, February 19, 2013 11:5= 5 PM
To: "Winterbottom, James" <= ;James.Winterbottom@commsc= ope.com>
Cc: "ecrit@ietf.org" <e= crit@ietf.org>
Subject: Re:= [Ecrit] What is the most appropriate method for registering new sub-service= s of urn:service:sos (trimming due too large message report)
<= br>
What I meant is that i= f a jurisdictional scope aware LoST service receives a request for urn:servi= ce:sos.police.A4 and nothing is configured, it looks for urn:service:sos.pol= ice.A3 then urn:service:sos.police.A2, etc. until it finds a configured serv= ice.  If nothing is found for urn:service:sos.police.country then it po= ps the last element and looks for urn:service:sos.police (but then again, it= is no longer jurisdictional scope aware).

I disagree that one needs = to formulate the request as urn:service:sos.police.country.A1.A2.A3.A4 in or= der for this to happen.  There must be only a single jurisdictional sco= pe appended to a Service URN.

I do not think we need a .A6 jurisdicti= onal scope (street level).  .A5 (neighborhood, would point to a precinc= t for example) provides enough granularity in my opinion.

Thanx,
D= an


On Tue, Feb 19, 2013 at 11:29 PM, Win= terbottom, James <James.Winterbottom@commscope.com> w= rote:

I am sorry, I am finding this c= onfusing.

 

RFC5139 puts a = hierarchy on A1 through A6. If you want this hierarchy to work then A1 throu= gh A6 can’t be at the same level if you expect A3 to fallback to A2 or= A1 in the case of a service not existing or a service failure of some kind.= If they exist at the same level then if A3 doesn’t exist you will go = to urn:service:sos.police  unless you impose the hierarchy in the urn.<= u>

 =

 

 

 

 

Fr= om:d= an@mongrain.org]
Sent: Wednesday, 20 February 2013 3:23 PMTo: DRAGE, Keith (Keith)
Cc: Winterbottom, James; Ivo Sedl= acek; ecrit@ietf.org
= Subject: Re: [Ecrit] What is the most appropriate method for register= ing new sub-services of urn:service:sos (trimming due too large message repo= rt)

 <= /p>

My recommendation for h= andling unknown Service URN depends if LoST service implements jurisdictiona= l scope or not.  If it does not, it pops the last element and evaluates= until a service is found.  If it implements jurisdictional scope, the = last element is a jurisdictional scope and it is not found, then you return = the next highest level defined.

While it may be true that citizens ty= pically dial 9-1-1 to request for help, police services such as state or pro= vincial polices advertises numbers to call them directly (star code to dial = using a mobile phone for example) especially to report accidents on freeways= .  We need an equivalent Service URN.

Also while RFC5031's scope= is citizen to authorities (I am not sure I agree with this) I do not want t= o re-invent the wheel to signal calls within an Emergency Services IP Networ= k (ESInet).  When I transfer a call from one PSAP to another, the mecha= nism to determine where to send the call is the same, using LoST.  For = a PSAP that covers a large area spanning multiple counties and the calltaker= needs to transfer the call to the appropriate sheriff department for the ca= ller's location, they only need a single transfer target (urn:service:sos.po= lice.A2).  It is not true that the calltaker always knows the actual de= stination of the call, especially when the calltaker is only a call screener= .

Thanx,
Dan

On Tue, Fe= b 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> w= rote:

The answ= er to James’s question depends on how you code it (and also what you m= ean by fallback).

 

On any service URN, you ignore an= y subtypes from the point you stop understanding it.

 <= span lang=3D"EN-GB">

So if the coding is sos.police.A2, and you do not understand A2, then the = service URN would be handled as if it was sos.police, not as sos.police.A1. = And if police was not understood then it would be handled as sos.

&= nbsp;

If you wanted something that went back to the next larger reg= ional coverage, then you would have to code successive subtypes in sequence.=

 

But I would also ask for an element of sanity in t= his discussion, rather than total flexibility.<= /u>

 

For = example while a national administration may have multiple levels of police f= orce, not all of them are either reachable directly as an emergency service = provider, nor are they necessarily an emergency service provider. If they ar= e neither of these, then they presumably do not need a special and distinct = service URN.

 =

It would therefore nice to see a curr= ent use case that is anything but a choice of two, i.e. countrywide (followi= ng the ITU-T E.164 definition of country) versus one more local variant. Thi= s restricted model certainly covers Ivo’s examples of Czeck Republic a= nd Poland, and I believe it also covers the other example I know of which is= Italy.

 

While the USA has multiple levels of police= force, on the PSTN, it only appears to have one level of access to citizen = to authority emergency service, which is 911. I see no reason why a change t= o voice over IP would cause a change to this.

 

I wou= ld also stress that it is important to have global expectations of what you = get when you use a service URN. If there is not care excercised with assigni= ng semantics and values, A3 in one country could result in the forestry poli= ce and in another country the financial police responding.

 

Note that read the scope of RFC 5031 as being for end user accessing= the emergency service. While it might be possible to apply RFC 5031 to furt= her network operations after the PSAP has been reached, e.g. to reach a subs= idiary PSAP, I read that as outside the scope of RFC 5031. Nor do I necessar= ily believe in that scenario that service URNs are necessarily the best solu= tion for routeing, as the first PSAP should know the particular office they = want to reach rather than just the type of emergency service.

 = ;

Regards

 

Keith<= u>

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Winter= bottom, James
Sent: 19 February 2013 23:29
To: Ivo Sedla= cek; Dan Mongrain
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] What is the most appro= priate method for registering new sub-services of urn:service:sos (trimming = due too large message report)=

 

I am okay with this, providing that= the fallback order is clearly defined.<= /u>

That is, does an A3 fall b= ack to an A2 or A1, or just back to sos?=

 

 

 

From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com]
Sent: Wedn= esday, 20 February 2013 7:32 AM
To: Dan Mongrain
Cc: Win= terbottom, James; Richard Barnes; ecrit@ietf.org
Subject: RE: [Ecrit] What is the most app= ropriate method for registering new sub-services of urn:service:sos (trimmin= g due too large message report)

 

Hello,

 <= span lang=3D"EN-GB">

If we go with RFC4119 based sub-services, would the IANA registration reque= st be as follows?

 

- urn:service:sos.police.A3&= nbsp;- The 'police.local' service refers to the emergency service offered by= the police department or other law enforcement authorities of the authoriti= es of a city, township, shi (JP).

- urn:service:sos.poli= ce.country - The 'police.national' service refers to the emergen= cy service offered by the police department or other law enforcement authori= ties of the government of a country.

 

Does= anyone see any issue in that?

 

If WG prefers this, it= is OK for me.

 =

> In the latter case, so how do I get = the county police (or state police, there can be up to 4 police services for= a given location in the US).  =

 

If I got it corr= ectly, you propose that we also add =

- urn:service:sos.police.A2<= /u> - The 'police.local' service refers to the emergency service offered by = the police department or other law enforcement authorities of the authoritie= s of county, parish, gun (JP), district (IN)"

- urn:serv= ice:sos.police.A1 - The 'police.local' service refers to the emergenc= y service offered by the police department or other law enforcement authorit= ies of the authorities of national subdivisions (state, region, prov= ince, prefecture)"

 

While I have no problem with t= hat, I am not aware of a regulation establishing such emergency service so I= cannot argue to IANA that the RFC5031 policy is satisfied for those URNs.

 

Kind regards

 <= u>

Ivo Sedlacek

 

=  

 

This Communication is Confidential.= We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From:<= span style=3D"font-size: 10pt; font-family: Tahoma, sans-serif; "> Dan Mongrai= n [mailto:dan@mongrain.org= ]
Sent: 19. =FAnora 2013 21:12
To: Ivo Sedlacek
Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: Re: [Ecrit] What is = the most appropriate method for registering new sub-services of urn:service:= sos (trimming due too large message report)=

 

Thing is, when there is no city police, local would = give you county police (sheriff department) but in a city with a city police= department local would give you city police.  In the latter case, so h= ow do I get the county police (or state police, there can be up to 4 police = services for a given location in the US).  Note that these examples are= US based, but we do have 3 levels of police services in Canada and I am sur= e other countries have the same issue.

 

There is also the terminology.  There is no "national" police in the U= S or Canada but there is a federal police.  Keeping the RFC 4119 termin= ology removes any "local" interpretation issues.

Dan

On Tue, Feb 19, 2013 at= 2:31 PM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:=

I agree with R= ichard - there are countries where both the emergency service of the nationa= l police and the emergency service of the municipal police are offered in a = given location.

A user would call the municipal police emergency se= rvice to report e.g. pickpockets.

A user would call the national pol= ice emergency service to report e.g. a murder.<= /u>

 

 =

I submitted to IANA a request to register:

- urn:service:so= s.police.local - The 'police.local' service refers to the emergency service = offered by the police department or other law enforcement authorities of the= local or municipal authorities.

- urn:service:sos.police.national -= The 'police.national' service refers to the emergency service offered by th= e police department or other law enforcement authorities of the national gov= ernment.

 

RFC5031 policy is hopefully fulfilled for th= em since they exist in two countries.

 

I am flexible w= hether the actual URNs contain the sub-services proposed above (i.e. .local = and .national sub-services) or subservices based on RFC4119 (i.e. .A3 and .c= ountry sub-services).

 =

If the preference is for subser= vices based on RFC4119, do I need to make another IANA registration request = or can we modify the URNs and their description during the expert review?

 

Kind regards

 

Ivo Sedlacek=

This Communication is Confidential. We only send and receive = email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19.= =FAnora 2013 15:36
To: Winterbottom, James
Cc: Richard Ba= rnes; Ivo Sedlacek; ecrit@ie= tf.org
Subject: Re: [Ecrit] What is the most appropriate metho= d for registering new sub-services of urn:service:sos

 

The problem is th= at different countries has different names for their political subdivisions.=   In the US they are states, in Canada they are provinces, etc.  S= ame when you further subdivide.  While not privy to the discussions tha= t came up with A1, A2, …, A5, I have the feeling this nomenclature was= picked for the same reason.  Why not utilise the same naming scheme fo= r specifying the jurisdiction you want to reach?

 

= Thanx,

Dan

 

On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James <James.Winterbottom@commscope= .com> wrote:

In that case, one might say state in the hi= erarchy, not A1.

 

Cheers=

James

 

 

<= div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm = 0cm">

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Tuesday, 19 February 2013 8:= 57 AM
To: Winterbottom, James
Cc: Dan Mongrain; Ivo Sedl= acek; ecrit@ietf.org


Subject: Re: [Ecrit] What is the most appropriate method for re= gistering new sub-services of urn:service:sos

 

It might make = sense if you wanted to allow the caller to explicitly select police at a dif= ferent level of responsibility, e.g., the state police rather than the local= police.  

 =

On Mon, Feb 18, 2013 at 4:21 PM,= Winterbottom, James <James.Winterbottom@commscope.com> wrote:

= I think I am missing something here, A1 is part of the location, so why does= it need to be in the URN at all?

As far as I understand current d= eployments, they use the URN to select a layer in the GIS that corresponds t= o the service type, and then use geographic boundaries within that layer to = select the final destination.=

 <= /u>

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On B= ehalf Of Dan Mongrain
Sent: Tuesday, 19 February 2013 7:30 AM<= /span>


To: Ivo Sedlacek
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service= :sos

=

 

Sorry for responding late to this thread, it = kinda fell into a  crack…  The current thread reminded me to= check this old thread…=

 <= /u>

You are indicating = that we need to register 77 Service URN (11 service subtypes * 7 jurisdictio= n types based on RFC 4119).  I do not recommend that we create so many = registrations.  Instead, we should allow a service URN to be suffixed w= ith a jurisdictional scope.  So the following Service URN are all valid= :

 

urn:service:sos.police

urn:service:so= s.police.traffic

urn:service:sos.police.A1

urn:service:s= os.police.traffic.A1

 

Question is, do we want to l= eave jurisdictional scope to only be applicable to police branch or any Serv= ice URN?  I’d say the latter as it is always up to the LoST servi= ce provisioning (based on local policy) to determine what is locally accepta= ble.

=  

Thanx,

Dan

<= /div>

 

 =

 


_______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/= mailman/listinfo/ecrit
--B_3444194887_112258-- From dan@mongrain.org Wed Feb 20 09:13:12 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4352221F8803 for ; Wed, 20 Feb 2013 09:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[AWL=0.975, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qD7P7-J4OVQL for ; Wed, 20 Feb 2013 09:13:09 -0800 (PST) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by ietfa.amsl.com (Postfix) with ESMTP id 6E98721F87D1 for ; Wed, 20 Feb 2013 09:13:09 -0800 (PST) Received: by mail-ob0-f176.google.com with SMTP id v19so7763617obq.7 for ; Wed, 20 Feb 2013 09:13:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=TSjfvRFroMhrG5Zjy7GG6iUhK6JErYRcwcOFN/bjyj0=; b=b7iQfY1vMeEToQJWoOFYyu5JZRITi99iZEWTWBQpiCN98iTP3iX+QHzSh2bVRWdRaQ bDAUp83uan9TC3EVwAvmxQWD3IezgW+jSvqKCvpU+RVoUwTW7Dz9TSrtKQyzglQV1EvG Ze3INmJ9nJ/0uv6GQnB4h3UEG7hsfNHUyjIK2pIJ+nw8/LvpGry69WzKay9h1cHbWTxH bGsFvhstIBfk0cInWItFyGfvUHS7Zc9NgDMdYXtFdkm3TnhZghWV0kMqrV8HSvNm5n9Z lhEwLp7d2ugPUmrruFBYdjHdfCR41hPirq3KDxsTcGH1xT29M94eR/kBC2DcNvkas58t T+sw== MIME-Version: 1.0 X-Received: by 10.60.13.162 with SMTP id i2mr9615103oec.121.1361380388749; Wed, 20 Feb 2013 09:13:08 -0800 (PST) Received: by 10.60.3.130 with HTTP; Wed, 20 Feb 2013 09:13:08 -0800 (PST) X-Originating-IP: [209.87.237.3] In-Reply-To: References: <39B5E4D390E9BD4890E2B3107900610109A5A8@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610109A6A7@ESESSMB301.ericsson.se> <5A55A45AE77F5941B18E5457ECAC81880121407712CD@SISPE7MB1.commscope.com> Date: Wed, 20 Feb 2013 12:13:08 -0500 Message-ID: From: Dan Mongrain To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=e89a8fb2011879c06a04d62b12fe X-Gm-Message-State: ALoCoQnoO5fo8ydH8+HPcsF4bMClY/LTTfFlJtCJP8eY0IJjadJ0TghNSZ9XbR1v4RvLZ28MT3+g Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 17:13:12 -0000 --e89a8fb2011879c06a04d62b12fe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Some provincial and state police can be called directly in an emergency. This is extracted from their web sites: Kentucky: "If you have an emergency situation, please use the Kentucky State Police Hotline phone numbersto reach us." Virginia: "For emergencies, call 9-1-1 or your local law enforcement agency or Virginia State Police office." "Dial #77 on a cellular telephone. Dial #77 on a cellular telephone. This is the most effective means to report a reckless and dangerous driver to the Virginia State Police." New Jersey: "For emergencies call 911 or your local police, sheriff, or State Police Office." Tennessee: "Contact Us Statewide via Mobile Phone: *THP (*847) for Highway Emergencies to connect to the THP District Headquarters nearest you at the time of your call." Ohio: "Contact the Patrol by Phone: #677" This is to report reckless or drunk driving." Florida: "Star FHP (*347) is a cellular phone program used by motorists to report drunk drivers, traffic crashes, stranded or disabled motorists, or any suspicious incidents occurring on Florida roadways."* * Georgia: "To report impaired drivers and highway emergencies - Dial *GSP on your cell phone or dial 911." Kansas: "Need help? Use your cellular phone to call *47 or *KTA" Qu=E9bec: "URGENCE Composez imm=E9diatement le: *4141 (pour les cellulaires= ) 24 heures sur 24, 7 jours sur 7" The Kansas State Highway Patrol website at " http://www.kansashighwaypatrol.org/about/state_contact.html" displays the emergency contact numbers for all 50 US states. A majority of the states have a number where to reach the state police directly. So there is already a well established practice of calling another number other than 9-1-1 (for US and Canada) for reporting emergencies to the state/provincial authorities. Also, in some states (California and Massachusetts come to mind) all mobile emergency calls are sent to state police (this is from the original assumption that mobile 9-1-1 calls were to report traffic emergencies). This basically means that for the same location, there are two different PSAPs depending on the source of the call. I think the demonstration is made that we need a Service URN to be able to specify the desired jurisdiction for a given location. My proposal for using RFC 4119 nomenclature allows for this and gets around the whole issue of local terminology (city vs. municipal, state vs. province, national vs. federal, etc.). The problem with using urn:service:sos.police.traffic" is that there are two agencies that provide assistance for traffic emergencies depending on where it occurs. On state/provincial highways and freeways you can call the state/provincial police where elsewhere you call the city or county police. As for signalling on the ESInet, in the E9-1-1 system there is already the concept of "Selective Transfers" where the primary PSAP that answers the 9-1-1 call transfers the call to the appropriate secondary PSAP based on the caller's location. The calltaker uses star codes (such as *11 for police, *12 for fire, *13 for medical, *14 for sheriff, *15 for state police, etc.) and the Selective Router selects the appropriate secondary PSAP based on the caller's location (the territory is divided into Emergency Services Zones and each zone has translation tables for specifying where each star code points to). A calltaker does not need to specify the exact agency to direct an emergency call to and also can cover a much larger geographic area where there is a multitude of secondary agencies. In NG9-1-1, the star codes are replaced with Service URNs which will specify not only the service subtype ".police, .fire, .medical, etc.) but also the jurisdiction in the case there are multiple agencies that provide the same service subtype (such as .police). By looking at the source of the request, a LoST service can either ignore service subtypes (as in the case of a call from a citizen that requests .fire or .medical) or respect the service subtype (when requests comes from a PSAP). The provisioning of the LoST service is always based on local policies. For states that do not allow emergency calls to be routed directly to the state police, findService requests for urn:service:sos.police.A2 can return the URI for urn:service:sos. Thanx, Dan ** * * On Wed, Feb 20, 2013 at 3:03 AM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > ** ** ** ** ** ** ** > > You seem to be assuming that a call to the police is automatically an > emergency call.**** > > ** ** > > My understanding is that most police forces advertise these local numbers > specifically for cases where it is NOT an emergency call. As a quick > reference to Wikipedia (incomplete but readily available) shows only one > number for ****Canada****.**** > > ** ** > > I would like you to describe your case for signalling calls within an > Esinet and I do not believe these cases were considered when RFC 5031 was > developed nor are they written into the scope of that document That is no= t > described in any RFC, and if we are extending to that capability, it woul= d > help to know which decision points are made using service URNs, and > consider whether that is better than other solutions.**** > > ** ** > > For the accidents on freeway, see my summary posting made recently. You > will see that other countries, e.g. ****China**** have these as an > entirely separate emergency service, and in my belief that should probabl= y > not be sos.police=85. but sos.trafficemergency.**** > > ** ** > > Keith**** > > ** ** > ------------------------------ > > *From:* Dan Mongrain [mailto:dan@mongrain.org] > *Sent:* 20 February 2013 04:23 > *To:* DRAGE, Keith (Keith) > *Cc:* Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos (trimming due too large > message report)**** > > ** ** > > My recommendation for handling unknown Service URN depends if LoST servic= e > implements jurisdictional scope or not. If it does not, it pops the last > element and evaluates until a service is found. If it implements > jurisdictional scope, the last element is a jurisdictional scope and it i= s > not found, then you return the next highest level defined. > > While it may be true that citizens typically dial 9-1-1 to request for > help, police services such as state or provincial polices advertises > numbers to call them directly (star code to dial using a mobile phone for > example) especially to report accidents on freeways. We need an equivale= nt > Service URN. > > Also while RFC5031's scope is citizen to authorities (I am not sure I > agree with this) I do not want to re-invent the wheel to signal calls > within an Emergency Services IP Network (ESInet). When I transfer a call > from one PSAP to another, the mechanism to determine where to send the ca= ll > is the same, using LoST. For a PSAP that covers a large area spanning > multiple counties and the calltaker needs to transfer the call to the > appropriate sheriff department for the caller's location, they only need = a > single transfer target (urn:service:sos.police.A2). It is not true that > the calltaker always knows the actual destination of the call, especially > when the calltaker is only a call screener. > > Thanx, > Dan**** > > On Tue, **Feb 19, 2013** at **7:18 PM**, DRAGE, Keith (Keith) < > keith.drage@alcatel-lucent.com> wrote:**** > > The answer to James=92s question depends on how you code it (and also wha= t > you mean by fallback).**** > > **** > > On any service URN, you ignore any subtypes from the point you stop > understanding it.**** > > **** > > So if the coding is sos.police.A2, and you do not understand A2, then the > service URN would be handled as if it was sos.police, not as sos.police.A= 1. > And if police was not understood then it would be handled as sos.**** > > **** > > If you wanted something that went back to the next larger regional > coverage, then you would have to code successive subtypes in sequence.***= * > > **** > > But I would also ask for an element of sanity in this discussion, rather > than total flexibility.**** > > **** > > For example while a national administration may have multiple levels of > police force, not all of them are either reachable directly as an emergen= cy > service provider, nor are they necessarily an emergency service provider. > If they are neither of these, then they presumably do not need a special > and distinct service URN. **** > > **** > > It would therefore nice to see a current use case that is anything but a > choice of two, i.e. countrywide (following the **ITU**-T E.164 definition > of country) versus one more local variant. This restricted model certainl= y > covers Ivo=92s examples of **Czeck** **Republic** and **Poland**, and I > believe it also covers the other example I know of which is ****Italy****= . > **** > > **** > > While the ****USA**** has multiple levels of police force, on the PSTN, > it only appears to have one level of access to citizen to authority > emergency service, which is 911. I see no reason why a change to voice ov= er > IP would cause a change to this.**** > > **** > > I would also stress that it is important to have global expectations of > what you get when you use a service URN. If there is not care excercised > with assigning semantics and values, A3 in one country could result in th= e > forestry police and in another country the financial police responding.**= * > * > > **** > > Note that read the scope of RFC 5031 as being for end user accessing the > emergency service. While it might be possible to apply RFC 5031 to furthe= r > network operations after the PSAP has been reached, e.g. to reach a > subsidiary PSAP, I read that as outside the scope of RFC 5031. Nor do I > necessarily believe in that scenario that service URNs are necessarily th= e > best solution for routeing, as the first PSAP should know the particular > office they want to reach rather than just the type of emergency service.= * > *** > > **** > > Regards**** > > **** > > Keith**** > > **** > ------------------------------ > > *From:* ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behalf > Of *Winterbottom, James > *Sent:* 19 February 2013 23:29 > *To:* Ivo Sedlacek; Dan Mongrain > *Cc:* ecrit@ietf.org > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos (trimming due too large > message report)**** > > **** > > I am okay with this, providing that the fallback order is clearly defined= . > **** > > That is, does an A3 fall back to an A2 or A1, or just back to sos?**** > > **** > > **** > > **** > > *From:* Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] > *Sent:* Wednesday, 20 February 2013 **7:32 AM** > *To:* Dan Mongrain > *Cc:* Winterbottom, James; Richard Barnes; ecrit@ietf.org > *Subject:* RE: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos (trimming due too large > message report)**** > > **** > > Hello,**** > > **** > > If we go with RFC4119 based sub-services, would the IANA registration > request be as follows?**** > > **** > > - urn:service:sos.police*.A3* - The 'police.local' service refers to the > emergency service offered by the police department or other law enforceme= nt > authorities of the authorities *of a city, township, shi (JP)*.**** > > - urn:service:sos.police*.country* - The 'police.national' service refers > to the emergency service offered by the police department or other law > enforcement authorities of the government *of a country*.**** > > **** > > Does anyone see any issue in that?**** > > **** > > If WG prefers this, it is OK for me.**** > > **** > > > In the latter case, so how do I get the county police (or state police, > there can be up to 4 police services for a given location in the ****US**= * > *). **** > > **** > > If I got it correctly, you propose that we also add **** > > - urn:service:sos.police*.A2* - The 'police.local' service refers to the > emergency service offered by the police department or other law enforceme= nt > authorities of the authorities *of county, parish, gun (JP), district (IN= ) > *"**** > > - urn:service:sos.police*.A1* - The 'police.local' service refers to the > emergency service offered by the police department or other law enforceme= nt > authorities of the authorities *of national subdivisions (state, region, > province, prefecture)*"**** > > **** > > While I have no problem with that, I am not aware of a regulation > establishing such emergency service so I cannot argue to IANA that the > RFC5031 policy is satisfied for those URNs.**** > > **** > > Kind regards**** > > **** > > Ivo Sedlacek**** > > **** > > **** > > **** > > **** > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out at www.ericsson.com/email_disclaimer **** > > *From:* Dan Mongrain [mailto:dan@mongrain.org ] > *Sent:* 19. =FAnora 2013 21:12 > *To:* Ivo Sedlacek > *Cc:* Winterbottom, James; Richard Barnes; ecrit@ietf.org > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos (trimming due too large > message report)**** > > **** > > Thing is, when there is no city police, local would give you county polic= e > (sheriff department) but in a city with a city police department local > would give you city police. In the latter case, so how do I get the coun= ty > police (or state police, there can be up to 4 police services for a given > location in the ****US****). Note that these examples are US based, but > we do have 3 levels of police services in ****Canada**** and I am sure > other countries have the same issue.**** > > **** > > There is also the terminology. There is no "national" police in the **US= * > * or ****Canada**** but there is a federal police. Keeping the RFC 4119 > terminology removes any "local" interpretation issues. > > Dan**** > > On Tue, **Feb 19, 2013** at **2:31 PM**, Ivo Sedlacek < > ivo.sedlacek@ericsson.com> wrote:**** > > I agree with Richard - there are countries where both the emergency > service of the national police and the emergency service of the municipal > police are offered in a given location. **** > > A user would call the municipal police emergency service to report e.g. > pickpockets.**** > > A user would call the national police emergency service to report e.g. a > murder.**** > > **** > > **** > > I submitted to IANA a request to register:**** > > - urn:service:sos.police.local - The 'police.local' service refers to the > emergency service offered by the police department or other law enforceme= nt > authorities of the local or municipal authorities.**** > > - urn:service:sos.police.national - The 'police.national' service refers > to the emergency service offered by the police department or other law > enforcement authorities of the national government.**** > > **** > > RFC5031 policy is hopefully fulfilled for them since they exist in two > countries.**** > > **** > > I am flexible whether the actual URNs contain the sub-services proposed > above (i.e. .local and .national sub-services) or subservices based on > RFC4119 (i.e. .A3 and .country sub-services).**** > > **** > > If the preference is for subservices based on RFC4119, do I need to make > another IANA registration request or can we modify the URNs and their > description during the expert review?**** > > **** > > Kind regards**** > > **** > > Ivo Sedlacek**** > > **** > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out at www.ericsson.com/email_disclaimer **** > > *From:* Dan Mongrain [mailto:dan@mongrain.org] > *Sent:* 19. =FAnora 2013 15:36 > *To:* Winterbottom, James > *Cc:* Richard Barnes; Ivo Sedlacek; ecrit@ietf.org > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > **** > > The problem is that different countries has different names for their > political subdivisions. In the **US** they are states, in ****Canada****= they are provinces, etc. Same when you further subdivide. While not privy > to the discussions that came up with A1, A2, =85, A5, I have the feeling = this > nomenclature was picked for the same reason. Why not utilise the same > naming scheme for specifying the jurisdiction you want to reach?**** > > **** > > Thanx,**** > > Dan**** > > **** > > On Mon, **Feb 18, 2013** at **5:01 PM**, Winterbottom, James < > James.Winterbottom@commscope.com> wrote:**** > > In that case, one might say state in the hierarchy, not A1.**** > > **** > > Cheers**** > > James**** > > **** > > **** > > *From:* Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* Tuesday, 19 February 2013 **8:57 AM** > *To:* Winterbottom, James > *Cc:* Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org**** > > > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > **** > > It might make sense if you wanted to allow the caller to explicitly selec= t > police at a different level of responsibility, e.g., the state police > rather than the local police. **** > > **** > > On Mon, **Feb 18, 2013** at **4:21 PM**, Winterbottom, James < > James.Winterbottom@commscope.com> wrote:**** > > I think I am missing something here, A1 is part of the location, so why > does it need to be in the URN at all?**** > > As far as I understand current deployments, they use the URN to select a > layer in the **GIS** that corresponds to the service type, and then use > geographic boundaries within that layer to select the final destination.*= * > ** > > **** > > *From:* ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behalf > Of *Dan Mongrain > *Sent:* Tuesday, 19 February 2013 **7:30 AM****** > > > *To:* Ivo Sedlacek > *Cc:* ecrit@ietf.org > *Subject:* Re: [Ecrit] What is the most appropriate method for > registering new sub-services of urn:service:sos**** > > **** > > Sorry for responding late to this thread, it kinda fell into a crack=85 > The current thread reminded me to check this old thread=85**** > > **** > > You are indicating that we need to register 77 Service URN (11 service > subtypes * 7 jurisdiction types based on RFC 4119). I do not recommend > that we create so many registrations. Instead, we should allow a service > URN to be suffixed with a jurisdictional scope. So the following Service > URN are all valid:**** > > **** > > urn:service:sos.police**** > > urn:service:sos.police.traffic**** > > urn:service:sos.police.A1**** > > urn:service:sos.police.traffic.A1**** > > **** > > Question is, do we want to leave jurisdictional scope to only be > applicable to police branch or any Service URN? I=92d say the latter as = it > is always up to the LoST service provisioning (based on local policy) to > determine what is locally acceptable.**** > > **** > > Thanx,**** > > Dan**** > > **** > > **** > > ** ** > --e89a8fb2011879c06a04d62b12fe Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Some provincial and state police can be called directly in an emergency. Th= is is extracted from their web sites:

Kentucky: "If you h= ave an emergency situation, please use the = Ke= ntucky State Police Hotline phone numbers to reach us."
Virginia: "For emergencies, call 9-1-1 or your local law enforce= ment agency or Virginia State Police office." "Dial #77 on = a cellular telephone. Dial #77 on a cellular telephone.=20 =A0This is the most effective means to report a reckless and dangerous=20 driver to the Virginia State Police."
New Jersey: "For emergencies call 911 or your=20 local police, sheriff, or State Police Office."
T= ennessee: "Contact = Us Statewide via Mobile Phone: *THP (*847) for Highway Emergencies to conne= ct to the THP District Headquarters nearest you at the time of your call.&= quot;
Ohio: "Conta= ct the Patrol by Phone: #677&qu= ot; This is to report re= ckless or drunk driving."
Florida: "Star FHP (*347) is a cellular phone program used by motorists to = report=20 drunk drivers, traffic crashes, stranded or disabled motorists, or any=20 suspicious incidents occurring on Florida roadways."
<= /b>
Georgia: "To report impa= ired drivers and highway emergencies - Dial *GSP on your cell phone or dial= 911."
Kansas: "Need help? Use your cellular phone to call *47= or *KTA"
Qu=E9bec: "URGENCE Composez imm=E9diatement le: *4141 (pour les cellul= aires) 24 heures sur 24, 7 jours sur 7"

The Kansas State Highwa= y Patrol website at "http://www.kansashighwaypatrol.org/about/state_conta= ct.html" displays the emergency contact numbers for all 50 US stat= es.=A0 A majority of the states have a number where to reach the state poli= ce directly.

So there is already a well established practice of calling another=20 number other than 9-1-1 (for US and Canada) for reporting emergencies to the state/provincial authorities.

Also, in some states (California = and Massachusetts come to mind) all=20 mobile emergency calls are sent to state police (this is from the=20 original assumption that mobile 9-1-1 calls were to report traffic=20 emergencies).=A0 This basically means that for the same location, there=20 are two different PSAPs depending on the source of the call.

I think= the demonstration is made that we need a Service URN to be able to specify= the desired jurisdiction for a given location.=A0 My proposal for using RF= C 4119 nomenclature allows for this and gets around the whole issue of loca= l terminology (city vs. municipal, state vs. province, national vs. federal= , etc.).

The problem with using urn:service:sos.police.traffic" is that the= re are two agencies that provide assistance for traffic emergencies depending=20 on where it occurs.=A0 On state/provincial highways and freeways you can=20 call the state/provincial police where elsewhere you call the city or=20 county police.

As for signalling on the ESInet, in the E9-1-1 system= there is already the concept of "Selective Transfers" where the = primary PSAP that answers the 9-1-1 call transfers the call to the appropri= ate secondary PSAP based on the caller's location.=A0 The calltaker use= s star codes (such as *11 for police, *12 for fire, *13 for medical, *14 fo= r sheriff, *15 for state police, etc.) and the Selective Router selects the= appropriate secondary PSAP based on the caller's location (the territo= ry is divided into Emergency Services Zones and each zone has translation t= ables for specifying where each star code points to).=A0 A calltaker does n= ot need to specify the exact agency to direct an emergency call to and also= can cover a much larger geographic area where there is a multitude of seco= ndary agencies.=A0 In NG9-1-1, the star codes are replaced with Service URN= s which will specify not only the service subtype ".police, .fire, .me= dical, etc.) but also the jurisdiction in the case there are multiple agenc= ies that provide the same service subtype (such as .police).=A0 By looking = at the source of the request, a LoST service can either ignore service subt= ypes (as in the case of a call from a citizen that requests .fire or .medic= al) or respect the service subtype (when requests comes from a PSAP).

The provisioning of the LoST service is always based on local policies.= =A0 For states that do not allow emergency calls to be routed directly to t= he state police, findService requests for urn:service:sos.police.A2 can ret= urn the URI for urn:service:sos.

Thanx,
Dan
=
=20
=20 =20
=20

On Wed, Feb 20, 2013 at 3:03 AM, DRAGE, Ke= ith (Keith) <keith.drage@alcatel-lucent.com> wr= ote:

You seem to be assuming that = a call to the police is automatically an emergency call.

=A0

My understanding is that most= police forces advertise these local numbers specifically for cases where it is NOT= an emergency call. As a quick reference to Wikipedia (incomplete but readily available) shows only one number for Canada.=

=A0

I would like you to describe = your case for signalling calls within an Esinet and I do not believe these cases were considered when RFC 5031 was developed nor are they written into the scope = of that document That is not described in any RFC, and if we are extending to = that capability, it would help to know which decision points are made using serv= ice URNs, and consider whether that is better than other solutions.

=A0

For the accidents on freeway,= see my summary posting made recently. You will see that other countries, e.g. <= /u>China =A0have these as an entirely separate emergency service, and in my belief that shou= ld probably not be sos.police=85. but sos.trafficemergency.

=A0

Keith

=A0

From: Dan Mongrain [mailto:= dan@mongrain.org]
Sent: 20 February 2013 04:23=
To: DRAGE, Keith (Keith)
Cc: Winterbottom, James; Ivo Sedlacek; ecrit@ietf.or= g
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)<= u>

=A0

My recommendation for handling unknown Service URN depends if LoST service implements jurisdictio= nal scope or not.=A0 If it does not, it pops the last element and evaluates until a service is found.=A0 If it implements jurisdictional scope, the las= t element is a jurisdictional scope and it is not found, then you return the = next highest level defined.

While it may be true that citizens typically dial 9-1-1 to request for help= , police services such as state or provincial polices advertises numbers to c= all them directly (star code to dial using a mobile phone for example) especially to report accidents on freeways.=A0 We need an equivalent Service URN.

Also while RFC5031's scope is citizen to authorities (I am not sure I a= gree with this) I do not want to re-invent the wheel to signal calls within an Emergency Services IP Network (ESInet).=A0 When I transfer a call from one PSAP to another, the mechanism to determine where to send the call is the s= ame, using LoST.=A0 For a PSAP that covers a large area spanning multiple counties and the calltaker needs to transfer the call to the appropriate sheriff department for the caller's location, they only need a single t= ransfer target (urn:service:sos.police.A2).=A0 It is not true that the calltaker always knows the actual destination of the call, especially when the callta= ker is only a call screener.

Thanx,
Dan

On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:

The answer to James=92s quest= ion depends on how you code it (and also what you mean by fallback).

=A0

On any service URN, you ignor= e any subtypes from the point you stop understanding it.

=A0

So if the coding is sos.polic= e.A2, and you do not understand A2, then the service URN would be handled as if it was sos.police, not as sos.police.A1. And if police was not understood then it would be handled as sos.

=A0

If you wanted something that = went back to the next larger regional coverage, then you would have to code successive subtypes in sequence.

=A0

But I would also ask for an e= lement of sanity in this discussion, rather than total flexibility.

=A0

For example while a national = administration may have multiple levels of police force, not all of them are either reachable directly as an emergency service provider, nor are they necessarily an emergency service provider. If they are neither of these, then they presumably do not need a special and distinct service URN.

=A0

It would therefore nice to se= e a current use case that is anything but a choice of two, i.e. countrywide (following the ITU-T E.164 definition of country) versus one more local variant. This restricted model certainly covers Ivo=92s examples of Czeck Republic and Poland, and I believe it also cove= rs the other example I know of which is Italy.=

=A0

While the USA has multiple levels of police force, on the PSTN, it only appears to have o= ne level of access to citizen to authority emergency service, which is 911. I = see no reason why a change to voice over IP would cause a change to this.

=A0

I would also stress that it i= s important to have global expectations of what you get when you use a service URN. If there is not ca= re excercised with assigning semantics and values, A3 in one country could res= ult in the forestry police and in another country the financial police respondi= ng.

=A0

Note that read the scope of R= FC 5031 as being for end user accessing the emergency service. While it might be possible to apply RFC 50= 31 to further network operations after the PSAP has been reached, e.g. to reac= h a subsidiary PSAP, I read that as outside the scope of RFC 5031. Nor do I necessarily believe in that scenario that service URNs are necessarily the = best solution for routeing, as the first PSAP should know the particular office = they want to reach rather than just the type of emergency service.=

=A0

Regards<= u>

=A0

Keith=

=A0

From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Winterbottom, J= ames
Sent: 19 February 2013 23:29=
To: Ivo Sedlacek; Dan Mongra= in
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

=A0

I am= okay with this, providing that the fallback order is clearly defined.

That= is, does an A3 fall back to an A2 or A1, or just back to sos?

=A0<= /span>

=A0<= /span>

=A0<= /span>

From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com]
Sent: Wednesday, 20 February= 2013 7:32 AM
To: Dan Mongrain
Cc: Winterbottom, James; Ric= hard Barnes; ecrit@ietf.org<= /a>
Subject: RE: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

=A0

Hello,=

=A0

If we = go with RFC4119 based sub-services, would the IANA registration request be as follows?<= /u>

=A0

- urn:= service:sos.police.A3=A0- The 'police.local' service refers to the emergency service offered by t= he police department or other law enforcement authorities of the authorities=A0of = a city, township, shi (JP).

- urn:= service:sos.police.country=A0- The 'police.national' service refers to the emergency service offer= ed by the police department or other law enforcement authorities of the government=A0= of a country.

=A0

Does a= nyone see any issue in that?

=A0

If WG = prefers this, it is OK for me.

=A0

> <= /span>In the latter case, so how do I get the county police (or state police, there can be up to 4 polic= e services for a given location in the US).=A0

=A0

If I g= ot it correctly, you propose that we also add

- urn:= service:sos.police.A2 - The 'police.local' service refers to the emergency service offered by t= he police department or other law enforcement authorities of the authorities=A0of county, parish, gun (JP), district (IN)"

- urn:= service:sos.police.A1 - The 'police.local' service refers to the emergency service offered by t= he police department or other law enforcement authorities of the authorities=A0of national subdivisions (state, region, province, prefecture)"

=A0

While = I have no problem with that, I am not aware of a regulation establishing such emergency service so I cannot argue= to IANA that the RFC5031 policy is satisfied for those URNs.<= /u>

=A0

Kind r= egards

=A0

Ivo Se= dlacek

=A0

=A0

=A0

=A0

This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19. =FAnora 2013 21:12=
To: Ivo Sedlacek
Cc: Winterbottom, James; Ric= hard Barnes; ecrit@ietf.org<= /a>
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos= (trimming due too large message report)

=A0

Thing is, when there is no city police, local would give you county police (sheri= ff department) but in a city with a city police department local would give yo= u city police.=A0 In the latter case, so how do I get the county police (or state police, there can be up to 4 police services for a given location in = the US).=A0 Note that these examples are US based, but we do have 3 levels of police service= s in Canada and I am sure other countries have the same issue.<= /u>

=A0<= /span>

There is also the terminology.=A0 There is no "national" police in the = US or Canada but there is a feder= al police.=A0 Keeping the RFC 4119 terminology removes any "local" interpretation issues.

Dan

On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek <ivo.sedl= acek@ericsson.com> wrote:

I agre= e with Richard - there are countries where both the emergency service of the national police and the emergency service of the municipal police are offered in a given location.

A user= would call the municipal police emergency service to report e.g. pickpockets.

A user= would call the national police emergency service to report e.g. a murder.

=A0

=A0

I subm= itted to IANA a request to register:

- urn:= service:sos.police.local - The 'police.local' service refers to the emergency service offered by the police department or other law enforcement authorities of the local or municipal authorities.

- urn:= service:sos.police.national - The 'police.national' service refers to the emergency service offered b= y the police department or other law enforcement authorities of the national government.=

=A0

RFC503= 1 policy is hopefully fulfilled for them since they exist in two countries.

=A0

I am f= lexible whether the actual URNs contain the sub-services proposed above (i.e. .local and .national sub-services) or subservices based on RFC4119 (i.e. .A3 and .country sub-services).

=A0

If the= preference is for subservices based on RFC4119, do I need to make another IANA registration request or can we modi= fy the URNs and their description during the expert review?

=A0

Kind r= egards

=A0

Ivo Se= dlacek

=A0

This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19. =FAnora 2013 15:36=
To: Winterbottom, James
Cc: Richard Barnes; Ivo Sedl= acek; ecrit@ietf.org
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos=

=A0

The = problem is that different countries has different names for their political subdivisions.=A0 In the US they are states, in Canada they are provinces, etc.=A0 Same when you further subdivide.=A0 While not privy to the discussions that came up with A1, A2, =85, A5, I have the feeling this nomenclature was picked for the same reason.=A0 Why not utilise the same naming scheme for specifying the jurisdiction you want to reach?

=A0<= /span>

Than= x,

Dan<= /span>

=A0

On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James <James.Winterbottom@commscope.com> wrote:

In t= hat case, one might say state in the hierarchy, not A1.

=A0<= /span>

Chee= rs

Jame= s

=A0<= /span>

=A0<= /span>

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Tuesday, 19 February 2= 013 8:57 AM
To: Winterbottom, James
Cc: Dan Mongrain; Ivo Sedlac= ek; ecrit@ietf.org<= /span>


Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos

=A0

It might make sense if you wanted to allow the caller to explicitly select pol= ice at a different level of responsibility, e.g., the state police rather than = the local police. =A0

=A0

On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James <James.Winterbottom@commscope.com> wrote:

I th= ink I am missing something here, A1 is part of the location, so why does it need to be in the URN at all?

As f= ar as I understand current deployments, they use the URN to select a layer in the GIS that corresponds to the service type, and then use geographic boundaries wi= thin that layer to select the final destination.

=A0<= /span>

From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Dan Mongrain Sent: Tuesday, 19 February 2= 013 7:30 AM


To: Ivo Sedlacek
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos=

=A0

Sorr= y for responding late to this thread, it kinda fell into a=A0 crack=85=A0 The current thread reminded me to check this old thread=85

=A0<= /span>

You = are indicating that we need to register 77 Service URN (11 service subtypes * 7 jurisdiction types based on RFC 4119).=A0 I do not recommend that we create so many registrations.=A0 Instead, we should allow a service URN to be suffixed with a jurisdictional scope.=A0 So the following Service URN are all valid:<= u>

=A0<= /span>

urn:= service:sos.police

urn:= service:sos.police.traffic

urn:= service:sos.police.A1

urn:= service:sos.police.traffic.A1

=A0<= /span>

Ques= tion is, do we want to leave jurisdictional scope to only be applicable to police branch or any Service = URN? =A0I=92d say the latter as it is always up to the LoST service provisioning (based on local policy) to determine what is locally acceptabl= e.

=A0<= /span>

Than= x,

Dan<= /span>

=A0

=A0

=A0


--e89a8fb2011879c06a04d62b12fe-- From dan@mongrain.org Wed Feb 20 09:30:08 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF1421F85D7 for ; Wed, 20 Feb 2013 09:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.644 X-Spam-Level: X-Spam-Status: No, score=-1.644 tagged_above=-999 required=5 tests=[AWL=0.732, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmZd8IPpQlN1 for ; Wed, 20 Feb 2013 09:30:04 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E258E21F8522 for ; Wed, 20 Feb 2013 09:30:03 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id tb18so7996311obb.3 for ; Wed, 20 Feb 2013 09:30:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=xDKifjbttvU6loS/4uK/+olQiRuXFQKHXzJ6XRSNQvk=; b=fo/rHqAWP6sR12ntV0VfQBQrKO4CKFQRGxt+ugcIrI3KW/BnxSFGguoaznRKXbwAUN gX7ljcUWjqk7wCknKS9p5fdnM8cBK5Djc/51EhgHsf21bBNFAAO8WjkovZ3yHEj5/Cna uTJ43zrDOh0ImP0dgLFZQ0ch+3eUxBm/QqAHbDEx4upOhEOtOEpBhIVUpAYYZaqPX2EA dx5TrXG4QYYvwKXgqMjqMW+bSBZQb2AZqHPVu5AvpWhthEbInXAQ+vWx64fW2S5abrgx Ps0rKbF4P6gU03Kq0+BxmJI8+8QGFLQ5Vd4vxdaCCgS01KnjKBEX8CwAEn6/13qZbp6C NSPw== MIME-Version: 1.0 X-Received: by 10.60.13.162 with SMTP id i2mr9639375oec.121.1361381402943; Wed, 20 Feb 2013 09:30:02 -0800 (PST) Received: by 10.60.3.130 with HTTP; Wed, 20 Feb 2013 09:30:02 -0800 (PST) X-Originating-IP: [209.87.237.3] In-Reply-To: References: Date: Wed, 20 Feb 2013 12:30:02 -0500 Message-ID: From: Dan Mongrain To: Marc Linsner Content-Type: multipart/alternative; boundary=e89a8fb20118ed1f9204d62b4ef2 X-Gm-Message-State: ALoCoQk27lY/nJKjOWR7/HKDTNTc7If1tINS99lQ4NixdCwca1w4zC5Ssf1n85udfyZeSOGm/QL6 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 17:30:08 -0000 --e89a8fb20118ed1f9204d62b4ef2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I do not understand your comment. What I am proposing is that requests do not specify a search pattern in the case a requested jurisdiction is not found. It should not be to the requester which submits urn:service:sos.police.country.A1.A2.A3.A4 to specify what to do if there is nothing configured for the A4 layer. It must be up to the LoST service to apply whatever policy it has in this case. If we allow this, then do we allow urn:service:sos.police.fire? Give me fire first but if not found give me police? The Service URN should specify the "desired" service in a findService request and the LoST service provides a response based on local policies. All I am proposing is that one can specify a jurisdiction in the case there are more then one service provider for a location. Thanx, Dan On Wed, Feb 20, 2013 at 8:48 AM, Marc Linsner wrote: > The findService request includes location information. Why wouldn't the > LoST server simple walk the A1-A6 tree included with the location? If > location is geo, reverse geocode it. > > What am I missing? > > -Marc- > > From: Dan Mongrain > Date: Tuesday, February 19, 2013 11:55 PM > To: "Winterbottom, James" > Cc: "ecrit@ietf.org" > Subject: Re: [Ecrit] What is the most appropriate method for registering > new sub-services of urn:service:sos (trimming due too large message repor= t) > > What I meant is that if a jurisdictional scope aware LoST service receive= s > a request for urn:service:sos.police.A4 and nothing is configured, it loo= ks > for urn:service:sos.police.A3 then urn:service:sos.police.A2, etc. until = it > finds a configured service. If nothing is found for > urn:service:sos.police.country then it pops the last element and looks fo= r > urn:service:sos.police (but then again, it is no longer jurisdictional > scope aware). > > I disagree that one needs to formulate the request as > urn:service:sos.police.country.A1.A2.A3.A4 in order for this to happen. > There must be only a single jurisdictional scope appended to a Service UR= N. > > I do not think we need a .A6 jurisdictional scope (street level). .A5 > (neighborhood, would point to a precinct for example) provides enough > granularity in my opinion. > > Thanx, > Dan > > > On Tue, Feb 19, 2013 at 11:29 PM, Winterbottom, James < > James.Winterbottom@commscope.com> wrote: > >> I am sorry, I am finding this confusing.**** >> >> ** ** >> >> RFC5139 puts a hierarchy on A1 through A6. If you want this hierarchy to >> work then A1 through A6 can=92t be at the same level if you expect A3 to >> fallback to A2 or A1 in the case of a service not existing or a service >> failure of some kind. If they exist at the same level then if A3 doesn= =92t >> exist you will go to urn:service:sos.police unless you impose the >> hierarchy in the urn.**** >> >> ** ** >> >> ** ** >> >> ** ** >> >> ** ** >> >> ** ** >> >> *From:* Dan Mongrain [mailto:dan@mongrain.org] >> *Sent:* Wednesday, 20 February 2013 3:23 PM >> *To:* DRAGE, Keith (Keith) >> *Cc:* Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org >> *Subject:* Re: [Ecrit] What is the most appropriate method for >> registering new sub-services of urn:service:sos (trimming due too large >> message report)**** >> >> ** ** >> >> My recommendation for handling unknown Service URN depends if LoST >> service implements jurisdictional scope or not. If it does not, it pops >> the last element and evaluates until a service is found. If it implemen= ts >> jurisdictional scope, the last element is a jurisdictional scope and it = is >> not found, then you return the next highest level defined. >> >> While it may be true that citizens typically dial 9-1-1 to request for >> help, police services such as state or provincial polices advertises >> numbers to call them directly (star code to dial using a mobile phone fo= r >> example) especially to report accidents on freeways. We need an equival= ent >> Service URN. >> >> Also while RFC5031's scope is citizen to authorities (I am not sure I >> agree with this) I do not want to re-invent the wheel to signal calls >> within an Emergency Services IP Network (ESInet). When I transfer a cal= l >> from one PSAP to another, the mechanism to determine where to send the c= all >> is the same, using LoST. For a PSAP that covers a large area spanning >> multiple counties and the calltaker needs to transfer the call to the >> appropriate sheriff department for the caller's location, they only need= a >> single transfer target (urn:service:sos.police.A2). It is not true that >> the calltaker always knows the actual destination of the call, especiall= y >> when the calltaker is only a call screener. >> >> Thanx, >> Dan**** >> >> On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) < >> keith.drage@alcatel-lucent.com> wrote:**** >> >> The answer to James=92s question depends on how you code it (and also wh= at >> you mean by fallback).**** >> >> **** >> >> On any service URN, you ignore any subtypes from the point you stop >> understanding it.**** >> >> **** >> >> So if the coding is sos.police.A2, and you do not understand A2, then th= e >> service URN would be handled as if it was sos.police, not as sos.police.= A1. >> And if police was not understood then it would be handled as sos.**** >> >> **** >> >> If you wanted something that went back to the next larger regional >> coverage, then you would have to code successive subtypes in sequence.**= * >> * >> >> **** >> >> But I would also ask for an element of sanity in this discussion, rather >> than total flexibility.**** >> >> **** >> >> For example while a national administration may have multiple levels of >> police force, not all of them are either reachable directly as an emerge= ncy >> service provider, nor are they necessarily an emergency service provider= . >> If they are neither of these, then they presumably do not need a special >> and distinct service URN. **** >> >> **** >> >> It would therefore nice to see a current use case that is anything but a >> choice of two, i.e. countrywide (following the ITU-T E.164 definition of >> country) versus one more local variant. This restricted model certainly >> covers Ivo=92s examples of Czeck Republic and Poland, and I believe it a= lso >> covers the other example I know of which is Italy.**** >> >> **** >> >> While the USA has multiple levels of police force, on the PSTN, it only >> appears to have one level of access to citizen to authority emergency >> service, which is 911. I see no reason why a change to voice over IP wou= ld >> cause a change to this.**** >> >> **** >> >> I would also stress that it is important to have global expectations of >> what you get when you use a service URN. If there is not care excercised >> with assigning semantics and values, A3 in one country could result in t= he >> forestry police and in another country the financial police responding.*= * >> ** >> >> **** >> >> Note that read the scope of RFC 5031 as being for end user accessing the >> emergency service. While it might be possible to apply RFC 5031 to furth= er >> network operations after the PSAP has been reached, e.g. to reach a >> subsidiary PSAP, I read that as outside the scope of RFC 5031. Nor do I >> necessarily believe in that scenario that service URNs are necessarily t= he >> best solution for routeing, as the first PSAP should know the particular >> office they want to reach rather than just the type of emergency service= . >> **** >> >> **** >> >> Regards**** >> >> **** >> >> Keith**** >> >> **** >> ------------------------------ >> >> *From:* ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On >> Behalf Of *Winterbottom, James >> *Sent:* 19 February 2013 23:29 >> *To:* Ivo Sedlacek; Dan Mongrain >> *Cc:* ecrit@ietf.org >> *Subject:* Re: [Ecrit] What is the most appropriate method for >> registering new sub-services of urn:service:sos (trimming due too large >> message report)**** >> >> **** >> >> I am okay with this, providing that the fallback order is clearly define= d. >> **** >> >> That is, does an A3 fall back to an A2 or A1, or just back to sos?**** >> >> **** >> >> **** >> >> **** >> >> *From:* Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] >> *Sent:* Wednesday, 20 February 2013 7:32 AM >> *To:* Dan Mongrain >> *Cc:* Winterbottom, James; Richard Barnes; ecrit@ietf.org >> *Subject:* RE: [Ecrit] What is the most appropriate method for >> registering new sub-services of urn:service:sos (trimming due too large >> message report)**** >> >> **** >> >> Hello,**** >> >> **** >> >> If we go with RFC4119 based sub-services, would the IANA registration >> request be as follows?**** >> >> **** >> >> - urn:service:sos.police*.A3* - The 'police.local' service refers to the >> emergency service offered by the police department or other law enforcem= ent >> authorities of the authorities *of a city, township, shi (JP)*.**** >> >> - urn:service:sos.police*.country* - The 'police.national' service >> refers to the emergency service offered by the police department or othe= r >> law enforcement authorities of the government *of a country*.**** >> >> **** >> >> Does anyone see any issue in that?**** >> >> **** >> >> If WG prefers this, it is OK for me.**** >> >> **** >> >> > In the latter case, so how do I get the county police (or state >> police, there can be up to 4 police services for a given location in the >> US). **** >> >> **** >> >> If I got it correctly, you propose that we also add **** >> >> - urn:service:sos.police*.A2* - The 'police.local' service refers to the >> emergency service offered by the police department or other law enforcem= ent >> authorities of the authorities *of county, parish, gun (JP), district >> (IN)*"**** >> >> - urn:service:sos.police*.A1* - The 'police.local' service refers to the >> emergency service offered by the police department or other law enforcem= ent >> authorities of the authorities *of national subdivisions (state, region, >> province, prefecture)*"**** >> >> **** >> >> While I have no problem with that, I am not aware of a regulation >> establishing such emergency service so I cannot argue to IANA that the >> RFC5031 policy is satisfied for those URNs.**** >> >> **** >> >> Kind regards**** >> >> **** >> >> Ivo Sedlacek**** >> >> **** >> >> **** >> >> **** >> >> **** >> >> This Communication is Confidential. We only send and receive email on th= e >> basis of the terms set out at www.ericsson.com/email_disclaimer **** >> >> *From:* Dan Mongrain [mailto:dan@mongrain.org ] >> *Sent:* 19. =FAnora 2013 21:12 >> *To:* Ivo Sedlacek >> *Cc:* Winterbottom, James; Richard Barnes; ecrit@ietf.org >> *Subject:* Re: [Ecrit] What is the most appropriate method for >> registering new sub-services of urn:service:sos (trimming due too large >> message report)**** >> >> **** >> >> Thing is, when there is no city police, local would give you county >> police (sheriff department) but in a city with a city police department >> local would give you city police. In the latter case, so how do I get t= he >> county police (or state police, there can be up to 4 police services for= a >> given location in the US). Note that these examples are US based, but w= e >> do have 3 levels of police services in Canada and I am sure other countr= ies >> have the same issue.**** >> >> **** >> >> There is also the terminology. There is no "national" police in the US >> or Canada but there is a federal police. Keeping the RFC 4119 terminolo= gy >> removes any "local" interpretation issues. >> >> Dan**** >> >> On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek >> wrote:**** >> >> I agree with Richard - there are countries where both the emergency >> service of the national police and the emergency service of the municipa= l >> police are offered in a given location. **** >> >> A user would call the municipal police emergency service to report e.g. >> pickpockets.**** >> >> A user would call the national police emergency service to report e.g. a >> murder.**** >> >> **** >> >> **** >> >> I submitted to IANA a request to register:**** >> >> - urn:service:sos.police.local - The 'police.local' service refers to th= e >> emergency service offered by the police department or other law enforcem= ent >> authorities of the local or municipal authorities.**** >> >> - urn:service:sos.police.national - The 'police.national' service refers >> to the emergency service offered by the police department or other law >> enforcement authorities of the national government.**** >> >> **** >> >> RFC5031 policy is hopefully fulfilled for them since they exist in two >> countries.**** >> >> **** >> >> I am flexible whether the actual URNs contain the sub-services proposed >> above (i.e. .local and .national sub-services) or subservices based on >> RFC4119 (i.e. .A3 and .country sub-services).**** >> >> **** >> >> If the preference is for subservices based on RFC4119, do I need to make >> another IANA registration request or can we modify the URNs and their >> description during the expert review?**** >> >> **** >> >> Kind regards**** >> >> **** >> >> Ivo Sedlacek**** >> >> **** >> >> This Communication is Confidential. We only send and receive email on th= e >> basis of the terms set out at www.ericsson.com/email_disclaimer **** >> >> *From:* Dan Mongrain [mailto:dan@mongrain.org] >> *Sent:* 19. =FAnora 2013 15:36 >> *To:* Winterbottom, James >> *Cc:* Richard Barnes; Ivo Sedlacek; ecrit@ietf.org >> *Subject:* Re: [Ecrit] What is the most appropriate method for >> registering new sub-services of urn:service:sos**** >> >> **** >> >> The problem is that different countries has different names for their >> political subdivisions. In the US they are states, in Canada they are >> provinces, etc. Same when you further subdivide. While not privy to th= e >> discussions that came up with A1, A2, =85, A5, I have the feeling this >> nomenclature was picked for the same reason. Why not utilise the same >> naming scheme for specifying the jurisdiction you want to reach?**** >> >> **** >> >> Thanx,**** >> >> Dan**** >> >> **** >> >> On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James < >> James.Winterbottom@commscope.com> wrote:**** >> >> In that case, one might say state in the hierarchy, not A1.**** >> >> **** >> >> Cheers**** >> >> James**** >> >> **** >> >> **** >> >> *From:* Richard Barnes [mailto:rlb@ipv.sx] >> *Sent:* Tuesday, 19 February 2013 8:57 AM >> *To:* Winterbottom, James >> *Cc:* Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org**** >> >> >> *Subject:* Re: [Ecrit] What is the most appropriate method for >> registering new sub-services of urn:service:sos**** >> >> **** >> >> It might make sense if you wanted to allow the caller to explicitly >> select police at a different level of responsibility, e.g., the state >> police rather than the local police. **** >> >> **** >> >> On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James < >> James.Winterbottom@commscope.com> wrote:**** >> >> I think I am missing something here, A1 is part of the location, so why >> does it need to be in the URN at all?**** >> >> As far as I understand current deployments, they use the URN to select a >> layer in the GIS that corresponds to the service type, and then use >> geographic boundaries within that layer to select the final destination.= * >> *** >> >> **** >> >> *From:* ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On >> Behalf Of *Dan Mongrain >> *Sent:* Tuesday, 19 February 2013 7:30 AM**** >> >> >> *To:* Ivo Sedlacek >> *Cc:* ecrit@ietf.org >> *Subject:* Re: [Ecrit] What is the most appropriate method for >> registering new sub-services of urn:service:sos**** >> >> **** >> >> Sorry for responding late to this thread, it kinda fell into a crack=85 >> The current thread reminded me to check this old thread=85**** >> >> **** >> >> You are indicating that we need to register 77 Service URN (11 service >> subtypes * 7 jurisdiction types based on RFC 4119). I do not recommend >> that we create so many registrations. Instead, we should allow a servic= e >> URN to be suffixed with a jurisdictional scope. So the following Servic= e >> URN are all valid:**** >> >> **** >> >> urn:service:sos.police**** >> >> urn:service:sos.police.traffic**** >> >> urn:service:sos.police.A1**** >> >> urn:service:sos.police.traffic.A1**** >> >> **** >> >> Question is, do we want to leave jurisdictional scope to only be >> applicable to police branch or any Service URN? I=92d say the latter as= it >> is always up to the LoST service provisioning (based on local policy) to >> determine what is locally acceptable.**** >> >> **** >> >> Thanx,**** >> >> Dan**** >> >> **** >> >> **** >> >> ** ** >> > > _______________________________________________ Ecrit mailing list > Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit > > --e89a8fb20118ed1f9204d62b4ef2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I do not understand your comment.=A0 What I am proposing is that requests d= o not specify a search pattern in the case a requested jurisdiction is not = found.=A0 It should not be to the requester which submits urn:service= :sos.police.country.A1.A2.A3.A4 to specify what to do if there is nothing c= onfigured for the A4 layer.=A0 It must be up to the LoST service to apply w= hatever policy it has in this case.=A0 If we allow this, then do we allow u= rn:service:sos.police.fire?=A0 Give me fire first but if not found give me = police?

The Service URN should specify the "desired" service in a fin= dService request and the LoST service provides a response based on local po= licies.=A0 All I am proposing is that one can specify a jurisdiction in the= case there are more then one service provider for a location.

Thanx,
Dan

On Wed, Feb 20, = 2013 at 8:48 AM, Marc Linsner <mlinsner@cisco.com> wrote:
The findService request includes location information. =A0Why w= ouldn't the LoST server simple walk the A1-A6 tree included with the lo= cation? =A0If location is geo, reverse geocode it.

What am I missing?

-Marc-

From: Dan Mongrain <dan@mongrain.org>
Date: Tuesday, February 19, 2013 11:55= PM
To: "Winterbottom, James"= ; <James.Winterbottom@commscope.com>
Cc: "ec= rit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] What is the m= ost appropriate method for registering new sub-services of urn:service:sos = (trimming due too large message report)

What I meant is that if a jurisdictional scope aware LoST service receives = a request for urn:service:sos.police.A4 and nothing is configured, it looks= for urn:service:sos.police.A3 then urn:service:sos.police.A2, etc. until i= t finds a configured service.=A0 If nothing is found for urn:service:sos.po= lice.country then it pops the last element and looks for urn:service:sos.po= lice (but then again, it is no longer jurisdictional scope aware).

I disagree that one needs to formulate the request as urn:service:sos.p= olice.country.A1.A2.A3.A4 in order for this to happen.=A0 There must be onl= y a single jurisdictional scope appended to a Service URN.

I do not = think we need a .A6 jurisdictional scope (street level).=A0 .A5 (neighborho= od, would point to a precinct for example) provides enough granularity in m= y opinion.

Thanx,
Dan


On Tue, Feb 19, 201= 3 at 11:29 PM, Winterbottom, James <James.Winterbottom@comm= scope.com> wrote:

I am sorry, I am finding this co= nfusing.

=A0

RFC5139 puts a hierarchy on A1 through A6. If you want this = hierarchy to work then A1 through A6 can=92t be at the same level if you ex= pect A3 to fallback to A2 or A1 in the case of a service not existing or a = service failure of some kind. If they exist at the same level then if A3 do= esn=92t exist you will go to urn:service:sos.police=A0 unless you impose th= e hierarchy in the urn.

=A0

=A0

=A0

=A0

=A0

From: Dan Mong= rain [mailto:dan@mong= rain.org]
Sent: Wednesday, 20 February 2013 3:23 PM
To: DRAGE, Keith= (Keith)
Cc: Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org
Subject: Re= : [Ecrit] What is the most appropriate method for registering new sub-servi= ces of urn:service:sos (trimming due too large message report)

=A0

My recommendation for handling unknown Service= URN depends if LoST service implements jurisdictional scope or not.=A0 If = it does not, it pops the last element and evaluates until a service is foun= d.=A0 If it implements jurisdictional scope, the last element is a jurisdic= tional scope and it is not found, then you return the next highest level de= fined.

While it may be true that citizens typically dial 9-1-1 to request for = help, police services such as state or provincial polices advertises number= s to call them directly (star code to dial using a mobile phone for example= ) especially to report accidents on freeways.=A0 We need an equivalent Serv= ice URN.

Also while RFC5031's scope is citizen to authorities (I am not sure= I agree with this) I do not want to re-invent the wheel to signal calls wi= thin an Emergency Services IP Network (ESInet).=A0 When I transfer a call f= rom one PSAP to another, the mechanism to determine where to send the call = is the same, using LoST.=A0 For a PSAP that covers a large area spanning mu= ltiple counties and the calltaker needs to transfer the call to the appropr= iate sheriff department for the caller's location, they only need a sin= gle transfer target (urn:service:sos.police.A2).=A0 It is not true that the= calltaker always knows the actual destination of the call, especially when= the calltaker is only a call screener.

Thanx,
Dan

On Tue, Feb = 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com&g= t; wrote:

The answer to James=92s questio= n depends on how you code it (and also what you mean by fallback).

=A0=

On any service URN, you ig= nore any subtypes from the point you stop understanding it.

=A0=

So if the coding is sos.po= lice.A2, and you do not understand A2, then the service URN would be handle= d as if it was sos.police, not as sos.police.A1. And if police was not unde= rstood then it would be handled as sos.<= u>

=A0=

If you wanted something th= at went back to the next larger regional coverage, then you would have to c= ode successive subtypes in sequence.<= /u>

=A0=

But I would also ask for a= n element of sanity in this discussion, rather than total flexibility.

=A0=

For example while a nation= al administration may have multiple levels of police force, not all of them= are either reachable directly as an emergency service provider, nor are th= ey necessarily an emergency service provider. If they are neither of these,= then they presumably do not need a special and distinct service URN.

=A0=

It would therefore nice to= see a current use case that is anything but a choice of two, i.e. countryw= ide (following the ITU-T E.164 definition of country) versus one more local= variant. This restricted model certainly covers Ivo=92s examples of Czeck = Republic and Poland, and I believe it also covers the other example I know = of which is Italy.

=A0=

While the USA has multiple= levels of police force, on the PSTN, it only appears to have one level of = access to citizen to authority emergency service, which is 911. I see no re= ason why a change to voice over IP would cause a change to this.

=A0=

I would also stress that i= t is important to have global expectations of what you get when you use a s= ervice URN. If there is not care excercised with assigning semantics and va= lues, A3 in one country could result in the forestry police and in another = country the financial police responding.=

=A0=

Note that read the scope o= f RFC 5031 as being for end user accessing the emergency service. While it = might be possible to apply RFC 5031 to further network operations after the= PSAP has been reached, e.g. to reach a subsidiary PSAP, I read that as out= side the scope of RFC 5031. Nor do I necessarily believe in that scenario t= hat service URNs are necessarily the best solution for routeing, as the fir= st PSAP should know the particular office they want to reach rather than ju= st the type of emergency service.=

=A0=

Regards

=A0=

Keith

=A0=

=

From: ecrit-bounces@ietf.org= [mailto:ec= rit-bounces@ietf.org] On Behalf Of Winterbottom, James
Sent: 19 February 2013 23:29
To: Ivo Sedlacek; Dan Mongrai= n
Cc: ecrit@i= etf.org
Subject: Re: [Ecrit] What is the most appropriate met= hod for registering new sub-services of urn:service:sos (trimming due too l= arge message report)

=A0<= /p>

I am okay with this, providing that the f= allback order is clearly defined.=

That is, does an A3 fall back to an A2 or A1= , or just back to sos?

=

=A0

=A0

=A0

From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com]
Sent: Wednesday, 20 February 2013 7:32 AM
To: Dan Mongrain=
Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: RE: [Ecr= it] What is the most appropriate method for registering new sub-services of= urn:service:sos (trimming due too large message report)

=A0

Hello,=

=A0<= /span>

If we go with RFC4119 based sub-serv= ices, would the IANA registration request be as follows?

=A0<= /span>

- urn:service:sos.police.A3= =A0- The 'police.local' service refers to the emergency service off= ered by the police department or other law enforcement authorities of the a= uthorities=A0of a city, township, shi (JP).

- urn:service:sos.police.country=A0- Th= e 'police.national' service refers to the emergency service offered= by the police department or other law enforcement authorities of the gover= nment=A0of a country.

=A0<= /span>

Does anyone see any issue in that?

=A0<= /span>

If WG prefers this, it is OK for me.=

=A0<= /span>

> In the latter case, so how do I get t= he county police (or state police, there can be up to 4 police services for= a given location in the US).=A0 =

=A0<= /span>

If I got it correctly, you propose t= hat we also add

- urn:service:sos.police.A2 - The '= police.local' service refers to the emergency service offered by the po= lice department or other law enforcement authorities of the authorities=A0<= u>of county, parish, gun (JP), district (IN)"

- urn:service:sos.police.A1 - The '= police.local' service refers to the emergency service offered by the po= lice department or other law enforcement authorities of the authorities=A0<= u>of national subdivisions (state, region, province, prefecture)"<= /span>

=A0<= /span>

While I have no problem with that, I= am not aware of a regulation establishing such emergency service so I cann= ot argue to IANA that the RFC5031 policy is satisfied for those URNs.

=A0<= /span>

Kind regards

=A0<= /span>

Ivo Sedlacek

=A0<= /span>

=A0

=A0

=A0

This Communication is Confidential. We only send= and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19. =FAnora 2013 21:12
To: Ivo Sedlacek
Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: Re: [Ecrit] What is t= he most appropriate method for registering new sub-services of urn:service:= sos (trimming due too large message report)<= /u>

=A0

Thing is, when there is no city police, local would give you county = police (sheriff department) but in a city with a city police department loc= al would give you city police.=A0 In the latter case, so how do I get the c= ounty police (or state police, there can be up to 4 police services for a g= iven location in the US).=A0 Note that these examples are US based, but we = do have 3 levels of police services in Canada and I am sure other countries= have the same issue.

=A0

There is also the terminology.=A0 There is no "national" police i= n the US or Canada but there is a federal police.=A0 Keeping the RFC 4119 t= erminology removes any "local" interpretation issues.

Dan<= span lang=3D"EN-GB">

On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek &= lt;ivo.sedla= cek@ericsson.com> wrote:

I agree with Richard - there are countrie= s where both the emergency service of the national police and the emergency= service of the municipal police are offered in a given location.

A user would call the municipal police emergen= cy service to report e.g. pickpockets.

A user would call the national police emergenc= y service to report e.g. a murder.

=A0<= /span>

=A0

I submitted to IANA a request to register:

- urn:service:sos.police.local - The 'police.local' service refe= rs to the emergency service offered by the police department or other law e= nforcement authorities of the local or municipal authorities.

- urn:service:sos.police.national - The 'p= olice.national' service refers to the emergency service offered by the = police department or other law enforcement authorities of the national gove= rnment.

=A0<= /span>

RFC5031 policy is hopefully fulfille= d for them since they exist in two countries.

=A0<= /span>

I am flexible whether the actual URN= s contain the sub-services proposed above (i.e. .local and .national sub-se= rvices) or subservices based on RFC4119 (i.e. .A3 and .country sub-services= ).

=A0<= /span>

If the preference is for subservices= based on RFC4119, do I need to make another IANA registration request or c= an we modify the URNs and their description during the expert review?

=A0<= /span>

Kind regards

=A0<= /span>

Ivo Sedlacek

=A0<= /span>

This Communication is Confidential. We= only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19. =FAnora 2013 15:36
To: Winterbottom, James
Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org
Subject: Re: [Ecrit] What is t= he most appropriate method for registering new sub-services of urn:service:= sos

=A0

The problem is that different countries has dif= ferent names for their political subdivisions.=A0 In the US they are states= , in Canada they are provinces, etc.=A0 Same when you further subdivide.=A0= While not privy to the discussions that came up with A1, A2, =85, A5, I ha= ve the feeling this nomenclature was picked for the same reason.=A0 Why not= utilise the same naming scheme for specifying the jurisdiction you want to= reach?

=A0

Thanx,

Dan

=A0

On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James <James.Winterbottom@co= mmscope.com> wrote:

In that case, one might say state = in the hierarchy, not A1.<= /p>

=A0

Cheers

James<= /u>

=A0

=A0

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Tuesday, 19 February 2013 8:57 AM
To: Winterbottom, = James
Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org<= /u>


Subject: Re: [Ecrit] What is th= e most appropriate method for registering new sub-services of urn:service:s= os

=A0

It might make sense if you wanted to allow the cal= ler to explicitly select police at a different level of responsibility, e.g= ., the state police rather than the local police. =A0<= u>

=A0

On Mon, = Feb 18, 2013 at 4:21 PM, Winterbottom, James <James.Winterbottom@commscope.co= m> wrote:

I think I am missing something her= e, A1 is part of the location, so why does it need to be in the URN at all?=

As far as I understand current deployments, = they use the URN to select a layer in the GIS that corresponds to the servi= ce type, and then use geographic boundaries within that layer to select the= final destination.

=A0

From: = ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Dan Mon= grain
Sent: Tuesday, 19 February 2013 7:30 AM<= u>


To: Ivo= Sedlacek
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] What is the most appropriate method for registe= ring new sub-services of urn:service:sos=

=A0

Sorry for responding late to this thread, it= kinda fell into a=A0 crack=85=A0 The current thread reminded me to check t= his old thread=85

=A0

You are indicating that we need = to register 77 Service URN (11 service subtypes * 7 jurisdiction types base= d on RFC 4119).=A0 I do not recommend that we create so many registrations.= =A0 Instead, we should allow a service URN to be suffixed with a jurisdicti= onal scope.=A0 So the following Service URN are all valid:

=A0

urn:service:sos.police

urn:service:sos.police.traffic

urn= :service:sos.police.A1

urn:service:sos.police.traffic.A1

= =A0

Question is, do we want to leave jurisdictio= nal scope to only be applicable to police branch or any Service URN? =A0I= =92d say the latter as it is always up to the LoST service provisioning (ba= sed on local policy) to determine what is locally acceptable.

=A0

Thanx,

Dan

=A0

=A0

=A0


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

Thanks fo= r the clarification, I personally disagree with that position.

 

 

Fr= om: Dan Mongrain [mailto:dan@mongrain.org]
Sent: Wednesday, 2= 0 February 2013 3:56 PM
To: Winterbottom, James
Cc: DRA= GE, Keith (Keith); Ivo Sedlacek; ecrit@ietf.org
Subject: Re: [Ecr= it] What is the most appropriate method for registering new sub-services of= urn:service:sos (trimming due too large message report)<= /p>

 

What I meant is that if a jurisdictional scope = aware LoST service receives a request for urn:service:sos.police.A4 and not= hing is configured, it looks for urn:service:sos.police.A3 then urn:service= :sos.police.A2, etc. until it finds a configured service.  If nothing = is found for urn:service:sos.police.country then it pops the last element a= nd looks for urn:service:sos.police (but then again, it is no longer jurisd= ictional scope aware).

I disagree that one needs to formulate the re= quest as urn:service:sos.police.country.A1.A2.A3.A4 in order for this to ha= ppen.  There must be only a single jurisdictional scope appended to a = Service URN.

I do not think we need a .A6 jurisdictional scope (stre= et level).  .A5 (neighborhood, would point to a precinct for example) = provides enough granularity in my opinion.

Thanx,
Dan

On Tue, Feb 19, 2013 at 11:29 PM, Wint= erbottom, James <James.Winterbottom@commscope.com> wrote:

I am sorry, I am finding this confusing.

 

RFC5= 139 puts a hierarchy on A1 through A6. If you want this hierarchy to work t= hen A1 through A6 can’t be at the same level if you expect A3 to fall= back to A2 or A1 in the case of a service not existing or a service failure= of some kind. If they exist at the same level then if A3 doesn’t exi= st you will go to urn:service:sos.police  unless you impose the hierar= chy in the urn.

 =

 

 

 

&nbs= p;

From: Dan Mongrain [mailto:dan@mongrain.org]
Se= nt: Wednesday, 20 February 2013 3:23 PM
To: DRAGE, Keith (Kei= th)
Cc: Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org
Subject: Re: [Ec= rit] What is the most appropriate method for registering new sub-services o= f urn:service:sos (trimming due too large message report)=

 

My recommendation for handling unkno= wn Service URN depends if LoST service implements jurisdictional scope or n= ot.  If it does not, it pops the last element and evaluates until a se= rvice is found.  If it implements jurisdictional scope, the last eleme= nt is a jurisdictional scope and it is not found, then you return the next = highest level defined.

While it may be true that citizens typically = dial 9-1-1 to request for help, police services such as state or provincial= polices advertises numbers to call them directly (star code to dial using = a mobile phone for example) especially to report accidents on freeways.&nbs= p; We need an equivalent Service URN.

Also while RFC5031's scope is = citizen to authorities (I am not sure I agree with this) I do not want to r= e-invent the wheel to signal calls within an Emergency Services IP Network = (ESInet).  When I transfer a call from one PSAP to another, the mechan= ism to determine where to send the call is the same, using LoST.  For = a PSAP that covers a large area spanning multiple counties and the calltake= r needs to transfer the call to the appropriate sheriff department for the = caller's location, they only need a single transfer target (urn:service:sos= .police.A2).  It is not true that the calltaker always knows the actua= l destination of the call, especially when the calltaker is only a call scr= eener.

Thanx,
Dan

On Tue, Feb 19, 201= 3 at 7:18 PM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrot= e:

The answer to James’= s question depends on how you code it (and also what you mean by fallback).=

 

On any service URN, you ignore any subtypes from the poi= nt you stop understanding it.

&n= bsp;

So if the coding is sos.pol= ice.A2, and you do not understand A2, then the service URN would be handled= as if it was sos.police, not as sos.police.A1. And if police was not under= stood then it would be handled as sos.

 

If you wanted some= thing that went back to the next larger regional coverage, then you would h= ave to code successive subtypes in sequence.

<= span lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Arial","sans-serif= ";color:navy'> 

But I wou= ld also ask for an element of sanity in this discussion, rather than total = flexibility.

 <= /o:p>

For example while a national administration = may have multiple levels of police force, not all of them are either reacha= ble directly as an emergency service provider, nor are they necessarily an = emergency service provider. If they are neither of these, then they presuma= bly do not need a special and distinct service URN.

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'> 

It w= ould therefore nice to see a current use case that is anything but a choice= of two, i.e. countrywide (following the ITU-T E.164 definition of country)= versus one more local variant. This restricted model certainly covers Ivo&= #8217;s examples of Czeck Republic and Poland, and I believe it also covers= the other example I know of which is Italy.

<= span lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Arial","sans-serif= ";color:navy'> 

While the= USA has multiple levels of police force, on the PSTN, it only appears to h= ave one level of access to citizen to authority emergency service, which is= 911. I see no reason why a change to voice over IP would cause a change to= this.

 <= /p>

I would also stress that it is important to have g= lobal expectations of what you get when you use a service URN. If there is = not care excercised with assigning semantics and values, A3 in one country = could result in the forestry police and in another country the financial po= lice responding.

 

Note that read the scope of RFC 5031 as = being for end user accessing the emergency service. While it might be possi= ble to apply RFC 5031 to further network operations after the PSAP has been= reached, e.g. to reach a subsidiary PSAP, I read that as outside the scope= of RFC 5031. Nor do I necessarily believe in that scenario that service UR= Ns are necessarily the best solution for routeing, as the first PSAP should= know the particular office they want to reach rather than just the type of= emergency service.

 

Regards

<= span lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Arial","sans-serif= ";color:navy'> 

Keith

 

=

From: ecrit-bounces@ietf.org [mailt= o:ecrit-bounces= @ietf.org] On Behalf Of Winterbottom, James
Sent: 19 F= ebruary 2013 23:29
To: Ivo Sedlacek; Dan Mongrain
Cc: <= a href=3D"mailto:ecrit@ietf.org" target=3D"_blank">ecrit@ietf.org
Subject: Re: [Ecrit] What is the most appropriate method for registeri= ng new sub-services of urn:service:sos (trimming due too large message repo= rt)

 =

I am okay with this, providing that the fallback or= der is clearly defined.

That is, does an= A3 fall back to an A2 or A1, or just back to sos?

 

 

 

From: Iv= o Sedlacek [mailto:ivo.sedlacek@ericsson.com]
Sent: Wednesday, 20 Februa= ry 2013 7:32 AM
To: Dan Mongrain
Cc: Winterbottom, Jame= s; Richard Barnes; ecri= t@ietf.org
Subject: RE: [Ecrit] What is the most appropriate = method for registering new sub-services of urn:service:sos (trimming due to= o large message report)

 =

Hello,

 =

If we go with RFC4119 based sub-services, would = the IANA registration request be as follows?

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#C050= 4D'> 

- urn:service:sos.police.A3<= /u> - The 'police.local' service refers to the emergency service offer= ed by the police department or other law enforcement authorities of the aut= horities of a city, township, shi (JP).

- urn:service:sos.police.country - The 'police.nation= al' service refers to the emergency service offered by the police departmen= t or other law enforcement authorities of the government of a count= ry.

 

Does anyone see any issue in that?

&= nbsp;

If WG prefers this, it is OK for me.=

 

&= gt; In the latter case, so how do I get the county police (or state police,= there can be up to 4 police services for a given location in the US). = ;

 

If I got it correctly, you propose that we also add

=

- urn:service:sos.police.A2 - The 'police.local' service= refers to the emergency service offered by the police department or other = law enforcement authorities of the authorities of county, parish, g= un (JP), district (IN)"

- urn:ser= vice:sos.police.A1 - The 'police.local' service refers to the emerge= ncy service offered by the police department or other law enforcement autho= rities of the authorities of national subdivisions (state, region, = province, prefecture)"

 

While I have no problem with that, I am not a= ware of a regulation establishing such emergency service so I cannot argue = to IANA that the RFC5031 policy is satisfied for those URNs.

 

Kind regards

 

Ivo= Sedlacek

 

 

 

 

This Communication is Confidential.= We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<= /a>

From: Dan Mongrain [mailto:dan@mongrain.org]
Sent:= 19. =FAnora 2013 21:12
To: Ivo Sedlacek
Cc: Winterbott= om, James; Richard Barnes; ecrit@ietf.org
Subject: Re: [Ecrit] What is the most appr= opriate method for registering new sub-services of urn:service:sos (trimmin= g due too large message report)

 

Thing is, when there is no city police, local would give you county p= olice (sheriff department) but in a city with a city police department loca= l would give you city police.  In the latter case, so how do I get the= county police (or state police, there can be up to 4 police services for a= given location in the US).  Note that these examples are US based, bu= t we do have 3 levels of police services in Canada and I am sure other coun= tries have the same issue.

 

There is also the terminology.  There is no "nat= ional" police in the US or Canada but there is a federal police. = Keeping the RFC 4119 terminology removes any "local" interpretat= ion issues.

Dan

On Tue, Feb 19, 2013 at 2:= 31 PM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:

I agree with Richard - there are countries where both the eme= rgency service of the national police and the emergency service of the muni= cipal police are offered in a given location.

= A user would call the municipal police emergency service to report e.g= . pickpockets.

A user would call the natio= nal police emergency service to report e.g. a murder.

=

 

 

I submitted to IANA a request to register:

- urn:service:sos.police.local - The 'police.local' servi= ce refers to the emergency service offered by the police department or othe= r law enforcement authorities of the local or municipal authorities.=

- urn:service:sos.police.national - The 'police.= national' service refers to the emergency service offered by the police dep= artment or other law enforcement authorities of the national government.

 

RFC5= 031 policy is hopefully fulfilled for them since they exist in two countrie= s.

 

I am flexible whether the actual URNs contain the sub-services proposed ab= ove (i.e. .local and .national sub-services) or subservices based on RFC411= 9 (i.e. .A3 and .country sub-services).

&n= bsp;

If the preference is for subservices = based on RFC4119, do I need to make another IANA registration request or ca= n we modify the URNs and their description during the expert review?=

 

Kind r= egards

 

= Ivo Sedlacek

 =

This Communication is Confidential. We only send and receive= email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19. =FAnora 2013 15:36To: Winterbottom, James
Cc: Richard Barnes; Ivo Sedlacek= ; ecrit@ietf.orgSubject: Re: [Ecrit] What is the most appropriate method for regist= ering new sub-services of urn:service:sos

 = ;

The problem is that different countries has d= ifferent names for their political subdivisions.  In the US they are s= tates, in Canada they are provinces, etc.  Same when you further subdi= vide.  While not privy to the discussions that came up with A1, A2, &#= 8230;, A5, I have the feeling this nomenclature was picked for the same rea= son.  Why not utilise the same naming scheme for specifying the jurisd= iction you want to reach?

 

Thanx,

Dan=

 

On Mon, Feb 18, 201= 3 at 5:01 PM, Winterbottom, James <James.Winterbottom@commscope.com> w= rote:

In that case, one might say sta= te in the hierarchy, not A1.

 

Cheers

Ja= mes

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

From: Richard Barnes [mailt= o:rlb@ipv.sx]
Se= nt: Tuesday, 19 February 2013 8:57 AM
To: Winterbottom, James=
Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org


Subject: Re: [Ecrit] What is the most appropriate method for r= egistering new sub-services of urn:service:sos

 

It might make sense= if you wanted to allow the caller to explicitly select police at a differe= nt level of responsibility, e.g., the state police rather than the local po= lice.  

 

O= n Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James <James.Winterbottom@comms= cope.com> wrote:

I think I am= missing something here, A1 is part of the location, so why does it need to= be in the URN at all?

As far as I under= stand current deployments, they use the URN to select a layer in the GIS th= at corresponds to the service type, and then use geographic boundaries with= in that layer to select the final destination.

=  

From: ecrit-bounces@ietf.org [mailt= o:ecrit-bounces= @ietf.org] On Behalf Of Dan Mongrain
Sent: Tuesday, 19= February 2013 7:30 AM


To:= Ivo Sedlacek
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] What is the most app= ropriate method for registering new sub-services of urn:service:sos

 

Sorry for responding late to this thread, it kinda fell into a  crac= k…  The current thread reminded me to check this old thread̷= 0;

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>You are indicating that we need to register 77 Service URN (11 servic= e subtypes * 7 jurisdiction types based on RFC 4119).  I do not recomm= end that we create so many registrations.  Instead, we should allow a = service URN to be suffixed with a jurisdictional scope.  So the follow= ing Service URN are all valid:

 

urn:service:sos.police

urn:service:sos.police.traffic

= urn:service:sos.police.A1

urn:ser= vice:sos.police.traffic.A1

 

Question is, do we want to leave jurisdiction= al scope to only be applicable to police branch or any Service URN?  I= ’d say the latter as it is always up to the LoST service provisioning= (based on local policy) to determine what is locally acceptable.

 

Thanx,<= /span>

Dan

 =

 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'> 

&nbs= p;

= --_000_5A55A45AE77F5941B18E5457ECAC818801214077135DSISPE7MB1co_-- From keith.drage@alcatel-lucent.com Wed Feb 20 00:03:33 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6137B21F870A for ; Wed, 20 Feb 2013 00:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.812 X-Spam-Level: X-Spam-Status: No, score=-108.812 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oGhUGmYF5YE for ; Wed, 20 Feb 2013 00:03:25 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2986421F8703 for ; Wed, 20 Feb 2013 00:03:25 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1K83JIe010386 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 20 Feb 2013 09:03:19 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 20 Feb 2013 09:03:19 +0100 From: "DRAGE, Keith (Keith)" To: Dan Mongrain Date: Wed, 20 Feb 2013 09:03:17 +0100 Thread-Topic: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) Thread-Index: Ac4PIfU8kRzky93xSs+tZQ2s3edHsgAHYCkg Message-ID: References: <39B5E4D390E9BD4890E2B3107900610109A5A8@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610109A6A7@ESESSMB301.ericsson.se> <5A55A45AE77F5941B18E5457ECAC81880121407712CD@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE21070160C6CFRMRSSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 08:03:33 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE21070160C6CFRMRSSXCHMBSC_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You seem to be assuming that a call to the police is automatically an emerg= ency call. My understanding is that most police forces advertise these local numbers s= pecifically for cases where it is NOT an emergency call. As a quick referen= ce to Wikipedia (incomplete but readily available) shows only one number fo= r Canada. I would like you to describe your case for signalling calls within an Esine= t and I do not believe these cases were considered when RFC 5031 was develo= ped nor are they written into the scope of that document That is not descri= bed in any RFC, and if we are extending to that capability, it would help t= o know which decision points are made using service URNs, and consider whet= her that is better than other solutions. For the accidents on freeway, see my summary posting made recently. You wil= l see that other countries, e.g. China have these as an entirely separate = emergency service, and in my belief that should probably not be sos.police.= ... but sos.trafficemergency. Keith ________________________________ From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 20 February 2013 04:23 To: DRAGE, Keith (Keith) Cc: Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) My recommendation for handling unknown Service URN depends if LoST service = implements jurisdictional scope or not. If it does not, it pops the last e= lement and evaluates until a service is found. If it implements jurisdicti= onal scope, the last element is a jurisdictional scope and it is not found,= then you return the next highest level defined. While it may be true that citizens typically dial 9-1-1 to request for help= , police services such as state or provincial polices advertises numbers to= call them directly (star code to dial using a mobile phone for example) es= pecially to report accidents on freeways. We need an equivalent Service UR= N. Also while RFC5031's scope is citizen to authorities (I am not sure I agree= with this) I do not want to re-invent the wheel to signal calls within an = Emergency Services IP Network (ESInet). When I transfer a call from one PS= AP to another, the mechanism to determine where to send the call is the sam= e, using LoST. For a PSAP that covers a large area spanning multiple count= ies and the calltaker needs to transfer the call to the appropriate sheriff= department for the caller's location, they only need a single transfer tar= get (urn:service:sos.police.A2). It is not true that the calltaker always = knows the actual destination of the call, especially when the calltaker is = only a call screener. Thanx, Dan On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) > wrote: The answer to James's question depends on how you code it (and also what yo= u mean by fallback). On any service URN, you ignore any subtypes from the point you stop underst= anding it. So if the coding is sos.police.A2, and you do not understand A2, then the s= ervice URN would be handled as if it was sos.police, not as sos.police.A1. = And if police was not understood then it would be handled as sos. If you wanted something that went back to the next larger regional coverage= , then you would have to code successive subtypes in sequence. But I would also ask for an element of sanity in this discussion, rather th= an total flexibility. For example while a national administration may have multiple levels of pol= ice force, not all of them are either reachable directly as an emergency se= rvice provider, nor are they necessarily an emergency service provider. If = they are neither of these, then they presumably do not need a special and d= istinct service URN. It would therefore nice to see a current use case that is anything but a ch= oice of two, i.e. countrywide (following the ITU-T E.164 definition of coun= try) versus one more local variant. This restricted model certainly covers = Ivo's examples of Czeck Republic and Poland, and I believe it also covers t= he other example I know of which is Italy. While the USA has multiple levels of police force, on the PSTN, it only app= ears to have one level of access to citizen to authority emergency service,= which is 911. I see no reason why a change to voice over IP would cause a = change to this. I would also stress that it is important to have global expectations of wha= t you get when you use a service URN. If there is not care excercised with = assigning semantics and values, A3 in one country could result in the fores= try police and in another country the financial police responding. Note that read the scope of RFC 5031 as being for end user accessing the em= ergency service. While it might be possible to apply RFC 5031 to further ne= twork operations after the PSAP has been reached, e.g. to reach a subsidiar= y PSAP, I read that as outside the scope of RFC 5031. Nor do I necessarily = believe in that scenario that service URNs are necessarily the best solutio= n for routeing, as the first PSAP should know the particular office they wa= nt to reach rather than just the type of emergency service. Regards Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Winterbottom, = James Sent: 19 February 2013 23:29 To: Ivo Sedlacek; Dan Mongrain Cc: ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) I am okay with this, providing that the fallback order is clearly defined. That is, does an A3 fall back to an A2 or A1, or just back to sos? From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] Sent: Wednesday, 20 February 2013 7:32 AM To: Dan Mongrain Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org Subject: RE: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) Hello, If we go with RFC4119 based sub-services, would the IANA registration reque= st be as follows? - urn:service:sos.police.A3 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of a city, township, shi (JP). - urn:service:sos.police.country - The 'police.national' service refers to = the emergency service offered by the police department or other law enforce= ment authorities of the government of a country. Does anyone see any issue in that? If WG prefers this, it is OK for me. > In the latter case, so how do I get the county police (or state police, t= here can be up to 4 police services for a given location in the US). If I got it correctly, you propose that we also add - urn:service:sos.police.A2 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of county, parish, gun (JP), district (IN)" - urn:service:sos.police.A1 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of national subdivisions (state, region, provin= ce, prefecture)" While I have no problem with that, I am not aware of a regulation establish= ing such emergency service so I cannot argue to IANA that the RFC5031 polic= y is satisfied for those URNs. 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 21:12 To: Ivo Sedlacek Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) Thing is, when there is no city police, local would give you county police = (sheriff department) but in a city with a city police department local woul= d give you city police. In the latter case, so how do I get the county pol= ice (or state police, there can be up to 4 police services for a given loca= tion in the US). Note that these examples are US based, but we do have 3 l= evels of police services in Canada and I am sure other countries have the s= ame issue. There is also the terminology. There is no "national" police in the US or = Canada but there is a federal police. Keeping the RFC 4119 terminology rem= oves any "local" interpretation issues. Dan On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek > wrote: I agree with Richard - there are countries where both the emergency service= of the national police and the emergency service of the municipal police a= re offered in a given location. A user would call the municipal police emergency service to report e.g. pic= kpockets. A user would call the national police emergency service to report e.g. a mu= rder. I submitted to IANA a request to register: - urn:service:sos.police.local - The 'police.local' service refers to the e= mergency service offered by the police department or other law enforcement = authorities of the local or municipal authorities. - urn:service:sos.police.national - The 'police.national' service refers to= the emergency service offered by the police department or other law enforc= ement authorities of the national government. RFC5031 policy is hopefully fulfilled for them since they exist in two coun= tries. I am flexible whether the actual URNs contain the sub-services proposed abo= ve (i.e. .local and .national sub-services) or subservices based on RFC4119= (i.e. .A3 and .country sub-services). If the preference is for subservices based on RFC4119, do I need to make an= other IANA registration request or can we modify the URNs and their descrip= tion during the expert review? 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 15:36 To: Winterbottom, James Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos The problem is that different countries has different names for their polit= ical subdivisions. In the US they are states, in Canada they are provinces= , etc. Same when you further subdivide. While not privy to the discussion= s that came up with A1, A2, ..., A5, I have the feeling this nomenclature w= as picked for the same reason. Why not utilise the same naming scheme for = specifying the jurisdiction you want to reach? Thanx, Dan On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James > wrote: In that case, one might say state in the hierarchy, not A1. Cheers James From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Tuesday, 19 February 2013 8:57 AM To: Winterbottom, James Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos It might make sense if you wanted to allow the caller to explicitly select = police at a different level of responsibility, e.g., the state police rathe= r than the local police. On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James > wrote: I think I am missing something here, A1 is part of the location, so why doe= s it need to be in the URN at all? As far as I understand current deployments, they use the URN to select a la= yer in the GIS that corresponds to the service type, and then use geographi= c boundaries within that layer to select the final destination. From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Dan Mongrain Sent: Tuesday, 19 February 2013 7:30 AM To: Ivo Sedlacek Cc: ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos Sorry for responding late to this thread, it kinda fell into a crack... T= he current thread reminded me to check this old thread... You are indicating that we need to register 77 Service URN (11 service subt= ypes * 7 jurisdiction types based on RFC 4119). I do not recommend that we= create so many registrations. Instead, we should allow a service URN to b= e suffixed with a jurisdictional scope. So the following Service URN are a= ll valid: urn:service:sos.police urn:service:sos.police.traffic urn:service:sos.police.A1 urn:service:sos.police.traffic.A1 Question is, do we want to leave jurisdictional scope to only be applicable= to police branch or any Service URN? I'd say the latter as it is always u= p to the LoST service provisioning (based on local policy) to determine wha= t is locally acceptable. Thanx, Dan --_000_EDC0A1AE77C57744B664A310A0B23AE21070160C6CFRMRSSXCHMBSC_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

You seem to be assuming that a call to= the police is automatically an emergency call.

 

My understanding is that most police forces advertise these local numbers specifically for cases where it is NOT= an emergency call. As a quick reference to Wikipedia (incomplete but readily available) shows only one number for Canada.

 

I would like you to describe your case= for signalling calls within an Esinet and I do not believe these cases were considered when RFC 5031 was developed nor are they written into the scope = of that document That is not described in any RFC, and if we are extending to = that capability, it would help to know which decision points are made using serv= ice URNs, and consider whether that is better than other solutions.<= /span>

 

For the accidents on freeway, see my summary posting made recently. You will see that other countries, e.g. China =A0have these as an entirely separate emergency service, and in my belief that shou= ld probably not be sos.police…. but sos.trafficemergency.

 

Keith

 

From:= Dan Mongrain [mailto:dan@mongrain.org]
Sent: 20 February 2013 04:23=
To: DRAGE, Keith (Keith)
Cc: Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

 

My recommendation= for handling unknown Service URN depends if LoST service implements jurisdictio= nal scope or not.  If it does not, it pops the last element and evaluates until a service is found.  If it implements jurisdictional scope, the = last element is a jurisdictional scope and it is not found, then you return the = next highest level defined.

While it may be true that citizens typically dial 9-1-1 to request for help= , police services such as state or provincial polices advertises numbers to c= all them directly (star code to dial using a mobile phone for example) especially to report accidents on freeways.  We need an equivalent Service URN.

Also while RFC5031's scope is citizen to authorities (I am not sure I agree with this) I do not want to re-invent the wheel to signal calls within an Emergency Services IP Network (ESInet).  When I transfer a call from o= ne PSAP to another, the mechanism to determine where to send the call is the s= ame, using LoST.  For a PSAP that covers a large area spanning multiple counties and the calltaker needs to transfer the call to the appropriate sheriff department for the caller's location, they only need a single trans= fer target (urn:service:sos.police.A2).  It is not true that the calltaker always knows the actual destination of the call, especially when the callta= ker is only a call screener.

Thanx,
Dan

On Tue, Feb 19, 2013 at 7:1= 8 PM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:<= /span>

The answer to James’s question depends on how you code it (and also what you mean by fallback).

 

On any service URN, you ignore any subtypes from the point you = stop understanding it.

 

So if the coding is sos.police.A2, and you do not understand A2= , then the service URN would be handled as if it was sos.police, not as sos.police.A1. And if police was not understood then it would be handled as sos.

 

If you wanted something that went back to the next larger regio= nal coverage, then you would have to code successive subtypes in sequence.

 

But I would also ask for an element of sanity in this discussio= n, rather than total flexibility.

 

For example while a national administration may have multiple levels of police force, not all of them are either reachable directly as an emergency service provider, nor are they necessarily an emergency service provider. If they are neither of these, then they presumably do not need a special and distinct service URN.

 

It would therefore nice to see a current use case that is anyth= ing but a choice of two, i.e. countrywide (following the ITU-T E.164 definition of country) versus one more local variant. This restricted model certainly covers Ivo’s examples of C= zeck Republic and Poland, and I believe it also covers the o= ther example I know of which is Italy.

 

While the USA has multiple levels of police force, on the PSTN, it only appears to have o= ne level of access to citizen to authority emergency service, which is 911. I = see no reason why a change to voice over IP would cause a change to this.

 

I would also stress that it is important to have global expectations of what you get when you use a service URN. If there is not ca= re excercised with assigning semantics and values, A3 in one country could res= ult in the forestry police and in another country the financial police respondi= ng.

 

Note that read the scope of RFC 5031 as being for end user accessing the emergency service. While it might be possible to apply RFC 50= 31 to further network operations after the PSAP has been reached, e.g. to reac= h a subsidiary PSAP, I read that as outside the scope of RFC 5031. Nor do I necessarily believe in that scenario that service URNs are necessarily the = best solution for routeing, as the first PSAP should know the particular office = they want to reach rather than just the type of emergency service.=

 

Regards

 

Keith

 

From: ecrit-bounces@ietf= .org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Winterbottom, J= ames
Sent: 19 February 2013 23:29=
To: Ivo Sedlacek; Dan Mongra= in
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

 

I am okay with this, providing that the fallback order is clearly defined.

That is, does an A3 fall back to an A2 o= r A1, or just back to sos?

 

 

 

From: Ivo Sedlacek [m= ailto:ivo.sedlacek@er= icsson.com]
Sent: Wednesday, 20 February= 2013 7:32 AM
To: Dan Mongrain
Cc: Winterbottom, James; Ric= hard Barnes; ecrit@ietf.org<= /a>
Subject: RE: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report)

 

Hello,

 

If we go with RFC4119 based sub-services, would the IANA registration request be as follows?=

 

- urn:service:sos.police.A3 - = The 'police.local' service refers to the emergency service offered by the polic= e department or other law enforcement authorities of the authorities = of a city, township, shi (JP).

- urn:service:sos.police.country&nb= sp;- The 'police.national' service refers to the emergency service offered by th= e police department or other law enforcement authorities of the government&nb= sp;of a country.

 

Does anyone see any issue in that?<= /font>

 

If WG prefers this, it is OK for me.

 

> In the latter c= ase, so how do I get the county police (or state police, there can be up to 4 polic= e services for a given location in the US). 

 

If I got it correctly, you propose that we also add

- urn:service:sos.police.A2 - The 'police.local' service refers to the emergency service offered by the polic= e department or other law enforcement authorities of the authorities = of county, parish, gun (JP), district (IN)"<= /p>

- urn:service:sos.police.A1 - The 'police.local' service refers to the emergency service offered by the polic= e department or other law enforcement authorities of the authorities = of national subdivisions (state, region, province, prefecture)"

 

While I have no problem with that, I am no= t aware of a regulation establishing such emergency service so I cannot argue= to IANA that the RFC5031 policy is satisfied for those URNs.

 

Kind regards

 

Ivo Sedlacek

 

 

 

 

This Communication is Confidential. We onl= y send and receive email on the basis of the terms set out at www.ericsson.com/email_d= isclaimer

From: Dan Mongrain [<= a href=3D"mailto:dan@mongrain.org" target=3D"_blank">mailto:dan@mongrain.org<= /a>]
Sent: 19. =FAnora 2013 21:12=
To: Ivo Sedlacek
Cc: Winterbottom, James; Ric= hard Barnes; ecrit@ietf.org<= /a>
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos= (trimming due too large message report)

 

Thing is, when there is no city police, local would give you county police (sheri= ff department) but in a city with a city police department local would give yo= u city police.  In the latter case, so how do I get the county police (o= r state police, there can be up to 4 police services for a given location in = the US).&nb= sp; Note that these examples are US based, but we do have 3 levels of police service= s in Canada and I am sure other countries have the same issue.=

 

There is also the terminology.  There is no "national" police in t= he US or Canada but there is a federal police.  Keeping the RFC 4119 terminology removes any "local"= ; interpretation issues.

Dan

On Tue, Feb= 19, 2013 at 2:31 PM, Ivo = Sedlacek <ivo.sedl= acek@ericsson.com> wrote:

I agree with Richard - there are countries where both the emergency service of the national police and the emergency service of the municipal police are offered in a given location.

A user would call the municipal police emergency service to report e.g. pickpockets.

A user would call the national police emergency service to report e.g. a murder.

 

 

I submitted to IANA a request to register:=

- urn:service:sos.police.local - The 'poli= ce.local' service refers to the emergency service offered by the police department or other law enforcement authorities of the local or municipal authorities.

- urn:service:sos.police.national - The 'police.national' service refers to the emergency service offered by the po= lice department or other law enforcement authorities of the national government.=

 

RFC5031 policy is hopefully fulfilled for = them since they exist in two countries.

 

I am flexible whether the actual URNs cont= ain the sub-services proposed above (i.e. .local and .national sub-services) or subservices based on RFC4119 (i.e. .A3 and .country sub-services).

 

If the preference is for subservices based= on RFC4119, do I need to make another IANA registration request or can we modi= fy the URNs and their description during the expert review?=

 

Kind regards

 

Ivo Sedlacek

 

This Communication is Confidential. We onl= y send and receive email on the basis of the terms set out at www.ericsson.com/email_d= isclaimer

From: Dan Mongrain [m= ailto:dan@mongrain.org] Sent: 19. =FAnora 2013 15:36=
To: Winterbottom, James
Cc: Richard Barnes; Ivo Sedl= acek; ecrit@ietf.org
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos=

 

The problem is that different countries = has different names for their political subdivisions.  In the US they are states, in Canada = they are provinces, etc.  Same when you further subdivide.  While not priv= y to the discussions that came up with A1, A2, …, A5, I have the feeling t= his nomenclature was picked for the same reason.  Why not utilise the same naming scheme for specifying the jurisdiction you want to reach?

 

Thanx,

Dan

 

On Mon, Feb= 18, 2013 at 5:01 PM, Wint= erbottom, James <James.Winterbottom@commscope.com> wrote:

In that case, one might say state in the hierarchy, not A1.

 

Cheers

James

 

 

From: Richard Barnes = [mailto:rlb@ipv.sx]
Sent: Tuesday, 19 February 2= 013 8:57 AM
To: Winterbottom, James
Cc: Dan Mongrain; Ivo Sedlac= ek; ecrit@ietf.org<= /font>


Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos

 

It might make sense if you wanted to allow the caller to explicitly select pol= ice at a different level of responsibility, e.g., the state police rather than = the local police.  

 

On Mon, Feb= 18, 2013 at 4:21 PM, Wint= erbottom, James <James.Winterbottom@commscope.com> wrote:

I think I am missing something here, A1 = is part of the location, so why does it need to be in the URN at all?

As far as I understand current deploymen= ts, they use the URN to select a layer in the GIS<= /st1:stockticker> that corresponds to the service type, and then use geographic boundaries wi= thin that layer to select the final destination.

 

From: ecrit-bounces@ietf= .org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Dan Mongrain Sent: Tuesday, 19 February 2= 013 7:30 AM<= /o:p>


To: Ivo Sedlacek
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service:sos=

 

Sorry for responding late to this thread= , it kinda fell into a  crack…  The current thread reminded me t= o check this old thread…

 

You are indicating that we need to regis= ter 77 Service URN (11 service subtypes * 7 jurisdiction types based on RFC 4119).  I do not recommend that we create so many registrations.  Instead, we should allow a service URN to be suffixed with a jurisdictional scope.  So the following Service URN are all valid:=

 

urn:service:sos.police

urn:service:sos.police.traffic

urn:service:sos.police.A1<= o:p>

urn:service:sos.police.traffic.A1=

 

Question is, do we want to leave jurisdictional scope to only be applicable to police branch or any Service = URN?  I’d say the latter as it is always up to the LoST service provisioning (based on local policy) to determine what is locally acceptabl= e.

 

Thanx,

Dan

 

 

 

--_000_EDC0A1AE77C57744B664A310A0B23AE21070160C6CFRMRSSXCHMBSC_-- From mlinsner@cisco.com Wed Feb 20 05:48:20 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271A321F858A for ; Wed, 20 Feb 2013 05:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.957 X-Spam-Level: X-Spam-Status: No, score=-8.957 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t63SaexQsgRO for ; Wed, 20 Feb 2013 05:48:11 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF1221F88A0 for ; Wed, 20 Feb 2013 05:48:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=58016; q=dns/txt; s=iport; t=1361368091; x=1362577691; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=g3hdlEFgmz4gJzJE52ScT+HhXgNf6LOQ003xPJuRXrs=; b=NcFeSxD3njrUBR3ieNNU/U09tnulQbsC6xUOt4xu8zWZ74fA8cyUR02I hk4DyAHRxyCUvv6ClXrue86rKezdELk6n/C8HxLo0ve2ozZRMTnU/sUFy YcEUoJUafpceskMxpSbzQ99MQMeRuxCuZqEnE0jbgysbRNI+DNaCqVYRz Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAHbTJFGtJV2c/2dsb2JhbABFgkNyvSIWZxZzgh8BAQEDAQEBARcjDB0FAwsFDggRAwEBAQEgAQIELh8JCAYKBAUbh3EGDK9MkEWNMwqBJhkBBgEGAQMGAQIEgzoDiDA2iU06gz+FcoppgVKBU4FU X-IronPort-AV: E=Sophos;i="4.84,702,1355097600"; d="scan'208,217";a="178947684" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 20 Feb 2013 13:48:08 +0000 Received: from [10.116.195.124] (rtp-mlinsner-87111.cisco.com [10.116.195.124]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1KDm5r2004951; Wed, 20 Feb 2013 13:48:06 GMT User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Wed, 20 Feb 2013 08:48:05 -0500 From: Marc Linsner To: Dan Mongrain , "Winterbottom, James" Message-ID: Thread-Topic: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3444194887_112258" Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 13:48:20 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3444194887_112258 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable The findService request includes location information. Why wouldn't the LoST server simple walk the A1-A6 tree included with the location? If location is geo, reverse geocode it. What am I missing? -Marc- From: Dan Mongrain Date: Tuesday, February 19, 2013 11:55 PM To: "Winterbottom, James" Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) > What I meant is that if a jurisdictional scope aware LoST service receive= s a > request for urn:service:sos.police.A4 and nothing is configured, it looks= for > urn:service:sos.police.A3 then urn:service:sos.police.A2, etc. until it f= inds > a configured service. If nothing is found for urn:service:sos.police.cou= ntry > then it pops the last element and looks for urn:service:sos.police (but t= hen > again, it is no longer jurisdictional scope aware). >=20 > I disagree that one needs to formulate the request as > urn:service:sos.police.country.A1.A2.A3.A4 in order for this to happen. = There > must be only a single jurisdictional scope appended to a Service URN. >=20 > I do not think we need a .A6 jurisdictional scope (street level). .A5 > (neighborhood, would point to a precinct for example) provides enough > granularity in my opinion. >=20 > Thanx, > Dan >=20 >=20 > On Tue, Feb 19, 2013 at 11:29 PM, Winterbottom, James > wrote: >> I am sorry, I am finding this confusing. >> =20 >> RFC5139 puts a hierarchy on A1 through A6. If you want this hierarchy to= work >> then A1 through A6 can=B9t be at the same level if you expect A3 to fallba= ck to >> A2 or A1 in the case of a service not existing or a service failure of s= ome >> kind. If they exist at the same level then if A3 doesn=B9t exist you will = go to >> urn:service:sos.police unless you impose the hierarchy in the urn. >> =20 >> =20 >> =20 >> =20 >> =20 >>=20 >> From: Dan Mongrain [mailto:dan@mongrain.org] >> Sent: Wednesday, 20 February 2013 3:23 PM >> To: DRAGE, Keith (Keith) >> Cc: Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org >> Subject: Re: [Ecrit] What is the most appropriate method for registering= new >> sub-services of urn:service:sos (trimming due too large message report) >> =20 >> My recommendation for handling unknown Service URN depends if LoST servi= ce >> implements jurisdictional scope or not. If it does not, it pops the las= t >> element and evaluates until a service is found. If it implements >> jurisdictional scope, the last element is a jurisdictional scope and it = is >> not found, then you return the next highest level defined. >>=20 >> While it may be true that citizens typically dial 9-1-1 to request for h= elp, >> police services such as state or provincial polices advertises numbers t= o >> call them directly (star code to dial using a mobile phone for example) >> especially to report accidents on freeways. We need an equivalent Servi= ce >> URN. >>=20 >> Also while RFC5031's scope is citizen to authorities (I am not sure I ag= ree >> with this) I do not want to re-invent the wheel to signal calls within a= n >> Emergency Services IP Network (ESInet). When I transfer a call from one= PSAP >> to another, the mechanism to determine where to send the call is the sam= e, >> using LoST. For a PSAP that covers a large area spanning multiple count= ies >> and the calltaker needs to transfer the call to the appropriate sheriff >> department for the caller's location, they only need a single transfer t= arget >> (urn:service:sos.police.A2). It is not true that the calltaker always k= nows >> the actual destination of the call, especially when the calltaker is onl= y a >> call screener. >>=20 >> Thanx, >> Dan >>=20 >> On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) >> wrote: >>=20 >> The answer to James=B9s question depends on how you code it (and also what= you >> mean by fallback). >> =20 >> On any service URN, you ignore any subtypes from the point you stop >> understanding it. >> =20 >> So if the coding is sos.police.A2, and you do not understand A2, then th= e >> service URN would be handled as if it was sos.police, not as sos.police.= A1. >> And if police was not understood then it would be handled as sos. >> =20 >> If you wanted something that went back to the next larger regional cover= age, >> then you would have to code successive subtypes in sequence. >> =20 >> But I would also ask for an element of sanity in this discussion, rather= than >> total flexibility. >> =20 >> For example while a national administration may have multiple levels of >> police force, not all of them are either reachable directly as an emerge= ncy >> service provider, nor are they necessarily an emergency service provider= . If >> they are neither of these, then they presumably do not need a special an= d >> distinct service URN. >> =20 >> It would therefore nice to see a current use case that is anything but a >> choice of two, i.e. countrywide (following the ITU-T E.164 definition of >> country) versus one more local variant. This restricted model certainly >> covers Ivo=B9s examples of Czeck Republic and Poland, and I believe it als= o >> covers the other example I know of which is Italy. >> =20 >> While the USA has multiple levels of police force, on the PSTN, it only >> appears to have one level of access to citizen to authority emergency >> service, which is 911. I see no reason why a change to voice over IP wou= ld >> cause a change to this. >> =20 >> I would also stress that it is important to have global expectations of = what >> you get when you use a service URN. If there is not care excercised with >> assigning semantics and values, A3 in one country could result in the >> forestry police and in another country the financial police responding. >> =20 >> Note that read the scope of RFC 5031 as being for end user accessing the >> emergency service. While it might be possible to apply RFC 5031 to furth= er >> network operations after the PSAP has been reached, e.g. to reach a >> subsidiary PSAP, I read that as outside the scope of RFC 5031. Nor do I >> necessarily believe in that scenario that service URNs are necessarily t= he >> best solution for routeing, as the first PSAP should know the particular >> office they want to reach rather than just the type of emergency service= . >> =20 >> Regards >> =20 >> Keith >> =20 >>=20 >>=20 >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf O= f >> Winterbottom, James >> Sent: 19 February 2013 23:29 >> To: Ivo Sedlacek; Dan Mongrain >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] What is the most appropriate method for registering= new >> sub-services of urn:service:sos (trimming due too large message report) >> =20 >> I am okay with this, providing that the fallback order is clearly define= d. >> That is, does an A3 fall back to an A2 or A1, or just back to sos? >> =20 >> =20 >> =20 >>=20 >> From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] >> Sent: Wednesday, 20 February 2013 7:32 AM >> To: Dan Mongrain >> Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org >> Subject: RE: [Ecrit] What is the most appropriate method for registering= new >> sub-services of urn:service:sos (trimming due too large message report) >> =20 >> Hello, >> =20 >> If we go with RFC4119 based sub-services, would the IANA registration re= quest >> be as follows? >> =20 >> - urn:service:sos.police.A3 - The 'police.local' service refers to the >> emergency service offered by the police department or other law enforcem= ent >> authorities of the authorities of a city, township, shi (JP). >> - urn:service:sos.police.country - The 'police.national' service refers = to >> the emergency service offered by the police department or other law >> enforcement authorities of the government of a country. >> =20 >> Does anyone see any issue in that? >> =20 >> If WG prefers this, it is OK for me. >> =20 >>> > In the latter case, so how do I get the county police (or state polic= e, >>> there can be up to 4 police services for a given location in the US). >> =20 >> If I got it correctly, you propose that we also add >> - urn:service:sos.police.A2 - The 'police.local' service refers to the >> emergency service offered by the police department or other law enforcem= ent >> authorities of the authorities of county, parish, gun (JP), district (IN= )" >> - urn:service:sos.police.A1 - The 'police.local' service refers to the >> emergency service offered by the police department or other law enforcem= ent >> authorities of the authorities of national subdivisions (state, region, >> province, prefecture)" >> =20 >> While I have no problem with that, I am not aware of a regulation >> establishing such emergency service so I cannot argue to IANA that the >> RFC5031 policy is satisfied for those URNs. >> =20 >> Kind regards >> =20 >> Ivo Sedlacek >> =20 >> =20 >> =20 >> =20 >> This Communication is Confidential. We only send and receive email on th= e >> basis of the terms set out at www.ericsson.com/email_disclaimer >> >> From: Dan Mongrain [mailto:dan@mongrain.org] >> Sent: 19. =FAnora 2013 21:12 >> To: Ivo Sedlacek >> Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org >> Subject: Re: [Ecrit] What is the most appropriate method for registering= new >> sub-services of urn:service:sos (trimming due too large message report) >> =20 >> Thing is, when there is no city police, local would give you county poli= ce >> (sheriff department) but in a city with a city police department local w= ould >> give you city police. In the latter case, so how do I get the county po= lice >> (or state police, there can be up to 4 police services for a given locat= ion >> in the US). Note that these examples are US based, but we do have 3 lev= els >> of police services in Canada and I am sure other countries have the same >> issue. >> =20 >> There is also the terminology. There is no "national" police in the US = or >> Canada but there is a federal police. Keeping the RFC 4119 terminology >> removes any "local" interpretation issues. >>=20 >> Dan >>=20 >> On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek >> wrote: >>=20 >> I agree with Richard - there are countries where both the emergency serv= ice >> of the national police and the emergency service of the municipal police= are >> offered in a given location. >> A user would call the municipal police emergency service to report e.g. >> pickpockets. >> A user would call the national police emergency service to report e.g. a >> murder. >> =20 >> =20 >> I submitted to IANA a request to register: >> - urn:service:sos.police.local - The 'police.local' service refers to th= e >> emergency service offered by the police department or other law enforcem= ent >> authorities of the local or municipal authorities. >> - urn:service:sos.police.national - The 'police.national' service refers= to >> the emergency service offered by the police department or other law >> enforcement authorities of the national government. >> =20 >> RFC5031 policy is hopefully fulfilled for them since they exist in two >> countries. >> =20 >> I am flexible whether the actual URNs contain the sub-services proposed = above >> (i.e. .local and .national sub-services) or subservices based on RFC4119 >> (i.e. .A3 and .country sub-services). >> =20 >> If the preference is for subservices based on RFC4119, do I need to make >> another IANA registration request or can we modify the URNs and their >> description during the expert review? >> =20 >> Kind regards >> =20 >> Ivo Sedlacek >> =20 >> This Communication is Confidential. We only send and receive email on th= e >> basis of the terms set out at www.ericsson.com/email_disclaimer >> >> From: Dan Mongrain [mailto:dan@mongrain.org] >> Sent: 19. =FAnora 2013 15:36 >> To: Winterbottom, James >> Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org >> Subject: Re: [Ecrit] What is the most appropriate method for registering= new >> sub-services of urn:service:sos >> =20 >> The problem is that different countries has different names for their >> political subdivisions. In the US they are states, in Canada they are >> provinces, etc. Same when you further subdivide. While not privy to th= e >> discussions that came up with A1, A2, =8A, A5, I have the feeling this >> nomenclature was picked for the same reason. Why not utilise the same n= aming >> scheme for specifying the jurisdiction you want to reach? >> =20 >> Thanx, >> Dan >> =20 >>=20 >> On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James >> wrote: >>=20 >> In that case, one might say state in the hierarchy, not A1. >> =20 >> Cheers >> James >> =20 >> =20 >>=20 >> From: Richard Barnes [mailto:rlb@ipv.sx] >> Sent: Tuesday, 19 February 2013 8:57 AM >> To: Winterbottom, James >> Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org >>=20 >>=20 >> Subject: Re: [Ecrit] What is the most appropriate method for registering= new >> sub-services of urn:service:sos >>=20 >> =20 >>=20 >> It might make sense if you wanted to allow the caller to explicitly sele= ct >> police at a different level of responsibility, e.g., the state police ra= ther >> than the local police. >>=20 >> =20 >>=20 >> On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James >> wrote: >>=20 >> I think I am missing something here, A1 is part of the location, so why = does >> it need to be in the URN at all? >> As far as I understand current deployments, they use the URN to select a >> layer in the GIS that corresponds to the service type, and then use >> geographic boundaries within that layer to select the final destination. >> =20 >>=20 >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf O= f Dan >> Mongrain >> Sent: Tuesday, 19 February 2013 7:30 AM >>=20 >>=20 >> To: Ivo Sedlacek >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] What is the most appropriate method for registering= new >> sub-services of urn:service:sos >>=20 >> =20 >> Sorry for responding late to this thread, it kinda fell into a crack=8A = The >> current thread reminded me to check this old thread=8A >> =20 >> You are indicating that we need to register 77 Service URN (11 service >> subtypes * 7 jurisdiction types based on RFC 4119). I do not recommend = that >> we create so many registrations. Instead, we should allow a service URN= to >> be suffixed with a jurisdictional scope. So the following Service URN a= re >> all valid: >> =20 >> urn:service:sos.police >> urn:service:sos.police.traffic >> urn:service:sos.police.A1 >> urn:service:sos.police.traffic.A1 >> =20 >> Question is, do we want to leave jurisdictional scope to only be applica= ble >> to police branch or any Service URN? I=B9d say the latter as it is always= up >> to the LoST service provisioning (based on local policy) to determine wh= at is >> locally acceptable. >> =20 >> Thanx, >> Dan >> =20 >> =20 >> =20 >=20 > _______________________________________________ Ecrit mailing list > Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --B_3444194887_112258 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
The findService request incl= udes location information.  Why wouldn't the LoST server simple walk th= e A1-A6 tree included with the location?  If location is geo, reverse g= eocode it.

What am I missing?

<= div>-Marc-

--e89a8fb20118ed1f9204d62b4ef2-- From RMarshall@telecomsys.com Wed Feb 20 11:19:25 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B4F21F8798 for ; Wed, 20 Feb 2013 11:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRSF3PkcG6rJ for ; Wed, 20 Feb 2013 11:19:24 -0800 (PST) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) by ietfa.amsl.com (Postfix) with ESMTP id 85D3B21F8780 for ; Wed, 20 Feb 2013 11:19:22 -0800 (PST) Received: from SEA-EXCAS-1.telecomsys.com (exc2010-local1.telecomsys.com [10.32.12.186]) by sea-mx-01.telecomsys.com (8.14.1/8.14.1) with ESMTP id r1KJJIIt023194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Wed, 20 Feb 2013 11:19:18 -0800 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.134]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Wed, 20 Feb 2013 11:19:18 -0800 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: Draft Agenda creation for Orlando meeting - IETF 86 Thread-Index: Ac4Pny1ifrPrkRXuRxSgGolsofD7pg== Date: Wed, 20 Feb 2013 19:19:18 +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_FBD5AAFFD0978846BF6D3FAB4C892ACC1FB105SEAEXMB1telecomsy_" MIME-Version: 1.0 Subject: [Ecrit] Draft Agenda creation for Orlando meeting - IETF 86 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 19:19:25 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC1FB105SEAEXMB1telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We're putting together the agenda for the Orlando ECRIT WG meeting, if you = have a presentation for a draft and want agenda time, please let us know. = An email to the list works good enough. Thanks, Marc & Roger CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC1FB105SEAEXMB1telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We're putting together the agenda fo= r the Orlando ECRIT WG meeting, if you have a presentation for a draft and = want agenda time, please let us know.  An email to the list works good enough.

 

Thanks,

 

Marc & Roger

 

 

CONFIDENTIALITY NOTIC= E: The information contained in this message may be privileged and/or confi= dential. If you are not the intended recipient, or responsible for deliveri= ng this message to the intended recipient, any review, forwarding, dissemin= ation, distribution or copying of this communication or any attachment(s) i= s strictly prohibited. If you have received this message in error, please n= otify the sender immediately, and delete it and all attachments from your c= omputer and network.

--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC1FB105SEAEXMB1telecomsy_-- From mlinsner@cisco.com Wed Feb 20 11:48:22 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CFF21F85D9 for ; Wed, 20 Feb 2013 11:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.922 X-Spam-Level: X-Spam-Status: No, score=-8.922 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUZy6fRUwYrU for ; Wed, 20 Feb 2013 11:48:12 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C667421E803C for ; Wed, 20 Feb 2013 11:48:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=63964; q=dns/txt; s=iport; t=1361389692; x=1362599292; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=L313U0fpgqcgBQTkPiCAz24Ge8eEibHgX/FV//KYQbY=; b=Ks2vUjKTZABd9IzUAB+PIwA1SSe/1lI44ukxw+bMoLx6ryxxkmZnWbHp Lmrf9mvxPcTi2pkhtVkxOp6F1KjUOZXeTNf79N2mvtM6ya+/wub5hmMX5 MNr3AzTuOSiFCdIkV7wiQzzqyZjy1+RdWcbg9RTidTE36+CqepCtnzBBx c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAOonJVGtJV2d/2dsb2JhbABFgkNyvSkWbBZzgh8BAQEDAQEBARcBIgwdBQMLBQ4IEQMBAQEBIAECBC4fCQgGCgQFCRKHcQYMsBmQRo0zCoEmGQEGAQYBAwYBAgSDOgOIMDaJTTqDP4VyimmBUoFTgVQ X-IronPort-AV: E=Sophos;i="4.84,703,1355097600"; d="scan'208,217";a="179285012" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 20 Feb 2013 19:48:01 +0000 Received: from [10.116.195.124] (rtp-mlinsner-87111.cisco.com [10.116.195.124]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r1KJlwCY030322; Wed, 20 Feb 2013 19:47:59 GMT User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Wed, 20 Feb 2013 14:47:58 -0500 From: Marc Linsner To: Dan Mongrain Message-ID: Thread-Topic: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3444216480_1464669" Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 19:48:22 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3444216480_1464669 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I understood you as requesting urn:service:sos.police.A4. My point was that if the LoST service had no entry for A4, it could simply check the Ax tree submitted in the location section of the request. So if the location included A1 & A4, the LoST service, finding nothing for A4 would then check A1 (not A3 or A2). This way the service would be matching the hierarchy of the given location vs. an arbitrary hierarchy that may be different from the requestors desire. Carry on=8A -Marc- From: Dan Mongrain Date: Wednesday, February 20, 2013 12:30 PM To: Marc Linsner Cc: "Winterbottom, James" , "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) > I do not understand your comment. What I am proposing is that requests d= o not > specify a search pattern in the case a requested jurisdiction is not foun= d. > It should not be to the requester which submits > urn:service:sos.police.country.A1.A2.A3.A4 to specify what to do if there= is > nothing configured for the A4 layer. It must be up to the LoST service t= o > apply whatever policy it has in this case. If we allow this, then do we = allow > urn:service:sos.police.fire? Give me fire first but if not found give me > police? >=20 > The Service URN should specify the "desired" service in a findService req= uest > and the LoST service provides a response based on local policies. All I = am > proposing is that one can specify a jurisdiction in the case there are mo= re > then one service provider for a location. >=20 > Thanx, > Dan >=20 > On Wed, Feb 20, 2013 at 8:48 AM, Marc Linsner wrote: >> The findService request includes location information. Why wouldn't the= LoST >> server simple walk the A1-A6 tree included with the location? If locati= on is >> geo, reverse geocode it. >>=20 >> What am I missing? >>=20 >> -Marc- >>=20 >> From: Dan Mongrain >> Date: Tuesday, February 19, 2013 11:55 PM >> To: "Winterbottom, James" >> Cc: "ecrit@ietf.org" >> Subject: Re: [Ecrit] What is the most appropriate method for registerin= g new >> sub-services of urn:service:sos (trimming due too large message report) >>=20 >>> What I meant is that if a jurisdictional scope aware LoST service recei= ves a >>> request for urn:service:sos.police.A4 and nothing is configured, it loo= ks >>> for urn:service:sos.police.A3 then urn:service:sos.police.A2, etc. unti= l it >>> finds a configured service. If nothing is found for >>> urn:service:sos.police.country then it pops the last element and looks = for >>> urn:service:sos.police (but then again, it is no longer jurisdictional = scope >>> aware). >>>=20 >>> I disagree that one needs to formulate the request as >>> urn:service:sos.police.country.A1.A2.A3.A4 in order for this to happen. >>> There must be only a single jurisdictional scope appended to a Service = URN. >>>=20 >>> I do not think we need a .A6 jurisdictional scope (street level). .A5 >>> (neighborhood, would point to a precinct for example) provides enough >>> granularity in my opinion. >>>=20 >>> Thanx, >>> Dan >>>=20 >>>=20 >>> On Tue, Feb 19, 2013 at 11:29 PM, Winterbottom, James >>> wrote: >>>> I am sorry, I am finding this confusing. >>>> =20 >>>> RFC5139 puts a hierarchy on A1 through A6. If you want this hierarchy = to >>>> work then A1 through A6 can=B9t be at the same level if you expect A3 to >>>> fallback to A2 or A1 in the case of a service not existing or a servic= e >>>> failure of some kind. If they exist at the same level then if A3 doesn= =B9t >>>> exist you will go to urn:service:sos.police unless you impose the >>>> hierarchy in the urn. >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>>=20 >>>> From: Dan Mongrain [mailto:dan@mongrain.org] >>>> Sent: Wednesday, 20 February 2013 3:23 PM >>>> To: DRAGE, Keith (Keith) >>>> Cc: Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org >>>> Subject: Re: [Ecrit] What is the most appropriate method for registeri= ng >>>> new sub-services of urn:service:sos (trimming due too large message re= port) >>>> =20 >>>> My recommendation for handling unknown Service URN depends if LoST ser= vice >>>> implements jurisdictional scope or not. If it does not, it pops the l= ast >>>> element and evaluates until a service is found. If it implements >>>> jurisdictional scope, the last element is a jurisdictional scope and i= t is >>>> not found, then you return the next highest level defined. >>>>=20 >>>> While it may be true that citizens typically dial 9-1-1 to request for >>>> help, police services such as state or provincial polices advertises >>>> numbers to call them directly (star code to dial using a mobile phone = for >>>> example) especially to report accidents on freeways. We need an equiv= alent >>>> Service URN. >>>>=20 >>>> Also while RFC5031's scope is citizen to authorities (I am not sure I = agree >>>> with this) I do not want to re-invent the wheel to signal calls within= an >>>> Emergency Services IP Network (ESInet). When I transfer a call from o= ne >>>> PSAP to another, the mechanism to determine where to send the call is = the >>>> same, using LoST. For a PSAP that covers a large area spanning multip= le >>>> counties and the calltaker needs to transfer the call to the appropria= te >>>> sheriff department for the caller's location, they only need a single >>>> transfer target (urn:service:sos.police.A2). It is not true that the >>>> calltaker always knows the actual destination of the call, especially = when >>>> the calltaker is only a call screener. >>>>=20 >>>> Thanx, >>>> Dan >>>>=20 >>>> On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) >>>> wrote: >>>>=20 >>>> The answer to James=B9s question depends on how you code it (and also wh= at >>>> you mean by fallback). >>>> =20 >>>> On any service URN, you ignore any subtypes from the point you stop >>>> understanding it. >>>> =20 >>>> So if the coding is sos.police.A2, and you do not understand A2, then = the >>>> service URN would be handled as if it was sos.police, not as sos.polic= e.A1. >>>> And if police was not understood then it would be handled as sos. >>>> =20 >>>> If you wanted something that went back to the next larger regional >>>> coverage, then you would have to code successive subtypes in sequence. >>>> =20 >>>> But I would also ask for an element of sanity in this discussion, rath= er >>>> than total flexibility. >>>> =20 >>>> For example while a national administration may have multiple levels o= f >>>> police force, not all of them are either reachable directly as an emer= gency >>>> service provider, nor are they necessarily an emergency service provid= er. >>>> If they are neither of these, then they presumably do not need a speci= al >>>> and distinct service URN. >>>> =20 >>>> It would therefore nice to see a current use case that is anything but= a >>>> choice of two, i.e. countrywide (following the ITU-T E.164 definition = of >>>> country) versus one more local variant. This restricted model certainl= y >>>> covers Ivo=B9s examples of Czeck Republic and Poland, and I believe it a= lso >>>> covers the other example I know of which is Italy. >>>> =20 >>>> While the USA has multiple levels of police force, on the PSTN, it onl= y >>>> appears to have one level of access to citizen to authority emergency >>>> service, which is 911. I see no reason why a change to voice over IP w= ould >>>> cause a change to this. >>>> =20 >>>> I would also stress that it is important to have global expectations o= f >>>> what you get when you use a service URN. If there is not care excercis= ed >>>> with assigning semantics and values, A3 in one country could result in= the >>>> forestry police and in another country the financial police responding= . >>>> =20 >>>> Note that read the scope of RFC 5031 as being for end user accessing t= he >>>> emergency service. While it might be possible to apply RFC 5031 to fur= ther >>>> network operations after the PSAP has been reached, e.g. to reach a >>>> subsidiary PSAP, I read that as outside the scope of RFC 5031. Nor do = I >>>> necessarily believe in that scenario that service URNs are necessarily= the >>>> best solution for routeing, as the first PSAP should know the particul= ar >>>> office they want to reach rather than just the type of emergency servi= ce. >>>> =20 >>>> Regards >>>> =20 >>>> Keith >>>> =20 >>>>=20 >>>>=20 >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf= Of >>>> Winterbottom, James >>>> Sent: 19 February 2013 23:29 >>>> To: Ivo Sedlacek; Dan Mongrain >>>> Cc: ecrit@ietf.org >>>> Subject: Re: [Ecrit] What is the most appropriate method for registeri= ng >>>> new sub-services of urn:service:sos (trimming due too large message re= port) >>>> =20 >>>> I am okay with this, providing that the fallback order is clearly defi= ned. >>>> That is, does an A3 fall back to an A2 or A1, or just back to sos? >>>> =20 >>>> =20 >>>> =20 >>>>=20 >>>> From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] >>>> Sent: Wednesday, 20 February 2013 7:32 AM >>>> To: Dan Mongrain >>>> Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org >>>> Subject: RE: [Ecrit] What is the most appropriate method for registeri= ng >>>> new sub-services of urn:service:sos (trimming due too large message re= port) >>>> =20 >>>> Hello, >>>> =20 >>>> If we go with RFC4119 based sub-services, would the IANA registration >>>> request be as follows? >>>> =20 >>>> - urn:service:sos.police.A3 - The 'police.local' service refers to the >>>> emergency service offered by the police department or other law enforc= ement >>>> authorities of the authorities of a city, township, shi (JP). >>>> - urn:service:sos.police.country - The 'police.national' service refer= s to >>>> the emergency service offered by the police department or other law >>>> enforcement authorities of the government of a country. >>>> =20 >>>> Does anyone see any issue in that? >>>> =20 >>>> If WG prefers this, it is OK for me. >>>> =20 >>>>> > In the latter case, so how do I get the county police (or state pol= ice, >>>>> there can be up to 4 police services for a given location in the US). >>>> =20 >>>> If I got it correctly, you propose that we also add >>>> - urn:service:sos.police.A2 - The 'police.local' service refers to the >>>> emergency service offered by the police department or other law enforc= ement >>>> authorities of the authorities of county, parish, gun (JP), district (= IN)" >>>> - urn:service:sos.police.A1 - The 'police.local' service refers to the >>>> emergency service offered by the police department or other law enforc= ement >>>> authorities of the authorities of national subdivisions (state, region= , >>>> province, prefecture)" >>>> =20 >>>> While I have no problem with that, I am not aware of a regulation >>>> establishing such emergency service so I cannot argue to IANA that the >>>> RFC5031 policy is satisfied for those URNs. >>>> =20 >>>> Kind regards >>>> =20 >>>> Ivo Sedlacek >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> This Communication is Confidential. We only send and receive email on = the >>>> basis of the terms set out at www.ericsson.com/email_disclaimer >>>> >>>> From: Dan Mongrain [mailto:dan@mongrain.org] >>>> Sent: 19. =FAnora 2013 21:12 >>>> To: Ivo Sedlacek >>>> Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org >>>> Subject: Re: [Ecrit] What is the most appropriate method for registeri= ng >>>> new sub-services of urn:service:sos (trimming due too large message re= port) >>>> =20 >>>> Thing is, when there is no city police, local would give you county po= lice >>>> (sheriff department) but in a city with a city police department local >>>> would give you city police. In the latter case, so how do I get the c= ounty >>>> police (or state police, there can be up to 4 police services for a gi= ven >>>> location in the US). Note that these examples are US based, but we do= have >>>> 3 levels of police services in Canada and I am sure other countries ha= ve >>>> the same issue. >>>> =20 >>>> There is also the terminology. There is no "national" police in the U= S or >>>> Canada but there is a federal police. Keeping the RFC 4119 terminolog= y >>>> removes any "local" interpretation issues. >>>>=20 >>>> Dan >>>>=20 >>>> On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek >>>> wrote: >>>>=20 >>>> I agree with Richard - there are countries where both the emergency se= rvice >>>> of the national police and the emergency service of the municipal poli= ce >>>> are offered in a given location. >>>> A user would call the municipal police emergency service to report e.g= . >>>> pickpockets. >>>> A user would call the national police emergency service to report e.g.= a >>>> murder. >>>> =20 >>>> =20 >>>> I submitted to IANA a request to register: >>>> - urn:service:sos.police.local - The 'police.local' service refers to = the >>>> emergency service offered by the police department or other law enforc= ement >>>> authorities of the local or municipal authorities. >>>> - urn:service:sos.police.national - The 'police.national' service refe= rs to >>>> the emergency service offered by the police department or other law >>>> enforcement authorities of the national government. >>>> =20 >>>> RFC5031 policy is hopefully fulfilled for them since they exist in two >>>> countries. >>>> =20 >>>> I am flexible whether the actual URNs contain the sub-services propose= d >>>> above (i.e. .local and .national sub-services) or subservices based on >>>> RFC4119 (i.e. .A3 and .country sub-services). >>>> =20 >>>> If the preference is for subservices based on RFC4119, do I need to ma= ke >>>> another IANA registration request or can we modify the URNs and their >>>> description during the expert review? >>>> =20 >>>> Kind regards >>>> =20 >>>> Ivo Sedlacek >>>> =20 >>>> This Communication is Confidential. We only send and receive email on = the >>>> basis of the terms set out at www.ericsson.com/email_disclaimer >>>> >>>> From: Dan Mongrain [mailto:dan@mongrain.org] >>>> Sent: 19. =FAnora 2013 15:36 >>>> To: Winterbottom, James >>>> Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org >>>> Subject: Re: [Ecrit] What is the most appropriate method for registeri= ng >>>> new sub-services of urn:service:sos >>>> =20 >>>> The problem is that different countries has different names for their >>>> political subdivisions. In the US they are states, in Canada they are >>>> provinces, etc. Same when you further subdivide. While not privy to = the >>>> discussions that came up with A1, A2, =8A, A5, I have the feeling this >>>> nomenclature was picked for the same reason. Why not utilise the same >>>> naming scheme for specifying the jurisdiction you want to reach? >>>> =20 >>>> Thanx, >>>> Dan >>>> =20 >>>>=20 >>>> On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James >>>> wrote: >>>>=20 >>>> In that case, one might say state in the hierarchy, not A1. >>>> =20 >>>> Cheers >>>> James >>>> =20 >>>> =20 >>>>=20 >>>> From: Richard Barnes [mailto:rlb@ipv.sx] >>>> Sent: Tuesday, 19 February 2013 8:57 AM >>>> To: Winterbottom, James >>>> Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org >>>>=20 >>>>=20 >>>> Subject: Re: [Ecrit] What is the most appropriate method for registeri= ng >>>> new sub-services of urn:service:sos >>>>=20 >>>> =20 >>>>=20 >>>> It might make sense if you wanted to allow the caller to explicitly se= lect >>>> police at a different level of responsibility, e.g., the state police >>>> rather than the local police. >>>>=20 >>>> =20 >>>>=20 >>>> On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James >>>> wrote: >>>>=20 >>>> I think I am missing something here, A1 is part of the location, so wh= y >>>> does it need to be in the URN at all? >>>> As far as I understand current deployments, they use the URN to select= a >>>> layer in the GIS that corresponds to the service type, and then use >>>> geographic boundaries within that layer to select the final destinatio= n. >>>> =20 >>>>=20 >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf= Of >>>> Dan Mongrain >>>> Sent: Tuesday, 19 February 2013 7:30 AM >>>>=20 >>>>=20 >>>> To: Ivo Sedlacek >>>> Cc: ecrit@ietf.org >>>> Subject: Re: [Ecrit] What is the most appropriate method for registeri= ng >>>> new sub-services of urn:service:sos >>>>=20 >>>> =20 >>>> Sorry for responding late to this thread, it kinda fell into a crack=8A= The >>>> current thread reminded me to check this old thread=8A >>>> =20 >>>> You are indicating that we need to register 77 Service URN (11 service >>>> subtypes * 7 jurisdiction types based on RFC 4119). I do not recommen= d >>>> that we create so many registrations. Instead, we should allow a serv= ice >>>> URN to be suffixed with a jurisdictional scope. So the following Serv= ice >>>> URN are all valid: >>>> =20 >>>> urn:service:sos.police >>>> urn:service:sos.police.traffic >>>> urn:service:sos.police.A1 >>>> urn:service:sos.police.traffic.A1 >>>> =20 >>>> Question is, do we want to leave jurisdictional scope to only be appli= cable >>>> to police branch or any Service URN? I=B9d say the latter as it is alwa= ys up >>>> to the LoST service provisioning (based on local policy) to determine = what >>>> is locally acceptable. >>>> =20 >>>> Thanx, >>>> Dan >>>> =20 >>>> =20 >>>> =20 >>>=20 >>> _______________________________________________ Ecrit mailing list >>> Ecrit@ietf.orghttps://www.ietf.org/mailman/listinfo/ecrit >=20 --B_3444216480_1464669 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
I understood you as requesti= ng urn:service:sos.police.A4.

My point was that if = the LoST service had no entry for A4, it could simply check the Ax tree subm= itted in the location section of the request.  So if the location inclu= ded A1 & A4, the LoST service, finding nothing for A4 would then check A= 1 (not A3 or A2).  This way the service would be matching the hierarchy= of the given location vs. an arbitrary hierarchy that may be different from= the requestors desire.

Carry on…
<= br>
-Marc-

From: <= /span> Dan Mongrain <dan@mongrain.org>
Date: Wednesday, February 2= 0, 2013 12:30 PM
To: Marc Linsner = <mlinsner@cisco.com>
Cc: "Winterbottom, James" <James.Winterbottom@commscope.com>= ;, "ecrit@ietf.org" <ecrit@ietf.org>
Sub= ject: Re: [Ecrit] What is the most appropriate method for registerin= g new sub-services of urn:service:sos (trimming due too large message report= )

I do = not understand your comment.  What I am proposing is that requests do n= ot specify a search pattern in the case a requested jurisdiction is not foun= d.  It should not be to the requester which submits urn:service:s= os.police.country.A1.A2.A3.A4 to specify what to do if there is nothing conf= igured for the A4 layer.  It must be up to the LoST service to apply wh= atever policy it has in this case.  If we allow this, then do we allow = urn:service:sos.police.fire?  Give me fire first but if not found give = me police?

The Service URN should specify the "desired" service in a = findService request and the LoST service provides a response based on local = policies.  All I am proposing is that one can specify a jurisdiction in= the case there are more then one service provider for a location.

Th= anx,
Dan

On Wed, Feb 20, 2013 at 8= :48 AM, Marc Linsner <mlinsner@cisco.com> wrote:
The findService request includes location information. &= nbsp;Why wouldn't the LoST server simple walk the A1-A6 tree included with t= he location?  If location is geo, reverse geocode it.

What am I missing?

-Marc-

From: Dan Mongrain= <dan@mongrain.org&= gt;
Date: Tuesday, February 19, 20= 13 11:55 PM
To: "Winterbottom, Jam= es" <Ja= mes.Winterbottom@commscope.com>
Cc:= "ecrit@ietf.org= " <ecrit@ietf.org>=
Subject: Re: [Ecrit] What is the = most appropriate method for registering new sub-services of urn:service:sos = (trimming due too large message report)

What I meant is that if a jurisdictional scope aware LoST service receives = a request for urn:service:sos.police.A4 and nothing is configured, it looks = for urn:service:sos.police.A3 then urn:service:sos.police.A2, etc. until it = finds a configured service.  If nothing is found for urn:service:sos.po= lice.country then it pops the last element and looks for urn:service:sos.pol= ice (but then again, it is no longer jurisdictional scope aware).

I d= isagree that one needs to formulate the request as urn:service:sos.police.co= untry.A1.A2.A3.A4 in order for this to happen.  There must be only a si= ngle jurisdictional scope appended to a Service URN.

I do not think w= e need a .A6 jurisdictional scope (street level).  .A5 (neighborhood, w= ould point to a precinct for example) provides enough granularity in my opin= ion.

Thanx,
Dan


On Tue, Feb 19= , 2013 at 11:29 PM, Winterbottom, James <James.Winterbottom@commsco= pe.com> wrote:

I am sor= ry, I am finding this confusing.

 

RFC5139 puts a hierarchy on A1 through A6. If you want this hierarch= y to work then A1 through A6 can’t be at the same level if you expect = A3 to fallback to A2 or A1 in the case of a service not existing or a servic= e failure of some kind. If they exist at the same level then if A3 doesnR= 17;t exist you will go to urn:service:sos.police  unless you impose the= hierarchy in the urn.

 

 

&nbs= p;

 =

 

From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: Wednesday, 20 F= ebruary 2013 3:23 PM
To: DRAGE, Keith (Keith)
Cc: Winter= bottom, James; Ivo Sedlacek; ecrit@ietf.org
Subject: Re: [Ecrit] What is the most appropri= ate method for registering new sub-services of urn:service:sos (trimming due= too large message report)

 

= My recommendation for handling unknown Service URN depends if LoST service i= mplements jurisdictional scope or not.  If it does not, it pops the las= t element and evaluates until a service is found.  If it implements jur= isdictional scope, the last element is a jurisdictional scope and it is not = found, then you return the next highest level defined.

While it may b= e true that citizens typically dial 9-1-1 to request for help, police servic= es such as state or provincial polices advertises numbers to call them direc= tly (star code to dial using a mobile phone for example) especially to repor= t accidents on freeways.  We need an equivalent Service URN.

Als= o while RFC5031's scope is citizen to authorities (I am not sure I agree wit= h this) I do not want to re-invent the wheel to signal calls within an Emerg= ency Services IP Network (ESInet).  When I transfer a call from one PSA= P to another, the mechanism to determine where to send the call is the same,= using LoST.  For a PSAP that covers a large area spanning multiple cou= nties and the calltaker needs to transfer the call to the appropriate sherif= f department for the caller's location, they only need a single transfer tar= get (urn:service:sos.police.A2).  It is not true that the calltaker alw= ays knows the actual destination of the call, especially when the calltaker = is only a call screener.

Thanx,
Dan

On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) <keith.drage@alcat= el-lucent.com> wrote:

The answer to James’s question depends on how you code = it (and also what you mean by fallback).=

 

On any ser= vice URN, you ignore any subtypes from the point you stop understanding it.<= /span>

 

So if the coding is sos.police.A2, and you do not u= nderstand A2, then the service URN would be handled as if it was sos.police,= not as sos.police.A1. And if police was not understood then it would be han= dled as sos.

 <= /p>

If you wanted something that went back= to the next larger regional coverage, then you would have to code successiv= e subtypes in sequence.

 <= /u>

But I would also ask for an= element of sanity in this discussion, rather than total flexibility.=

 

For example while a national administration may have mult= iple levels of police force, not all of them are either reachable directly a= s an emergency service provider, nor are they necessarily an emergency servi= ce provider. If they are neither of these, then they presumably do not need = a special and distinct service URN. =

 

It would there= fore nice to see a current use case that is anything but a choice of two, i.= e. countrywide (following the ITU-T E.164 definition of country) versus one = more local variant. This restricted model certainly covers Ivo’s examp= les of Czeck Republic and Poland, and I believe it also covers the other exa= mple I know of which is Italy.

 <= /u>

While the USA has mu= ltiple levels of police force, on the PSTN, it only appears to have one leve= l of access to citizen to authority emergency service, which is 911. I see n= o reason why a change to voice over IP would cause a change to this.<= span lang=3D"EN-GB">

 

I would also stress that it is important to have global ex= pectations of what you get when you use a service URN. If there is not care = excercised with assigning semantics and values, A3 in one country could resu= lt in the forestry police and in another country the financial police respon= ding.

 

Note that read the scope of RFC 5031 as being= for end user accessing the emergency service. While it might be possible to= apply RFC 5031 to further network operations after the PSAP has been reache= d, e.g. to reach a subsidiary PSAP, I read that as outside the scope of RFC = 5031. Nor do I necessarily believe in that scenario that service URNs are ne= cessarily the best solution for routeing, as the first PSAP should know the = particular office they want to reach rather than just the type of emergency = service.

 

<= p class=3D"MsoNormal">Regards

 

Keith

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] = On Behalf Of Winterbottom, James
Sent: 19 February 2013 23:29<= br>To: Ivo Sedlacek; Dan Mongrain
Cc: ecrit@ietf.org
Subject: Re: [Ecrit]= What is the most appropriate method for registering new sub-services of urn= :service:sos (trimming due too large message report)

&nb= sp;

I am okay wi= th this, providing that the fallback order is clearly defined.

Tha= t is, does an A3 fall back to an A2 or A1, or just back to sos?

&n= bsp;

=  

 

From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com= ]
Sent: Wednesday, 20 February 2013 7:32 AM
To: Dan Mon= grain
Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: RE: [Ecri= t] What is the most appropriate method for registering new sub-services of u= rn:service:sos (trimming due too large message report)

 

Hello,=

 

If we go with RFC4119 based sub-services, would the = IANA registration request be as follows?=

 

- urn:servic= e:sos.police.A3 - The 'police.local' service refers to the emerg= ency service offered by the police department or other law enforcement autho= rities of the authorities of a city, township, shi (JP).<= span lang=3D"EN-GB">

- urn:service:sos.police.country - The 'police.national' servic= e refers to the emergency service offered by the police department or other = law enforcement authorities of the government of a country.

 

Does anyone see any issue in that?

 <= span lang=3D"EN-GB">

If WG prefers this, it is OK for me.

 

> In the latter= case, so how do I get the county police (or state police, there can be up t= o 4 police services for a given location in the US). 

 

If I got it correctly, you propose that we also add

- urn:se= rvice:sos.police.A2 - The 'police.local' service refers to the emerge= ncy service offered by the police department or other law enforcement author= ities of the authorities of county, parish, gun (JP), district (IN)<= /u>"

= - urn:service:sos.police.A1 - The 'police.local' service= refers to the emergency service offered by the police department or other l= aw enforcement authorities of the authorities of national subdivisio= ns (state, region, province, prefecture)"

 

While I= have no problem with that, I am not aware of a regulation establishing such= emergency service so I cannot argue to IANA that the RFC5031 policy is sati= sfied for those URNs.

 =

Kind regards

 

Ivo Sedlacek

 

 

 <= u>

 

This Communi= cation is Confidential. We only send and receive email on the basis of the t= erms set out at www.ericsson.com/ema= il_disclaimer

From: Dan Mongrain [= mailto:dan@mongrain.org]
Sent: 19. =FAnora 2013 21:12
To:= Ivo Sedlacek
Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-s= ervices of urn:service:sos (trimming due too large message report)

 

Thing is, when there is no ci= ty police, local would give you county police (sheriff department) but in a = city with a city police department local would give you city police.  I= n the latter case, so how do I get the county police (or state police, there= can be up to 4 police services for a given location in the US).  Note = that these examples are US based, but we do have 3 levels of police services= in Canada and I am sure other countries have the same issue.

&nbs= p;

There is also the terminology.  There is no "national" police in the U= S or Canada but there is a federal police.  Keeping the RFC 4119 termin= ology removes any "local" interpretation issues.

Dan

On Tue, Feb 19, 2013 at= 2:31 PM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:=

I agree with R= ichard - there are countries where both the emergency service of the nationa= l police and the emergency service of the municipal police are offered in a = given location.

A user would call the municipal police emergency se= rvice to report e.g. pickpockets.

A user would call the national pol= ice emergency service to report e.g. a murder.<= /u>

 

 =

I submitted to IANA a request to register:

- urn:service:so= s.police.local - The 'police.local' service refers to the emergency service = offered by the police department or other law enforcement authorities of the= local or municipal authorities.

- urn:service:sos.police.national -= The 'police.national' service refers to the emergency service offered by th= e police department or other law enforcement authorities of the national gov= ernment.

 

RFC5031 policy is hopefully fulfilled for th= em since they exist in two countries.

 

I am flexible w= hether the actual URNs contain the sub-services proposed above (i.e. .local = and .national sub-services) or subservices based on RFC4119 (i.e. .A3 and .c= ountry sub-services).

 =

If the preference is for subser= vices based on RFC4119, do I need to make another IANA registration request = or can we modify the URNs and their description during the expert review?

 

Kind regards

 

Ivo Sedlacek=

This Communication is Confidential. We only send and receive = email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19.= =FAnora 2013 15:36
To: Winterbottom, James
Cc: Richard Ba= rnes; Ivo Sedlacek; ecrit@ie= tf.org
Subject: Re: [Ecrit] What is the most appropriate metho= d for registering new sub-services of urn:service:sos

 

The problem is th= at different countries has different names for their political subdivisions.=   In the US they are states, in Canada they are provinces, etc.  S= ame when you further subdivide.  While not privy to the discussions tha= t came up with A1, A2, …, A5, I have the feeling this nomenclature was= picked for the same reason.  Why not utilise the same naming scheme fo= r specifying the jurisdiction you want to reach?

 

= Thanx,

Dan

 

On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James <James.Winterbottom@commscope= .com> wrote:

In that case, one might say state in the hi= erarchy, not A1.

 

Cheers=

James

 

 

<= div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm = 0cm">

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Tuesday, 19 February 2013 8:= 57 AM
To: Winterbottom, James
Cc: Dan Mongrain; Ivo Sedl= acek; ecrit@ietf.org


Subject: Re: [Ecrit] What is the most appropriate method for re= gistering new sub-services of urn:service:sos

 

It might make = sense if you wanted to allow the caller to explicitly select police at a dif= ferent level of responsibility, e.g., the state police rather than the local= police.  

 =

On Mon, Feb 18, 2013 at 4:21 PM,= Winterbottom, James <James.Winterbottom@commscope.com> wrote:

= I think I am missing something here, A1 is part of the location, so why does= it need to be in the URN at all?

As far as I understand current d= eployments, they use the URN to select a layer in the GIS that corresponds t= o the service type, and then use geographic boundaries within that layer to = select the final destination.=

 <= /u>

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On B= ehalf Of Dan Mongrain
Sent: Tuesday, 19 February 2013 7:30 AM<= /span>


To: Ivo Sedlacek
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service= :sos

=

 

Sorry for responding late to this thread, it = kinda fell into a  crack…  The current thread reminded me to= check this old thread…=

 <= /u>

You are indicating = that we need to register 77 Service URN (11 service subtypes * 7 jurisdictio= n types based on RFC 4119).  I do not recommend that we create so many = registrations.  Instead, we should allow a service URN to be suffixed w= ith a jurisdictional scope.  So the following Service URN are all valid= :

 

urn:service:sos.police

urn:service:so= s.police.traffic

urn:service:sos.police.A1

urn:service:s= os.police.traffic.A1

 

Question is, do we want to l= eave jurisdictional scope to only be applicable to police branch or any Serv= ice URN?  I’d say the latter as it is always up to the LoST servi= ce provisioning (based on local policy) to determine what is locally accepta= ble.

=  

Thanx,

Dan

<= /div>

 

 =

 


_______________________________________________ Ecrit mailing list Ecrit@ietf.orghttps://www.iet= f.org/mailman/listinfo/ecrit

--B_3444216480_1464669-- From brian.rosen@neustar.biz Wed Feb 20 11:56:09 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C545D21E8030 for ; Wed, 20 Feb 2013 11:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.989 X-Spam-Level: X-Spam-Status: No, score=-5.989 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j208Fw-4nPoW for ; Wed, 20 Feb 2013 11:56:07 -0800 (PST) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1EF21E803A for ; Wed, 20 Feb 2013 11:56:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1361390356; x=1676744793; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=ETQ9KZrcX6JCZkNSf5yTVYY0u39bl+4hxfhpD1eRSNM=; b=siK3EeLJE4OVzjbniC0jM8RuTeXg76Wv7X7TSm5ZHLpKdeGODbuujFNefDm3qT QHO6YgeJ1p04DGv0oKwzLZeA== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.20022016; Wed, 20 Feb 2013 14:59:15 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Wed, 20 Feb 2013 14:56:01 -0500 From: "Rosen, Brian" To: Marc Linsner Date: Wed, 20 Feb 2013 14:56:00 -0500 Thread-Topic: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) Thread-Index: Ac4PpE6YkeHQCqmMS36Xdhcopik67w== Message-ID: <7C40F453-27B2-45AB-95A6-E7B56AACDBD5@neustar.biz> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: x-ems-stamp: y3Yn0Vie3vxCNttQvsh4pQ== Content-Type: multipart/alternative; boundary="_000_7C40F45327B245AB95A6E7B56AACDBD5neustarbiz_" MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 19:56:09 -0000 --_000_7C40F45327B245AB95A6E7B56AACDBD5neustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable To me, this doesn't make sense. Suppose I have a local police department in cities, but a provincial police= department in rural areas, as well as a national police. I ask for sos.po= lice.A3. If location was in a city, I should get sos.police.A3 But if I was in a rural area, a request for sos.police.A3 should return a r= esponse of sos.police.A2. That may or may not be the same as sos.police Brian On Feb 20, 2013, at 2:47 PM, Marc Linsner > wrote: I understood you as requesting urn:service:sos.police.A4. My point was that if the LoST service had no entry for A4, it could simply = check the Ax tree submitted in the location section of the request. So if = the location included A1 & A4, the LoST service, finding nothing for A4 wou= ld then check A1 (not A3 or A2). This way the service would be matching th= e hierarchy of the given location vs. an arbitrary hierarchy that may be di= fferent from the requestors desire. Carry on=85 -Marc- From: Dan Mongrain > Date: Wednesday, February 20, 2013 12:30 PM To: Marc Linsner > Cc: "Winterbottom, James" >, "ecrit@ietf.org" > Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) I do not understand your comment. What I am proposing is that requests do = not specify a search pattern in the case a requested jurisdiction is not fo= und. It should not be to the requester which submits urn:service:sos.polic= e.country.A1.A2.A3.A4 to specify what to do if there is nothing configured = for the A4 layer. It must be up to the LoST service to apply whatever poli= cy it has in this case. If we allow this, then do we allow urn:service:sos= .police.fire? Give me fire first but if not found give me police? The Service URN should specify the "desired" service in a findService reque= st and the LoST service provides a response based on local policies. All I= am proposing is that one can specify a jurisdiction in the case there are = more then one service provider for a location. Thanx, Dan On Wed, Feb 20, 2013 at 8:48 AM, Marc Linsner > wrote: The findService request includes location information. Why wouldn't the Lo= ST server simple walk the A1-A6 tree included with the location? If locati= on is geo, reverse geocode it. What am I missing? -Marc- From: Dan Mongrain > Date: Tuesday, February 19, 2013 11:55 PM To: "Winterbottom, James" > Cc: "ecrit@ietf.org" > Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) What I meant is that if a jurisdictional scope aware LoST service receives = a request for urn:service:sos.police.A4 and nothing is configured, it looks= for urn:service:sos.police.A3 then urn:service:sos.police.A2, etc. until i= t finds a configured service. If nothing is found for urn:service:sos.poli= ce.country then it pops the last element and looks for urn:service:sos.poli= ce (but then again, it is no longer jurisdictional scope aware). I disagree that one needs to formulate the request as urn:service:sos.polic= e.country.A1.A2.A3.A4 in order for this to happen. There must be only a si= ngle jurisdictional scope appended to a Service URN. I do not think we need a .A6 jurisdictional scope (street level). .A5 (nei= ghborhood, would point to a precinct for example) provides enough granulari= ty in my opinion. Thanx, Dan On Tue, Feb 19, 2013 at 11:29 PM, Winterbottom, James > wrote: I am sorry, I am finding this confusing. RFC5139 puts a hierarchy on A1 through A6. If you want this hierarchy to wo= rk then A1 through A6 can=92t be at the same level if you expect A3 to fall= back to A2 or A1 in the case of a service not existing or a service failure= of some kind. If they exist at the same level then if A3 doesn=92t exist y= ou will go to urn:service:sos.police unless you impose the hierarchy in th= e urn. From: Dan Mongrain [mailto:dan@mongrain.org] Sent: Wednesday, 20 February 2013 3:23 PM To: DRAGE, Keith (Keith) Cc: Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) My recommendation for handling unknown Service URN depends if LoST service = implements jurisdictional scope or not. If it does not, it pops the last e= lement and evaluates until a service is found. If it implements jurisdicti= onal scope, the last element is a jurisdictional scope and it is not found,= then you return the next highest level defined. While it may be true that citizens typically dial 9-1-1 to request for help= , police services such as state or provincial polices advertises numbers to= call them directly (star code to dial using a mobile phone for example) es= pecially to report accidents on freeways. We need an equivalent Service UR= N. Also while RFC5031's scope is citizen to authorities (I am not sure I agree= with this) I do not want to re-invent the wheel to signal calls within an = Emergency Services IP Network (ESInet). When I transfer a call from one PS= AP to another, the mechanism to determine where to send the call is the sam= e, using LoST. For a PSAP that covers a large area spanning multiple count= ies and the calltaker needs to transfer the call to the appropriate sheriff= department for the caller's location, they only need a single transfer tar= get (urn:service:sos.police.A2). It is not true that the calltaker always = knows the actual destination of the call, especially when the calltaker is = only a call screener. Thanx, Dan On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) > wrote: The answer to James=92s question depends on how you code it (and also what = you mean by fallback). On any service URN, you ignore any subtypes from the point you stop underst= anding it. So if the coding is sos.police.A2, and you do not understand A2, then the s= ervice URN would be handled as if it was sos.police, not as sos.police.A1. = And if police was not understood then it would be handled as sos. If you wanted something that went back to the next larger regional coverage= , then you would have to code successive subtypes in sequence. But I would also ask for an element of sanity in this discussion, rather th= an total flexibility. For example while a national administration may have multiple levels of pol= ice force, not all of them are either reachable directly as an emergency se= rvice provider, nor are they necessarily an emergency service provider. If = they are neither of these, then they presumably do not need a special and d= istinct service URN. It would therefore nice to see a current use case that is anything but a ch= oice of two, i.e. countrywide (following the ITU-T E.164 definition of coun= try) versus one more local variant. This restricted model certainly covers = Ivo=92s examples of Czeck Republic and Poland, and I believe it also covers= the other example I know of which is Italy. While the USA has multiple levels of police force, on the PSTN, it only app= ears to have one level of access to citizen to authority emergency service,= which is 911. I see no reason why a change to voice over IP would cause a = change to this. I would also stress that it is important to have global expectations of wha= t you get when you use a service URN. If there is not care excercised with = assigning semantics and values, A3 in one country could result in the fores= try police and in another country the financial police responding. Note that read the scope of RFC 5031 as being for end user accessing the em= ergency service. While it might be possible to apply RFC 5031 to further ne= twork operations after the PSAP has been reached, e.g. to reach a subsidiar= y PSAP, I read that as outside the scope of RFC 5031. Nor do I necessarily = believe in that scenario that service URNs are necessarily the best solutio= n for routeing, as the first PSAP should know the particular office they wa= nt to reach rather than just the type of emergency service. Regards Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Winterbottom, = James Sent: 19 February 2013 23:29 To: Ivo Sedlacek; Dan Mongrain Cc: ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) I am okay with this, providing that the fallback order is clearly defined. That is, does an A3 fall back to an A2 or A1, or just back to sos? From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] Sent: Wednesday, 20 February 2013 7:32 AM To: Dan Mongrain Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org Subject: RE: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) Hello, If we go with RFC4119 based sub-services, would the IANA registration reque= st be as follows? - urn:service:sos.police.A3 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of a city, township, shi (JP). - urn:service:sos.police.country - The 'police.national' service refers to = the emergency service offered by the police department or other law enforce= ment authorities of the government of a country. Does anyone see any issue in that? If WG prefers this, it is OK for me. > In the latter case, so how do I get the county police (or state police, t= here can be up to 4 police services for a given location in the US). If I got it correctly, you propose that we also add - urn:service:sos.police.A2 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of county, parish, gun (JP), district (IN)" - urn:service:sos.police.A1 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of national subdivisions (state, region, provin= ce, prefecture)" While I have no problem with that, I am not aware of a regulation establish= ing such emergency service so I cannot argue to IANA that the RFC5031 polic= y is satisfied for those URNs. 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 21:12 To: Ivo Sedlacek Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) Thing is, when there is no city police, local would give you county police = (sheriff department) but in a city with a city police department local woul= d give you city police. In the latter case, so how do I get the county pol= ice (or state police, there can be up to 4 police services for a given loca= tion in the US). Note that these examples are US based, but we do have 3 l= evels of police services in Canada and I am sure other countries have the s= ame issue. There is also the terminology. There is no "national" police in the US or = Canada but there is a federal police. Keeping the RFC 4119 terminology rem= oves any "local" interpretation issues. Dan On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek > wrote: I agree with Richard - there are countries where both the emergency service= of the national police and the emergency service of the municipal police a= re offered in a given location. A user would call the municipal police emergency service to report e.g. pic= kpockets. A user would call the national police emergency service to report e.g. a mu= rder. I submitted to IANA a request to register: - urn:service:sos.police.local - The 'police.local' service refers to the e= mergency service offered by the police department or other law enforcement = authorities of the local or municipal authorities. - urn:service:sos.police.national - The 'police.national' service refers to= the emergency service offered by the police department or other law enforc= ement authorities of the national government. RFC5031 policy is hopefully fulfilled for them since they exist in two coun= tries. I am flexible whether the actual URNs contain the sub-services proposed abo= ve (i.e. .local and .national sub-services) or subservices based on RFC4119= (i.e. .A3 and .country sub-services). If the preference is for subservices based on RFC4119, do I need to make an= other IANA registration request or can we modify the URNs and their descrip= tion during the expert review? 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 15:36 To: Winterbottom, James Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos The problem is that different countries has different names for their polit= ical subdivisions. In the US they are states, in Canada they are provinces= , etc. Same when you further subdivide. While not privy to the discussion= s that came up with A1, A2, =85, A5, I have the feeling this nomenclature w= as picked for the same reason. Why not utilise the same naming scheme for = specifying the jurisdiction you want to reach? Thanx, Dan On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James > wrote: In that case, one might say state in the hierarchy, not A1. Cheers James From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Tuesday, 19 February 2013 8:57 AM To: Winterbottom, James Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos It might make sense if you wanted to allow the caller to explicitly select = police at a different level of responsibility, e.g., the state police rathe= r than the local police. On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James > wrote: I think I am missing something here, A1 is part of the location, so why doe= s it need to be in the URN at all? As far as I understand current deployments, they use the URN to select a la= yer in the GIS that corresponds to the service type, and then use geographi= c boundaries within that layer to select the final destination. From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Dan Mongrain Sent: Tuesday, 19 February 2013 7:30 AM To: Ivo Sedlacek Cc: ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos Sorry for responding late to this thread, it kinda fell into a crack=85 T= he current thread reminded me to check this old thread=85 You are indicating that we need to register 77 Service URN (11 service subt= ypes * 7 jurisdiction types based on RFC 4119). I do not recommend that we= create so many registrations. Instead, we should allow a service URN to b= e suffixed with a jurisdictional scope. So the following Service URN are a= ll valid: urn:service:sos.police urn:service:sos.police.traffic urn:service:sos.police.A1 urn:service:sos.police.traffic.A1 Question is, do we want to leave jurisdictional scope to only be applicable= to police branch or any Service URN? I=92d say the latter as it is always= up to the LoST service provisioning (based on local policy) to determine w= hat is locally acceptable. Thanx, Dan _______________________________________________ Ecrit mailing list Ecrit@ie= tf.orghttps://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_7C40F45327B245AB95A6E7B56AACDBD5neustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable To me, this doesn't m= ake sense.

Suppose I have a local police department in c= ities, but a provincial police department in rural areas, as well as a nati= onal police.  I ask for sos.police.A3.  If location was in a city= , I should get sos.police.A3

But if I was in a rur= al area, a request for sos.police.A3 should return a response of sos.police= .A2.

That may or may not be the same as sos.police=

Brian

On Feb 20, 2013, at= 2:47 PM, Marc Linsner <mlinsner@c= isco.com> wrote:

I understood you as requesting urn:service:so= s.police.A4.

My point was that if the LoST service= had no entry for A4, it could simply check the Ax tree submitted in the lo= cation section of the request.  So if the location included A1 & A= 4, the LoST service, finding nothing for A4 would then check A1 (not A3 or = A2).  This way the service would be matching the hierarchy of the give= n location vs. an arbitrary hierarchy that may be different from the reques= tors desire.

Carry on=85

= -Marc-

From: Dan Mongrain <dan@mongrain.org<= /a>>
Date: Wednesday, Februa= ry 20, 2013 12:30 PM
To: Marc L= insner <mlinsner@cisco.com>=
Cc: "Winterbottom, James" <= James.Winterbottom@comm= scope.com>, "ecrit@ietf.org" &= lt;ecrit@ietf.org>
Subject: Re: [Ecrit] What is the most appropr= iate method for registering new sub-services of urn:service:sos (trimming d= ue too large message report)

I do not understand your c= omment.  What I am proposing is that requests do not specify a search = pattern in the case a requested jurisdiction is not found.  It should = not be to the requester which submits urn:service:sos.police.country.= A1.A2.A3.A4 to specify what to do if there is nothing configured for the A4= layer.  It must be up to the LoST service to apply whatever policy it= has in this case.  If we allow this, then do we allow urn:service:sos= .police.fire?  Give me fire first but if not found give me police?
=
The Service URN should specify the "desired" service in a findService r= equest and the LoST service provides a response based on local policies.&nb= sp; All I am proposing is that one can specify a jurisdiction in the case t= here are more then one service provider for a location.

Thanx,
Da= n

On Wed, Feb 20, 2013 at 8:48 AM,= Marc Linsner <mlinsner@cisco.com> wrote:
The findService request includes= location information.  Why wouldn't the LoST server simple walk the A= 1-A6 tree included with the location?  If location is geo, reverse geo= code it.

What am I missing?

-Marc-

From: Dan Mongrain <dan@mongrain.org>
Date: Tuesday, February 19, 2013 11:55 PM
To: "Winterbottom, James" <James.Winterbottom@commsco= pe.com>
Cc: "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] What is the most app= ropriate method for registering new sub-services of urn:service:sos (trimmi= ng due too large message report)

What I meant is that if a jurisdictional scope aware LoST service receives = a request for urn:service:sos.police.A4 and nothing is configured, it looks= for urn:service:sos.police.A3 then urn:service:sos.police.A2, etc. until i= t finds a configured service.  If nothing is found for urn:service:sos= .police.country then it pops the last element and looks for urn:service:sos= .police (but then again, it is no longer jurisdictional scope aware).
I disagree that one needs to formulate the request as urn:service:sos.pol= ice.country.A1.A2.A3.A4 in order for this to happen.  There must be on= ly a single jurisdictional scope appended to a Service URN.

I do not= think we need a .A6 jurisdictional scope (street level).  .A5 (neighb= orhood, would point to a precinct for example) provides enough granularity = in my opinion.

Thanx,
Dan


O= n Tue, Feb 19, 2013 at 11:29 PM, Winterbottom, James <= James= .Winterbottom@commscope.com> wrote:
<= div class=3D"MsoNormal">I am sorry, I am finding this con= fusing.
 
 
 
 
 
= From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: Wednesday, 20 February 2013= 3:23 PM
To: DRAGE, Keith (Keith)
Cc: Winterbottom, Jam= es; Ivo Sedlacek; ecrit= @ietf.org
Subject: Re: [Ecrit] What is the most appropriate m= ethod for registering new sub-services of urn:service:sos (trimming due too= large message report)
 

My recommendation for handling unknown Service URN depends if LoS= T service implements jurisdictional scope or not.  If it does not, it = pops the last element and evaluates until a service is found.  If it i= mplements jurisdictional scope, the last element is a jurisdictional scope = and it is not found, then you return the next highest level defined.
While it may be true that citizens typically dial 9-1-1 to request for hel= p, police services such as state or provincial polices advertises numbers t= o call them directly (star code to dial using a mobile phone for example) e= specially to report accidents on freeways.  We need an equivalent Serv= ice URN.

Also while RFC5031's scope is citizen to authorities (I am = not sure I agree with this) I do not want to re-invent the wheel to signal = calls within an Emergency Services IP Network (ESInet).  When I transf= er a call from one PSAP to another, the mechanism to determine where to sen= d the call is the same, using LoST.  For a PSAP that covers a large ar= ea spanning multiple counties and the calltaker needs to transfer the call = to the appropriate sheriff department for the caller's location, they only = need a single transfer target (urn:service:sos.police.A2).  It is not = true that the calltaker always knows the actual destination of the call, es= pecially when the calltaker is only a call screener.

Thanx,
Dan

On Tue, Feb 19, 2013 at 7:18 = PM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:<= u>
The answer to = James=92s question depends on how you code it (and also what you mean by fa= llback).
 =
On any serv= ice URN, you ignore any subtypes from the point you stop understanding it.<= /span>
 
So if the coding is so= s.police.A2, and you do not understand A2, then the service URN would be ha= ndled as if it was sos.police, not as sos.police.A1. And if police was not = understood then it would be handled as sos.<= /u>
 
If you wanted something that went back to the next la= rger regional coverage, then you would have to code successive subtypes in = sequence.
 =
But I would= also ask for an element of sanity in this discussion, rather than total fl= exibility.
 =
For example= while a national administration may have multiple levels of police force, = not all of them are either reachable directly as an emergency service provi= der, nor are they necessarily an emergency service provider. If they are ne= ither of these, then they presumably do not need a special and distinct ser= vice URN.
 =
It would th= erefore nice to see a current use case that is anything but a choice of two= , i.e. countrywide (following the ITU-T E.164 definition of country) versus= one more local variant. This restricted model certainly covers Ivo=92s exa= mples of Czeck Republic and Poland, and I believe it also covers the other = example I know of which is Italy.=
 
While the USA has multiple levels of police force, on the PSTN,= it only appears to have one level of access to citizen to authority emerge= ncy service, which is 911. I see no reason why a change to voice over IP wo= uld cause a change to this.
 
I would also stress that it is important to have global expectation= s of what you get when you use a service URN. If there is not care excercis= ed with assigning semantics and values, A3 in one country could result in t= he forestry police and in another country the financial police responding.<= /span>
 
Note that read the sco= pe of RFC 5031 as being for end user accessing the emergency service. While= it might be possible to apply RFC 5031 to further network operations after= the PSAP has been reached, e.g. to reach a subsidiary PSAP, I read that as= outside the scope of RFC 5031. Nor do I necessarily believe in that scenar= io that service URNs are necessarily the best solution for routeing, as the= first PSAP should know the particular office they want to reach rather tha= n just the type of emergency service.=
 <= span lang=3D"EN-GB">
Regards
 
Keith
 =
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behal= f Of Winterbottom, James
Sent: 19 February 2013 23:29
T= o: Ivo Sedlacek; Dan Mongrain
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] = What is the most appropriate method for registering new sub-services of urn= :service:sos (trimming due too large message report)
 
I am okay with this, providing that the fallback order is clear= ly defined.
That is, does an A3 fall back to an A2 or= A1, or just back to sos?<= /div>
 
 <= u>
From: Ivo Sedlacek = [mailto:ivo.= sedlacek@ericsson.com]
Sent: Wednesday, 20 February 2013 7:3= 2 AM
To: Dan Mongrain
Cc: Winterbottom, James; Richard = Barnes; ecrit@ietf.org<= /a>
Subject: RE: [Ecrit] What is the most appropriate method for = registering new sub-services of urn:service:sos (trimming due too large mes= sage report)
 
Hello,
 
If we go with RFC4119 based sub-services, would= the IANA registration request be as follows?
 
- urn:service:sos.police.A3 - The 'police.loc= al' service refers to the emergency service offered by the police departmen= t or other law enforcement authorities of the authorities of a city= , township, shi (JP).<= /div>
- urn:service:sos.police.c= ountry - The 'police.national' service refers to the emergency ser= vice offered by the police department or other law enforcement authorities = of the government of a country.<= /u>
 
= Does anyone see any issue in that?
&nbs= p;
If WG prefers this, it is OK for me.
 
> In the latter case, so how do I get th= e county police (or state police, there can be up to 4 police services for = a given location in the US). 
 
If I got it correctly, you propose that we also add
- urn:service:sos.police.A2 - The 'police.local' service refer= s to the emergency service offered by the police department or other law en= forcement authorities of the authorities of county, parish, gun (JP= ), district (IN)"
- urn:service:sos.police.A1 - The 'police.local' service refers to the emergency service offered by t= he police department or other law enforcement authorities of the authoritie= s of national subdivisions (state, region, province, prefecture)"
 
While I have no problem w= ith that, I am not aware of a regulation establishing such emergency servic= e so I cannot argue to IANA that the RFC5031 policy is satisfied for those = URNs.
 <= /span>
Kind regards
 
Ivo Sedlacek
&nbs= p;
 
 =
 
This Communication is Confidential. We only send and receive email on t= he basis of the terms set out at www.ericsson.com/email_disclaimer <= /u>
From: Dan Mongrain [mailto:dan@mongrain.org]=
Sent: 19. =FAnora 2013 21:12
To: Ivo Sedlacek
C= c: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: Re: [Ecrit] What= is the most appropriate method for registering new sub-services of urn:ser= vice:sos (trimming due too large message report)
 
Thing is, when there is n= o city police, local would give you county police (sheriff department) but = in a city with a city police department local would give you city police.&n= bsp; In the latter case, so how do I get the county police (or state police= , there can be up to 4 police services for a given location in the US).&nbs= p; Note that these examples are US based, but we do have 3 levels of police= services in Canada and I am sure other countries have the same issue.
=  

There is also the terminology.  There is no "national" police in the U= S or Canada but there is a federal police.  Keeping the RFC 4119 termi= nology removes any "local" interpretation issues.

Dan

On Tue, Feb 19= , 2013 at 2:31 PM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:
I agree with Richard - there are countries where both the emergenc= y service of the national police and the emergency service of the municipal= police are offered in a given location.
A user would = call the municipal police emergency service to report e.g. pickpockets.
A user would call the national police emergency service to= report e.g. a murder.
 
 = ;
I submitted to IANA a request to register:
- urn:service:sos.police.local - The 'police.local' service refer= s to the emergency service offered by the police department or other law en= forcement authorities of the local or municipal authorities.
- urn:service:sos.police.national - The 'police.national' service ref= ers to the emergency service offered by the police department or other law = enforcement authorities of the national government.
&nb= sp;
RFC5031 policy is hopefully fulfilled for them sinc= e they exist in two countries.
 
I am flexible whether the actual URNs contain the sub-services propose= d above (i.e. .local and .national sub-services) or subservices based on RF= C4119 (i.e. .A3 and .country sub-services).<= /u>
 
= If the preference is for subservices based on RFC4119, do I= need to make another IANA registration request or can we modify the URNs a= nd their description during the expert review?<= u>
 
Kind regards
 
Ivo Sedlacek
 =
This Communi= cation is Confidential. We only send and receive email on the basis of the = terms set out at www.ericsso= n.com/email_disclaimer
From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: = 19. =FAnora 2013 15:36
To: Winterbottom, James
Cc: Rich= ard Barnes; Ivo Sedlacek; ecrit@ietf.org
Subject: Re: [Ecrit] What is the most appro= priate method for registering new sub-services of urn:service:sos
 = ;
<= span style=3D"font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibr= i, sans-serif; ">The problem is that different countries has different name= s for their political subdivisions.  In the US they are states, in Can= ada they are provinces, etc.  Same when you further subdivide.  W= hile not privy to the discussions that came up with A1, A2, =85, A5, I have= the feeling this nomenclature was picked for the same reason.  Why no= t utilise the same naming scheme for specifying the jurisdiction you want t= o reach?
 <= u>
Thanx,=
Dan
<= p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">  

On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James <James.Winterbott= om@commscope.com> wrote:
In that case, one might= say state in the hierarchy, not A1.<= /u>
 
Cheers
<= div class=3D"MsoNormal">James=
 = ;
 
From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Tuesday, 19 February 2013 8:57 AM
To: Winterbottom, James
Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org<= /span>

Subject: Re: [Ecrit] W= hat is the most appropriate method for registering new sub-services of urn:= service:sos
 <= /div>
It might make sense if you wanted to all= ow the caller to explicitly select police at a different level of responsib= ility, e.g., the state police rather than the local police.  

 

On Mon, Feb 18, 2013 at 4:21 PM, Winter= bottom, James <James.Winterbottom@commscope.com> wrote:
I think I am missing something here, A1 is part of the location, so = why does it need to be in the URN at all?
As far as I= understand current deployments, they use the URN to select a layer in the = GIS that corresponds to the service type, and then use geographic boundarie= s within that layer to select the final destination.
=  
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Dan Mongrain
Sent: Tuesday, 19 February 2013 7:30 AM
<= br>To: Ivo Sedlacek
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:servic= e:sos
 
<= div class=3D"MsoNormal">Sorry for responding late to this= thread, it kinda fell into a  crack=85  The current thread remin= ded me to check this old thread=85
 
You are indicating that we need to register 77 Service URN (11 s= ervice subtypes * 7 jurisdiction types based on RFC 4119).  I do not r= ecommend that we create so many registrations.  Instead, we should all= ow a service URN to be suffixed with a jurisdictional scope.  So the f= ollowing Service URN are all valid:
 
urn:service:sos.police
urn:service:sos.po= lice.traffic
urn:service:sos.police.A1
urn:service:sos.police.traffic.A1
 
= Question is, do we want to leave jurisdictional scope to = only be applicable to police branch or any Service URN?  I=92d say the= latter as it is always up to the LoST service provisioning (based on local= policy) to determine what is locally acceptable.
&nb= sp;
Thanx,<= /span>
Dan
<= /div>
 
 
=  

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

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

What I proposed allows the requestor to tailor the request = to match his desire.

The fallback is multiple reque= sts.

-Marc-

From: "Rosen, Brian" <Brian.Rosen@neustar.biz>
Dat= e: Wednesday, February 20, 2013 2:56 PM
To: Marc Linsner <mlins= ner@cisco.com>
Cc: Dan Mong= rain <dan@mongrain.org>, "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-= services of urn:service:sos (trimming due too large message report)

To me, this doesn't make sense.

Suppose I= have a local police department in cities, but a provincial police departmen= t in rural areas, as well as a national police.  I ask for sos.police.A= 3.  If location was in a city, I should get sos.police.A3
But if I was in a rural area, a request for sos.police.A3 should= return a response of sos.police.A2.

That may or ma= y not be the same as sos.police

Brian
On Feb 20, 2013, at 2:47 PM, Marc Linsner <mlinsner@cisco.com> wrote:

I understood you as requesti= ng urn:service:sos.police.A4.

My point was that if = the LoST service had no entry for A4, it could simply check the Ax tree subm= itted in the location section of the request.  So if the location inclu= ded A1 & A4, the LoST service, finding nothing for A4 would then check A= 1 (not A3 or A2).  This way the service would be matching the hierarchy= of the given location vs. an arbitrary hierarchy that may be different from= the requestors desire.

Carry on…
<= br>
-Marc-

From:= Dan Mongrain <dan@mongrain.org= >
Date: Wednesday, February= 20, 2013 12:30 PM
To: Marc Linsne= r <mlinsner@cisco.com>
Cc: "Winterbottom, James" <James.Winterbottom@commscope.com&= gt;, "ecrit@ietf.org" <ecrit@ietf.org>
S= ubject: Re: [Ecrit] What is the most appropriate method for register= ing new sub-services of urn:service:sos (trimming due too large message repo= rt)

I do not understand your comment.  What I am proposing is th= at requests do not specify a search pattern in the case a requested jurisdic= tion is not found.  It should not be to the requester which submits urn:service:sos.police.country.A1.A2.A3.A4 to specify what to do if there= is nothing configured for the A4 layer.  It must be up to the LoST ser= vice to apply whatever policy it has in this case.  If we allow this, t= hen do we allow urn:service:sos.police.fire?  Give me fire first but if= not found give me police?

The Service URN should specify the "desire= d" service in a findService request and the LoST service provides a response= based on local policies.  All I am proposing is that one can specify a= jurisdiction in the case there are more then one service provider for a loc= ation.

Thanx,
Dan

On Wed, F= eb 20, 2013 at 8:48 AM, Marc Linsner <mlinsner@cisco.com> wrote:
The findService request incl= udes location information.  Why wouldn't the LoST server simple walk th= e A1-A6 tree included with the location?  If location is geo, reverse g= eocode it.

What am I missing?

<= div>-Marc-

From: Dan Mongrain <dan@mongrain.org>
Date: Tuesday, February 19, 2013 11:55 PM
To= : "Winterbottom, James" <James.Winterbottom@commscope.com>
Cc: "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-= services of urn:service:sos (trimming due too large message report)

What I meant is that if a jurisdictional scope aware LoST service receives = a request for urn:service:sos.police.A4 and nothing is configured, it looks = for urn:service:sos.police.A3 then urn:service:sos.police.A2, etc. until it = finds a configured service.  If nothing is found for urn:service:sos.po= lice.country then it pops the last element and looks for urn:service:sos.pol= ice (but then again, it is no longer jurisdictional scope aware).

I d= isagree that one needs to formulate the request as urn:service:sos.police.co= untry.A1.A2.A3.A4 in order for this to happen.  There must be only a si= ngle jurisdictional scope appended to a Service URN.

I do not think w= e need a .A6 jurisdictional scope (street level).  .A5 (neighborhood, w= ould point to a precinct for example) provides enough granularity in my opin= ion.

Thanx,
Dan


On Tue, Feb 19= , 2013 at 11:29 PM, Winterbottom, James <James.Winterbottom@commsco= pe.com> wrote:
I am sorry, I am finding this confusing.
 
RFC5139 puts a hierarchy on A1 through A6. If you w= ant this hierarchy to work then A1 through A6 can’t be at the same lev= el if you expect A3 to fallback to A2 or A1 in the case of a service not exi= sting or a service failure of some kind. If they exist at the same level the= n if A3 doesn’t exist you will go to urn:service:sos.police  unle= ss you impose the hierarchy in the urn.
 
 
 
 
 
From: Dan Mong= rain [mailto:dan@mongrain.= org]
Sent: Wednesday, 20 February 2013 3:23 PM
To: = DRAGE, Keith (Keith)
Cc: Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org
Subject:<= /b> Re: [Ecrit] What is the most appropriate method for registering new sub-= services of urn:service:sos (trimming due too large message report)
 

My recommendation for handlin= g unknown Service URN depends if LoST service implements jurisdictional scop= e or not.  If it does not, it pops the last element and evaluates until= a service is found.  If it implements jurisdictional scope, the last e= lement is a jurisdictional scope and it is not found, then you return the ne= xt highest level defined.

While it may be true that citizens typicall= y dial 9-1-1 to request for help, police services such as state or provincia= l polices advertises numbers to call them directly (star code to dial using = a mobile phone for example) especially to report accidents on freeways. = ; We need an equivalent Service URN.

Also while RFC5031's scope is ci= tizen to authorities (I am not sure I agree with this) I do not want to re-i= nvent the wheel to signal calls within an Emergency Services IP Network (ESI= net).  When I transfer a call from one PSAP to another, the mechanism t= o determine where to send the call is the same, using LoST.  For a PSAP= that covers a large area spanning multiple counties and the calltaker needs= to transfer the call to the appropriate sheriff department for the caller's= location, they only need a single transfer target (urn:service:sos.police.A= 2).  It is not true that the calltaker always knows the actual destinat= ion of the call, especially when the calltaker is only a call screener.
<= br>Thanx,
Dan

On Tue, Feb 19= , 2013 at 7:18 PM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote= :
The answer to= James’s question depends on how you code it (and also what you mean b= y fallback).
 
On any service URN, you ignore= any subtypes from the point you stop understanding it.
 <= /span>
<= span style=3D"font-size: 10pt; color: navy; font-family: Arial, sans-serif; " = lang=3D"EN-GB">So if the coding is sos.police.A2, and you do not understand A2= , then the service URN would be handled as if it was sos.police, not as sos.= police.A1. And if police was not understood then it would be handled as sos.=
=  
If you wanted something that went back to = the next larger regional coverage, then you would have to code successive su= btypes in sequence.
 <= /u>
But I would also ask fo= r an element of sanity in this discussion, rather than total flexibility.
 
For example while a national administration m= ay have multiple levels of police force, not all of them are either reachabl= e directly as an emergency service provider, nor are they necessarily an eme= rgency service provider. If they are neither of these, then they presumably = do not need a special and distinct service URN.
 <= span lang=3D"EN-GB">
It would therefore nice to see a current use case that is anything but= a choice of two, i.e. countrywide (following the ITU-T E.164 definition of = country) versus one more local variant. This restricted model certainly cove= rs Ivo’s examples of Czeck Republic and Poland, and I believe it also = covers the other example I know of which is Italy.=
 
While the USA has multiple levels of police force, on the PSTN, it o= nly appears to have one level of access to citizen to authority emergency se= rvice, which is 911. I see no reason why a change to voice over IP would cau= se a change to this.
 =
I would also stress th= at it is important to have global expectations of what you get when you use = a service URN. If there is not care excercised with assigning semantics and = values, A3 in one country could result in the forestry police and in another= country the financial police responding.
 
N= ote that read the scope of RFC 5031 as being for end user accessing the emer= gency service. While it might be possible to apply RFC 5031 to further netwo= rk operations after the PSAP has been reached, e.g. to reach a subsidiary PS= AP, I read that as outside the scope of RFC 5031. Nor do I necessarily belie= ve in that scenario that service URNs are necessarily the best solution for = routeing, as the first PSAP should know the particular office they want to r= each rather than just the type of emergency service.
 
Regards
 
Keith
 =
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behal= f Of Winterbottom, James
Sent: 19 February 2013 23:29
To= : Ivo Sedlacek; Dan Mongrain
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service= :sos (trimming due too large message report)
 <= u>
I am okay wi= th this, providing that the fallback order is clearly defined.
That is, does an A3 fall back to an A2 or A1, or just back to sos?
 
 
 
From: Ivo Sedlacek = [mailto:ivo.sedla= cek@ericsson.com]
Sent: Wednesday, 20 February 2013 7:32 AMTo: Dan Mongrain
Cc: Winterbottom, James; Richard Barnes;= ecrit@ietf.org
Su= bject: RE: [Ecrit] What is the most appropriate method for registering n= ew sub-services of urn:service:sos (trimming due too large message report)
 
Hello,<= /div>
 =
If we go with RF= C4119 based sub-services, would the IANA registration request be as follows?=
=  
- urn:service:sos.police.A3 - Th= e 'police.local' service refers to the emergency service offered by the poli= ce department or other law enforcement authorities of the authorities <= u>of a city, township, shi (JP).=
- urn:service:sos.police= .country - The 'police.national' service refers to the emergency se= rvice offered by the police department or other law enforcement authorities = of the government of a country.=
 
D= oes anyone see any issue in that?
 
If WG prefe= rs this, it is OK for me.
 
> In the latter cas= e, so how do I get the county police (or state police, there can be up to 4 = police services for a given location in the US). 
 
If I got it correctly, you propose that we also add
= - urn:service:sos.police.A2 - The 'police.local' service refers to th= e emergency service offered by the police department or other law enforcemen= t authorities of the authorities of county, parish, gun (JP), distri= ct (IN)"
- urn:service:sos.police.A1 - The 'police.lo= cal' service refers to the emergency service offered by the police departmen= t or other law enforcement authorities of the authorities of nationa= l subdivisions (state, region, province, prefecture)"
 =
= While I have no problem with that, I am not aware of a regulati= on establishing such emergency service so I cannot argue to IANA that the RF= C5031 policy is satisfied for those URNs.
 
Kin= d regards
 <= /div>
Ivo Sedlacek
 
&nbs= p;
 
 
This Communication is Confidenti= al. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer
From: Dan = Mongrain [mailto:dan@mongr= ain.org]
Sent: 19. =FAnora 2013 21:12
To: Ivo Sedlace= k
Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: Re: [Ecrit] W= hat is the most appropriate method for registering new sub-services of urn:s= ervice:sos (trimming due too large message report)=
 <= u>
Thing is, when there is no city polic= e, local would give you county police (sheriff department) but in a city wit= h a city police department local would give you city police.  In the la= tter case, so how do I get the county police (or state police, there can be = up to 4 police services for a given location in the US).  Note that the= se examples are US based, but we do have 3 levels of police services in Cana= da and I am sure other countries have the same issue.
 

There is also the terminology.  There is no "national" police in the U= S or Canada but there is a federal police.  Keeping the RFC 4119 termin= ology removes any "local" interpretation issues.

Dan

On Tue, Feb 19, 2013 = at 2:31 PM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:
I agree with = Richard - there are countries where both the emergency service of the nation= al police and the emergency service of the municipal police are offered in a= given location.
A user would call the municipal police emergen= cy service to report e.g. pickpockets.
A user would call the nat= ional police emergency service to report e.g. a murder.
 
 
I submitted to IANA a request to register:
- urn:service:sos.police.local - The 'police.local' service refers = to the emergency service offered by the police department or other law enfor= cement authorities of the local or municipal authorities.
- urn:= service:sos.police.national - The 'police.national' service refers to the em= ergency service offered by the police department or other law enforcement au= thorities of the national government.
 
RFC5031= policy is hopefully fulfilled for them since they exist in two countries.
 
I am flexible whether the actual URNs contain = the sub-services proposed above (i.e. .local and .national sub-services) or = subservices based on RFC4119 (i.e. .A3 and .country sub-services).
If the preference is for subservices based on RFC4119,= do I need to make another IANA registration request or can we modify the UR= Ns and their description during the expert review?=
 =
Kind regards
 
Ivo Sedlacek
&= nbsp;
This Communication is Confidential. We only send and receive= email on the basis of the terms set out at www.ericsson.com/email_disclaimer <= /u>
From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19. =FAnora 2013 15:36
To: Winterbottom, James
Cc: Richa= rd Barnes; Ivo Sedlacek; ecr= it@ietf.org
Subject: Re: [Ecrit] What is the most appropriate = method for registering new sub-services of urn:service:sos
 
The = problem is that different countries has different names for their political = subdivisions.  In the US they are states, in Canada they are provinces,= etc.  Same when you further subdivide.  While not privy to the di= scussions that came up with A1, A2, …, A5, I have the feeling this nom= enclature was picked for the same reason.  Why not utilise the same nam= ing scheme for specifying the jurisdiction you want to reach?
=  
Thanx,
Dan

 

On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James <James.Winterbottom@commsco= pe.com> wrote:
In that case, one might say state in the h= ierarchy, not A1.
 
Cheers
Ja= mes
 
 
From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Tue= sday, 19 February 2013 8:57 AM
To: Winterbottom, James
Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org

Subject: Re: [Ecrit] What is the most a= ppropriate method for registering new sub-services of urn:service:sos
 
It might make sense if you wanted to allow the caller to explicitly s= elect police at a different level of responsibility, e.g., the state police = rather than the local police.  =

 

On Mon,= Feb 18, 2013 at 4:21 PM, Winterbottom, James <James.Winterbottom@commscope.com= > wrote:
I think I am missing something here, A1 is part of t= he location, so why does it need to be in the URN at all?
As f= ar as I understand current deployments, they use the URN to select a layer i= n the GIS that corresponds to the service type, and then use geographic boun= daries within that layer to select the final destination.
&nbs= p;
= From: ecrit-bounces@= ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Dan Mongrain
Sent: Tuesday, 19 February 2013 7:30 AM<= /span>

To: Ivo Sedlacek
Cc= : ecrit@ietf.org
= Subject: Re: [Ecrit] What is the most appropriate method for register= ing new sub-services of urn:service:sos
 
Sorry for res= ponding late to this thread, it kinda fell into a  crack…  T= he current thread reminded me to check this old thread…
=  
You are indicating that we need to register 77 Service = URN (11 service subtypes * 7 jurisdiction types based on RFC 4119).  I = do not recommend that we create so many registrations.  Instead, we sho= uld allow a service URN to be suffixed with a jurisdictional scope.  So= the following Service URN are all valid:
 
urn:service:sos.police
=
urn:service:sos.police.traffic<= span lang=3D"EN-GB">
urn:service:sos.police.A1
urn:service:sos.police.traffi= c.A1
 
Question is, do we want to leave jur= isdictional scope to only be applicable to police branch or any Service URN?=  I’d say the latter as it is always up to the LoST service provi= sioning (based on local policy) to determine what is locally acceptable.
 
Thanx,
Dan
<= div class=3D"MsoNormal"> 
 
 
=

_______________________________________________ Ecrit mailing list Ecrit@ietf.orghttps://www.iet= f.org/mailman/listinfo/ecrit

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

--B_3444218186_1567595-- From brian.rosen@neustar.biz Wed Feb 20 12:19:54 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A78921F87C6 for ; Wed, 20 Feb 2013 12:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.714 X-Spam-Level: X-Spam-Status: No, score=-5.714 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZwWUA47VsLJ for ; Wed, 20 Feb 2013 12:19:51 -0800 (PST) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4A221F874F for ; Wed, 20 Feb 2013 12:19:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1361391782; x=1676744793; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=umoNG+5QJQItLAJNFYI5nx5juiSrM7EOGAfvmosddxs=; b=ZVmLz75LZMC/kzx/RKcKWXmE/tHaXwUPBYeVnzsRUYyXx7eff8RS+dm2DQ02xu b11/5JmOMdbWQ9ppZYJ/CTXQ== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.20023191; Wed, 20 Feb 2013 15:23:01 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Wed, 20 Feb 2013 15:19:47 -0500 From: "Rosen, Brian" To: Marc Linsner Date: Wed, 20 Feb 2013 15:19:46 -0500 Thread-Topic: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) Thread-Index: Ac4Pp6Bp8t7b8MB1Q0+LmtgpO7W7AQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: x-ems-stamp: gs8vLB1UNJe5cBRLzyWYAA== Content-Type: multipart/alternative; boundary="_000_D96247920C2A411F8F4808D97434320Cneustarbiz_" MIME-Version: 1.0 Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:19:54 -0000 --_000_D96247920C2A411F8F4808D97434320Cneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable If you don't want A2, repeat the request with A1. You know that you got A2= , so you know when you have to do that. It's a corner case at best. Brian On Feb 20, 2013, at 3:16 PM, Marc Linsner > wrote: What if I don't want A2 (I don't trust Butler County sheriff), if no A3 (Ma= rs) give me A1 (PA)? What I proposed allows the requestor to tailor the request to match his des= ire. The fallback is multiple requests. -Marc- From: "Rosen, Brian" > Date: Wednesday, February 20, 2013 2:56 PM To: Marc Linsner > Cc: Dan Mongrain >, "ecrit@ietf.o= rg" > Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) To me, this doesn't make sense. Suppose I have a local police department in cities, but a provincial police= department in rural areas, as well as a national police. I ask for sos.po= lice.A3. If location was in a city, I should get sos.police.A3 But if I was in a rural area, a request for sos.police.A3 should return a r= esponse of sos.police.A2. That may or may not be the same as sos.police Brian On Feb 20, 2013, at 2:47 PM, Marc Linsner > wrote: I understood you as requesting urn:service:sos.police.A4. My point was that if the LoST service had no entry for A4, it could simply = check the Ax tree submitted in the location section of the request. So if = the location included A1 & A4, the LoST service, finding nothing for A4 wou= ld then check A1 (not A3 or A2). This way the service would be matching th= e hierarchy of the given location vs. an arbitrary hierarchy that may be di= fferent from the requestors desire. Carry on=85 -Marc- From: Dan Mongrain > Date: Wednesday, February 20, 2013 12:30 PM To: Marc Linsner > Cc: "Winterbottom, James" >, "ecrit@ietf.org" > Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) I do not understand your comment. What I am proposing is that requests do = not specify a search pattern in the case a requested jurisdiction is not fo= und. It should not be to the requester which submits urn:service:sos.polic= e.country.A1.A2.A3.A4 to specify what to do if there is nothing configured = for the A4 layer. It must be up to the LoST service to apply whatever poli= cy it has in this case. If we allow this, then do we allow urn:service:sos= .police.fire? Give me fire first but if not found give me police? The Service URN should specify the "desired" service in a findService reque= st and the LoST service provides a response based on local policies. All I= am proposing is that one can specify a jurisdiction in the case there are = more then one service provider for a location. Thanx, Dan On Wed, Feb 20, 2013 at 8:48 AM, Marc Linsner > wrote: The findService request includes location information. Why wouldn't the Lo= ST server simple walk the A1-A6 tree included with the location? If locati= on is geo, reverse geocode it. What am I missing? -Marc- From: Dan Mongrain > Date: Tuesday, February 19, 2013 11:55 PM To: "Winterbottom, James" > Cc: "ecrit@ietf.org" > Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) What I meant is that if a jurisdictional scope aware LoST service receives = a request for urn:service:sos.police.A4 and nothing is configured, it looks= for urn:service:sos.police.A3 then urn:service:sos.police.A2, etc. until i= t finds a configured service. If nothing is found for urn:service:sos.poli= ce.country then it pops the last element and looks for urn:service:sos.poli= ce (but then again, it is no longer jurisdictional scope aware). I disagree that one needs to formulate the request as urn:service:sos.polic= e.country.A1.A2.A3.A4 in order for this to happen. There must be only a si= ngle jurisdictional scope appended to a Service URN. I do not think we need a .A6 jurisdictional scope (street level). .A5 (nei= ghborhood, would point to a precinct for example) provides enough granulari= ty in my opinion. Thanx, Dan On Tue, Feb 19, 2013 at 11:29 PM, Winterbottom, James > wrote: I am sorry, I am finding this confusing. RFC5139 puts a hierarchy on A1 through A6. If you want this hierarchy to wo= rk then A1 through A6 can=92t be at the same level if you expect A3 to fall= back to A2 or A1 in the case of a service not existing or a service failure= of some kind. If they exist at the same level then if A3 doesn=92t exist y= ou will go to urn:service:sos.police unless you impose the hierarchy in th= e urn. From: Dan Mongrain [mailto:dan@mongrain.org] Sent: Wednesday, 20 February 2013 3:23 PM To: DRAGE, Keith (Keith) Cc: Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) My recommendation for handling unknown Service URN depends if LoST service = implements jurisdictional scope or not. If it does not, it pops the last e= lement and evaluates until a service is found. If it implements jurisdicti= onal scope, the last element is a jurisdictional scope and it is not found,= then you return the next highest level defined. While it may be true that citizens typically dial 9-1-1 to request for help= , police services such as state or provincial polices advertises numbers to= call them directly (star code to dial using a mobile phone for example) es= pecially to report accidents on freeways. We need an equivalent Service UR= N. Also while RFC5031's scope is citizen to authorities (I am not sure I agree= with this) I do not want to re-invent the wheel to signal calls within an = Emergency Services IP Network (ESInet). When I transfer a call from one PS= AP to another, the mechanism to determine where to send the call is the sam= e, using LoST. For a PSAP that covers a large area spanning multiple count= ies and the calltaker needs to transfer the call to the appropriate sheriff= department for the caller's location, they only need a single transfer tar= get (urn:service:sos.police.A2). It is not true that the calltaker always = knows the actual destination of the call, especially when the calltaker is = only a call screener. Thanx, Dan On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) > wrote: The answer to James=92s question depends on how you code it (and also what = you mean by fallback). On any service URN, you ignore any subtypes from the point you stop underst= anding it. So if the coding is sos.police.A2, and you do not understand A2, then the s= ervice URN would be handled as if it was sos.police, not as sos.police.A1. = And if police was not understood then it would be handled as sos. If you wanted something that went back to the next larger regional coverage= , then you would have to code successive subtypes in sequence. But I would also ask for an element of sanity in this discussion, rather th= an total flexibility. For example while a national administration may have multiple levels of pol= ice force, not all of them are either reachable directly as an emergency se= rvice provider, nor are they necessarily an emergency service provider. If = they are neither of these, then they presumably do not need a special and d= istinct service URN. It would therefore nice to see a current use case that is anything but a ch= oice of two, i.e. countrywide (following the ITU-T E.164 definition of coun= try) versus one more local variant. This restricted model certainly covers = Ivo=92s examples of Czeck Republic and Poland, and I believe it also covers= the other example I know of which is Italy. While the USA has multiple levels of police force, on the PSTN, it only app= ears to have one level of access to citizen to authority emergency service,= which is 911. I see no reason why a change to voice over IP would cause a = change to this. I would also stress that it is important to have global expectations of wha= t you get when you use a service URN. If there is not care excercised with = assigning semantics and values, A3 in one country could result in the fores= try police and in another country the financial police responding. Note that read the scope of RFC 5031 as being for end user accessing the em= ergency service. While it might be possible to apply RFC 5031 to further ne= twork operations after the PSAP has been reached, e.g. to reach a subsidiar= y PSAP, I read that as outside the scope of RFC 5031. Nor do I necessarily = believe in that scenario that service URNs are necessarily the best solutio= n for routeing, as the first PSAP should know the particular office they wa= nt to reach rather than just the type of emergency service. Regards Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Winterbottom, = James Sent: 19 February 2013 23:29 To: Ivo Sedlacek; Dan Mongrain Cc: ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) I am okay with this, providing that the fallback order is clearly defined. That is, does an A3 fall back to an A2 or A1, or just back to sos? From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] Sent: Wednesday, 20 February 2013 7:32 AM To: Dan Mongrain Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org Subject: RE: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) Hello, If we go with RFC4119 based sub-services, would the IANA registration reque= st be as follows? - urn:service:sos.police.A3 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of a city, township, shi (JP). - urn:service:sos.police.country - The 'police.national' service refers to = the emergency service offered by the police department or other law enforce= ment authorities of the government of a country. Does anyone see any issue in that? If WG prefers this, it is OK for me. > In the latter case, so how do I get the county police (or state police, t= here can be up to 4 police services for a given location in the US). If I got it correctly, you propose that we also add - urn:service:sos.police.A2 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of county, parish, gun (JP), district (IN)" - urn:service:sos.police.A1 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of national subdivisions (state, region, provin= ce, prefecture)" While I have no problem with that, I am not aware of a regulation establish= ing such emergency service so I cannot argue to IANA that the RFC5031 polic= y is satisfied for those URNs. 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 21:12 To: Ivo Sedlacek Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) Thing is, when there is no city police, local would give you county police = (sheriff department) but in a city with a city police department local woul= d give you city police. In the latter case, so how do I get the county pol= ice (or state police, there can be up to 4 police services for a given loca= tion in the US). Note that these examples are US based, but we do have 3 l= evels of police services in Canada and I am sure other countries have the s= ame issue. There is also the terminology. There is no "national" police in the US or = Canada but there is a federal police. Keeping the RFC 4119 terminology rem= oves any "local" interpretation issues. Dan On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek > wrote: I agree with Richard - there are countries where both the emergency service= of the national police and the emergency service of the municipal police a= re offered in a given location. A user would call the municipal police emergency service to report e.g. pic= kpockets. A user would call the national police emergency service to report e.g. a mu= rder. I submitted to IANA a request to register: - urn:service:sos.police.local - The 'police.local' service refers to the e= mergency service offered by the police department or other law enforcement = authorities of the local or municipal authorities. - urn:service:sos.police.national - The 'police.national' service refers to= the emergency service offered by the police department or other law enforc= ement authorities of the national government. RFC5031 policy is hopefully fulfilled for them since they exist in two coun= tries. I am flexible whether the actual URNs contain the sub-services proposed abo= ve (i.e. .local and .national sub-services) or subservices based on RFC4119= (i.e. .A3 and .country sub-services). If the preference is for subservices based on RFC4119, do I need to make an= other IANA registration request or can we modify the URNs and their descrip= tion during the expert review? 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 15:36 To: Winterbottom, James Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos The problem is that different countries has different names for their polit= ical subdivisions. In the US they are states, in Canada they are provinces= , etc. Same when you further subdivide. While not privy to the discussion= s that came up with A1, A2, =85, A5, I have the feeling this nomenclature w= as picked for the same reason. Why not utilise the same naming scheme for = specifying the jurisdiction you want to reach? Thanx, Dan On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James > wrote: In that case, one might say state in the hierarchy, not A1. Cheers James From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Tuesday, 19 February 2013 8:57 AM To: Winterbottom, James Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos It might make sense if you wanted to allow the caller to explicitly select = police at a different level of responsibility, e.g., the state police rathe= r than the local police. On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James > wrote: I think I am missing something here, A1 is part of the location, so why doe= s it need to be in the URN at all? As far as I understand current deployments, they use the URN to select a la= yer in the GIS that corresponds to the service type, and then use geographi= c boundaries within that layer to select the final destination. From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Dan Mongrain Sent: Tuesday, 19 February 2013 7:30 AM To: Ivo Sedlacek Cc: ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos Sorry for responding late to this thread, it kinda fell into a crack=85 T= he current thread reminded me to check this old thread=85 You are indicating that we need to register 77 Service URN (11 service subt= ypes * 7 jurisdiction types based on RFC 4119). I do not recommend that we= create so many registrations. Instead, we should allow a service URN to b= e suffixed with a jurisdictional scope. So the following Service URN are a= ll valid: urn:service:sos.police urn:service:sos.police.traffic urn:service:sos.police.A1 urn:service:sos.police.traffic.A1 Question is, do we want to leave jurisdictional scope to only be applicable= to police branch or any Service URN? I=92d say the latter as it is always= up to the LoST service provisioning (based on local policy) to determine w= hat is locally acceptable. Thanx, Dan _______________________________________________ Ecrit mailing list Ecrit@ie= tf.orghttps://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_D96247920C2A411F8F4808D97434320Cneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable If you don't want A2,= repeat the request with A1.  You know that you got A2, so you know wh= en you have to do that.  It's a corner case at best.

Brian

On Feb 20, 2013, at 3:16 PM, Marc Linsner &= lt;mlinsner@cisco.com> wrote:<= /div>
What if I don't want A2 (I don't trust Butler County sheriff), if no = A3 (Mars) give me A1 (PA)?

What I proposed allows = the requestor to tailor the request to match his desire.

The fallback is multiple requests.

-Marc-

From: "Ro= sen, Brian" <Brian.Rosen@neus= tar.biz>
Date: Wednesday= , February 20, 2013 2:56 PM
To: = Marc Linsner <mlinsner@cisco.com<= /a>>
Cc: Dan Mongrain <dan@mongrain.org>, "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] What is the most appropriate method for registering new sub= -services of urn:service:sos (trimming due too large message report)

To me, this doesn't make sens= e.

Suppose I have a local police department in cities, b= ut a provincial police department in rural areas, as well as a national pol= ice.  I ask for sos.police.A3.  If location was in a city, I shou= ld get sos.police.A3

But if I was in a rural area,= a request for sos.police.A3 should return a response of sos.police.A2.

That may or may not be the same as sos.police

Brian

On Feb 20, 2013, at 2:47 PM= , Marc Linsner <mlinsner@cisco.com= > wrote:

I understood you as requesting urn:service:sos.police= .A4.

My point was that if the LoST service had no = entry for A4, it could simply check the Ax tree submitted in the location s= ection of the request.  So if the location included A1 & A4, the L= oST service, finding nothing for A4 would then check A1 (not A3 or A2). &nb= sp;This way the service would be matching the hierarchy of the given locati= on vs. an arbitrary hierarchy that may be different from the requestors des= ire.

Carry on=85

-Marc-

From: Dan= Mongrain <dan@mongrain.org><= br>Date: Wednesday, February 20, 2= 013 12:30 PM
To: Marc Linsner &= lt;mlinsner@cisco.com>
Cc: "Winterbottom, James" <James.Winterbottom@commscope.c= om>, "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] What is the most appropriate met= hod for registering new sub-services of urn:service:sos (trimming due too l= arge message report)

I do not understand your comment. = What I am proposing is that requests do not specify a search pattern in th= e case a requested jurisdiction is not found.  It should not be to the= requester which submits urn:service:sos.police.country.A1.A2.A3.A4 t= o specify what to do if there is nothing configured for the A4 layer. = It must be up to the LoST service to apply whatever policy it has in this = case.  If we allow this, then do we allow urn:service:sos.police.fire?=   Give me fire first but if not found give me police?

The Servi= ce URN should specify the "desired" service in a findService request and th= e LoST service provides a response based on local policies.  All I am = proposing is that one can specify a jurisdiction in the case there are more= then one service provider for a location.

Thanx,
Dan
<= br>
On Wed, Feb 20, 2013 at 8:48 AM, Marc Linsner= <mlinsner@cisco.com> wrote:
The findService request includes location inf= ormation.  Why wouldn't the LoST server simple walk the A1-A6 tree inc= luded with the location?  If location is geo, reverse geocode it.

What am I missing?

-Marc-

From= : Dan Mongrain <dan@mongrain.org>
Date: Tuesday, February 19, 2013 11:55 PM
To: "Winterbottom, James" <James.Winterbottom@commscope.com>= ;
Cc: "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] What is the most appropriate meth= od for registering new sub-services of urn:service:sos (trimming due too la= rge message report)

What I meant is that if a jurisdictional scope aware LoST service receives = a request for urn:service:sos.police.A4 and nothing is configured, it looks= for urn:service:sos.police.A3 then urn:service:sos.police.A2, etc. until i= t finds a configured service.  If nothing is found for urn:service:sos= .police.country then it pops the last element and looks for urn:service:sos= .police (but then again, it is no longer jurisdictional scope aware).
I disagree that one needs to formulate the request as urn:service:sos.pol= ice.country.A1.A2.A3.A4 in order for this to happen.  There must be on= ly a single jurisdictional scope appended to a Service URN.

I do not= think we need a .A6 jurisdictional scope (street level).  .A5 (neighb= orhood, would point to a precinct for example) provides enough granularity = in my opinion.

Thanx,
Dan


O= n Tue, Feb 19, 2013 at 11:29 PM, Winterbottom, James <= James= .Winterbottom@commscope.com> wrote:
<= div class=3D"MsoNormal">I am sorry, I am finding this con= fusing.
 
 
 
 
 
= From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: Wednesday, 20 February 2013= 3:23 PM
To: DRAGE, Keith (Keith)
Cc: Winterbottom, Jam= es; Ivo Sedlacek; ecrit= @ietf.org
Subject: Re: [Ecrit] What is the most appropriate m= ethod for registering new sub-services of urn:service:sos (trimming due too= large message report)
 

My recommendation for handling unknown Service URN depends if LoS= T service implements jurisdictional scope or not.  If it does not, it = pops the last element and evaluates until a service is found.  If it i= mplements jurisdictional scope, the last element is a jurisdictional scope = and it is not found, then you return the next highest level defined.
While it may be true that citizens typically dial 9-1-1 to request for hel= p, police services such as state or provincial polices advertises numbers t= o call them directly (star code to dial using a mobile phone for example) e= specially to report accidents on freeways.  We need an equivalent Serv= ice URN.

Also while RFC5031's scope is citizen to authorities (I am = not sure I agree with this) I do not want to re-invent the wheel to signal = calls within an Emergency Services IP Network (ESInet).  When I transf= er a call from one PSAP to another, the mechanism to determine where to sen= d the call is the same, using LoST.  For a PSAP that covers a large ar= ea spanning multiple counties and the calltaker needs to transfer the call = to the appropriate sheriff department for the caller's location, they only = need a single transfer target (urn:service:sos.police.A2).  It is not = true that the calltaker always knows the actual destination of the call, es= pecially when the calltaker is only a call screener.

Thanx,
Dan

On Tue, Feb 19, 2013 at 7:18 = PM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:<= u>
The answer to = James=92s question depends on how you code it (and also what you mean by fa= llback).
 =
On any serv= ice URN, you ignore any subtypes from the point you stop understanding it.<= /span>
 
So if the coding is so= s.police.A2, and you do not understand A2, then the service URN would be ha= ndled as if it was sos.police, not as sos.police.A1. And if police was not = understood then it would be handled as sos.<= /u>
 
If you wanted something that went back to the next la= rger regional coverage, then you would have to code successive subtypes in = sequence.
 =
But I would= also ask for an element of sanity in this discussion, rather than total fl= exibility.
 =
For example= while a national administration may have multiple levels of police force, = not all of them are either reachable directly as an emergency service provi= der, nor are they necessarily an emergency service provider. If they are ne= ither of these, then they presumably do not need a special and distinct ser= vice URN.
 =
It would th= erefore nice to see a current use case that is anything but a choice of two= , i.e. countrywide (following the ITU-T E.164 definition of country) versus= one more local variant. This restricted model certainly covers Ivo=92s exa= mples of Czeck Republic and Poland, and I believe it also covers the other = example I know of which is Italy.=
 
While the USA has multiple levels of police force, on the PSTN,= it only appears to have one level of access to citizen to authority emerge= ncy service, which is 911. I see no reason why a change to voice over IP wo= uld cause a change to this.
 
I would also stress that it is important to have global expectation= s of what you get when you use a service URN. If there is not care excercis= ed with assigning semantics and values, A3 in one country could result in t= he forestry police and in another country the financial police responding.<= /span>
 
Note that read the sco= pe of RFC 5031 as being for end user accessing the emergency service. While= it might be possible to apply RFC 5031 to further network operations after= the PSAP has been reached, e.g. to reach a subsidiary PSAP, I read that as= outside the scope of RFC 5031. Nor do I necessarily believe in that scenar= io that service URNs are necessarily the best solution for routeing, as the= first PSAP should know the particular office they want to reach rather tha= n just the type of emergency service.=
 <= span lang=3D"EN-GB">
Regards
 
Keith
 =
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behal= f Of Winterbottom, James
Sent: 19 February 2013 23:29
T= o: Ivo Sedlacek; Dan Mongrain
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] = What is the most appropriate method for registering new sub-services of urn= :service:sos (trimming due too large message report)
 
I am okay with this, providing that the fallback order is clear= ly defined.
That is, does an A3 fall back to an A2 or= A1, or just back to sos?<= /div>
 
 <= u>
From: Ivo Sedlacek = [mailto:ivo.= sedlacek@ericsson.com]
Sent: Wednesday, 20 February 2013 7:3= 2 AM
To: Dan Mongrain
Cc: Winterbottom, James; Richard = Barnes; ecrit@ietf.org<= /a>
Subject: RE: [Ecrit] What is the most appropriate method for = registering new sub-services of urn:service:sos (trimming due too large mes= sage report)
 
Hello,
 
If we go with RFC4119 based sub-services, would= the IANA registration request be as follows?
 
- urn:service:sos.police.A3 - The 'police.loc= al' service refers to the emergency service offered by the police departmen= t or other law enforcement authorities of the authorities of a city= , township, shi (JP).<= /div>
- urn:service:sos.police.c= ountry - The 'police.national' service refers to the emergency ser= vice offered by the police department or other law enforcement authorities = of the government of a country.<= /u>
 
= Does anyone see any issue in that?
&nbs= p;
If WG prefers this, it is OK for me.
 
> In the latter case, so how do I get th= e county police (or state police, there can be up to 4 police services for = a given location in the US). 
 
If I got it correctly, you propose that we also add
- urn:service:sos.police.A2 - The 'police.local' service refer= s to the emergency service offered by the police department or other law en= forcement authorities of the authorities of county, parish, gun (JP= ), district (IN)"
- urn:service:sos.police.A1 - The 'police.local' service refers to the emergency service offered by t= he police department or other law enforcement authorities of the authoritie= s of national subdivisions (state, region, province, prefecture)"
 
While I have no problem w= ith that, I am not aware of a regulation establishing such emergency servic= e so I cannot argue to IANA that the RFC5031 policy is satisfied for those = URNs.
 <= /span>
Kind regards
 
Ivo Sedlacek
&nbs= p;
 
 =
 
This Communication is Confidential. We only send and receive email on t= he basis of the terms set out at www.ericsson.com/email_disclaimer <= /u>
From: Dan Mongrain [mailto:dan@mongrain.org]=
Sent: 19. =FAnora 2013 21:12
To: Ivo Sedlacek
C= c: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: Re: [Ecrit] What= is the most appropriate method for registering new sub-services of urn:ser= vice:sos (trimming due too large message report)
 
Thing is, when there is n= o city police, local would give you county police (sheriff department) but = in a city with a city police department local would give you city police.&n= bsp; In the latter case, so how do I get the county police (or state police= , there can be up to 4 police services for a given location in the US).&nbs= p; Note that these examples are US based, but we do have 3 levels of police= services in Canada and I am sure other countries have the same issue.
=  

There is also the terminology.  There is no "national" police in the U= S or Canada but there is a federal police.  Keeping the RFC 4119 termi= nology removes any "local" interpretation issues.

Dan

On Tue, Feb 19= , 2013 at 2:31 PM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:
I agree with Richard - there are countries where both the emergenc= y service of the national police and the emergency service of the municipal= police are offered in a given location.
A user would = call the municipal police emergency service to report e.g. pickpockets.
A user would call the national police emergency service to= report e.g. a murder.
 
 = ;
I submitted to IANA a request to register:
- urn:service:sos.police.local - The 'police.local' service refer= s to the emergency service offered by the police department or other law en= forcement authorities of the local or municipal authorities.
- urn:service:sos.police.national - The 'police.national' service ref= ers to the emergency service offered by the police department or other law = enforcement authorities of the national government.
&nb= sp;
RFC5031 policy is hopefully fulfilled for them sinc= e they exist in two countries.
 
I am flexible whether the actual URNs contain the sub-services propose= d above (i.e. .local and .national sub-services) or subservices based on RF= C4119 (i.e. .A3 and .country sub-services).<= /u>
 
= If the preference is for subservices based on RFC4119, do I= need to make another IANA registration request or can we modify the URNs a= nd their description during the expert review?<= u>
 
Kind regards
 
Ivo Sedlacek
 =
This Communi= cation is Confidential. We only send and receive email on the basis of the = terms set out at www.ericsso= n.com/email_disclaimer
From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: = 19. =FAnora 2013 15:36
To: Winterbottom, James
Cc: Rich= ard Barnes; Ivo Sedlacek; ecrit@ietf.org
Subject: Re: [Ecrit] What is the most appro= priate method for registering new sub-services of urn:service:sos
 = ;
<= span style=3D"font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibr= i, sans-serif; ">The problem is that different countries has different name= s for their political subdivisions.  In the US they are states, in Can= ada they are provinces, etc.  Same when you further subdivide.  W= hile not privy to the discussions that came up with A1, A2, =85, A5, I have= the feeling this nomenclature was picked for the same reason.  Why no= t utilise the same naming scheme for specifying the jurisdiction you want t= o reach?
 <= u>
Thanx,=
Dan
<= p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">  

On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James <James.Winterbott= om@commscope.com> wrote:
In that case, one might= say state in the hierarchy, not A1.<= /u>
 
Cheers
<= div class=3D"MsoNormal">James=
 = ;
 
From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Tuesday, 19 February 2013 8:57 AM
To: Winterbottom, James
Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org<= /span>

Subject: Re: [Ecrit] W= hat is the most appropriate method for registering new sub-services of urn:= service:sos
 <= /div>
It might make sense if you wanted to all= ow the caller to explicitly select police at a different level of responsib= ility, e.g., the state police rather than the local police.  

 

On Mon, Feb 18, 2013 at 4:21 PM, Winter= bottom, James <James.Winterbottom@commscope.com> wrote:
I think I am missing something here, A1 is part of the location, so = why does it need to be in the URN at all?
As far as I= understand current deployments, they use the URN to select a layer in the = GIS that corresponds to the service type, and then use geographic boundarie= s within that layer to select the final destination.
=  
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Dan Mongrain
Sent: Tuesday, 19 February 2013 7:30 AM
<= br>To: Ivo Sedlacek
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:servic= e:sos
 
<= div class=3D"MsoNormal">Sorry for responding late to this= thread, it kinda fell into a  crack=85  The current thread remin= ded me to check this old thread=85
 
You are indicating that we need to register 77 Service URN (11 s= ervice subtypes * 7 jurisdiction types based on RFC 4119).  I do not r= ecommend that we create so many registrations.  Instead, we should all= ow a service URN to be suffixed with a jurisdictional scope.  So the f= ollowing Service URN are all valid:
 
urn:service:sos.police
urn:service:sos.po= lice.traffic
urn:service:sos.police.A1
urn:service:sos.police.traffic.A1
 
= Question is, do we want to leave jurisdictional scope to = only be applicable to police branch or any Service URN?  I=92d say the= latter as it is always up to the LoST service provisioning (based on local= policy) to determine what is locally acceptable.
&nb= sp;
Thanx,<= /span>
Dan
<= /div>
 
 
=  

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

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

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

= --_000_D96247920C2A411F8F4808D97434320Cneustarbiz_-- From dan@mongrain.org Wed Feb 20 12:22:21 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F24521E8030 for ; Wed, 20 Feb 2013 12:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.515 X-Spam-Level: X-Spam-Status: No, score=-0.515 tagged_above=-999 required=5 tests=[AWL=-0.690, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKEWO9pLuq1F for ; Wed, 20 Feb 2013 12:22:18 -0800 (PST) Received: from mail-ia0-x236.google.com (ia-in-x0236.1e100.net [IPv6:2607:f8b0:4001:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3793221F86C3 for ; Wed, 20 Feb 2013 12:22:18 -0800 (PST) Received: by mail-ia0-f182.google.com with SMTP id k38so904951iah.27 for ; Wed, 20 Feb 2013 12:22:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=6dlslJSIqG/FiuoZQYIcPe2ITgD9PYR81gYOzNmGtcM=; b=RfkagbjUts3fITiRC+SedMn8CSUOIe6sPo2KA5u4pX/wf8ei6FqPuwdNjJvGE30v/t Q5udEJOiimpdK635TJcVd+klhmj+tbo9FB1KvMMa21WspCY5EpWNdi/JY/JRpapmWRPk 3kGdtiDZLlj1GeeE/XF+NdiJzAWzUhH0JbhiAkyGF1F0ku2Q2K6RYDI4WpKlQdUqJ8bI p2YZ3IU2hnSTbBD7qESo4Dvb2u3e0c7C4d8UBDNyQ3m8A6g0ZWvEKThEe5N7NF1oFGFD gUcvHnOQyvYg0MOwgKP+uUiv5kVC1qT4WD4ynloE8XOdSHILwxrJZrUKWs0GkhP/EI3c KQaA== MIME-Version: 1.0 X-Received: by 10.42.98.76 with SMTP id r12mr9655401icn.10.1361391737690; Wed, 20 Feb 2013 12:22:17 -0800 (PST) Received: by 10.50.171.41 with HTTP; Wed, 20 Feb 2013 12:22:17 -0800 (PST) X-Originating-IP: [209.87.237.3] In-Reply-To: References: Date: Wed, 20 Feb 2013 15:22:17 -0500 Message-ID: From: Dan Mongrain To: Marc Linsner Content-Type: multipart/alternative; boundary=90e6ba614a96ecd9ff04d62db60a X-Gm-Message-State: ALoCoQlYwuQDxF7BT6E0529pbqOANyHJvx2+58XwiauvBdgq9xq3GG2Swsci6Hi936cf4kaI7eto Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:22:21 -0000 --90e6ba614a96ecd9ff04d62db60a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The typical civic address includes A6, A3 and A1. A2 is not always populated as it can be inferred from A3 and A1. But if one requests urn:service:sos.police.A3 but there is no such agency then it is perfectly valid to return the A2 level service (even if A2 was not populated in the provided location). The LoST service knows this information. This can be the default behaviour when dealing with a jurisdictional scope that is not found, return the next configured level up. But as always, local provisioning prevails which could provide a lower service instead. Dan On Wed, Feb 20, 2013 at 2:47 PM, Marc Linsner wrote: > I understood you as requesting urn:service:sos.police.A4. > > My point was that if the LoST service had no entry for A4, it could simpl= y > check the Ax tree submitted in the location section of the request. So i= f > the location included A1 & A4, the LoST service, finding nothing for A4 > would then check A1 (not A3 or A2). This way the service would be matchi= ng > the hierarchy of the given location vs. an arbitrary hierarchy that may b= e > different from the requestors desire. > > Carry on=85 > > -Marc- > > From: Dan Mongrain > Date: Wednesday, February 20, 2013 12:30 PM > To: Marc Linsner > Cc: "Winterbottom, James" , " > ecrit@ietf.org" > Subject: Re: [Ecrit] What is the most appropriate method for registering > new sub-services of urn:service:sos (trimming due too large message repor= t) > > I do not understand your comment. What I am proposing is that requests d= o > not specify a search pattern in the case a requested jurisdiction is not > found. It should not be to the requester which submits urn:service:sos.p= olice.country.A1.A2.A3.A4 > to specify what to do if there is nothing configured for the A4 layer. I= t > must be up to the LoST service to apply whatever policy it has in this > case. If we allow this, then do we allow urn:service:sos.police.fire? > Give me fire first but if not found give me police? > > The Service URN should specify the "desired" service in a findService > request and the LoST service provides a response based on local policies. > All I am proposing is that one can specify a jurisdiction in the case the= re > are more then one service provider for a location. > > Thanx, > Dan > > On Wed, Feb 20, 2013 at 8:48 AM, Marc Linsner wrote: > >> The findService request includes location information. Why wouldn't the >> LoST server simple walk the A1-A6 tree included with the location? If >> location is geo, reverse geocode it. >> >> What am I missing? >> >> -Marc- >> >> From: Dan Mongrain >> Date: Tuesday, February 19, 2013 11:55 PM >> To: "Winterbottom, James" >> Cc: "ecrit@ietf.org" >> Subject: Re: [Ecrit] What is the most appropriate method for registering >> new sub-services of urn:service:sos (trimming due too large message repo= rt) >> >> What I meant is that if a jurisdictional scope aware LoST service >> receives a request for urn:service:sos.police.A4 and nothing is configur= ed, >> it looks for urn:service:sos.police.A3 then urn:service:sos.police.A2, e= tc. >> until it finds a configured service. If nothing is found for >> urn:service:sos.police.country then it pops the last element and looks f= or >> urn:service:sos.police (but then again, it is no longer jurisdictional >> scope aware). >> >> I disagree that one needs to formulate the request as >> urn:service:sos.police.country.A1.A2.A3.A4 in order for this to happen. >> There must be only a single jurisdictional scope appended to a Service U= RN. >> >> I do not think we need a .A6 jurisdictional scope (street level). .A5 >> (neighborhood, would point to a precinct for example) provides enough >> granularity in my opinion. >> >> Thanx, >> Dan >> >> >> On Tue, Feb 19, 2013 at 11:29 PM, Winterbottom, James < >> James.Winterbottom@commscope.com> wrote: >> >>> I am sorry, I am finding this confusing.**** >>> >>> ** ** >>> >>> RFC5139 puts a hierarchy on A1 through A6. If you want this hierarchy t= o >>> work then A1 through A6 can=92t be at the same level if you expect A3 t= o >>> fallback to A2 or A1 in the case of a service not existing or a service >>> failure of some kind. If they exist at the same level then if A3 doesn= =92t >>> exist you will go to urn:service:sos.police unless you impose the >>> hierarchy in the urn.**** >>> >>> ** ** >>> >>> ** ** >>> >>> ** ** >>> >>> ** ** >>> >>> ** ** >>> >>> *From:* Dan Mongrain [mailto:dan@mongrain.org] >>> *Sent:* Wednesday, 20 February 2013 3:23 PM >>> *To:* DRAGE, Keith (Keith) >>> *Cc:* Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org >>> *Subject:* Re: [Ecrit] What is the most appropriate method for >>> registering new sub-services of urn:service:sos (trimming due too large >>> message report)**** >>> >>> ** ** >>> >>> My recommendation for handling unknown Service URN depends if LoST >>> service implements jurisdictional scope or not. If it does not, it pop= s >>> the last element and evaluates until a service is found. If it impleme= nts >>> jurisdictional scope, the last element is a jurisdictional scope and it= is >>> not found, then you return the next highest level defined. >>> >>> While it may be true that citizens typically dial 9-1-1 to request for >>> help, police services such as state or provincial polices advertises >>> numbers to call them directly (star code to dial using a mobile phone f= or >>> example) especially to report accidents on freeways. We need an equiva= lent >>> Service URN. >>> >>> Also while RFC5031's scope is citizen to authorities (I am not sure I >>> agree with this) I do not want to re-invent the wheel to signal calls >>> within an Emergency Services IP Network (ESInet). When I transfer a ca= ll >>> from one PSAP to another, the mechanism to determine where to send the = call >>> is the same, using LoST. For a PSAP that covers a large area spanning >>> multiple counties and the calltaker needs to transfer the call to the >>> appropriate sheriff department for the caller's location, they only nee= d a >>> single transfer target (urn:service:sos.police.A2). It is not true tha= t >>> the calltaker always knows the actual destination of the call, especial= ly >>> when the calltaker is only a call screener. >>> >>> Thanx, >>> Dan**** >>> >>> On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) < >>> keith.drage@alcatel-lucent.com> wrote:**** >>> >>> The answer to James=92s question depends on how you code it (and also w= hat >>> you mean by fallback).**** >>> >>> **** >>> >>> On any service URN, you ignore any subtypes from the point you stop >>> understanding it.**** >>> >>> **** >>> >>> So if the coding is sos.police.A2, and you do not understand A2, then >>> the service URN would be handled as if it was sos.police, not as >>> sos.police.A1. And if police was not understood then it would be handle= d as >>> sos.**** >>> >>> **** >>> >>> If you wanted something that went back to the next larger regional >>> coverage, then you would have to code successive subtypes in sequence.*= * >>> ** >>> >>> **** >>> >>> But I would also ask for an element of sanity in this discussion, rathe= r >>> than total flexibility.**** >>> >>> **** >>> >>> For example while a national administration may have multiple levels of >>> police force, not all of them are either reachable directly as an emerg= ency >>> service provider, nor are they necessarily an emergency service provide= r. >>> If they are neither of these, then they presumably do not need a specia= l >>> and distinct service URN. **** >>> >>> **** >>> >>> It would therefore nice to see a current use case that is anything but = a >>> choice of two, i.e. countrywide (following the ITU-T E.164 definition o= f >>> country) versus one more local variant. This restricted model certainly >>> covers Ivo=92s examples of Czeck Republic and Poland, and I believe it = also >>> covers the other example I know of which is Italy.**** >>> >>> **** >>> >>> While the USA has multiple levels of police force, on the PSTN, it only >>> appears to have one level of access to citizen to authority emergency >>> service, which is 911. I see no reason why a change to voice over IP wo= uld >>> cause a change to this.**** >>> >>> **** >>> >>> I would also stress that it is important to have global expectations of >>> what you get when you use a service URN. If there is not care excercise= d >>> with assigning semantics and values, A3 in one country could result in = the >>> forestry police and in another country the financial police responding.= * >>> *** >>> >>> **** >>> >>> Note that read the scope of RFC 5031 as being for end user accessing th= e >>> emergency service. While it might be possible to apply RFC 5031 to furt= her >>> network operations after the PSAP has been reached, e.g. to reach a >>> subsidiary PSAP, I read that as outside the scope of RFC 5031. Nor do I >>> necessarily believe in that scenario that service URNs are necessarily = the >>> best solution for routeing, as the first PSAP should know the particula= r >>> office they want to reach rather than just the type of emergency servic= e. >>> **** >>> >>> **** >>> >>> Regards**** >>> >>> **** >>> >>> Keith**** >>> >>> **** >>> ------------------------------ >>> >>> *From:* ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On >>> Behalf Of *Winterbottom, James >>> *Sent:* 19 February 2013 23:29 >>> *To:* Ivo Sedlacek; Dan Mongrain >>> *Cc:* ecrit@ietf.org >>> *Subject:* Re: [Ecrit] What is the most appropriate method for >>> registering new sub-services of urn:service:sos (trimming due too large >>> message report)**** >>> >>> **** >>> >>> I am okay with this, providing that the fallback order is clearly >>> defined.**** >>> >>> That is, does an A3 fall back to an A2 or A1, or just back to sos?**** >>> >>> **** >>> >>> **** >>> >>> **** >>> >>> *From:* Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] >>> *Sent:* Wednesday, 20 February 2013 7:32 AM >>> *To:* Dan Mongrain >>> *Cc:* Winterbottom, James; Richard Barnes; ecrit@ietf.org >>> *Subject:* RE: [Ecrit] What is the most appropriate method for >>> registering new sub-services of urn:service:sos (trimming due too large >>> message report)**** >>> >>> **** >>> >>> Hello,**** >>> >>> **** >>> >>> If we go with RFC4119 based sub-services, would the IANA registration >>> request be as follows?**** >>> >>> **** >>> >>> - urn:service:sos.police*.A3* - The 'police.local' service refers to >>> the emergency service offered by the police department or other law >>> enforcement authorities of the authorities *of a city, township, shi >>> (JP)*.**** >>> >>> - urn:service:sos.police*.country* - The 'police.national' service >>> refers to the emergency service offered by the police department or oth= er >>> law enforcement authorities of the government *of a country*.**** >>> >>> **** >>> >>> Does anyone see any issue in that?**** >>> >>> **** >>> >>> If WG prefers this, it is OK for me.**** >>> >>> **** >>> >>> > In the latter case, so how do I get the county police (or state >>> police, there can be up to 4 police services for a given location in th= e >>> US). **** >>> >>> **** >>> >>> If I got it correctly, you propose that we also add **** >>> >>> - urn:service:sos.police*.A2* - The 'police.local' service refers to >>> the emergency service offered by the police department or other law >>> enforcement authorities of the authorities *of county, parish, gun >>> (JP), district (IN)*"**** >>> >>> - urn:service:sos.police*.A1* - The 'police.local' service refers to >>> the emergency service offered by the police department or other law >>> enforcement authorities of the authorities *of national subdivisions >>> (state, region, province, prefecture)*"**** >>> >>> **** >>> >>> While I have no problem with that, I am not aware of a regulation >>> establishing such emergency service so I cannot argue to IANA that the >>> RFC5031 policy is satisfied for those URNs.**** >>> >>> **** >>> >>> Kind regards**** >>> >>> **** >>> >>> Ivo Sedlacek**** >>> >>> **** >>> >>> **** >>> >>> **** >>> >>> **** >>> >>> This Communication is Confidential. We only send and receive email on >>> the basis of the terms set out at www.ericsson.com/email_disclaimer ***= * >>> >>> *From:* Dan Mongrain [mailto:dan@mongrain.org ] >>> *Sent:* 19. =FAnora 2013 21:12 >>> *To:* Ivo Sedlacek >>> *Cc:* Winterbottom, James; Richard Barnes; ecrit@ietf.org >>> *Subject:* Re: [Ecrit] What is the most appropriate method for >>> registering new sub-services of urn:service:sos (trimming due too large >>> message report)**** >>> >>> **** >>> >>> Thing is, when there is no city police, local would give you county >>> police (sheriff department) but in a city with a city police department >>> local would give you city police. In the latter case, so how do I get = the >>> county police (or state police, there can be up to 4 police services fo= r a >>> given location in the US). Note that these examples are US based, but = we >>> do have 3 levels of police services in Canada and I am sure other count= ries >>> have the same issue.**** >>> >>> **** >>> >>> There is also the terminology. There is no "national" police in the US >>> or Canada but there is a federal police. Keeping the RFC 4119 terminol= ogy >>> removes any "local" interpretation issues. >>> >>> Dan**** >>> >>> On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek >>> wrote:**** >>> >>> I agree with Richard - there are countries where both the emergency >>> service of the national police and the emergency service of the municip= al >>> police are offered in a given location. **** >>> >>> A user would call the municipal police emergency service to report e.g. >>> pickpockets.**** >>> >>> A user would call the national police emergency service to report e.g. = a >>> murder.**** >>> >>> **** >>> >>> **** >>> >>> I submitted to IANA a request to register:**** >>> >>> - urn:service:sos.police.local - The 'police.local' service refers to >>> the emergency service offered by the police department or other law >>> enforcement authorities of the local or municipal authorities.**** >>> >>> - urn:service:sos.police.national - The 'police.national' service refer= s >>> to the emergency service offered by the police department or other law >>> enforcement authorities of the national government.**** >>> >>> **** >>> >>> RFC5031 policy is hopefully fulfilled for them since they exist in two >>> countries.**** >>> >>> **** >>> >>> I am flexible whether the actual URNs contain the sub-services proposed >>> above (i.e. .local and .national sub-services) or subservices based on >>> RFC4119 (i.e. .A3 and .country sub-services).**** >>> >>> **** >>> >>> If the preference is for subservices based on RFC4119, do I need to mak= e >>> another IANA registration request or can we modify the URNs and their >>> description during the expert review?**** >>> >>> **** >>> >>> Kind regards**** >>> >>> **** >>> >>> Ivo Sedlacek**** >>> >>> **** >>> >>> This Communication is Confidential. We only send and receive email on >>> the basis of the terms set out at www.ericsson.com/email_disclaimer ***= * >>> >>> *From:* Dan Mongrain [mailto:dan@mongrain.org] >>> *Sent:* 19. =FAnora 2013 15:36 >>> *To:* Winterbottom, James >>> *Cc:* Richard Barnes; Ivo Sedlacek; ecrit@ietf.org >>> *Subject:* Re: [Ecrit] What is the most appropriate method for >>> registering new sub-services of urn:service:sos**** >>> >>> **** >>> >>> The problem is that different countries has different names for their >>> political subdivisions. In the US they are states, in Canada they are >>> provinces, etc. Same when you further subdivide. While not privy to t= he >>> discussions that came up with A1, A2, =85, A5, I have the feeling this >>> nomenclature was picked for the same reason. Why not utilise the same >>> naming scheme for specifying the jurisdiction you want to reach?**** >>> >>> **** >>> >>> Thanx,**** >>> >>> Dan**** >>> >>> **** >>> >>> On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James < >>> James.Winterbottom@commscope.com> wrote:**** >>> >>> In that case, one might say state in the hierarchy, not A1.**** >>> >>> **** >>> >>> Cheers**** >>> >>> James**** >>> >>> **** >>> >>> **** >>> >>> *From:* Richard Barnes [mailto:rlb@ipv.sx] >>> *Sent:* Tuesday, 19 February 2013 8:57 AM >>> *To:* Winterbottom, James >>> *Cc:* Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org**** >>> >>> >>> *Subject:* Re: [Ecrit] What is the most appropriate method for >>> registering new sub-services of urn:service:sos**** >>> >>> **** >>> >>> It might make sense if you wanted to allow the caller to explicitly >>> select police at a different level of responsibility, e.g., the state >>> police rather than the local police. **** >>> >>> **** >>> >>> On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James < >>> James.Winterbottom@commscope.com> wrote:**** >>> >>> I think I am missing something here, A1 is part of the location, so why >>> does it need to be in the URN at all?**** >>> >>> As far as I understand current deployments, they use the URN to select = a >>> layer in the GIS that corresponds to the service type, and then use >>> geographic boundaries within that layer to select the final destination= . >>> **** >>> >>> **** >>> >>> *From:* ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On >>> Behalf Of *Dan Mongrain >>> *Sent:* Tuesday, 19 February 2013 7:30 AM**** >>> >>> >>> *To:* Ivo Sedlacek >>> *Cc:* ecrit@ietf.org >>> *Subject:* Re: [Ecrit] What is the most appropriate method for >>> registering new sub-services of urn:service:sos**** >>> >>> **** >>> >>> Sorry for responding late to this thread, it kinda fell into a crack= =85 >>> The current thread reminded me to check this old thread=85**** >>> >>> **** >>> >>> You are indicating that we need to register 77 Service URN (11 service >>> subtypes * 7 jurisdiction types based on RFC 4119). I do not recommend >>> that we create so many registrations. Instead, we should allow a servi= ce >>> URN to be suffixed with a jurisdictional scope. So the following Servi= ce >>> URN are all valid:**** >>> >>> **** >>> >>> urn:service:sos.police**** >>> >>> urn:service:sos.police.traffic**** >>> >>> urn:service:sos.police.A1**** >>> >>> urn:service:sos.police.traffic.A1**** >>> >>> **** >>> >>> Question is, do we want to leave jurisdictional scope to only be >>> applicable to police branch or any Service URN? I=92d say the latter a= s it >>> is always up to the LoST service provisioning (based on local policy) t= o >>> determine what is locally acceptable.**** >>> >>> **** >>> >>> Thanx,**** >>> >>> Dan**** >>> >>> **** >>> >>> **** >>> >>> ** ** >>> >> >> _______________________________________________ Ecrit mailing list >> Ecrit@ietf.orghttps://www.ietf.org/mailman/listinfo/ecrit >> >> > --90e6ba614a96ecd9ff04d62db60a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

The ty= pical civic address includes A6, A3 and A1.=A0 A2 is not always populated a= s it can be inferred from A3 and A1.=A0 But if one requests urn:serv= ice:sos.police.A3 but there is no such agency then it is perfectly valid to= return the A2 level service (even if A2 was not populated in the provided = location).=A0 The LoST service knows this information.=A0 This can be the d= efault behaviour when dealing with a jurisdictional scope that is not found= , return the next configured level up. But as always, local provisioning pr= evails which could provide a lower service instead.


Dan



On Wed, Feb 20, 2013 at 2:47 PM, Marc Li= nsner <mlinsner@cisco.com> wrote:
I understood you as requesting urn:service:sos.police.A4.
=

My point was that if the LoST service had no entry for = A4, it could simply check the Ax tree submitted in the location section of = the request. =A0So if the location included A1 & A4, the LoST service, = finding nothing for A4 would then check A1 (not A3 or A2). =A0This way the = service would be matching the hierarchy of the given location vs. an arbitr= ary hierarchy that may be different from the requestors desire.

Carry on=85

-Marc-
<= br>
From: Dan Mongrain <dan@mongrain.org>
Date: Wednesday, February 20, 2013 12:= 30 PM
To: Marc Linsner <mlinsner@cisco.com>
Cc: "Winterbottom, James" = <J= ames.Winterbottom@commscope.com>, "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] What is the m= ost appropriate method for registering new sub-services of urn:service:sos = (trimming due too large message report)

I do not understand your comment.=A0 What I am proposing is that requests d= o not specify a search pattern in the case a requested jurisdiction is not = found.=A0 It should not be to the requester which submits urn:service= :sos.police.country.A1.A2.A3.A4 to specify what to do if there is nothing c= onfigured for the A4 layer.=A0 It must be up to the LoST service to apply w= hatever policy it has in this case.=A0 If we allow this, then do we allow u= rn:service:sos.police.fire?=A0 Give me fire first but if not found give me = police?

The Service URN should specify the "desired" service in a fin= dService request and the LoST service provides a response based on local po= licies.=A0 All I am proposing is that one can specify a jurisdiction in the= case there are more then one service provider for a location.

Thanx,
Dan

On Wed, Feb 20, = 2013 at 8:48 AM, Marc Linsner <mlinsner@cisco.com> wrote:
The findService request includes location information. =A0Why w= ouldn't the LoST server simple walk the A1-A6 tree included with the lo= cation? =A0If location is geo, reverse geocode it.

What am I missing?

-Marc-

From: Dan Mongrain <dan@mongrain.org>
Date: Tuesday, February 19, 2013 11:55= PM
To: "Winterbottom, James"= ; <James.Winterbottom@commscope.com>
Cc: "ec= rit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] What is the m= ost appropriate method for registering new sub-services of urn:service:sos = (trimming due too large message report)

What I meant is that if a jurisdictional scope aware LoST service receives = a request for urn:service:sos.police.A4 and nothing is configured, it looks= for urn:service:sos.police.A3 then urn:service:sos.police.A2, etc. until i= t finds a configured service.=A0 If nothing is found for urn:service:sos.po= lice.country then it pops the last element and looks for urn:service:sos.po= lice (but then again, it is no longer jurisdictional scope aware).

I disagree that one needs to formulate the request as urn:service:sos.p= olice.country.A1.A2.A3.A4 in order for this to happen.=A0 There must be onl= y a single jurisdictional scope appended to a Service URN.

I do not = think we need a .A6 jurisdictional scope (street level).=A0 .A5 (neighborho= od, would point to a precinct for example) provides enough granularity in m= y opinion.

Thanx,
Dan


On Tue, Feb 19, 201= 3 at 11:29 PM, Winterbottom, James <James.Winterbottom@comm= scope.com> wrote:

I am sorry, I am finding this co= nfusing.

=A0

RFC5139 puts a hierarchy on A1 through A6. If you want this = hierarchy to work then A1 through A6 can=92t be at the same level if you ex= pect A3 to fallback to A2 or A1 in the case of a service not existing or a = service failure of some kind. If they exist at the same level then if A3 do= esn=92t exist you will go to urn:service:sos.police=A0 unless you impose th= e hierarchy in the urn.

=A0

=A0

=A0

=A0

=A0

From: Dan Mong= rain [mailto:dan@mong= rain.org]
Sent: Wednesday, 20 February 2013 3:23 PM
To: DRAGE, Keith= (Keith)
Cc: Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org
Subject: Re= : [Ecrit] What is the most appropriate method for registering new sub-servi= ces of urn:service:sos (trimming due too large message report)

=A0

My recommendation for handling unknown Service= URN depends if LoST service implements jurisdictional scope or not.=A0 If = it does not, it pops the last element and evaluates until a service is foun= d.=A0 If it implements jurisdictional scope, the last element is a jurisdic= tional scope and it is not found, then you return the next highest level de= fined.

While it may be true that citizens typically dial 9-1-1 to request for = help, police services such as state or provincial polices advertises number= s to call them directly (star code to dial using a mobile phone for example= ) especially to report accidents on freeways.=A0 We need an equivalent Serv= ice URN.

Also while RFC5031's scope is citizen to authorities (I am not sure= I agree with this) I do not want to re-invent the wheel to signal calls wi= thin an Emergency Services IP Network (ESInet).=A0 When I transfer a call f= rom one PSAP to another, the mechanism to determine where to send the call = is the same, using LoST.=A0 For a PSAP that covers a large area spanning mu= ltiple counties and the calltaker needs to transfer the call to the appropr= iate sheriff department for the caller's location, they only need a sin= gle transfer target (urn:service:sos.police.A2).=A0 It is not true that the= calltaker always knows the actual destination of the call, especially when= the calltaker is only a call screener.

Thanx,
Dan

On Tue, Feb = 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com&g= t; wrote:

The answer to James=92s questio= n depends on how you code it (and also what you mean by fallback).

=A0=

On any service URN, you ig= nore any subtypes from the point you stop understanding it.

=A0=

So if the coding is sos.po= lice.A2, and you do not understand A2, then the service URN would be handle= d as if it was sos.police, not as sos.police.A1. And if police was not unde= rstood then it would be handled as sos.<= u>

=A0=

If you wanted something th= at went back to the next larger regional coverage, then you would have to c= ode successive subtypes in sequence.<= /u>

=A0=

But I would also ask for a= n element of sanity in this discussion, rather than total flexibility.

=A0=

For example while a nation= al administration may have multiple levels of police force, not all of them= are either reachable directly as an emergency service provider, nor are th= ey necessarily an emergency service provider. If they are neither of these,= then they presumably do not need a special and distinct service URN.

=A0=

It would therefore nice to= see a current use case that is anything but a choice of two, i.e. countryw= ide (following the ITU-T E.164 definition of country) versus one more local= variant. This restricted model certainly covers Ivo=92s examples of Czeck = Republic and Poland, and I believe it also covers the other example I know = of which is Italy.

=A0=

While the USA has multiple= levels of police force, on the PSTN, it only appears to have one level of = access to citizen to authority emergency service, which is 911. I see no re= ason why a change to voice over IP would cause a change to this.

=A0=

I would also stress that i= t is important to have global expectations of what you get when you use a s= ervice URN. If there is not care excercised with assigning semantics and va= lues, A3 in one country could result in the forestry police and in another = country the financial police responding.=

=A0=

Note that read the scope o= f RFC 5031 as being for end user accessing the emergency service. While it = might be possible to apply RFC 5031 to further network operations after the= PSAP has been reached, e.g. to reach a subsidiary PSAP, I read that as out= side the scope of RFC 5031. Nor do I necessarily believe in that scenario t= hat service URNs are necessarily the best solution for routeing, as the fir= st PSAP should know the particular office they want to reach rather than ju= st the type of emergency service.=

=A0=

Regards

=A0=

Keith

=A0=

=

From: ecrit-bounces@ietf.org= [mailto:ec= rit-bounces@ietf.org] On Behalf Of Winterbottom, James
Sent: 19 February 2013 23:29
To: Ivo Sedlacek; Dan Mongrai= n
Cc: ecrit@i= etf.org
Subject: Re: [Ecrit] What is the most appropriate met= hod for registering new sub-services of urn:service:sos (trimming due too l= arge message report)

=A0<= /p>

I am okay with this, providing that the f= allback order is clearly defined.=

That is, does an A3 fall back to an A2 or A1= , or just back to sos?

=

=A0

=A0

=A0

From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com]
Sent: Wednesday, 20 February 2013 7:32 AM
To: Dan Mongrain=
Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: RE: [Ecr= it] What is the most appropriate method for registering new sub-services of= urn:service:sos (trimming due too large message report)

=A0

Hello,=

=A0<= /span>

If we go with RFC4119 based sub-serv= ices, would the IANA registration request be as follows?

=A0<= /span>

- urn:service:sos.police.A3= =A0- The 'police.local' service refers to the emergency service off= ered by the police department or other law enforcement authorities of the a= uthorities=A0of a city, township, shi (JP).

- urn:service:sos.police.country=A0- Th= e 'police.national' service refers to the emergency service offered= by the police department or other law enforcement authorities of the gover= nment=A0of a country.

=A0<= /span>

Does anyone see any issue in that?

=A0<= /span>

If WG prefers this, it is OK for me.=

=A0<= /span>

> In the latter case, so how do I get t= he county police (or state police, there can be up to 4 police services for= a given location in the US).=A0 =

=A0<= /span>

If I got it correctly, you propose t= hat we also add

- urn:service:sos.police.A2 - The '= police.local' service refers to the emergency service offered by the po= lice department or other law enforcement authorities of the authorities=A0<= u>of county, parish, gun (JP), district (IN)"

- urn:service:sos.police.A1 - The '= police.local' service refers to the emergency service offered by the po= lice department or other law enforcement authorities of the authorities=A0<= u>of national subdivisions (state, region, province, prefecture)"<= /span>

=A0<= /span>

While I have no problem with that, I= am not aware of a regulation establishing such emergency service so I cann= ot argue to IANA that the RFC5031 policy is satisfied for those URNs.

=A0<= /span>

Kind regards

=A0<= /span>

Ivo Sedlacek

=A0<= /span>

=A0

=A0

=A0

This Communication is Confidential. We only send= and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19. =FAnora 2013 21:12
To: Ivo Sedlacek
Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: Re: [Ecrit] What is t= he most appropriate method for registering new sub-services of urn:service:= sos (trimming due too large message report)<= /u>

=A0

Thing is, when there is no city police, local would give you county = police (sheriff department) but in a city with a city police department loc= al would give you city police.=A0 In the latter case, so how do I get the c= ounty police (or state police, there can be up to 4 police services for a g= iven location in the US).=A0 Note that these examples are US based, but we = do have 3 levels of police services in Canada and I am sure other countries= have the same issue.

=A0

There is also the terminology.=A0 There is no "national" police i= n the US or Canada but there is a federal police.=A0 Keeping the RFC 4119 t= erminology removes any "local" interpretation issues.

Dan<= span lang=3D"EN-GB">

On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek &= lt;ivo.sedla= cek@ericsson.com> wrote:

I agree with Richard - there are countrie= s where both the emergency service of the national police and the emergency= service of the municipal police are offered in a given location.

A user would call the municipal police emergen= cy service to report e.g. pickpockets.

A user would call the national police emergenc= y service to report e.g. a murder.

=A0<= /span>

=A0

I submitted to IANA a request to register:

- urn:service:sos.police.local - The 'police.local' service refe= rs to the emergency service offered by the police department or other law e= nforcement authorities of the local or municipal authorities.

- urn:service:sos.police.national - The 'p= olice.national' service refers to the emergency service offered by the = police department or other law enforcement authorities of the national gove= rnment.

=A0<= /span>

RFC5031 policy is hopefully fulfille= d for them since they exist in two countries.

=A0<= /span>

I am flexible whether the actual URN= s contain the sub-services proposed above (i.e. .local and .national sub-se= rvices) or subservices based on RFC4119 (i.e. .A3 and .country sub-services= ).

=A0<= /span>

If the preference is for subservices= based on RFC4119, do I need to make another IANA registration request or c= an we modify the URNs and their description during the expert review?

=A0<= /span>

Kind regards

=A0<= /span>

Ivo Sedlacek

=A0<= /span>

This Communication is Confidential. We= only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19. =FAnora 2013 15:36
To: Winterbottom, James
Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org
Subject: Re: [Ecrit] What is t= he most appropriate method for registering new sub-services of urn:service:= sos

=A0

The problem is that different countries has dif= ferent names for their political subdivisions.=A0 In the US they are states= , in Canada they are provinces, etc.=A0 Same when you further subdivide.=A0= While not privy to the discussions that came up with A1, A2, =85, A5, I ha= ve the feeling this nomenclature was picked for the same reason.=A0 Why not= utilise the same naming scheme for specifying the jurisdiction you want to= reach?

=A0

Thanx,

Dan

=A0

On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James <James.Winterbottom@co= mmscope.com> wrote:

In that case, one might say state = in the hierarchy, not A1.<= /p>

=A0

Cheers

James<= /u>

=A0

=A0

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Tuesday, 19 February 2013 8:57 AM
To: Winterbottom, = James
Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org<= /u>


Subject: Re: [Ecrit] What is th= e most appropriate method for registering new sub-services of urn:service:s= os

=A0

It might make sense if you wanted to allow the cal= ler to explicitly select police at a different level of responsibility, e.g= ., the state police rather than the local police. =A0<= u>

=A0

On Mon, = Feb 18, 2013 at 4:21 PM, Winterbottom, James <James.Winterbottom@commscope.co= m> wrote:

I think I am missing something her= e, A1 is part of the location, so why does it need to be in the URN at all?=

As far as I understand current deployments, = they use the URN to select a layer in the GIS that corresponds to the servi= ce type, and then use geographic boundaries within that layer to select the= final destination.

=A0

From: = ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Dan Mon= grain
Sent: Tuesday, 19 February 2013 7:30 AM<= u>


To: Ivo= Sedlacek
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] What is the most appropriate method for registe= ring new sub-services of urn:service:sos=

=A0

Sorry for responding late to this thread, it= kinda fell into a=A0 crack=85=A0 The current thread reminded me to check t= his old thread=85

=A0

You are indicating that we need = to register 77 Service URN (11 service subtypes * 7 jurisdiction types base= d on RFC 4119).=A0 I do not recommend that we create so many registrations.= =A0 Instead, we should allow a service URN to be suffixed with a jurisdicti= onal scope.=A0 So the following Service URN are all valid:

=A0

urn:service:sos.police

urn:service:sos.police.traffic

urn= :service:sos.police.A1

urn:service:sos.police.traffic.A1

= =A0

Question is, do we want to leave jurisdictio= nal scope to only be applicable to police branch or any Service URN? =A0I= =92d say the latter as it is always up to the LoST service provisioning (ba= sed on local policy) to determine what is locally acceptable.

=A0

Thanx,

Dan

=A0

=A0

=A0


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


--90e6ba614a96ecd9ff04d62db60a-- From dan@mongrain.org Wed Feb 20 12:32:58 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C8021F8802 for ; Wed, 20 Feb 2013 12:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[AWL=-0.875, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_36=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mDHsQMkSU5C for ; Wed, 20 Feb 2013 12:32:56 -0800 (PST) Received: from mail-ia0-x22a.google.com (ia-in-x022a.1e100.net [IPv6:2607:f8b0:4001:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 38B0421F86B6 for ; Wed, 20 Feb 2013 12:32:56 -0800 (PST) Received: by mail-ia0-f170.google.com with SMTP id k20so7698014iak.29 for ; Wed, 20 Feb 2013 12:32:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=xcGD0uotASl240czg82MHJ7/E7i0ubwIuyTGfRO+x9I=; b=LXluLqqogYzKBa4bytly+FlJLXaPuZVyStkDKNnb08mRj7fGSN0J52udChw7OBC5bS pbE00Xjkxsa0cQqyLwZGUqkvW86pqZdSkeztIcZDLDAe0rxp/8rbRpne1p9U4BomXFNJ 2RmFPFCOBWlS7Cyr5lvHGq+EazcSTOkW2ganIcC2CEy/tXvwyAf29N0pCn0goXUjfIkw 8ati/T3EoVaqDbpiw5Ha4c3iBaVSPknMWJuKpJUSHIatMn2l+ZAz8+3alH2n98WZIW8a 0yntDiFSRh19p8LxSy2796gzGulY+iFmQO0TlqlB7PxgBqIk6kIL+lV2Sb+h4NffeyYx Jlrg== MIME-Version: 1.0 X-Received: by 10.50.149.195 with SMTP id uc3mr11600598igb.4.1361392375725; Wed, 20 Feb 2013 12:32:55 -0800 (PST) Received: by 10.50.171.41 with HTTP; Wed, 20 Feb 2013 12:32:55 -0800 (PST) X-Originating-IP: [209.87.237.3] In-Reply-To: References: <7C40F453-27B2-45AB-95A6-E7B56AACDBD5@neustar.biz> Date: Wed, 20 Feb 2013 15:32:55 -0500 Message-ID: From: Dan Mongrain To: Marc Linsner Content-Type: multipart/alternative; boundary=e89a8f3ba31bf47e0704d62ddcc7 X-Gm-Message-State: ALoCoQmL+Zh7DBEqvafHY927xPX0MFd0nRQ4OQpy2TfX8MRzqAgBM4c2n+cZO+6K9w2Ba1kt6m5/ Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:32:59 -0000 --e89a8f3ba31bf47e0704d62ddcc7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable We should not infer anything from missing information especially if this information is optional (as my previous message shows). Doing anything else is misleading at best. Requester makes a request specifying desired service nothing more. You may ask for sos.fire, but you are getting sos as you cannot call .fire directly, local policy. If you do not like the answer, try again if you want with a different service (same service request will give same response back). Dan On Wed, Feb 20, 2013 at 3:16 PM, Marc Linsner wrote: > What if I don't want A2 (I don't trust Butler County sheriff), if no A3 > (Mars) give me A1 (PA)? > > What I proposed allows the requestor to tailor the request to match his > desire. > > The fallback is multiple requests. > > -Marc- > > From: "Rosen, Brian" > Date: Wednesday, February 20, 2013 2:56 PM > To: Marc Linsner > Cc: Dan Mongrain , "ecrit@ietf.org" > Subject: Re: [Ecrit] What is the most appropriate method for registering > new sub-services of urn:service:sos (trimming due too large message repor= t) > > To me, this doesn't make sense. > > Suppose I have a local police department in cities, but a provincial > police department in rural areas, as well as a national police. I ask fo= r > sos.police.A3. If location was in a city, I should get sos.police.A3 > > But if I was in a rural area, a request for sos.police.A3 should return a > response of sos.police.A2. > > That may or may not be the same as sos.police > > Brian > > On Feb 20, 2013, at 2:47 PM, Marc Linsner wrote: > > I understood you as requesting urn:service:sos.police.A4. > > My point was that if the LoST service had no entry for A4, it could simpl= y > check the Ax tree submitted in the location section of the request. So i= f > the location included A1 & A4, the LoST service, finding nothing for A4 > would then check A1 (not A3 or A2). This way the service would be matchi= ng > the hierarchy of the given location vs. an arbitrary hierarchy that may b= e > different from the requestors desire. > > Carry on=85 > > -Marc- > > From: Dan Mongrain > Date: Wednesday, February 20, 2013 12:30 PM > To: Marc Linsner > Cc: "Winterbottom, James" , " > ecrit@ietf.org" > Subject: Re: [Ecrit] What is the most appropriate method for registering > new sub-services of urn:service:sos (trimming due too large message repor= t) > > I do not understand your comment. What I am proposing is that requests d= o > not specify a search pattern in the case a requested jurisdiction is not > found. It should not be to the requester which submits urn:service:sos.p= olice.country.A1.A2.A3.A4 > to specify what to do if there is nothing configured for the A4 layer. I= t > must be up to the LoST service to apply whatever policy it has in this > case. If we allow this, then do we allow urn:service:sos.police.fire? > Give me fire first but if not found give me police? > > The Service URN should specify the "desired" service in a findService > request and the LoST service provides a response based on local policies. > All I am proposing is that one can specify a jurisdiction in the case the= re > are more then one service provider for a location. > > Thanx, > Dan > > On Wed, Feb 20, 2013 at 8:48 AM, Marc Linsner wrote: > >> The findService request includes location information. Why wouldn't the >> LoST server simple walk the A1-A6 tree included with the location? If >> location is geo, reverse geocode it. >> >> What am I missing? >> >> -Marc- >> >> From: Dan Mongrain >> Date: Tuesday, February 19, 2013 11:55 PM >> To: "Winterbottom, James" >> Cc: "ecrit@ietf.org" >> Subject: Re: [Ecrit] What is the most appropriate method for registering >> new sub-services of urn:service:sos (trimming due too large message repo= rt) >> >> What I meant is that if a jurisdictional scope aware LoST service >> receives a request for urn:service:sos.police.A4 and nothing is configur= ed, >> it looks for urn:service:sos.police.A3 then urn:service:sos.police.A2, e= tc. >> until it finds a configured service. If nothing is found for >> urn:service:sos.police.country then it pops the last element and looks f= or >> urn:service:sos.police (but then again, it is no longer jurisdictional >> scope aware). >> >> I disagree that one needs to formulate the request as >> urn:service:sos.police.country.A1.A2.A3.A4 in order for this to happen. >> There must be only a single jurisdictional scope appended to a Service U= RN. >> >> I do not think we need a .A6 jurisdictional scope (street level). .A5 >> (neighborhood, would point to a precinct for example) provides enough >> granularity in my opinion. >> >> Thanx, >> Dan >> >> >> On Tue, Feb 19, 2013 at 11:29 PM, Winterbottom, James < >> James.Winterbottom@commscope.com> wrote: >> >>> I am sorry, I am finding this confusing.**** >>> ** ** >>> RFC5139 puts a hierarchy on A1 through A6. If you want this hierarchy t= o >>> work then A1 through A6 can=92t be at the same level if you expect A3 t= o >>> fallback to A2 or A1 in the case of a service not existing or a service >>> failure of some kind. If they exist at the same level then if A3 doesn= =92t >>> exist you will go to urn:service:sos.police unless you impose the >>> hierarchy in the urn.**** >>> ** ** >>> ** ** >>> ** ** >>> ** ** >>> ** ** >>> *From:* Dan Mongrain [mailto:dan@mongrain.org] >>> *Sent:* Wednesday, 20 February 2013 3:23 PM >>> *To:* DRAGE, Keith (Keith) >>> *Cc:* Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org >>> *Subject:* Re: [Ecrit] What is the most appropriate method for >>> registering new sub-services of urn:service:sos (trimming due too large >>> message report)**** >>> ** ** >>> >>> My recommendation for handling unknown Service URN depends if LoST >>> service implements jurisdictional scope or not. If it does not, it pop= s >>> the last element and evaluates until a service is found. If it impleme= nts >>> jurisdictional scope, the last element is a jurisdictional scope and it= is >>> not found, then you return the next highest level defined. >>> >>> While it may be true that citizens typically dial 9-1-1 to request for >>> help, police services such as state or provincial polices advertises >>> numbers to call them directly (star code to dial using a mobile phone f= or >>> example) especially to report accidents on freeways. We need an equiva= lent >>> Service URN. >>> >>> Also while RFC5031's scope is citizen to authorities (I am not sure I >>> agree with this) I do not want to re-invent the wheel to signal calls >>> within an Emergency Services IP Network (ESInet). When I transfer a ca= ll >>> from one PSAP to another, the mechanism to determine where to send the = call >>> is the same, using LoST. For a PSAP that covers a large area spanning >>> multiple counties and the calltaker needs to transfer the call to the >>> appropriate sheriff department for the caller's location, they only nee= d a >>> single transfer target (urn:service:sos.police.A2). It is not true tha= t >>> the calltaker always knows the actual destination of the call, especial= ly >>> when the calltaker is only a call screener. >>> >>> Thanx, >>> Dan**** >>> On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) < >>> keith.drage@alcatel-lucent.com> wrote:**** >>> The answer to James=92s question depends on how you code it (and also w= hat >>> you mean by fallback).**** >>> **** >>> On any service URN, you ignore any subtypes from the point you stop >>> understanding it.**** >>> **** >>> So if the coding is sos.police.A2, and you do not understand A2, then >>> the service URN would be handled as if it was sos.police, not as >>> sos.police.A1. And if police was not understood then it would be handle= d as >>> sos.**** >>> **** >>> If you wanted something that went back to the next larger regional >>> coverage, then you would have to code successive subtypes in sequence.*= * >>> ** >>> **** >>> But I would also ask for an element of sanity in this discussion, rathe= r >>> than total flexibility.**** >>> **** >>> For example while a national administration may have multiple levels of >>> police force, not all of them are either reachable directly as an emerg= ency >>> service provider, nor are they necessarily an emergency service provide= r. >>> If they are neither of these, then they presumably do not need a specia= l >>> and distinct service URN. **** >>> **** >>> It would therefore nice to see a current use case that is anything but = a >>> choice of two, i.e. countrywide (following the ITU-T E.164 definition o= f >>> country) versus one more local variant. This restricted model certainly >>> covers Ivo=92s examples of Czeck Republic and Poland, and I believe it = also >>> covers the other example I know of which is Italy.**** >>> **** >>> While the USA has multiple levels of police force, on the PSTN, it only >>> appears to have one level of access to citizen to authority emergency >>> service, which is 911. I see no reason why a change to voice over IP wo= uld >>> cause a change to this.**** >>> **** >>> I would also stress that it is important to have global expectations of >>> what you get when you use a service URN. If there is not care excercise= d >>> with assigning semantics and values, A3 in one country could result in = the >>> forestry police and in another country the financial police responding.= * >>> *** >>> **** >>> Note that read the scope of RFC 5031 as being for end user accessing th= e >>> emergency service. While it might be possible to apply RFC 5031 to furt= her >>> network operations after the PSAP has been reached, e.g. to reach a >>> subsidiary PSAP, I read that as outside the scope of RFC 5031. Nor do I >>> necessarily believe in that scenario that service URNs are necessarily = the >>> best solution for routeing, as the first PSAP should know the particula= r >>> office they want to reach rather than just the type of emergency servic= e. >>> **** >>> **** >>> Regards**** >>> **** >>> Keith**** >>> **** >>> ------------------------------ >>> *From:* ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On >>> Behalf Of *Winterbottom, James >>> *Sent:* 19 February 2013 23:29 >>> *To:* Ivo Sedlacek; Dan Mongrain >>> *Cc:* ecrit@ietf.org >>> *Subject:* Re: [Ecrit] What is the most appropriate method for >>> registering new sub-services of urn:service:sos (trimming due too large >>> message report)**** >>> **** >>> I am okay with this, providing that the fallback order is clearly >>> defined.**** >>> That is, does an A3 fall back to an A2 or A1, or just back to sos?**** >>> **** >>> **** >>> **** >>> *From:* Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] >>> *Sent:* Wednesday, 20 February 2013 7:32 AM >>> *To:* Dan Mongrain >>> *Cc:* Winterbottom, James; Richard Barnes; ecrit@ietf.org >>> *Subject:* RE: [Ecrit] What is the most appropriate method for >>> registering new sub-services of urn:service:sos (trimming due too large >>> message report)**** >>> **** >>> Hello,**** >>> **** >>> If we go with RFC4119 based sub-services, would the IANA registration >>> request be as follows?**** >>> **** >>> - urn:service:sos.police*.A3* - The 'police.local' service refers to >>> the emergency service offered by the police department or other law >>> enforcement authorities of the authorities *of a city, township, shi >>> (JP)*.**** >>> - urn:service:sos.police*.country* - The 'police.national' service >>> refers to the emergency service offered by the police department or oth= er >>> law enforcement authorities of the government *of a country*.**** >>> **** >>> Does anyone see any issue in that?**** >>> **** >>> If WG prefers this, it is OK for me.**** >>> **** >>> > In the latter case, so how do I get the county police (or state >>> police, there can be up to 4 police services for a given location in th= e >>> US). **** >>> **** >>> If I got it correctly, you propose that we also add **** >>> - urn:service:sos.police*.A2* - The 'police.local' service refers to >>> the emergency service offered by the police department or other law >>> enforcement authorities of the authorities *of county, parish, gun >>> (JP), district (IN)*"**** >>> - urn:service:sos.police*.A1* - The 'police.local' service refers to >>> the emergency service offered by the police department or other law >>> enforcement authorities of the authorities *of national subdivisions >>> (state, region, province, prefecture)*"**** >>> **** >>> While I have no problem with that, I am not aware of a regulation >>> establishing such emergency service so I cannot argue to IANA that the >>> RFC5031 policy is satisfied for those URNs.**** >>> **** >>> Kind regards**** >>> **** >>> Ivo Sedlacek**** >>> **** >>> **** >>> **** >>> **** >>> This Communication is Confidential. We only send and receive email on >>> the basis of the terms set out at www.ericsson.com/email_disclaimer ***= * >>> *From:* Dan Mongrain [mailto:dan@mongrain.org ] >>> *Sent:* 19. =FAnora 2013 21:12 >>> *To:* Ivo Sedlacek >>> *Cc:* Winterbottom, James; Richard Barnes; ecrit@ietf.org >>> *Subject:* Re: [Ecrit] What is the most appropriate method for >>> registering new sub-services of urn:service:sos (trimming due too large >>> message report)**** >>> **** >>> Thing is, when there is no city police, local would give you county >>> police (sheriff department) but in a city with a city police department >>> local would give you city police. In the latter case, so how do I get = the >>> county police (or state police, there can be up to 4 police services fo= r a >>> given location in the US). Note that these examples are US based, but = we >>> do have 3 levels of police services in Canada and I am sure other count= ries >>> have the same issue.**** >>> **** >>> >>> There is also the terminology. There is no "national" police in the US >>> or Canada but there is a federal police. Keeping the RFC 4119 terminol= ogy >>> removes any "local" interpretation issues. >>> >>> Dan**** >>> On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek >>> wrote:**** >>> I agree with Richard - there are countries where both the emergency >>> service of the national police and the emergency service of the municip= al >>> police are offered in a given location. **** >>> A user would call the municipal police emergency service to report e.g. >>> pickpockets.**** >>> A user would call the national police emergency service to report e.g. = a >>> murder.**** >>> **** >>> **** >>> I submitted to IANA a request to register:**** >>> - urn:service:sos.police.local - The 'police.local' service refers to >>> the emergency service offered by the police department or other law >>> enforcement authorities of the local or municipal authorities.**** >>> - urn:service:sos.police.national - The 'police.national' service refer= s >>> to the emergency service offered by the police department or other law >>> enforcement authorities of the national government.**** >>> **** >>> RFC5031 policy is hopefully fulfilled for them since they exist in two >>> countries.**** >>> **** >>> I am flexible whether the actual URNs contain the sub-services proposed >>> above (i.e. .local and .national sub-services) or subservices based on >>> RFC4119 (i.e. .A3 and .country sub-services).**** >>> **** >>> If the preference is for subservices based on RFC4119, do I need to mak= e >>> another IANA registration request or can we modify the URNs and their >>> description during the expert review?**** >>> **** >>> Kind regards**** >>> **** >>> Ivo Sedlacek**** >>> **** >>> This Communication is Confidential. We only send and receive email on >>> the basis of the terms set out at www.ericsson.com/email_disclaimer ***= * >>> *From:* Dan Mongrain [mailto:dan@mongrain.org] >>> *Sent:* 19. =FAnora 2013 15:36 >>> *To:* Winterbottom, James >>> *Cc:* Richard Barnes; Ivo Sedlacek; ecrit@ietf.org >>> *Subject:* Re: [Ecrit] What is the most appropriate method for >>> registering new sub-services of urn:service:sos**** >>> **** >>> The problem is that different countries has different names for their >>> political subdivisions. In the US they are states, in Canada they are >>> provinces, etc. Same when you further subdivide. While not privy to t= he >>> discussions that came up with A1, A2, =85, A5, I have the feeling this >>> nomenclature was picked for the same reason. Why not utilise the same >>> naming scheme for specifying the jurisdiction you want to reach?**** >>> **** >>> Thanx,**** >>> Dan**** >>> >>> **** >>> On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James < >>> James.Winterbottom@commscope.com> wrote:**** >>> In that case, one might say state in the hierarchy, not A1.**** >>> **** >>> Cheers**** >>> James**** >>> **** >>> **** >>> *From:* Richard Barnes [mailto:rlb@ipv.sx] >>> *Sent:* Tuesday, 19 February 2013 8:57 AM >>> *To:* Winterbottom, James >>> *Cc:* Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org**** >>> >>> *Subject:* Re: [Ecrit] What is the most appropriate method for >>> registering new sub-services of urn:service:sos**** >>> **** >>> It might make sense if you wanted to allow the caller to explicitly >>> select police at a different level of responsibility, e.g., the state >>> police rather than the local police. **** >>> >>> **** >>> On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James < >>> James.Winterbottom@commscope.com> wrote:**** >>> I think I am missing something here, A1 is part of the location, so why >>> does it need to be in the URN at all?**** >>> As far as I understand current deployments, they use the URN to select = a >>> layer in the GIS that corresponds to the service type, and then use >>> geographic boundaries within that layer to select the final destination= . >>> **** >>> **** >>> *From:* ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On >>> Behalf Of *Dan Mongrain >>> *Sent:* Tuesday, 19 February 2013 7:30 AM**** >>> >>> *To:* Ivo Sedlacek >>> *Cc:* ecrit@ietf.org >>> *Subject:* Re: [Ecrit] What is the most appropriate method for >>> registering new sub-services of urn:service:sos**** >>> **** >>> Sorry for responding late to this thread, it kinda fell into a crack= =85 >>> The current thread reminded me to check this old thread=85**** >>> **** >>> You are indicating that we need to register 77 Service URN (11 service >>> subtypes * 7 jurisdiction types based on RFC 4119). I do not recommend >>> that we create so many registrations. Instead, we should allow a servi= ce >>> URN to be suffixed with a jurisdictional scope. So the following Servi= ce >>> URN are all valid:**** >>> **** >>> urn:service:sos.police**** >>> urn:service:sos.police.traffic**** >>> urn:service:sos.police.A1**** >>> urn:service:sos.police.traffic.A1**** >>> **** >>> Question is, do we want to leave jurisdictional scope to only be >>> applicable to police branch or any Service URN? I=92d say the latter a= s it >>> is always up to the LoST service provisioning (based on local policy) t= o >>> determine what is locally acceptable.**** >>> **** >>> Thanx,**** >>> Dan**** >>> **** >>> **** >>> ** ** >>> >> >> _______________________________________________ Ecrit mailing list >> Ecrit@ietf.orghttps://www.ietf.org/mailman/listinfo/ecrit >> >> > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > --e89a8f3ba31bf47e0704d62ddcc7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable We should not infer anything from missing information especially if this in= formation is optional (as my previous message shows).=A0 Doing anything els= e is misleading at best.=A0 Requester makes a request specifying desired se= rvice nothing more.=A0 You may ask for sos.fire, but you are getting sos as= you cannot call .fire directly, local policy.=A0 If you do not like the an= swer, try again if you want with a different service (same service request = will give same response back).

Dan

On Wed, Feb 20, 2013 at 3:16 PM, = Marc Linsner <mlinsner@cisco.com> wrote:
What if I don't want A2 (I don't trust Butler County sh= eriff), if no A3 (Mars) give me A1 (PA)?

What I pr= oposed allows the requestor to tailor the request to match his desire.

The fallback is multiple requests.

=
-Marc-

From: "Rosen, Brian" <= ;Brian.Rosen@n= eustar.biz>
Date: Wednes= day, February 20, 2013 2:56 PM
To: Marc Linsner <mlinsner@cisco.com>
Cc: Dan Mongrain <dan@mongrain.org>, "ecrit@ietf.org" &l= t;ecrit@ietf.org>= ;
Subject: Re: [Ecrit] What is the m= ost appropriate method for registering new sub-services of urn:service:sos = (trimming due too large message report)

To me, this doesn't make sense= .

Suppose I have a local police department in cities, bu= t a provincial police department in rural areas, as well as a national poli= ce. =A0I ask for sos.police.A3. =A0If location was in a city, I should get = sos.police.A3

But if I was in a rural area, a request for sos.police.= A3 should return a response of sos.police.A2.

That= may or may not be the same as sos.police

Brian

On Feb 20, 2013, at 2:47 PM, Marc Linsner <mlinsner@cisco.com> wr= ote:

I understood you as requesting urn:service:sos.police.A4.
My point was that if the LoST service had no entry for A4, it = could simply check the Ax tree submitted in the location section of the req= uest. =A0So if the location included A1 & A4, the LoST service, finding= nothing for A4 would then check A1 (not A3 or A2). =A0This way the service= would be matching the hierarchy of the given location vs. an arbitrary hie= rarchy that may be different from the requestors desire.

Carry on=85

-Marc-
<= br>
From: Dan Mongrain <dan@mongrain.org>
Date: Wednesday, February 20, 2013 12:= 30 PM
To: Marc Linsner <mlinsner@cisco.com>
Cc: "Winterbottom, James" = <J= ames.Winterbottom@commscope.com>, "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] What is the m= ost appropriate method for registering new sub-services of urn:service:sos = (trimming due too large message report)

I do not understand your comment.=A0 What I am proposing is that requests d= o not specify a search pattern in the case a requested jurisdiction is not = found.=A0 It should not be to the requester which submits urn:service= :sos.police.country.A1.A2.A3.A4 to specify what to do if there is nothing c= onfigured for the A4 layer.=A0 It must be up to the LoST service to apply w= hatever policy it has in this case.=A0 If we allow this, then do we allow u= rn:service:sos.police.fire?=A0 Give me fire first but if not found give me = police?

The Service URN should specify the "desired" service in a fin= dService request and the LoST service provides a response based on local po= licies.=A0 All I am proposing is that one can specify a jurisdiction in the= case there are more then one service provider for a location.

Thanx,
Dan

On Wed, Feb 20, = 2013 at 8:48 AM, Marc Linsner <mlinsner@cisco.com> wrote:
The findService request includes location information. =A0Why w= ouldn't the LoST server simple walk the A1-A6 tree included with the lo= cation? =A0If location is geo, reverse geocode it.

What am I missing?

-Marc-

From: Dan Mongrain <dan@mongrain.org>
Date: Tuesday, February 19, 2013 11:55= PM
To: "Winterbottom, James"= ; <James.Winterbottom@commscope.com>
Cc: "ec= rit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] What is the m= ost appropriate method for registering new sub-services of urn:service:sos = (trimming due too large message report)

What I meant is that if a jurisdictional scope aware LoST service receives = a request for urn:service:sos.police.A4 and nothing is configured, it looks= for urn:service:sos.police.A3 then urn:service:sos.police.A2, etc. until i= t finds a configured service.=A0 If nothing is found for urn:service:sos.po= lice.country then it pops the last element and looks for urn:service:sos.po= lice (but then again, it is no longer jurisdictional scope aware).

I disagree that one needs to formulate the request as urn:service:sos.p= olice.country.A1.A2.A3.A4 in order for this to happen.=A0 There must be onl= y a single jurisdictional scope appended to a Service URN.

I do not = think we need a .A6 jurisdictional scope (street level).=A0 .A5 (neighborho= od, would point to a precinct for example) provides enough granularity in m= y opinion.

Thanx,
Dan


On Tue, Feb 19, 201= 3 at 11:29 PM, Winterbottom, James <James.Winterbottom@comm= scope.com> wrote:
I am sorry, I am find= ing this confusing.
=A0
RFC5139 puts a hierarchy on A1 through A6. If you wa= nt this hierarchy to work then A1 through A6 can=92t be at the same level i= f you expect A3 to fallback to A2 or A1 in the case of a service not existi= ng or a service failure of some kind. If they exist at the same level then = if A3 doesn=92t exist you will go to urn:service:sos.police=A0 unless you i= mpose the hierarchy in the urn.
=A0
=A0
=A0
=A0
=A0
<= div class=3D"MsoNormal"> From: Dan Mong= rain [mailto:dan@mong= rain.org]
Sent: Wednesday, 20 February 2013 3:23 PM
To: DRAGE, Keith= (Keith)
Cc: Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org
Subject: Re= : [Ecrit] What is the most appropriate method for registering new sub-servi= ces of urn:service:sos (trimming due too large message report)
=A0

My recommendation for handling unknown Ser= vice URN depends if LoST service implements jurisdictional scope or not.=A0= If it does not, it pops the last element and evaluates until a service is = found.=A0 If it implements jurisdictional scope, the last element is a juri= sdictional scope and it is not found, then you return the next highest leve= l defined.

While it may be true that citizens typically dial 9-1-1 to request for = help, police services such as state or provincial polices advertises number= s to call them directly (star code to dial using a mobile phone for example= ) especially to report accidents on freeways.=A0 We need an equivalent Serv= ice URN.

Also while RFC5031's scope is citizen to authorities (I am not sure= I agree with this) I do not want to re-invent the wheel to signal calls wi= thin an Emergency Services IP Network (ESInet).=A0 When I transfer a call f= rom one PSAP to another, the mechanism to determine where to send the call = is the same, using LoST.=A0 For a PSAP that covers a large area spanning mu= ltiple counties and the calltaker needs to transfer the call to the appropr= iate sheriff department for the caller's location, they only need a sin= gle transfer target (urn:service:sos.police.A2).=A0 It is not true that the= calltaker always knows the actual destination of the call, especially when= the calltaker is only a call screener.

Thanx,
Dan

On Tue, Fe= b 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com= > wrote:
The answer to James=92s question d= epends on how you code it (and also what you mean by fallback).
=A0<= u>
On any service URN, = you ignore any subtypes from the point you stop understanding it.
=A0<= u>
So if the coding is = sos.police.A2, and you do not understand A2, then the service URN would be = handled as if it was sos.police, not as sos.police.A1. And if police was no= t understood then it would be handled as sos.
=A0<= u>
If you wanted someth= ing that went back to the next larger regional coverage, then you would hav= e to code successive subtypes in sequence.
=A0<= u>
But I would also ask= for an element of sanity in this discussion, rather than total flexibility= .
=A0<= u>
For example while a = national administration may have multiple levels of police force, not all o= f them are either reachable directly as an emergency service provider, nor = are they necessarily an emergency service provider. If they are neither of = these, then they presumably do not need a special and distinct service URN.=
=A0<= u>
It would therefore n= ice to see a current use case that is anything but a choice of two, i.e. co= untrywide (following the ITU-T E.164 definition of country) versus one more= local variant. This restricted model certainly covers Ivo=92s examples of = Czeck Republic and Poland, and I believe it also covers the other example I= know of which is Italy.
=A0<= u>
While the USA has mu= ltiple levels of police force, on the PSTN, it only appears to have one lev= el of access to citizen to authority emergency service, which is 911. I see= no reason why a change to voice over IP would cause a change to this.
=A0<= u>
I would also stress = that it is important to have global expectations of what you get when you u= se a service URN. If there is not care excercised with assigning semantics = and values, A3 in one country could result in the forestry police and in an= other country the financial police responding.<= u>
=A0<= u>
Note that read the s= cope of RFC 5031 as being for end user accessing the emergency service. Whi= le it might be possible to apply RFC 5031 to further network operations aft= er the PSAP has been reached, e.g. to reach a subsidiary PSAP, I read that = as outside the scope of RFC 5031. Nor do I necessarily believe in that scen= ario that service URNs are necessarily the best solution for routeing, as t= he first PSAP should know the particular office they want to reach rather t= han just the type of emergency service.<= u>
=A0<= u>
Regards
=A0<= u>
Keith
=A0<= u>
=
From: ecrit-bounces@ietf.o= rg [mailto:= ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James
Sent: 19 February 2013 23:29
To: Ivo Sedlacek; Dan Mongrai= n
Cc: ecrit@i= etf.org
Subject: Re: [Ecrit] What is the most appropriate met= hod for registering new sub-services of urn:service:sos (trimming due too l= arge message report)
=A0
I am okay with this, providing that= the fallback order is clearly defined.<= u>
That is, does an A3 fall back to an A2 or = A1, or just back to sos?
=A0<= /u>
=A0
=A0<= /u>
From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com]
Sent: Wednesday, 20 February 2013 7:32 AM
To: Dan Mongrain=
Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: RE: [Ecr= it] What is the most appropriate method for registering new sub-services of= urn:service:sos (trimming due too large message report)
=A0=
Hello,
=A0
If we go with RFC4119 based su= b-services, would the IANA registration request be as follows?
=A0
- urn:service:sos.police.A3= =A0- The 'police.local' service refers to the emergency service= offered by the police department or other law enforcement authorities of t= he authorities=A0of a city, township, shi (JP).
- urn:service:sos.police.country=A0- = The 'police.national' service refers to the emergency service offer= ed by the police department or other law enforcement authorities of the gov= ernment=A0of a country.
=A0
Does anyone see any issue in t= hat?
=A0
If WG prefers this, it is OK f= or me.
=A0
> In the latter case, so how do I= get the county police (or state police, there can be up to 4 police servic= es for a given location in the US).=A0 <= u>
=A0
If I got it correctly, you pro= pose that we also add
- urn:service:sos.police.A2 - The = 9;police.local' service refers to the emergency service offered by the = police department or other law enforcement authorities of the authorities= =A0of county, parish, gun (JP), district (IN)"
- urn:service:sos.police.A1 - The = 9;police.local' service refers to the emergency service offered by the = police department or other law enforcement authorities of the authorities= =A0of national subdivisions (state, region, province, prefecture)&qu= ot;
=A0
While I have no problem with t= hat, I am not aware of a regulation establishing such emergency service so = I cannot argue to IANA that the RFC5031 policy is satisfied for those URNs.=
=A0
Kind regards
=A0
Ivo Sedlacek
=A0
=A0
=A0
=A0
This Communication is Confidential. We only se= nd and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer =
From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19. =FAnora 2013 21:12
To: Ivo Sedlacek
Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: Re: [Ecrit] What is t= he most appropriate method for registering new sub-services of urn:service:= sos (trimming due too large message report)<= /u>
=A0
Thing is, when there is no city police, local would give you c= ounty police (sheriff department) but in a city with a city police departme= nt local would give you city police.=A0 In the latter case, so how do I get= the county police (or state police, there can be up to 4 police services f= or a given location in the US).=A0 Note that these examples are US based, b= ut we do have 3 levels of police services in Canada and I am sure other cou= ntries have the same issue.
=A0<= /u>

There is also the terminology.=A0 There is no "national" police i= n the US or Canada but there is a federal police.=A0 Keeping the RFC 4119 t= erminology removes any "local" interpretation issues.

Dan<= span lang=3D"EN-GB">

On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek= <ivo.sed= lacek@ericsson.com> wrote:=
I agree with Richard - there are countr= ies where both the emergency service of the national police and the emergen= cy service of the municipal police are offered in a given location. =
A user would call the municipal police emerg= ency service to report e.g. pickpockets.=
A user would call the national police emerge= ncy service to report e.g. a murder.<= /u>
=A0
=A0
I submitted to IANA a request to register:
- urn:service:sos.police.local - The 'police.local' servic= e refers to the emergency service offered by the police department or other= law enforcement authorities of the local or municipal authorities.<= span lang=3D"EN-GB">
- urn:service:sos.police.national - The '= ;police.national' service refers to the emergency service offered by th= e police department or other law enforcement authorities of the national go= vernment.
=A0
RFC5031 policy is hopefully fu= lfilled for them since they exist in two countries.
=A0
I am flexible whether the actu= al URNs contain the sub-services proposed above (i.e. .local and .national = sub-services) or subservices based on RFC4119 (i.e. .A3 and .country sub-se= rvices).
=A0
If the preference is for subse= rvices based on RFC4119, do I need to make another IANA registration reques= t or can we modify the URNs and their description during the expert review?=
=A0
Kind regards
=A0
Ivo Sedlacek
=A0
This Communication is Confidenti= al. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaim= er
From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19. =FAnora 2013 15:36
To: Winterbottom, James
Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org
Subject: Re: [Ecrit] What is t= he most appropriate method for registering new sub-services of urn:service:= sos
=A0
The problem is that different countries h= as different names for their political subdivisions.=A0 In the US they are = states, in Canada they are provinces, etc.=A0 Same when you further subdivi= de.=A0 While not privy to the discussions that came up with A1, A2, =85, A5= , I have the feeling this nomenclature was picked for the same reason.=A0 W= hy not utilise the same naming scheme for specifying the jurisdiction you w= ant to reach?
=A0<= /u>
Thanx,
Dan<= /u>

=A0

On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James <James.Winterbottom@= commscope.com> wrote:
In that case, one might say state in = the hierarchy, not A1.
=A0<= /u>
Cheers
James
=A0
=A0<= /u>
From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Tuesday, 19 February 2013 8:57 AM
To: Winterbottom, = James
Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org<= /u>

Subject: Re: [Ecrit] What is the m= ost appropriate method for registering new sub-services of urn:service:sos<= span lang=3D"EN-GB">
=A0
It might make sense if you wanted to allow the caller to explicitly s= elect police at a different level of responsibility, e.g., the state police= rather than the local police. =A0

=A0

On Mon= , Feb 18, 2013 at 4:21 PM, Winterbottom, James <James.Winterbottom@commscope.= com> wrote:
I think I am missing something here, = A1 is part of the location, so why does it need to be in the URN at all?
As far as I understand current deployments= , they use the URN to select a layer in the GIS that corresponds to the ser= vice type, and then use geographic boundaries within that layer to select t= he final destination.
=A0<= /u>
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Dan M= ongrain
Sent: Tuesday, 19 February 2013 7:30 AM<= u>

To: Ivo = Sedlacek
Cc: = ecrit@ietf.org
Subject: Re: [Ecrit] What is the most appropriate method for registe= ring new sub-services of urn:service:sos=
=A0
Sorry for responding late to this thread, = it kinda fell into a=A0 crack=85=A0 The current thread reminded me to check= this old thread=85
=A0<= /u>
You are indicating that we= need to register 77 Service URN (11 service subtypes * 7 jurisdiction type= s based on RFC 4119).=A0 I do not recommend that we create so many registra= tions.=A0 Instead, we should allow a service URN to be suffixed with a juri= sdictional scope.=A0 So the following Service URN are all valid:
=A0<= /u>
urn:service:sos.police
urn:service:sos.police.traffic
urn:service:sos.police.A1=
urn:service:sos.police.traffic.A1
=A0
Question is, do we want to leave jurisdict= ional scope to only be applicable to police branch or any Service URN? =A0I= =92d say the latter as it is always up to the LoST service provisioning (ba= sed on local policy) to determine what is locally acceptable.
=A0<= /u>
Thanx,
Dan<= /u>
=A0
=A0
=A0

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

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


--e89a8f3ba31bf47e0704d62ddcc7-- From mlinsner@cisco.com Wed Feb 20 13:15:29 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B7E21E803A for ; Wed, 20 Feb 2013 13:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.568 X-Spam-Level: X-Spam-Status: No, score=-8.568 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_36=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5iLwFTIdvkf for ; Wed, 20 Feb 2013 13:15:15 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDD921F84C7 for ; Wed, 20 Feb 2013 13:15:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=74355; q=dns/txt; s=iport; t=1361394914; x=1362604514; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=nbMCuZmzdCxqLlELugdIT+qcFV9mg5ZeiD1jXr2cawo=; b=M8Fqlm80wicfIH4TYB2iSLAdSotHkVYVLybiTmmfgAUM/0UiY9kqRZ0X Aunif23N42idrwA21xyyiRyo2rtbWRy0dJTwqb++rtDDZhfhiDxtYJZRR 4myhI4avoWTXEh89tT0eeEELmf1eb9aRiOP2hiZsoIaxug6Gyt/u4dval U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAFU7JVGtJV2Y/2dsb2JhbABFgkNyvSwWbBZzgh8BAQEDAQEBARcBIgwdBQMLBQ4IEQMBAQEBIAECBC4fCQgGCgQFCRKHcQYMsAeQP40zCoEmGQEGAQYBAwYBAgSDOgOIMDaJTTqDP4VyimmBUoFTgVQ X-IronPort-AV: E=Sophos;i="4.84,703,1355097600"; d="scan'208,217";a="179123251" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 20 Feb 2013 21:15:11 +0000 Received: from [10.116.195.124] (rtp-mlinsner-87111.cisco.com [10.116.195.124]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1KLF8MU029467; Wed, 20 Feb 2013 21:15:09 GMT User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Wed, 20 Feb 2013 16:15:07 -0500 From: Marc Linsner To: Dan Mongrain Message-ID: Thread-Topic: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3444221710_1723703" Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 21:15:29 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3444221710_1723703 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Not sure I agree with your summation. In your example, .sos IS the proper way to call .fire. Just because .sos is also the proper way to call .polic= e is irrelevant. Maybe it would be best to use a DNS-like approach. No record =3D 'not found'= . No ambiguity this way. Populate .sos and .sos.fire and .sos.police all wit= h the same uri if that is the response you want. If request is for .sos.help and the jurisdiction doesn't support .help, the response is 'not found'. Why try to guess what was requested? -Marc- From: Dan Mongrain Date: Wednesday, February 20, 2013 3:32 PM To: Marc Linsner Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) > We should not infer anything from missing information especially if this > information is optional (as my previous message shows). Doing anything e= lse > is misleading at best. Requester makes a request specifying desired serv= ice > nothing more. You may ask for sos.fire, but you are getting sos as you c= annot > call .fire directly, local policy. If you do not like the answer, try ag= ain > if you want with a different service (same service request will give same > response back). >=20 > Dan >=20 > On Wed, Feb 20, 2013 at 3:16 PM, Marc Linsner wrote: >> What if I don't want A2 (I don't trust Butler County sheriff), if no A3 >> (Mars) give me A1 (PA)? >>=20 >> What I proposed allows the requestor to tailor the request to match his >> desire. >>=20 >> The fallback is multiple requests. >>=20 >> -Marc- >>=20 >> From: "Rosen, Brian" >> Date: Wednesday, February 20, 2013 2:56 PM >> To: Marc Linsner >> Cc: Dan Mongrain , "ecrit@ietf.org" >> Subject: Re: [Ecrit] What is the most appropriate method for registerin= g new >> sub-services of urn:service:sos (trimming due too large message report) >>=20 >>> To me, this doesn't make sense. >>>=20 >>> Suppose I have a local police department in cities, but a provincial po= lice >>> department in rural areas, as well as a national police. I ask for >>> sos.police.A3. If location was in a city, I should get sos.police.A3 >>>=20 >>> But if I was in a rural area, a request for sos.police.A3 should return= a >>> response of sos.police.A2. >>>=20 >>> That may or may not be the same as sos.police >>>=20 >>> Brian >>>=20 >>> On Feb 20, 2013, at 2:47 PM, Marc Linsner wrote: >>>=20 >>>> I understood you as requesting urn:service:sos.police.A4. >>>>=20 >>>> My point was that if the LoST service had no entry for A4, it could si= mply >>>> check the Ax tree submitted in the location section of the request. S= o if >>>> the location included A1 & A4, the LoST service, finding nothing for A= 4 >>>> would then check A1 (not A3 or A2). This way the service would be mat= ching >>>> the hierarchy of the given location vs. an arbitrary hierarchy that ma= y be >>>> different from the requestors desire. >>>>=20 >>>> Carry on=8A >>>>=20 >>>> -Marc- >>>>=20 >>>> From: Dan Mongrain >>>> Date: Wednesday, February 20, 2013 12:30 PM >>>> To: Marc Linsner >>>> Cc: "Winterbottom, James" , >>>> "ecrit@ietf.org" >>>> Subject: Re: [Ecrit] What is the most appropriate method for register= ing >>>> new sub-services of urn:service:sos (trimming due too large message re= port) >>>>=20 >>>>> I do not understand your comment. What I am proposing is that reques= ts do >>>>> not specify a search pattern in the case a requested jurisdiction is = not >>>>> found. It should not be to the requester which submits >>>>> urn:service:sos.police.country.A1.A2.A3.A4 to specify what to do if t= here >>>>> is nothing configured for the A4 layer. It must be up to the LoST se= rvice >>>>> to apply whatever policy it has in this case. If we allow this, then= do >>>>> we allow urn:service:sos.police.fire? Give me fire first but if not = found >>>>> give me police? >>>>>=20 >>>>> The Service URN should specify the "desired" service in a findService >>>>> request and the LoST service provides a response based on local polic= ies. >>>>> All I am proposing is that one can specify a jurisdiction in the case >>>>> there are more then one service provider for a location. >>>>>=20 >>>>> Thanx, >>>>> Dan >>>>>=20 >>>>> On Wed, Feb 20, 2013 at 8:48 AM, Marc Linsner wr= ote: >>>>>> The findService request includes location information. Why wouldn't= the >>>>>> LoST server simple walk the A1-A6 tree included with the location? = If >>>>>> location is geo, reverse geocode it. >>>>>>=20 >>>>>> What am I missing? >>>>>>=20 >>>>>> -Marc- >>>>>>=20 >>>>>> From: Dan Mongrain >>>>>> Date: Tuesday, February 19, 2013 11:55 PM >>>>>> To: "Winterbottom, James" >>>>>> Cc: "ecrit@ietf.org" >>>>>> Subject: Re: [Ecrit] What is the most appropriate method for regist= ering >>>>>> new sub-services of urn:service:sos (trimming due too large message >>>>>> report) >>>>>>=20 >>>>>>> What I meant is that if a jurisdictional scope aware LoST service >>>>>>> receives a request for urn:service:sos.police.A4 and nothing is >>>>>>> configured, it looks for urn:service:sos.police.A3 then >>>>>>> urn:service:sos.police.A2, etc. until it finds a configured service= . If >>>>>>> nothing is found for urn:service:sos.police.country then it pops th= e >>>>>>> last element and looks for urn:service:sos.police (but then again, = it is >>>>>>> no longer jurisdictional scope aware). >>>>>>>=20 >>>>>>> I disagree that one needs to formulate the request as >>>>>>> urn:service:sos.police.country.A1.A2.A3.A4 in order for this to hap= pen. >>>>>>> There must be only a single jurisdictional scope appended to a Serv= ice >>>>>>> URN. >>>>>>>=20 >>>>>>> I do not think we need a .A6 jurisdictional scope (street level). = .A5 >>>>>>> (neighborhood, would point to a precinct for example) provides enou= gh >>>>>>> granularity in my opinion. >>>>>>>=20 >>>>>>> Thanx, >>>>>>> Dan >>>>>>>=20 >>>>>>>=20 >>>>>>> On Tue, Feb 19, 2013 at 11:29 PM, Winterbottom, James >>>>>>> wrote: >>>>>>> I am sorry, I am finding this confusing. >>>>>>> =20 >>>>>>> RFC5139 puts a hierarchy on A1 through A6. If you want this hierarc= hy to >>>>>>> work then A1 through A6 can=B9t be at the same level if you expect A3= to >>>>>>> fallback to A2 or A1 in the case of a service not existing or a ser= vice >>>>>>> failure of some kind. If they exist at the same level then if A3 do= esn=B9t >>>>>>> exist you will go to urn:service:sos.police unless you impose the >>>>>>> hierarchy in the urn. >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> From: Dan Mongrain [mailto:dan@mongrain.org] >>>>>>> Sent: Wednesday, 20 February 2013 3:23 PM >>>>>>> To: DRAGE, Keith (Keith) >>>>>>> Cc: Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org >>>>>>> Subject: Re: [Ecrit] What is the most appropriate method for regist= ering >>>>>>> new sub-services of urn:service:sos (trimming due too large message >>>>>>> report) >>>>>>> =20 >>>>>>> My recommendation for handling unknown Service URN depends if LoST >>>>>>> service implements jurisdictional scope or not. If it does not, it= pops >>>>>>> the last element and evaluates until a service is found. If it >>>>>>> implements jurisdictional scope, the last element is a jurisdiction= al >>>>>>> scope and it is not found, then you return the next highest level >>>>>>> defined. >>>>>>>=20 >>>>>>> While it may be true that citizens typically dial 9-1-1 to request = for >>>>>>> help, police services such as state or provincial polices advertise= s >>>>>>> numbers to call them directly (star code to dial using a mobile pho= ne >>>>>>> for example) especially to report accidents on freeways. We need a= n >>>>>>> equivalent Service URN. >>>>>>>=20 >>>>>>> Also while RFC5031's scope is citizen to authorities (I am not sure= I >>>>>>> agree with this) I do not want to re-invent the wheel to signal cal= ls >>>>>>> within an Emergency Services IP Network (ESInet). When I transfer = a >>>>>>> call from one PSAP to another, the mechanism to determine where to = send >>>>>>> the call is the same, using LoST. For a PSAP that covers a large a= rea >>>>>>> spanning multiple counties and the calltaker needs to transfer the = call >>>>>>> to the appropriate sheriff department for the caller's location, th= ey >>>>>>> only need a single transfer target (urn:service:sos.police.A2). It= is >>>>>>> not true that the calltaker always knows the actual destination of = the >>>>>>> call, especially when the calltaker is only a call screener. >>>>>>>=20 >>>>>>> Thanx, >>>>>>> Dan >>>>>>>=20 >>>>>>> On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) >>>>>>> wrote: >>>>>>> The answer to James=B9s question depends on how you code it (and also= what >>>>>>> you mean by fallback). >>>>>>> =20 >>>>>>> On any service URN, you ignore any subtypes from the point you stop >>>>>>> understanding it. >>>>>>> =20 >>>>>>> So if the coding is sos.police.A2, and you do not understand A2, th= en >>>>>>> the service URN would be handled as if it was sos.police, not as >>>>>>> sos.police.A1. And if police was not understood then it would be ha= ndled >>>>>>> as sos. >>>>>>> =20 >>>>>>> If you wanted something that went back to the next larger regional >>>>>>> coverage, then you would have to code successive subtypes in sequen= ce. >>>>>>> =20 >>>>>>> But I would also ask for an element of sanity in this discussion, r= ather >>>>>>> than total flexibility. >>>>>>> =20 >>>>>>> For example while a national administration may have multiple level= s of >>>>>>> police force, not all of them are either reachable directly as an >>>>>>> emergency service provider, nor are they necessarily an emergency >>>>>>> service provider. If they are neither of these, then they presumabl= y do >>>>>>> not need a special and distinct service URN. >>>>>>> =20 >>>>>>> It would therefore nice to see a current use case that is anything = but a >>>>>>> choice of two, i.e. countrywide (following the ITU-T E.164 definiti= on of >>>>>>> country) versus one more local variant. This restricted model certa= inly >>>>>>> covers Ivo=B9s examples of Czeck Republic and Poland, and I believe i= t >>>>>>> also covers the other example I know of which is Italy. >>>>>>> =20 >>>>>>> While the USA has multiple levels of police force, on the PSTN, it = only >>>>>>> appears to have one level of access to citizen to authority emergen= cy >>>>>>> service, which is 911. I see no reason why a change to voice over I= P >>>>>>> would cause a change to this. >>>>>>> =20 >>>>>>> I would also stress that it is important to have global expectation= s of >>>>>>> what you get when you use a service URN. If there is not care excer= cised >>>>>>> with assigning semantics and values, A3 in one country could result= in >>>>>>> the forestry police and in another country the financial police >>>>>>> responding. >>>>>>> =20 >>>>>>> Note that read the scope of RFC 5031 as being for end user accessin= g the >>>>>>> emergency service. While it might be possible to apply RFC 5031 to >>>>>>> further network operations after the PSAP has been reached, e.g. to >>>>>>> reach a subsidiary PSAP, I read that as outside the scope of RFC 50= 31. >>>>>>> Nor do I necessarily believe in that scenario that service URNs are >>>>>>> necessarily the best solution for routeing, as the first PSAP shoul= d >>>>>>> know the particular office they want to reach rather than just the = type >>>>>>> of emergency service. >>>>>>> =20 >>>>>>> Regards >>>>>>> =20 >>>>>>> Keith >>>>>>> =20 >>>>>>>=20 >>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Beh= alf >>>>>>> Of Winterbottom, James >>>>>>> Sent: 19 February 2013 23:29 >>>>>>> To: Ivo Sedlacek; Dan Mongrain >>>>>>> Cc: ecrit@ietf.org >>>>>>> Subject: Re: [Ecrit] What is the most appropriate method for regist= ering >>>>>>> new sub-services of urn:service:sos (trimming due too large message >>>>>>> report) >>>>>>> =20 >>>>>>> I am okay with this, providing that the fallback order is clearly >>>>>>> defined. >>>>>>> That is, does an A3 fall back to an A2 or A1, or just back to sos? >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] >>>>>>> Sent: Wednesday, 20 February 2013 7:32 AM >>>>>>> To: Dan Mongrain >>>>>>> Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org >>>>>>> Subject: RE: [Ecrit] What is the most appropriate method for regist= ering >>>>>>> new sub-services of urn:service:sos (trimming due too large message >>>>>>> report) >>>>>>> =20 >>>>>>> Hello, >>>>>>> =20 >>>>>>> If we go with RFC4119 based sub-services, would the IANA registrati= on >>>>>>> request be as follows? >>>>>>> =20 >>>>>>> - urn:service:sos.police.A3 - The 'police.local' service refers to = the >>>>>>> emergency service offered by the police department or other law >>>>>>> enforcement authorities of the authorities of a city, township, shi >>>>>>> (JP). >>>>>>> - urn:service:sos.police.country - The 'police.national' service re= fers >>>>>>> to the emergency service offered by the police department or other = law >>>>>>> enforcement authorities of the government of a country. >>>>>>> =20 >>>>>>> Does anyone see any issue in that? >>>>>>> =20 >>>>>>> If WG prefers this, it is OK for me. >>>>>>> =20 >>>>>>>> > In the latter case, so how do I get the county police (or state >>>>>>>> police, there can be up to 4 police services for a given location = in >>>>>>>> the US). =20 >>>>>>> =20 >>>>>>> If I got it correctly, you propose that we also add >>>>>>> - urn:service:sos.police.A2 - The 'police.local' service refers to = the >>>>>>> emergency service offered by the police department or other law >>>>>>> enforcement authorities of the authorities of county, parish, gun (= JP), >>>>>>> district (IN)" >>>>>>> - urn:service:sos.police.A1 - The 'police.local' service refers to = the >>>>>>> emergency service offered by the police department or other law >>>>>>> enforcement authorities of the authorities of national subdivisions >>>>>>> (state, region, province, prefecture)" >>>>>>> =20 >>>>>>> While I have no problem with that, I am not aware of a regulation >>>>>>> establishing such emergency service so I cannot argue to IANA that = the >>>>>>> RFC5031 policy is satisfied for those URNs. >>>>>>> =20 >>>>>>> Kind regards >>>>>>> =20 >>>>>>> Ivo Sedlacek >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>> This Communication is Confidential. We only send and receive email = on >>>>>>> the basis of the terms set out at www.ericsson.com/email_disclaimer >>>>>>> >>>>>>> From: Dan Mongrain [mailto:dan@mongrain.org] >>>>>>> Sent: 19. =FAnora 2013 21:12 >>>>>>> To: Ivo Sedlacek >>>>>>> Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org >>>>>>> Subject: Re: [Ecrit] What is the most appropriate method for regist= ering >>>>>>> new sub-services of urn:service:sos (trimming due too large message >>>>>>> report) >>>>>>> =20 >>>>>>> Thing is, when there is no city police, local would give you county >>>>>>> police (sheriff department) but in a city with a city police depart= ment >>>>>>> local would give you city police. In the latter case, so how do I = get >>>>>>> the county police (or state police, there can be up to 4 police ser= vices >>>>>>> for a given location in the US). Note that these examples are US b= ased, >>>>>>> but we do have 3 levels of police services in Canada and I am sure = other >>>>>>> countries have the same issue. >>>>>>> =20 >>>>>>> There is also the terminology. There is no "national" police in th= e US >>>>>>> or Canada but there is a federal police. Keeping the RFC 4119 >>>>>>> terminology removes any "local" interpretation issues. >>>>>>>=20 >>>>>>> Dan >>>>>>>=20 >>>>>>> On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek >>>>>>> wrote: >>>>>>> I agree with Richard - there are countries where both the emergency >>>>>>> service of the national police and the emergency service of the >>>>>>> municipal police are offered in a given location. >>>>>>> A user would call the municipal police emergency service to report = e.g. >>>>>>> pickpockets. >>>>>>> A user would call the national police emergency service to report e= .g. a >>>>>>> murder. >>>>>>> =20 >>>>>>> =20 >>>>>>> I submitted to IANA a request to register: >>>>>>> - urn:service:sos.police.local - The 'police.local' service refers = to >>>>>>> the emergency service offered by the police department or other law >>>>>>> enforcement authorities of the local or municipal authorities. >>>>>>> - urn:service:sos.police.national - The 'police.national' service r= efers >>>>>>> to the emergency service offered by the police department or other = law >>>>>>> enforcement authorities of the national government. >>>>>>> =20 >>>>>>> RFC5031 policy is hopefully fulfilled for them since they exist in = two >>>>>>> countries. >>>>>>> =20 >>>>>>> I am flexible whether the actual URNs contain the sub-services prop= osed >>>>>>> above (i.e. .local and .national sub-services) or subservices based= on >>>>>>> RFC4119 (i.e. .A3 and .country sub-services). >>>>>>> =20 >>>>>>> If the preference is for subservices based on RFC4119, do I need to= make >>>>>>> another IANA registration request or can we modify the URNs and the= ir >>>>>>> description during the expert review? >>>>>>> =20 >>>>>>> Kind regards >>>>>>> =20 >>>>>>> Ivo Sedlacek >>>>>>> =20 >>>>>>> This Communication is Confidential. We only send and receive email = on >>>>>>> the basis of the terms set out at www.ericsson.com/email_disclaimer >>>>>>> >>>>>>> From: Dan Mongrain [mailto:dan@mongrain.org] >>>>>>> Sent: 19. =FAnora 2013 15:36 >>>>>>> To: Winterbottom, James >>>>>>> Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org >>>>>>> Subject: Re: [Ecrit] What is the most appropriate method for regist= ering >>>>>>> new sub-services of urn:service:sos >>>>>>> =20 >>>>>>> The problem is that different countries has different names for the= ir >>>>>>> political subdivisions. In the US they are states, in Canada they = are >>>>>>> provinces, etc. Same when you further subdivide. While not privy = to >>>>>>> the discussions that came up with A1, A2, =8A, A5, I have the feeling= this >>>>>>> nomenclature was picked for the same reason. Why not utilise the s= ame >>>>>>> naming scheme for specifying the jurisdiction you want to reach? >>>>>>> =20 >>>>>>> Thanx, >>>>>>> Dan >>>>>>> =20 >>>>>>>=20 >>>>>>> On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James >>>>>>> wrote: >>>>>>> In that case, one might say state in the hierarchy, not A1. >>>>>>> =20 >>>>>>> Cheers >>>>>>> James >>>>>>> =20 >>>>>>> =20 >>>>>>> From: Richard Barnes [mailto:rlb@ipv.sx] >>>>>>> Sent: Tuesday, 19 February 2013 8:57 AM >>>>>>> To: Winterbottom, James >>>>>>> Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org >>>>>>>=20 >>>>>>> Subject: Re: [Ecrit] What is the most appropriate method for regist= ering >>>>>>> new sub-services of urn:service:sos >>>>>>> =20 >>>>>>> It might make sense if you wanted to allow the caller to explicitly >>>>>>> select police at a different level of responsibility, e.g., the sta= te >>>>>>> police rather than the local police. >>>>>>> =20 >>>>>>>=20 >>>>>>> On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James >>>>>>> wrote: >>>>>>> I think I am missing something here, A1 is part of the location, so= why >>>>>>> does it need to be in the URN at all? >>>>>>> As far as I understand current deployments, they use the URN to sel= ect a >>>>>>> layer in the GIS that corresponds to the service type, and then use >>>>>>> geographic boundaries within that layer to select the final destina= tion. >>>>>>> =20 >>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Beh= alf >>>>>>> Of Dan Mongrain >>>>>>> Sent: Tuesday, 19 February 2013 7:30 AM >>>>>>>=20 >>>>>>> To: Ivo Sedlacek >>>>>>> Cc: ecrit@ietf.org >>>>>>> Subject: Re: [Ecrit] What is the most appropriate method for regist= ering >>>>>>> new sub-services of urn:service:sos >>>>>>> =20 >>>>>>> Sorry for responding late to this thread, it kinda fell into a cra= ck=8A >>>>>>> The current thread reminded me to check this old thread=8A >>>>>>> =20 >>>>>>> You are indicating that we need to register 77 Service URN (11 serv= ice >>>>>>> subtypes * 7 jurisdiction types based on RFC 4119). I do not recom= mend >>>>>>> that we create so many registrations. Instead, we should allow a >>>>>>> service URN to be suffixed with a jurisdictional scope. So the >>>>>>> following Service URN are all valid: >>>>>>> =20 >>>>>>> urn:service:sos.police >>>>>>> urn:service:sos.police.traffic >>>>>>> urn:service:sos.police.A1 >>>>>>> urn:service:sos.police.traffic.A1 >>>>>>> =20 >>>>>>> Question is, do we want to leave jurisdictional scope to only be >>>>>>> applicable to police branch or any Service URN? I=B9d say the latter= as >>>>>>> it is always up to the LoST service provisioning (based on local po= licy) >>>>>>> to determine what is locally acceptable. >>>>>>> =20 >>>>>>> Thanx, >>>>>>> Dan >>>>>>> =20 >>>>>>> =20 >>>>>>> =20 >>>>>>>=20 >>>>>>> _______________________________________________ Ecrit mailing list >>>>>>> Ecrit@ietf.orghttps://www.ietf.org/mailman/listinfo/ecrit >>>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >=20 --B_3444221710_1723703 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Not sure I agree with your s= ummation.  In your example, .sos IS the proper way to call .fire.  = ;Just because .sos is also the proper way to call .police is irrelevant.

Maybe it would be best to use a DNS-like approach. &nb= sp;No record =3D 'not found'.  No ambiguity this way.  Populate .sos= and .sos.fire and .sos.police all with the same uri if that is the response= you want.  If request is for .sos.help and the jurisdiction doesn't su= pport .help, the response is 'not found'.  Why try to guess what was re= quested?

-Marc-


=

From: Dan Mongrain <dan@mongrain.org>
Date: Wednesday, February 20, 2013 3:32 PM
To: Marc Linsner <mlinsner@cisco.com>
Cc= : "Rosen, Brian" <Brian.= Rosen@neustar.biz>, "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] What is the most appropria= te method for registering new sub-services of urn:service:sos (trimming due = too large message report)

We should not infer anything from missing information esp= ecially if this information is optional (as my previous message shows). = ; Doing anything else is misleading at best.  Requester makes a request= specifying desired service nothing more.  You may ask for sos.fire, bu= t you are getting sos as you cannot call .fire directly, local policy. = If you do not like the answer, try again if you want with a different servi= ce (same service request will give same response back).

Dan

On Wed, Feb 20, 2013 at 3:16 PM, Marc Linsner <mlinsner@ci= sco.com> wrote:
What if = I don't want A2 (I don't trust Butler County sheriff), if no A3 (Mars) give = me A1 (PA)?

What I proposed allows the requestor to= tailor the request to match his desire.

The fallba= ck is multiple requests.

-Marc-

From: "Rosen, Brian"= <Brian.Rosen@ne= ustar.biz>
Date: Wednesday,= February 20, 2013 2:56 PM
To: Mar= c Linsner <mlinsner@c= isco.com>
Cc: Dan Mongrain = <dan@mongrain.org&g= t;, "ecrit@ietf.org" <= ;ecrit@ietf.org>
<= span style=3D"font-weight:bold">Subject: Re: [Ecrit] What is the most = appropriate method for registering new sub-services of urn:service:sos (trim= ming due too large message report)

To me, this doesn't make sense.

= Suppose I have a local police department in cities, but a provincial police = department in rural areas, as well as a national police.  I ask for sos= .police.A3.  If location was in a city, I should get sos.police.A3

But if I was in a rural area, a request for sos.police.= A3 should return a response of sos.police.A2.

That = may or may not be the same as sos.police

Brian

On Feb 20, 2013, at 2:47 PM, Marc Linsner <mlinsner@cisco.com> wrote:<= /div>
I understood you as requesting urn= :service:sos.police.A4.

My point was that if the Lo= ST service had no entry for A4, it could simply check the Ax tree submitted = in the location section of the request.  So if the location included A1= & A4, the LoST service, finding nothing for A4 would then check A1 (not= A3 or A2).  This way the service would be matching the hierarchy of th= e given location vs. an arbitrary hierarchy that may be different from the r= equestors desire.

Carry on…

-Marc-

From: Dan Mongrain <dan@mongrain.org>
Date: Wednesday, February 20, 2013 12:30 PM
To: Marc Linsner <mlinsner@cisco.com>
Cc: "Winterbottom, James" <James.Winterbottom@commscope.com&g= t;, "ecrit@ietf.org" <= ;ecrit@ietf.org>
<= span style=3D"font-weight:bold">Subject: Re: [Ecrit] What is the most = appropriate method for registering new sub-services of urn:service:sos (trim= ming due too large message report)

I do not understand your comment.  What I am proposing is that request= s do not specify a search pattern in the case a requested jurisdiction is no= t found.  It should not be to the requester which submits urn:ser= vice:sos.police.country.A1.A2.A3.A4 to specify what to do if there is nothin= g configured for the A4 layer.  It must be up to the LoST service to ap= ply whatever policy it has in this case.  If we allow this, then do we = allow urn:service:sos.police.fire?  Give me fire first but if not found= give me police?

The Service URN should specify the "desired" service= in a findService request and the LoST service provides a response based on = local policies.  All I am proposing is that one can specify a jurisdict= ion in the case there are more then one service provider for a location.
=
Thanx,
Dan

On Wed, Feb 20, 201= 3 at 8:48 AM, Marc Linsner <mlinsner@cisco.com> wrote:
The findService request includes locat= ion information.  Why wouldn't the LoST server simple walk the A1-A6 tr= ee included with the location?  If location is geo, reverse geocode it.=

What am I missing?

-Marc-=

From: Dan Mongrain <dan= @mongrain.org>
Date: Tuesda= y, February 19, 2013 11:55 PM
To: = "Winterbottom, James" <James.Winterbottom@commscope.com>
Cc: "= ecrit@ietf.org" <ecri= t@ietf.org>
Subject: Re: [E= crit] What is the most appropriate method for registering new sub-services o= f urn:service:sos (trimming due too large message report)

=
What I meant is that if a jurisdictional scope aware LoST service receives = a request for urn:service:sos.police.A4 and nothing is configured, it looks = for urn:service:sos.police.A3 then urn:service:sos.police.A2, etc. until it = finds a configured service.  If nothing is found for urn:service:sos.po= lice.country then it pops the last element and looks for urn:service:sos.pol= ice (but then again, it is no longer jurisdictional scope aware).

I d= isagree that one needs to formulate the request as urn:service:sos.police.co= untry.A1.A2.A3.A4 in order for this to happen.  There must be only a si= ngle jurisdictional scope appended to a Service URN.

I do not think w= e need a .A6 jurisdictional scope (street level).  .A5 (neighborhood, w= ould point to a precinct for example) provides enough granularity in my opin= ion.

Thanx,
Dan


On Tue, Feb 19= , 2013 at 11:29 PM, Winterbottom, James <James.Winterbottom@commsco= pe.com> wrote:
I am sorry, I am finding this confusing.
 
RFC5139 puts a hierarchy on A1 through A6. If you w= ant this hierarchy to work then A1 through A6 can’t be at the same lev= el if you expect A3 to fallback to A2 or A1 in the case of a service not exi= sting or a service failure of some kind. If they exist at the same level the= n if A3 doesn’t exist you will go to urn:service:sos.police  unle= ss you impose the hierarchy in the urn.
 
 
 
 
 
From: Dan Mong= rain [mailto:dan@mongrain.= org]
Sent: Wednesday, 20 February 2013 3:23 PM
To: = DRAGE, Keith (Keith)
Cc: Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org
Subject:<= /b> Re: [Ecrit] What is the most appropriate method for registering new sub-= services of urn:service:sos (trimming due too large message report)
 

My recommendation for handlin= g unknown Service URN depends if LoST service implements jurisdictional scop= e or not.  If it does not, it pops the last element and evaluates until= a service is found.  If it implements jurisdictional scope, the last e= lement is a jurisdictional scope and it is not found, then you return the ne= xt highest level defined.

While it may be true that citizens typicall= y dial 9-1-1 to request for help, police services such as state or provincia= l polices advertises numbers to call them directly (star code to dial using = a mobile phone for example) especially to report accidents on freeways. = ; We need an equivalent Service URN.

Also while RFC5031's scope is ci= tizen to authorities (I am not sure I agree with this) I do not want to re-i= nvent the wheel to signal calls within an Emergency Services IP Network (ESI= net).  When I transfer a call from one PSAP to another, the mechanism t= o determine where to send the call is the same, using LoST.  For a PSAP= that covers a large area spanning multiple counties and the calltaker needs= to transfer the call to the appropriate sheriff department for the caller's= location, they only need a single transfer target (urn:service:sos.police.A= 2).  It is not true that the calltaker always knows the actual destinat= ion of the call, especially when the calltaker is only a call screener.
<= br>Thanx,
Dan

On Tue, Feb 19= , 2013 at 7:18 PM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote= :
The answer to= James’s question depends on how you code it (and also what you mean b= y fallback).
 
On any service URN, you ignore= any subtypes from the point you stop understanding it.
 <= /span>
<= span style=3D"font-size: 10pt; color: navy; font-family: Arial, sans-serif; " = lang=3D"EN-GB">So if the coding is sos.police.A2, and you do not understand A2= , then the service URN would be handled as if it was sos.police, not as sos.= police.A1. And if police was not understood then it would be handled as sos.=
=  
If you wanted something that went back to = the next larger regional coverage, then you would have to code successive su= btypes in sequence.
 <= /u>
But I would also ask fo= r an element of sanity in this discussion, rather than total flexibility.
 
For example while a national administration m= ay have multiple levels of police force, not all of them are either reachabl= e directly as an emergency service provider, nor are they necessarily an eme= rgency service provider. If they are neither of these, then they presumably = do not need a special and distinct service URN.
 <= span lang=3D"EN-GB">
It would therefore nice to see a current use case that is anything but= a choice of two, i.e. countrywide (following the ITU-T E.164 definition of = country) versus one more local variant. This restricted model certainly cove= rs Ivo’s examples of Czeck Republic and Poland, and I believe it also = covers the other example I know of which is Italy.=
 
While the USA has multiple levels of police force, on the PSTN, it o= nly appears to have one level of access to citizen to authority emergency se= rvice, which is 911. I see no reason why a change to voice over IP would cau= se a change to this.
 =
I would also stress th= at it is important to have global expectations of what you get when you use = a service URN. If there is not care excercised with assigning semantics and = values, A3 in one country could result in the forestry police and in another= country the financial police responding.
 
N= ote that read the scope of RFC 5031 as being for end user accessing the emer= gency service. While it might be possible to apply RFC 5031 to further netwo= rk operations after the PSAP has been reached, e.g. to reach a subsidiary PS= AP, I read that as outside the scope of RFC 5031. Nor do I necessarily belie= ve in that scenario that service URNs are necessarily the best solution for = routeing, as the first PSAP should know the particular office they want to r= each rather than just the type of emergency service.
 
Regards
 
Keith
 =
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behal= f Of Winterbottom, James
Sent: 19 February 2013 23:29
To= : Ivo Sedlacek; Dan Mongrain
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] What is= the most appropriate method for registering new sub-services of urn:service= :sos (trimming due too large message report)
 <= u>
I am okay wi= th this, providing that the fallback order is clearly defined.
That is, does an A3 fall back to an A2 or A1, or just back to sos?
 
 
 
From: Ivo Sedlacek = [mailto:ivo.sedla= cek@ericsson.com]
Sent: Wednesday, 20 February 2013 7:32 AMTo: Dan Mongrain
Cc: Winterbottom, James; Richard Barnes;= ecrit@ietf.org
Su= bject: RE: [Ecrit] What is the most appropriate method for registering n= ew sub-services of urn:service:sos (trimming due too large message report)
 
Hello,<= /div>
 =
If we go with RF= C4119 based sub-services, would the IANA registration request be as follows?=
=  
- urn:service:sos.police.A3 - Th= e 'police.local' service refers to the emergency service offered by the poli= ce department or other law enforcement authorities of the authorities <= u>of a city, township, shi (JP).=
- urn:service:sos.police= .country - The 'police.national' service refers to the emergency se= rvice offered by the police department or other law enforcement authorities = of the government of a country.=
 
D= oes anyone see any issue in that?
 
If WG prefe= rs this, it is OK for me.
 
> In the latter cas= e, so how do I get the county police (or state police, there can be up to 4 = police services for a given location in the US). 
 
If I got it correctly, you propose that we also add
= - urn:service:sos.police.A2 - The 'police.local' service refers to th= e emergency service offered by the police department or other law enforcemen= t authorities of the authorities of county, parish, gun (JP), distri= ct (IN)"
- urn:service:sos.police.A1 - The 'police.lo= cal' service refers to the emergency service offered by the police departmen= t or other law enforcement authorities of the authorities of nationa= l subdivisions (state, region, province, prefecture)"
 =
= While I have no problem with that, I am not aware of a regulati= on establishing such emergency service so I cannot argue to IANA that the RF= C5031 policy is satisfied for those URNs.
 
Kin= d regards
 <= /div>
Ivo Sedlacek
 
&nbs= p;
 
 
This Communication is Confidenti= al. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer
From: Dan = Mongrain [mailto:dan@mongr= ain.org]
Sent: 19. =FAnora 2013 21:12
To: Ivo Sedlace= k
Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: Re: [Ecrit] W= hat is the most appropriate method for registering new sub-services of urn:s= ervice:sos (trimming due too large message report)=
 <= u>
Thing is, when there is no city polic= e, local would give you county police (sheriff department) but in a city wit= h a city police department local would give you city police.  In the la= tter case, so how do I get the county police (or state police, there can be = up to 4 police services for a given location in the US).  Note that the= se examples are US based, but we do have 3 levels of police services in Cana= da and I am sure other countries have the same issue.
 

There is also the terminology.  There is no "national" police in the U= S or Canada but there is a federal police.  Keeping the RFC 4119 termin= ology removes any "local" interpretation issues.

Dan

On Tue, Feb 19, 2013 = at 2:31 PM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:
I agree with = Richard - there are countries where both the emergency service of the nation= al police and the emergency service of the municipal police are offered in a= given location.
A user would call the municipal police emergen= cy service to report e.g. pickpockets.
A user would call the nat= ional police emergency service to report e.g. a murder.
 
 
I submitted to IANA a request to register:
- urn:service:sos.police.local - The 'police.local' service refers = to the emergency service offered by the police department or other law enfor= cement authorities of the local or municipal authorities.
- urn:= service:sos.police.national - The 'police.national' service refers to the em= ergency service offered by the police department or other law enforcement au= thorities of the national government.
 
RFC5031= policy is hopefully fulfilled for them since they exist in two countries.
 
I am flexible whether the actual URNs contain = the sub-services proposed above (i.e. .local and .national sub-services) or = subservices based on RFC4119 (i.e. .A3 and .country sub-services).
If the preference is for subservices based on RFC4119,= do I need to make another IANA registration request or can we modify the UR= Ns and their description during the expert review?=
 =
Kind regards
 
Ivo Sedlacek
&= nbsp;
This Communication is Confidential. We only send and receive= email on the basis of the terms set out at www.ericsson.com/email_disclaimer <= /u>
From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19. =FAnora 2013 15:36
To: Winterbottom, James
Cc: Richa= rd Barnes; Ivo Sedlacek; ecr= it@ietf.org
Subject: Re: [Ecrit] What is the most appropriate = method for registering new sub-services of urn:service:sos
 
The = problem is that different countries has different names for their political = subdivisions.  In the US they are states, in Canada they are provinces,= etc.  Same when you further subdivide.  While not privy to the di= scussions that came up with A1, A2, …, A5, I have the feeling this nom= enclature was picked for the same reason.  Why not utilise the same nam= ing scheme for specifying the jurisdiction you want to reach?
=  
Thanx,
Dan

 

On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James <James.Winterbottom@commsco= pe.com> wrote:
In that case, one might say state in the h= ierarchy, not A1.
 
Cheers
Ja= mes
 
 
From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Tue= sday, 19 February 2013 8:57 AM
To: Winterbottom, James
Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org

Subject: Re: [Ecrit] What is the most a= ppropriate method for registering new sub-services of urn:service:sos
 
It might make sense if you wanted to allow the caller to explicitly sel= ect police at a different level of responsibility, e.g., the state police ra= ther than the local police.  

 

On Mon, F= eb 18, 2013 at 4:21 PM, Winterbottom, James <James.Winterbottom@commscope.com&g= t; wrote:
I think I am missing something here, A1 is part of the= location, so why does it need to be in the URN at all?
As far= as I understand current deployments, they use the URN to select a layer in = the GIS that corresponds to the service type, and then use geographic bounda= ries within that layer to select the final destination.
 =
Fr= om:ecrit-bounces@ie= tf.org [mailto:e= crit-bounces@ietf.org] On Behalf Of Dan Mongrain
Sent: = Tuesday, 19 February 2013 7:30 AM

To: Ivo Sedlacek
Cc:<= /b> ecrit@ietf.org
Subject: Re: [Ecrit] What is the most appropriate method for registerin= g new sub-services of urn:service:sos
 <= /u>
Sorry for respo= nding late to this thread, it kinda fell into a  crack…  The= current thread reminded me to check this old thread…
&n= bsp;
You are indicating that we need to register 77 Service UR= N (11 service subtypes * 7 jurisdiction types based on RFC 4119).  I do= not recommend that we create so many registrations.  Instead, we shoul= d allow a service URN to be suffixed with a jurisdictional scope.  So t= he following Service URN are all valid:<= /u>
 
u= rn:service:sos.police
urn:service:sos.police.traffic
urn:service:sos.police.A1
urn:service:sos.police.traffic.= A1
 
=
Question is, do we want to leave juris= dictional scope to only be applicable to police branch or any Service URN? &= nbsp;I’d say the latter as it is always up to the LoST service provisi= oning (based on local policy) to determine what is locally acceptable.
 
Thanx,=
Dan
 
 
=
 

_______________________________________________ Ecrit mailing list Ecrit@ietf.orghttps://www.iet= f.org/mailman/listinfo/ecrit

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


--B_3444221710_1723703-- From ngwilcox@gmail.com Wed Feb 20 14:03:06 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63EC021E805A for ; Wed, 20 Feb 2013 14:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.372 X-Spam-Level: X-Spam-Status: No, score=0.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_36=0.6, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPXCfGxOaynC for ; Wed, 20 Feb 2013 14:03:00 -0800 (PST) Received: from mail-ia0-x229.google.com (ia-in-x0229.1e100.net [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7586C21E804B for ; Wed, 20 Feb 2013 14:02:59 -0800 (PST) Received: by mail-ia0-f169.google.com with SMTP id j5so7672827iaf.14 for ; Wed, 20 Feb 2013 14:02:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=KYSXJ6/SQvPoeai9O6qIA5H1NiXtb4lsOSLNzTFPQ40=; b=w5sWLJ/pHLRcyc5K2NVm1kh00x2fug/zaE9T5mJ79L/ErOGUTlLhjeq9TJSwKEnV5J f6MfBKc9z5QXCFlqk+UjawQrT7fv/fHBtfKgir7mN1X3+jFhsLL/81u8/MctQUphBg+s 5c/Xpx7jLMyZ23upo3MBMBrgCc8I6siqClvKixs2oJrqTUCbxn/h4gscyHhpseMRdAo1 Sdj5YfY+FdOgGSC8P+SFSGXiWxPGlcIrJYNnv4fVhVlUMspi1hmZq/m/CG1H1vrjCbO+ caJ7LouWGODHqfA3tkJ65vSXnb4IL8KajwXonZrOuILVfJjGqu6bpyhxrkV+tWW/qgLp H3gQ== X-Received: by 10.50.156.133 with SMTP id we5mr1862166igb.51.1361397779001; Wed, 20 Feb 2013 14:02:59 -0800 (PST) Received: from [192.168.6.48] (ip-64-134-162-22.public.wayport.net. [64.134.162.22]) by mx.google.com with ESMTPS id ur12sm17253624igb.8.2013.02.20.14.02.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Feb 2013 14:02:58 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_4614DE82-715A-49AE-BC05-8ACABE3B96CE" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Nathan Wilcox In-Reply-To: Date: Wed, 20 Feb 2013 16:02:55 -0600 Message-Id: References: To: Marc Linsner X-Mailer: Apple Mail (2.1499) Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 22:03:06 -0000 --Apple-Mail=_4614DE82-715A-49AE-BC05-8ACABE3B96CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 +1 On Feb 20, 2013, at 3:15 PM, Marc Linsner wrote: > Not sure I agree with your summation. In your example, .sos IS the = proper way to call .fire. Just because .sos is also the proper way to = call .police is irrelevant. >=20 > Maybe it would be best to use a DNS-like approach. No record =3D 'not = found'. No ambiguity this way. Populate .sos and .sos.fire and = .sos.police all with the same uri if that is the response you want. If = request is for .sos.help and the jurisdiction doesn't support .help, the = response is 'not found'. Why try to guess what was requested? >=20 > -Marc- >=20 >=20 >=20 > From: Dan Mongrain > Date: Wednesday, February 20, 2013 3:32 PM > To: Marc Linsner > Cc: "Rosen, Brian" , "ecrit@ietf.org" = > Subject: Re: [Ecrit] What is the most appropriate method for = registering new sub-services of urn:service:sos (trimming due too large = message report) >=20 >> We should not infer anything from missing information especially if = this information is optional (as my previous message shows). Doing = anything else is misleading at best. Requester makes a request = specifying desired service nothing more. You may ask for sos.fire, but = you are getting sos as you cannot call .fire directly, local policy. If = you do not like the answer, try again if you want with a different = service (same service request will give same response back). >>=20 >> Dan >>=20 >> On Wed, Feb 20, 2013 at 3:16 PM, Marc Linsner = wrote: >>> What if I don't want A2 (I don't trust Butler County sheriff), if no = A3 (Mars) give me A1 (PA)? >>>=20 >>> What I proposed allows the requestor to tailor the request to match = his desire. >>>=20 >>> The fallback is multiple requests. >>>=20 >>> -Marc- >>>=20 >>> From: "Rosen, Brian" >>> Date: Wednesday, February 20, 2013 2:56 PM >>> To: Marc Linsner >>> Cc: Dan Mongrain , "ecrit@ietf.org" = >>> Subject: Re: [Ecrit] What is the most appropriate method for = registering new sub-services of urn:service:sos (trimming due too large = message report) >>>=20 >>>> To me, this doesn't make sense. >>>>=20 >>>> Suppose I have a local police department in cities, but a = provincial police department in rural areas, as well as a national = police. I ask for sos.police.A3. If location was in a city, I should = get sos.police.A3 >>>>=20 >>>> But if I was in a rural area, a request for sos.police.A3 should = return a response of sos.police.A2. >>>>=20 >>>> That may or may not be the same as sos.police >>>>=20 >>>> Brian >>>>=20 >>>> On Feb 20, 2013, at 2:47 PM, Marc Linsner = wrote: >>>>=20 >>>>> I understood you as requesting urn:service:sos.police.A4. >>>>>=20 >>>>> My point was that if the LoST service had no entry for A4, it = could simply check the Ax tree submitted in the location section of the = request. So if the location included A1 & A4, the LoST service, finding = nothing for A4 would then check A1 (not A3 or A2). This way the service = would be matching the hierarchy of the given location vs. an arbitrary = hierarchy that may be different from the requestors desire. >>>>>=20 >>>>> Carry on=85 >>>>>=20 >>>>> -Marc- >>>>>=20 >>>>> From: Dan Mongrain >>>>> Date: Wednesday, February 20, 2013 12:30 PM >>>>> To: Marc Linsner >>>>> Cc: "Winterbottom, James" , = "ecrit@ietf.org" >>>>> Subject: Re: [Ecrit] What is the most appropriate method for = registering new sub-services of urn:service:sos (trimming due too large = message report) >>>>>=20 >>>>>> I do not understand your comment. What I am proposing is that = requests do not specify a search pattern in the case a requested = jurisdiction is not found. It should not be to the requester which = submits urn:service:sos.police.country.A1.A2.A3.A4 to specify what to do = if there is nothing configured for the A4 layer. It must be up to the = LoST service to apply whatever policy it has in this case. If we allow = this, then do we allow urn:service:sos.police.fire? Give me fire first = but if not found give me police? >>>>>>=20 >>>>>> The Service URN should specify the "desired" service in a = findService request and the LoST service provides a response based on = local policies. All I am proposing is that one can specify a = jurisdiction in the case there are more then one service provider for a = location. >>>>>>=20 >>>>>> Thanx, >>>>>> Dan >>>>>>=20 >>>>>> On Wed, Feb 20, 2013 at 8:48 AM, Marc Linsner = wrote: >>>>>>> The findService request includes location information. Why = wouldn't the LoST server simple walk the A1-A6 tree included with the = location? If location is geo, reverse geocode it. >>>>>>>=20 >>>>>>> What am I missing? >>>>>>>=20 >>>>>>> -Marc- >>>>>>>=20 >>>>>>> From: Dan Mongrain >>>>>>> Date: Tuesday, February 19, 2013 11:55 PM >>>>>>> To: "Winterbottom, James" >>>>>>> Cc: "ecrit@ietf.org" >>>>>>> Subject: Re: [Ecrit] What is the most appropriate method for = registering new sub-services of urn:service:sos (trimming due too large = message report) >>>>>>>=20 >>>>>>>> What I meant is that if a jurisdictional scope aware LoST = service receives a request for urn:service:sos.police.A4 and nothing is = configured, it looks for urn:service:sos.police.A3 then = urn:service:sos.police.A2, etc. until it finds a configured service. If = nothing is found for urn:service:sos.police.country then it pops the = last element and looks for urn:service:sos.police (but then again, it is = no longer jurisdictional scope aware). >>>>>>>>=20 >>>>>>>> I disagree that one needs to formulate the request as = urn:service:sos.police.country.A1.A2.A3.A4 in order for this to happen. = There must be only a single jurisdictional scope appended to a Service = URN. >>>>>>>>=20 >>>>>>>> I do not think we need a .A6 jurisdictional scope (street = level). .A5 (neighborhood, would point to a precinct for example) = provides enough granularity in my opinion. >>>>>>>>=20 >>>>>>>> Thanx, >>>>>>>> Dan >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Tue, Feb 19, 2013 at 11:29 PM, Winterbottom, James = wrote: >>>>>>>>> I am sorry, I am finding this confusing. >>>>>>>>> =20 >>>>>>>>> RFC5139 puts a hierarchy on A1 through A6. If you want this = hierarchy to work then A1 through A6 can=92t be at the same level if you = expect A3 to fallback to A2 or A1 in the case of a service not existing = or a service failure of some kind. If they exist at the same level then = if A3 doesn=92t exist you will go to urn:service:sos.police unless you = impose the hierarchy in the urn. >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> From: Dan Mongrain [mailto:dan@mongrain.org]=20 >>>>>>>>> Sent: Wednesday, 20 February 2013 3:23 PM >>>>>>>>> To: DRAGE, Keith (Keith) >>>>>>>>> Cc: Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org >>>>>>>>> Subject: Re: [Ecrit] What is the most appropriate method for = registering new sub-services of urn:service:sos (trimming due too large = message report) >>>>>>>>> =20 >>>>>>>>> My recommendation for handling unknown Service URN depends if = LoST service implements jurisdictional scope or not. If it does not, it = pops the last element and evaluates until a service is found. If it = implements jurisdictional scope, the last element is a jurisdictional = scope and it is not found, then you return the next highest level = defined. >>>>>>>>>=20 >>>>>>>>> While it may be true that citizens typically dial 9-1-1 to = request for help, police services such as state or provincial polices = advertises numbers to call them directly (star code to dial using a = mobile phone for example) especially to report accidents on freeways. = We need an equivalent Service URN. >>>>>>>>>=20 >>>>>>>>> Also while RFC5031's scope is citizen to authorities (I am not = sure I agree with this) I do not want to re-invent the wheel to signal = calls within an Emergency Services IP Network (ESInet). When I transfer = a call from one PSAP to another, the mechanism to determine where to = send the call is the same, using LoST. For a PSAP that covers a large = area spanning multiple counties and the calltaker needs to transfer the = call to the appropriate sheriff department for the caller's location, = they only need a single transfer target (urn:service:sos.police.A2). It = is not true that the calltaker always knows the actual destination of = the call, especially when the calltaker is only a call screener. >>>>>>>>>=20 >>>>>>>>> Thanx, >>>>>>>>> Dan >>>>>>>>>=20 >>>>>>>>> On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) = wrote: >>>>>>>>> The answer to James=92s question depends on how you code it = (and also what you mean by fallback). >>>>>>>>> =20 >>>>>>>>> On any service URN, you ignore any subtypes from the point you = stop understanding it. >>>>>>>>> =20 >>>>>>>>> So if the coding is sos.police.A2, and you do not understand = A2, then the service URN would be handled as if it was sos.police, not = as sos.police.A1. And if police was not understood then it would be = handled as sos. >>>>>>>>> =20 >>>>>>>>> If you wanted something that went back to the next larger = regional coverage, then you would have to code successive subtypes in = sequence. >>>>>>>>> =20 >>>>>>>>> But I would also ask for an element of sanity in this = discussion, rather than total flexibility. >>>>>>>>> =20 >>>>>>>>> For example while a national administration may have multiple = levels of police force, not all of them are either reachable directly as = an emergency service provider, nor are they necessarily an emergency = service provider. If they are neither of these, then they presumably do = not need a special and distinct service URN. >>>>>>>>> =20 >>>>>>>>> It would therefore nice to see a current use case that is = anything but a choice of two, i.e. countrywide (following the ITU-T = E.164 definition of country) versus one more local variant. This = restricted model certainly covers Ivo=92s examples of Czeck Republic and = Poland, and I believe it also covers the other example I know of which = is Italy. >>>>>>>>> =20 >>>>>>>>> While the USA has multiple levels of police force, on the = PSTN, it only appears to have one level of access to citizen to = authority emergency service, which is 911. I see no reason why a change = to voice over IP would cause a change to this. >>>>>>>>> =20 >>>>>>>>> I would also stress that it is important to have global = expectations of what you get when you use a service URN. If there is not = care excercised with assigning semantics and values, A3 in one country = could result in the forestry police and in another country the financial = police responding. >>>>>>>>> =20 >>>>>>>>> Note that read the scope of RFC 5031 as being for end user = accessing the emergency service. While it might be possible to apply RFC = 5031 to further network operations after the PSAP has been reached, e.g. = to reach a subsidiary PSAP, I read that as outside the scope of RFC = 5031. Nor do I necessarily believe in that scenario that service URNs = are necessarily the best solution for routeing, as the first PSAP should = know the particular office they want to reach rather than just the type = of emergency service. >>>>>>>>> =20 >>>>>>>>> Regards >>>>>>>>> =20 >>>>>>>>> Keith >>>>>>>>> =20 >>>>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] = On Behalf Of Winterbottom, James >>>>>>>>> Sent: 19 February 2013 23:29 >>>>>>>>> To: Ivo Sedlacek; Dan Mongrain >>>>>>>>> Cc: ecrit@ietf.org >>>>>>>>> Subject: Re: [Ecrit] What is the most appropriate method for = registering new sub-services of urn:service:sos (trimming due too large = message report) >>>>>>>>> =20 >>>>>>>>> I am okay with this, providing that the fallback order is = clearly defined. >>>>>>>>> That is, does an A3 fall back to an A2 or A1, or just back to = sos? >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com]=20 >>>>>>>>> Sent: Wednesday, 20 February 2013 7:32 AM >>>>>>>>> To: Dan Mongrain >>>>>>>>> Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org >>>>>>>>> Subject: RE: [Ecrit] What is the most appropriate method for = registering new sub-services of urn:service:sos (trimming due too large = message report) >>>>>>>>> =20 >>>>>>>>> Hello, >>>>>>>>> =20 >>>>>>>>> If we go with RFC4119 based sub-services, would the IANA = registration request be as follows? >>>>>>>>> =20 >>>>>>>>> - urn:service:sos.police.A3 - The 'police.local' service = refers to the emergency service offered by the police department or = other law enforcement authorities of the authorities of a city, = township, shi (JP). >>>>>>>>> - urn:service:sos.police.country - The 'police.national' = service refers to the emergency service offered by the police department = or other law enforcement authorities of the government of a country. >>>>>>>>> =20 >>>>>>>>> Does anyone see any issue in that? >>>>>>>>> =20 >>>>>>>>> If WG prefers this, it is OK for me. >>>>>>>>> =20 >>>>>>>>> > In the latter case, so how do I get the county police (or = state police, there can be up to 4 police services for a given location = in the US).=20 >>>>>>>>> =20 >>>>>>>>> If I got it correctly, you propose that we also add >>>>>>>>> - urn:service:sos.police.A2 - The 'police.local' service = refers to the emergency service offered by the police department or = other law enforcement authorities of the authorities of county, parish, = gun (JP), district (IN)" >>>>>>>>> - urn:service:sos.police.A1 - The 'police.local' service = refers to the emergency service offered by the police department or = other law enforcement authorities of the authorities of national = subdivisions (state, region, province, prefecture)" >>>>>>>>> =20 >>>>>>>>> While I have no problem with that, I am not aware of a = regulation establishing such emergency service so I cannot argue to IANA = that the RFC5031 policy is satisfied for those URNs. >>>>>>>>> =20 >>>>>>>>> Kind regards >>>>>>>>> =20 >>>>>>>>> Ivo Sedlacek >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> This Communication is Confidential. We only send and receive = email on the basis of the terms set out at = www.ericsson.com/email_disclaimer >>>>>>>>> From: Dan Mongrain [mailto:dan@mongrain.org]=20 >>>>>>>>> Sent: 19. =FAnora 2013 21:12 >>>>>>>>> To: Ivo Sedlacek >>>>>>>>> Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org >>>>>>>>> Subject: Re: [Ecrit] What is the most appropriate method for = registering new sub-services of urn:service:sos (trimming due too large = message report) >>>>>>>>> =20 >>>>>>>>> Thing is, when there is no city police, local would give you = county police (sheriff department) but in a city with a city police = department local would give you city police. In the latter case, so how = do I get the county police (or state police, there can be up to 4 police = services for a given location in the US). Note that these examples are = US based, but we do have 3 levels of police services in Canada and I am = sure other countries have the same issue. >>>>>>>>> =20 >>>>>>>>> There is also the terminology. There is no "national" police = in the US or Canada but there is a federal police. Keeping the RFC 4119 = terminology removes any "local" interpretation issues. >>>>>>>>>=20 >>>>>>>>> Dan >>>>>>>>>=20 >>>>>>>>> On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek = wrote: >>>>>>>>> I agree with Richard - there are countries where both the = emergency service of the national police and the emergency service of = the municipal police are offered in a given location. >>>>>>>>> A user would call the municipal police emergency service to = report e.g. pickpockets. >>>>>>>>> A user would call the national police emergency service to = report e.g. a murder. >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> I submitted to IANA a request to register: >>>>>>>>> - urn:service:sos.police.local - The 'police.local' service = refers to the emergency service offered by the police department or = other law enforcement authorities of the local or municipal authorities. >>>>>>>>> - urn:service:sos.police.national - The 'police.national' = service refers to the emergency service offered by the police department = or other law enforcement authorities of the national government. >>>>>>>>> =20 >>>>>>>>> RFC5031 policy is hopefully fulfilled for them since they = exist in two countries. >>>>>>>>> =20 >>>>>>>>> I am flexible whether the actual URNs contain the sub-services = proposed above (i.e. .local and .national sub-services) or subservices = based on RFC4119 (i.e. .A3 and .country sub-services). >>>>>>>>> =20 >>>>>>>>> If the preference is for subservices based on RFC4119, do I = need to make another IANA registration request or can we modify the URNs = and their description during the expert review? >>>>>>>>> =20 >>>>>>>>> Kind regards >>>>>>>>> =20 >>>>>>>>> Ivo Sedlacek >>>>>>>>> =20 >>>>>>>>> This Communication is Confidential. We only send and receive = email on the basis of the terms set out at = www.ericsson.com/email_disclaimer >>>>>>>>> From: Dan Mongrain [mailto:dan@mongrain.org]=20 >>>>>>>>> Sent: 19. =FAnora 2013 15:36 >>>>>>>>> To: Winterbottom, James >>>>>>>>> Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org >>>>>>>>> Subject: Re: [Ecrit] What is the most appropriate method for = registering new sub-services of urn:service:sos >>>>>>>>> =20 >>>>>>>>> The problem is that different countries has different names = for their political subdivisions. In the US they are states, in Canada = they are provinces, etc. Same when you further subdivide. While not = privy to the discussions that came up with A1, A2, =85, A5, I have the = feeling this nomenclature was picked for the same reason. Why not = utilise the same naming scheme for specifying the jurisdiction you want = to reach? >>>>>>>>> =20 >>>>>>>>> Thanx, >>>>>>>>> Dan >>>>>>>>> =20 >>>>>>>>>=20 >>>>>>>>> On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James = wrote: >>>>>>>>> In that case, one might say state in the hierarchy, not A1. >>>>>>>>> =20 >>>>>>>>> Cheers >>>>>>>>> James >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> From: Richard Barnes [mailto:rlb@ipv.sx]=20 >>>>>>>>> Sent: Tuesday, 19 February 2013 8:57 AM >>>>>>>>> To: Winterbottom, James >>>>>>>>> Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org >>>>>>>>>=20 >>>>>>>>> Subject: Re: [Ecrit] What is the most appropriate method for = registering new sub-services of urn:service:sos >>>>>>>>> =20 >>>>>>>>> It might make sense if you wanted to allow the caller to = explicitly select police at a different level of responsibility, e.g., = the state police rather than the local police. =20 >>>>>>>>> =20 >>>>>>>>>=20 >>>>>>>>> On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James = wrote: >>>>>>>>> I think I am missing something here, A1 is part of the = location, so why does it need to be in the URN at all? >>>>>>>>> As far as I understand current deployments, they use the URN = to select a layer in the GIS that corresponds to the service type, and = then use geographic boundaries within that layer to select the final = destination. >>>>>>>>> =20 >>>>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] = On Behalf Of Dan Mongrain >>>>>>>>> Sent: Tuesday, 19 February 2013 7:30 AM >>>>>>>>>=20 >>>>>>>>> To: Ivo Sedlacek >>>>>>>>> Cc: ecrit@ietf.org >>>>>>>>> Subject: Re: [Ecrit] What is the most appropriate method for = registering new sub-services of urn:service:sos >>>>>>>>> =20 >>>>>>>>> Sorry for responding late to this thread, it kinda fell into a = crack=85 The current thread reminded me to check this old thread=85 >>>>>>>>> =20 >>>>>>>>> You are indicating that we need to register 77 Service URN (11 = service subtypes * 7 jurisdiction types based on RFC 4119). I do not = recommend that we create so many registrations. Instead, we should = allow a service URN to be suffixed with a jurisdictional scope. So the = following Service URN are all valid: >>>>>>>>> =20 >>>>>>>>> urn:service:sos.police >>>>>>>>> urn:service:sos.police.traffic >>>>>>>>> urn:service:sos.police.A1 >>>>>>>>> urn:service:sos.police.traffic.A1 >>>>>>>>> =20 >>>>>>>>> Question is, do we want to leave jurisdictional scope to only = be applicable to police branch or any Service URN? I=92d say the latter = as it is always up to the LoST service provisioning (based on local = policy) to determine what is locally acceptable. >>>>>>>>> =20 >>>>>>>>> Thanx, >>>>>>>>> Dan >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>> =20 >>>>>>>>=20 >>>>>>>> _______________________________________________ Ecrit mailing = list Ecrit@ietf.orghttps://www.ietf.org/mailman/listinfo/ecrit >>>>>>=20 >>>>> _______________________________________________ >>>>> 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 --Apple-Mail=_4614DE82-715A-49AE-BC05-8ACABE3B96CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 mlinsner@cisco.com> = wrote:
Not sure I agree with your = summation.  In your example, .sos IS the proper way to call .fire. =  Just because .sos is also the proper way to call .police is = irrelevant.

Maybe it would be best to use a = DNS-like approach.  No record =3D 'not found'.  No ambiguity = this way.  Populate .sos and .sos.fire and .sos.police all with the = same uri if that is the response you want.  If request is for = .sos.help and the jurisdiction doesn't support .help, the response is = 'not found'.  Why try to guess what was = requested?

-Marc-



From: Dan Mongrain <dan@mongrain.org>
Date: Wednesday, February 20, 2013 = 3:32 PM
To: Marc Linsner = <mlinsner@cisco.com>
Cc: "Rosen, Brian" <Brian.Rosen@neustar.biz>, = "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] What is the most = appropriate method for registering new sub-services of urn:service:sos = (trimming due too large message = report)

We should not infer anything from missing = information especially if this information is optional (as my previous = message shows).  Doing anything else is misleading at best.  = Requester makes a request specifying desired service nothing more.  = You may ask for sos.fire, but you are getting sos as you cannot call = .fire directly, local policy.  If you do not like the answer, try = again if you want with a different service (same service request will = give same response back).

Dan

On = Wed, Feb 20, 2013 at 3:16 PM, Marc Linsner <mlinsner@cisco.com> = wrote:
What if I don't want A2 (I don't trust Butler County sheriff), = if no A3 (Mars) give me A1 (PA)?

What I = proposed allows the requestor to tailor the request to match his = desire.

The fallback is multiple = requests.

-Marc-

From: "Rosen, Brian" <Brian.Rosen@neustar.biz>
Date: Wednesday, February 20, 2013 = 2:56 PM
To: Marc Linsner = <mlinsner@cisco.com>
Cc: Dan Mongrain <dan@mongrain.org>, "ecrit@ietf.org" = <ecrit@ietf.org>
Subject: Re: [Ecrit] What is the most = appropriate method for registering new sub-services of urn:service:sos = (trimming due too large message = report)

To me, this doesn't make = sense.

Suppose I have a local police department in = cities, but a provincial police department in rural areas, as well as a = national police.  I ask for sos.police.A3.  If location was in = a city, I should get sos.police.A3

But if I was = in a rural area, a request for sos.police.A3 should return a response of = sos.police.A2.

That may or may not be the same = as sos.police

Brian

On = Feb 20, 2013, at 2:47 PM, Marc Linsner <mlinsner@cisco.com> wrote:

I understood you as requesting = urn:service:sos.police.A4.

My point was that if = the LoST service had no entry for A4, it could simply check the Ax tree = submitted in the location section of the request.  So if the = location included A1 & A4, the LoST service, finding nothing for A4 = would then check A1 (not A3 or A2).  This way the service would be = matching the hierarchy of the given location vs. an arbitrary hierarchy = that may be different from the requestors = desire.

Carry = on=85

-Marc-

From: Dan Mongrain <dan@mongrain.org>
Date: Wednesday, February 20, 2013 = 12:30 PM
To: Marc Linsner = <mlinsner@cisco.com>
Cc: "Winterbottom, James" <James.Winterbottom@commscope.com>, "ecrit@ietf.org" = <ecrit@ietf.org>
Subject: Re: [Ecrit] What is the most = appropriate method for registering new sub-services of urn:service:sos = (trimming due too large message = report)

I do not understand your comment.  What I am proposing is that = requests do not specify a search pattern in the case a requested = jurisdiction is not found.  It should not be to the requester which = submits urn:service:sos.police.country.A1.A2.A3.A4 to specify what = to do if there is nothing configured for the A4 layer.  It must be = up to the LoST service to apply whatever policy it has in this = case.  If we allow this, then do we allow = urn:service:sos.police.fire?  Give me fire first but if not found = give me police?

The Service URN should specify the "desired" = service in a findService request and the LoST service provides a = response based on local policies.  All I am proposing is that one = can specify a jurisdiction in the case there are more then one service = provider for a location.

Thanx,
Dan

On Wed, Feb 20, 2013 at 8:48 AM, Marc Linsner = <mlinsner@cisco.com> = wrote:
The findService request includes location information.  Why = wouldn't the LoST server simple walk the A1-A6 tree included with the = location?  If location is geo, reverse geocode = it.

What am I = missing?

-Marc-

From: Dan Mongrain <dan@mongrain.org>
Date: Tuesday, February 19, 2013 = 11:55 PM
To: "Winterbottom, = James" <James.Winterbottom@commscope.com>
Cc: "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] What is the most = appropriate method for registering new sub-services of urn:service:sos = (trimming due too large message = report)

What I meant is that if a jurisdictional scope aware LoST service = receives a request for urn:service:sos.police.A4 and nothing is = configured, it looks for urn:service:sos.police.A3 then = urn:service:sos.police.A2, etc. until it finds a configured = service.  If nothing is found for urn:service:sos.police.country = then it pops the last element and looks for urn:service:sos.police (but = then again, it is no longer jurisdictional scope aware).

I = disagree that one needs to formulate the request as = urn:service:sos.police.country.A1.A2.A3.A4 in order for this to = happen.  There must be only a single jurisdictional scope appended = to a Service URN.

I do not think we need a .A6 jurisdictional = scope (street level).  .A5 (neighborhood, would point to a precinct = for example) provides enough granularity in my = opinion.

Thanx,
Dan


On = Tue, Feb 19, 2013 at 11:29 PM, Winterbottom, James <James.Winterbottom@commscope.com> = wrote:
I am sorry, I am finding this = confusing.
 
RFC5139 puts a hierarchy on A1 = through A6. If you want this hierarchy to work then A1 through A6 can=92t = be at the same level if you expect A3 to fallback to A2 or A1 in the = case of a service not existing or a service failure of some kind. If = they exist at the same level then if A3 doesn=92t exist you will go to = urn:service:sos.police  unless you impose the hierarchy in the = urn.
 
 
 
From: Dan = Mongrain [mailto:dan@mongrain.org]
Sent: Wednesday, 20 = February 2013 3:23 PM
To: DRAGE, Keith (Keith)
Cc: = Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org
Subject: Re: [Ecrit] What = is the most appropriate method for registering new sub-services of = urn:service:sos (trimming due too large message = report)
 

My recommendation for handling unknown = Service URN depends if LoST service implements jurisdictional scope or = not.  If it does not, it pops the last element and evaluates until = a service is found.  If it implements jurisdictional scope, the = last element is a jurisdictional scope and it is not found, then you = return the next highest level defined.

While it may be true that = citizens typically dial 9-1-1 to request for help, police services such = as state or provincial polices advertises numbers to call them directly = (star code to dial using a mobile phone for example) especially to = report accidents on freeways.  We need an equivalent Service = URN.

Also while RFC5031's scope is citizen to authorities (I am = not sure I agree with this) I do not want to re-invent the wheel to = signal calls within an Emergency Services IP Network (ESInet).  = When I transfer a call from one PSAP to another, the mechanism to = determine where to send the call is the same, using LoST.  For a = PSAP that covers a large area spanning multiple counties and the = calltaker needs to transfer the call to the appropriate sheriff = department for the caller's location, they only need a single transfer = target (urn:service:sos.police.A2).  It is not true that the = calltaker always knows the actual destination of the call, especially = when the calltaker is only a call = screener.

Thanx,
Dan

On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith = (Keith) <keith.drage@alcatel-lucent.com> = wrote:
The answer to James=92s question depends on how you code = it (and also what you mean by fallback).
 
On any service URN, you ignore any subtypes from the = point you stop understanding it.
 
So if the coding is sos.police.A2, and you do not = understand A2, then the service URN would be handled as if it was = sos.police, not as sos.police.A1. And if police was not understood then = it would be handled as sos.
 
If you wanted something that went back to the next larger = regional coverage, then you would have to code successive subtypes in = sequence.
 
But I would also ask for an element of sanity in this = discussion, rather than total flexibility.
 
For example while a national administration may have = multiple levels of police force, not all of them are either reachable = directly as an emergency service provider, nor are they necessarily an = emergency service provider. If they are neither of these, then they = presumably do not need a special and distinct service URN.
 
It would therefore nice to see a current use case that is = anything but a choice of two, i.e. countrywide (following the ITU-T = E.164 definition of country) versus one more local variant. This = restricted model certainly covers Ivo=92s examples of Czeck Republic and = Poland, and I believe it also covers the other example I know of which = is Italy.
 
While the USA has multiple levels of police force, on the = PSTN, it only appears to have one level of access to citizen to = authority emergency service, which is 911. I see no reason why a change = to voice over IP would cause a change to this.
 
I would also stress that it is important to have global = expectations of what you get when you use a service URN. If there is not = care excercised with assigning semantics and values, A3 in one country = could result in the forestry police and in another country the financial = police responding.
 
Note that read the scope of RFC 5031 as being for end = user accessing the emergency service. While it might be possible to = apply RFC 5031 to further network operations after the PSAP has been = reached, e.g. to reach a subsidiary PSAP, I read that as outside the = scope of RFC 5031. Nor do I necessarily believe in that scenario that = service URNs are necessarily the best solution for routeing, as the = first PSAP should know the particular office they want to reach rather = than just the type of emergency service.
 
Regards
 
Keith
 
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of = Winterbottom, James
Sent: 19 February 2013 = 23:29
To: Ivo Sedlacek; Dan Mongrain
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] What = is the most appropriate method for registering new sub-services of = urn:service:sos (trimming due too large message report)
 
I am okay with this, providing = that the fallback order is clearly defined.
That is, does an A3 fall back to an A2 or A1, or just back = to sos?
 
 
 
From: Ivo = Sedlacek [mailto:ivo.sedlacek@ericsson.com]
Sent: = Wednesday, 20 February 2013 7:32 AM
To: Dan = Mongrain
Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: RE: [Ecrit] What = is the most appropriate method for registering new sub-services of = urn:service:sos (trimming due too large message report)
 
Hello,
 
If we go with RFC4119 based sub-services, would the IANA = registration request be as follows?
 
- urn:service:sos.police.A3 - The = 'police.local' service refers to the emergency service offered by the = police department or other law enforcement authorities of the = authorities of a city, township, shi (JP).
- urn:service:sos.police.country - The = 'police.national' service refers to the emergency service offered by the = police department or other law enforcement authorities of the = government of a country.
 
Does anyone see any issue in that?
 
If WG prefers this, it is OK for me.
 
> In the latter case, so how do I get the county = police (or state police, there can be up to 4 police services for a = given location in the US). 
 
If I got it correctly, you propose that we also add =
- = urn:service:sos.police.A2 - The 'police.local' service refers to = the emergency service offered by the police department or other law = enforcement authorities of the authorities of county, parish, = gun (JP), district (IN)"
- urn:service:sos.police.A1 - The 'police.local' = service refers to the emergency service offered by the police department = or other law enforcement authorities of the authorities of = national subdivisions (state, region, province, = prefecture)"
 
While I have no problem with that, I am not aware of a = regulation establishing such emergency service so I cannot argue to IANA = that the RFC5031 policy is satisfied for those URNs.
 
Kind regards
 
Ivo Sedlacek
 
 
 
 
This Communication is Confidential. We only send and = receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer
From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19. = =FAnora 2013 21:12
To: Ivo Sedlacek
Cc: = Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: Re: [Ecrit] What = is the most appropriate method for registering new sub-services of = urn:service:sos (trimming due too large message report)
 
Thing is, = when there is no city police, local would give you county police = (sheriff department) but in a city with a city police department local = would give you city police.  In the latter case, so how do I get = the county police (or state police, there can be up to 4 police services = for a given location in the US).  Note that these examples are US = based, but we do have 3 levels of police services in Canada and I am = sure other countries have the same issue.
 

There is also the terminology.  There is no "national" police in = the US or Canada but there is a federal police.  Keeping the RFC = 4119 terminology removes any "local" interpretation = issues.

Dan

On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:
I agree with Richard - there are = countries where both the emergency service of the national police and = the emergency service of the municipal police are offered in a given = location.
A user would call the municipal = police emergency service to report e.g. pickpockets.
A user would call the national police emergency service to = report e.g. a murder.
 
 
I submitted to IANA a request to register:
- urn:service:sos.police.local - The 'police.local' = service refers to the emergency service offered by the police department = or other law enforcement authorities of the local or municipal = authorities.
- urn:service:sos.police.national = - The 'police.national' service refers to the emergency service offered = by the police department or other law enforcement authorities of the = national government.
 
RFC5031 policy is hopefully fulfilled for them since they = exist in two countries.
 
I am flexible whether the actual URNs contain the = sub-services proposed above (i.e. .local and .national sub-services) or = subservices based on RFC4119 (i.e. .A3 and .country = sub-services).
 
If the preference is for subservices based on RFC4119, do = I need to make another IANA registration request or can we modify the = URNs and their description during the expert review?
 
Kind regards
 
Ivo Sedlacek
 
This Communication is Confidential. We only send and = receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer
From: Dan Mongrain [mailto:dan@mongrain.org] =
Sent: 19. =FAnora 2013 15:36
To: Winterbottom, = James
Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org
Subject: Re: [Ecrit] What = is the most appropriate method for registering new sub-services of = urn:service:sos
 
The problem is that different countries has different = names for their political subdivisions.  In the US they are states, = in Canada they are provinces, etc.  Same when you further = subdivide.  While not privy to the discussions that came up with = A1, A2, =85, A5, I have the feeling this nomenclature was picked for the = same reason.  Why not utilise the same naming scheme for specifying = the jurisdiction you want to reach?
 
Thanx,
Dan
 

On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James = <James.Winterbottom@commscope.com> wrote:
In that case, one might say = state in the hierarchy, not A1.
 
Cheers
James
 
 
From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Tuesday, 19 February = 2013 8:57 AM
To: Winterbottom, James
Cc: Dan = Mongrain; Ivo Sedlacek; ecrit@ietf.org

Subject: Re: [Ecrit] What is the most = appropriate method for registering new sub-services of = urn:service:sos
 
It might make sense if you wanted to allow the = caller to explicitly select police at a different level of = responsibility, e.g., the state police rather than the local police. =  

 

On = Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James <James.Winterbottom@commscope.com> wrote:
I think I am missing something = here, A1 is part of the location, so why does it need to be in the URN = at all?
As far as I understand current = deployments, they use the URN to select a layer in the GIS that = corresponds to the service type, and then use geographic boundaries = within that layer to select the final destination.
 
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Dan = Mongrain
Sent: Tuesday, 19 February 2013 7:30 AM

To: Ivo Sedlacek
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] What = is the most appropriate method for registering new sub-services of = urn:service:sos
 
Sorry for responding late to this thread, it kinda fell = into a  crack=85  The current thread reminded me to check this = old thread=85
 
You are indicating that we need to register 77 Service URN = (11 service subtypes * 7 jurisdiction types based on RFC 4119).  I = do not recommend that we create so many registrations.  Instead, we = should allow a service URN to be suffixed with a jurisdictional = scope.  So the following Service URN are all valid:
 
urn:service:sos.police
urn:service:sos.police.traffic
urn:service:sos.police.A1
urn:service:sos.police.traffic.A1
 
Question is, do we want to leave jurisdictional scope to = only be applicable to police branch or any Service URN?  I=92d say = the latter as it is always up to the LoST service provisioning (based on = local policy) to determine what is locally acceptable.
 
Thanx,
Dan
 
 
 
_______________________________________________ Ecrit mailing list Ecrit@ietf.orghttps://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=_4614DE82-715A-49AE-BC05-8ACABE3B96CE-- From rlb@ipv.sx Wed Feb 20 15:25:14 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA67821E8037 for ; Wed, 20 Feb 2013 15:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmnmRP9Crx2W for ; Wed, 20 Feb 2013 15:25:11 -0800 (PST) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCFB21E8049 for ; Wed, 20 Feb 2013 15:25:10 -0800 (PST) Received: by mail-oa0-f43.google.com with SMTP id l10so8652927oag.30 for ; Wed, 20 Feb 2013 15:25:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=JWRrx+XeU4ttkuhESXyfpe2Zczfpf0/JlUq/A7IiwYE=; b=JVaB7u7pCio6RBYUPgA1siiNOV7rdE8tQ6Z2tw/1EGeN7KJNeLkZkPcFEAcNMJiFRi PKOWLmq6lSDg6rR3pvAm2K6xuImFdIsg7qfe1Q5CtpxRz1lGSKX3wxWXBuuJrU50Orok gn9zcD25cnQjGOlsTw0lOLg7BVU3K6LJLdMxMlVJ1bauh4CP7T7gmQFBhKXVzmzWzob9 6bh3leoU3w7eP+Zt3MSzisXbfD+5HzMOVYeHvbdyNyKM3HFhCNj5mPgHQklzGqHRo6Nq /ccTZcDgk+Ahzgz5bJGKwzaH9yo6DwufbhHPi7CKxc91ypfg9XoswCWbuLoBAE1Bnp4R H8tA== MIME-Version: 1.0 X-Received: by 10.60.171.5 with SMTP id aq5mr10473670oec.38.1361402710175; Wed, 20 Feb 2013 15:25:10 -0800 (PST) Received: by 10.60.60.98 with HTTP; Wed, 20 Feb 2013 15:25:10 -0800 (PST) X-Originating-IP: [50.59.37.123] In-Reply-To: References: Date: Wed, 20 Feb 2013 18:25:10 -0500 Message-ID: From: Richard Barnes To: Nathan Wilcox Content-Type: multipart/alternative; boundary=bcaec5523dccefb09904d6304445 X-Gm-Message-State: ALoCoQkSw8koqEmQmi3Co4aaOFhLMwd4QVLur8R04Y7iYNgRUFJfi86DwmmOvJn42P//QMvpY+HG Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 23:25:15 -0000 --bcaec5523dccefb09904d6304445 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yes. This. My first reaction to these suggestions of chaining was "It's a provisioning problem -- just put the same contact information under all those URNs." On Wed, Feb 20, 2013 at 5:02 PM, Nathan Wilcox wrote: > +1 > > On Feb 20, 2013, at 3:15 PM, Marc Linsner wrote: > > Not sure I agree with your summation. In your example, .sos IS the prope= r > way to call .fire. Just because .sos is also the proper way to call > .police is irrelevant. > > Maybe it would be best to use a DNS-like approach. No record =3D 'not > found'. No ambiguity this way. Populate .sos and .sos.fire and > .sos.police all with the same uri if that is the response you want. If > request is for .sos.help and the jurisdiction doesn't support .help, the > response is 'not found'. Why try to guess what was requested? > > -Marc- > > > > From: Dan Mongrain > Date: Wednesday, February 20, 2013 3:32 PM > To: Marc Linsner > Cc: "Rosen, Brian" , "ecrit@ietf.org" < > ecrit@ietf.org> > Subject: Re: [Ecrit] What is the most appropriate method for registering > new sub-services of urn:service:sos (trimming due too large message repor= t) > > We should not infer anything from missing information especially if this > information is optional (as my previous message shows). Doing anything > else is misleading at best. Requester makes a request specifying desired > service nothing more. You may ask for sos.fire, but you are getting sos = as > you cannot call .fire directly, local policy. If you do not like the > answer, try again if you want with a different service (same service > request will give same response back). > > Dan > > On Wed, Feb 20, 2013 at 3:16 PM, Marc Linsner wrote: > >> What if I don't want A2 (I don't trust Butler County sheriff), if no A3 >> (Mars) give me A1 (PA)? >> >> What I proposed allows the requestor to tailor the request to match his >> desire. >> >> The fallback is multiple requests. >> >> -Marc- >> >> From: "Rosen, Brian" >> Date: Wednesday, February 20, 2013 2:56 PM >> To: Marc Linsner >> Cc: Dan Mongrain , "ecrit@ietf.org" >> Subject: Re: [Ecrit] What is the most appropriate method for registering >> new sub-services of urn:service:sos (trimming due too large message repo= rt) >> >> To me, this doesn't make sense. >> >> Suppose I have a local police department in cities, but a provincial >> police department in rural areas, as well as a national police. I ask f= or >> sos.police.A3. If location was in a city, I should get sos.police.A3 >> >> But if I was in a rural area, a request for sos.police.A3 should return = a >> response of sos.police.A2. >> >> That may or may not be the same as sos.police >> >> Brian >> >> On Feb 20, 2013, at 2:47 PM, Marc Linsner wrote: >> >> I understood you as requesting urn:service:sos.police.A4. >> >> My point was that if the LoST service had no entry for A4, it could >> simply check the Ax tree submitted in the location section of the reques= t. >> So if the location included A1 & A4, the LoST service, finding nothing = for >> A4 would then check A1 (not A3 or A2). This way the service would be >> matching the hierarchy of the given location vs. an arbitrary hierarchy >> that may be different from the requestors desire. >> >> Carry on=85 >> >> -Marc- >> >> From: Dan Mongrain >> Date: Wednesday, February 20, 2013 12:30 PM >> To: Marc Linsner >> Cc: "Winterbottom, James" , " >> ecrit@ietf.org" >> Subject: Re: [Ecrit] What is the most appropriate method for registering >> new sub-services of urn:service:sos (trimming due too large message repo= rt) >> >> I do not understand your comment. What I am proposing is that requests >> do not specify a search pattern in the case a requested jurisdiction is = not >> found. It should not be to the requester which submits urn:service:sos.= police.country.A1.A2.A3.A4 >> to specify what to do if there is nothing configured for the A4 layer. = It >> must be up to the LoST service to apply whatever policy it has in this >> case. If we allow this, then do we allow urn:service:sos.police.fire? >> Give me fire first but if not found give me police? >> >> The Service URN should specify the "desired" service in a findService >> request and the LoST service provides a response based on local policies= . >> All I am proposing is that one can specify a jurisdiction in the case th= ere >> are more then one service provider for a location. >> >> Thanx, >> Dan >> >> On Wed, Feb 20, 2013 at 8:48 AM, Marc Linsner wrote= : >> >>> The findService request includes location information. Why wouldn't th= e >>> LoST server simple walk the A1-A6 tree included with the location? If >>> location is geo, reverse geocode it. >>> >>> What am I missing? >>> >>> -Marc- >>> >>> From: Dan Mongrain >>> Date: Tuesday, February 19, 2013 11:55 PM >>> To: "Winterbottom, James" >>> Cc: "ecrit@ietf.org" >>> Subject: Re: [Ecrit] What is the most appropriate method for >>> registering new sub-services of urn:service:sos (trimming due too large >>> message report) >>> >>> What I meant is that if a jurisdictional scope aware LoST service >>> receives a request for urn:service:sos.police.A4 and nothing is configu= red, >>> it looks for urn:service:sos.police.A3 then urn:service:sos.police.A2, = etc. >>> until it finds a configured service. If nothing is found for >>> urn:service:sos.police.country then it pops the last element and looks = for >>> urn:service:sos.police (but then again, it is no longer jurisdictional >>> scope aware). >>> >>> I disagree that one needs to formulate the request as >>> urn:service:sos.police.country.A1.A2.A3.A4 in order for this to happen. >>> There must be only a single jurisdictional scope appended to a Service = URN. >>> >>> I do not think we need a .A6 jurisdictional scope (street level). .A5 >>> (neighborhood, would point to a precinct for example) provides enough >>> granularity in my opinion. >>> >>> Thanx, >>> Dan >>> >>> >>> On Tue, Feb 19, 2013 at 11:29 PM, Winterbottom, James < >>> James.Winterbottom@commscope.com> wrote: >>> >>>> I am sorry, I am finding this confusing.**** >>>> ** ** >>>> RFC5139 puts a hierarchy on A1 through A6. If you want this hierarchy >>>> to work then A1 through A6 can=92t be at the same level if you expect = A3 to >>>> fallback to A2 or A1 in the case of a service not existing or a servic= e >>>> failure of some kind. If they exist at the same level then if A3 doesn= =92t >>>> exist you will go to urn:service:sos.police unless you impose the >>>> hierarchy in the urn.**** >>>> ** ** >>>> ** ** >>>> ** ** >>>> ** ** >>>> ** ** >>>> *From:* Dan Mongrain [mailto:dan@mongrain.org] >>>> *Sent:* Wednesday, 20 February 2013 3:23 PM >>>> *To:* DRAGE, Keith (Keith) >>>> *Cc:* Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org >>>> *Subject:* Re: [Ecrit] What is the most appropriate method for >>>> registering new sub-services of urn:service:sos (trimming due too larg= e >>>> message report)**** >>>> ** ** >>>> >>>> My recommendation for handling unknown Service URN depends if LoST >>>> service implements jurisdictional scope or not. If it does not, it po= ps >>>> the last element and evaluates until a service is found. If it implem= ents >>>> jurisdictional scope, the last element is a jurisdictional scope and i= t is >>>> not found, then you return the next highest level defined. >>>> >>>> While it may be true that citizens typically dial 9-1-1 to request for >>>> help, police services such as state or provincial polices advertises >>>> numbers to call them directly (star code to dial using a mobile phone = for >>>> example) especially to report accidents on freeways. We need an equiv= alent >>>> Service URN. >>>> >>>> Also while RFC5031's scope is citizen to authorities (I am not sure I >>>> agree with this) I do not want to re-invent the wheel to signal calls >>>> within an Emergency Services IP Network (ESInet). When I transfer a c= all >>>> from one PSAP to another, the mechanism to determine where to send the= call >>>> is the same, using LoST. For a PSAP that covers a large area spanning >>>> multiple counties and the calltaker needs to transfer the call to the >>>> appropriate sheriff department for the caller's location, they only ne= ed a >>>> single transfer target (urn:service:sos.police.A2). It is not true th= at >>>> the calltaker always knows the actual destination of the call, especia= lly >>>> when the calltaker is only a call screener. >>>> >>>> Thanx, >>>> Dan**** >>>> On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) < >>>> keith.drage@alcatel-lucent.com> wrote:**** >>>> The answer to James=92s question depends on how you code it (and also >>>> what you mean by fallback).**** >>>> **** >>>> On any service URN, you ignore any subtypes from the point you stop >>>> understanding it.**** >>>> **** >>>> So if the coding is sos.police.A2, and you do not understand A2, then >>>> the service URN would be handled as if it was sos.police, not as >>>> sos.police.A1. And if police was not understood then it would be handl= ed as >>>> sos.**** >>>> **** >>>> If you wanted something that went back to the next larger regional >>>> coverage, then you would have to code successive subtypes in sequence.= * >>>> *** >>>> **** >>>> But I would also ask for an element of sanity in this discussion, >>>> rather than total flexibility.**** >>>> **** >>>> For example while a national administration may have multiple levels o= f >>>> police force, not all of them are either reachable directly as an emer= gency >>>> service provider, nor are they necessarily an emergency service provid= er. >>>> If they are neither of these, then they presumably do not need a speci= al >>>> and distinct service URN. **** >>>> **** >>>> It would therefore nice to see a current use case that is anything but >>>> a choice of two, i.e. countrywide (following the ITU-T E.164 definitio= n of >>>> country) versus one more local variant. This restricted model certainl= y >>>> covers Ivo=92s examples of Czeck Republic and Poland, and I believe it= also >>>> covers the other example I know of which is Italy.**** >>>> **** >>>> While the USA has multiple levels of police force, on the PSTN, it onl= y >>>> appears to have one level of access to citizen to authority emergency >>>> service, which is 911. I see no reason why a change to voice over IP w= ould >>>> cause a change to this.**** >>>> **** >>>> I would also stress that it is important to have global expectations o= f >>>> what you get when you use a service URN. If there is not care excercis= ed >>>> with assigning semantics and values, A3 in one country could result in= the >>>> forestry police and in another country the financial police responding= . >>>> **** >>>> **** >>>> Note that read the scope of RFC 5031 as being for end user accessing >>>> the emergency service. While it might be possible to apply RFC 5031 to >>>> further network operations after the PSAP has been reached, e.g. to re= ach a >>>> subsidiary PSAP, I read that as outside the scope of RFC 5031. Nor do = I >>>> necessarily believe in that scenario that service URNs are necessarily= the >>>> best solution for routeing, as the first PSAP should know the particul= ar >>>> office they want to reach rather than just the type of emergency servi= ce. >>>> **** >>>> **** >>>> Regards**** >>>> **** >>>> Keith**** >>>> **** >>>> ------------------------------ >>>> *From:* ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On >>>> Behalf Of *Winterbottom, James >>>> *Sent:* 19 February 2013 23:29 >>>> *To:* Ivo Sedlacek; Dan Mongrain >>>> *Cc:* ecrit@ietf.org >>>> *Subject:* Re: [Ecrit] What is the most appropriate method for >>>> registering new sub-services of urn:service:sos (trimming due too larg= e >>>> message report)**** >>>> **** >>>> I am okay with this, providing that the fallback order is clearly >>>> defined.**** >>>> That is, does an A3 fall back to an A2 or A1, or just back to sos?**** >>>> **** >>>> **** >>>> **** >>>> *From:* Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] >>>> *Sent:* Wednesday, 20 February 2013 7:32 AM >>>> *To:* Dan Mongrain >>>> *Cc:* Winterbottom, James; Richard Barnes; ecrit@ietf.org >>>> *Subject:* RE: [Ecrit] What is the most appropriate method for >>>> registering new sub-services of urn:service:sos (trimming due too larg= e >>>> message report)**** >>>> **** >>>> Hello,**** >>>> **** >>>> If we go with RFC4119 based sub-services, would the IANA registration >>>> request be as follows?**** >>>> **** >>>> - urn:service:sos.police*.A3* - The 'police.local' service refers to >>>> the emergency service offered by the police department or other law >>>> enforcement authorities of the authorities *of a city, township, shi >>>> (JP)*.**** >>>> - urn:service:sos.police*.country* - The 'police.national' service >>>> refers to the emergency service offered by the police department or ot= her >>>> law enforcement authorities of the government *of a country*.**** >>>> **** >>>> Does anyone see any issue in that?**** >>>> **** >>>> If WG prefers this, it is OK for me.**** >>>> **** >>>> > In the latter case, so how do I get the county police (or state >>>> police, there can be up to 4 police services for a given location in t= he >>>> US). **** >>>> **** >>>> If I got it correctly, you propose that we also add **** >>>> - urn:service:sos.police*.A2* - The 'police.local' service refers to >>>> the emergency service offered by the police department or other law >>>> enforcement authorities of the authorities *of county, parish, gun >>>> (JP), district (IN)*"**** >>>> - urn:service:sos.police*.A1* - The 'police.local' service refers to >>>> the emergency service offered by the police department or other law >>>> enforcement authorities of the authorities *of national subdivisions >>>> (state, region, province, prefecture)*"**** >>>> **** >>>> While I have no problem with that, I am not aware of a regulation >>>> establishing such emergency service so I cannot argue to IANA that the >>>> RFC5031 policy is satisfied for those URNs.**** >>>> **** >>>> Kind regards**** >>>> **** >>>> Ivo Sedlacek**** >>>> **** >>>> **** >>>> **** >>>> **** >>>> This Communication is Confidential. We only send and receive email on >>>> the basis of the terms set out at www.ericsson.com/email_disclaimer **= * >>>> * >>>> *From:* Dan Mongrain [mailto:dan@mongrain.org ] >>>> *Sent:* 19. =FAnora 2013 21:12 >>>> *To:* Ivo Sedlacek >>>> *Cc:* Winterbottom, James; Richard Barnes; ecrit@ietf.org >>>> *Subject:* Re: [Ecrit] What is the most appropriate method for >>>> registering new sub-services of urn:service:sos (trimming due too larg= e >>>> message report)**** >>>> **** >>>> Thing is, when there is no city police, local would give you county >>>> police (sheriff department) but in a city with a city police departmen= t >>>> local would give you city police. In the latter case, so how do I get= the >>>> county police (or state police, there can be up to 4 police services f= or a >>>> given location in the US). Note that these examples are US based, but= we >>>> do have 3 levels of police services in Canada and I am sure other coun= tries >>>> have the same issue.**** >>>> **** >>>> >>>> There is also the terminology. There is no "national" police in the U= S >>>> or Canada but there is a federal police. Keeping the RFC 4119 termino= logy >>>> removes any "local" interpretation issues. >>>> >>>> Dan**** >>>> On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek < >>>> ivo.sedlacek@ericsson.com> wrote:**** >>>> I agree with Richard - there are countries where both the emergency >>>> service of the national police and the emergency service of the munici= pal >>>> police are offered in a given location. **** >>>> A user would call the municipal police emergency service to report e.g= . >>>> pickpockets.**** >>>> A user would call the national police emergency service to report e.g. >>>> a murder.**** >>>> **** >>>> **** >>>> I submitted to IANA a request to register:**** >>>> - urn:service:sos.police.local - The 'police.local' service refers to >>>> the emergency service offered by the police department or other law >>>> enforcement authorities of the local or municipal authorities.**** >>>> - urn:service:sos.police.national - The 'police.national' service >>>> refers to the emergency service offered by the police department or ot= her >>>> law enforcement authorities of the national government.**** >>>> **** >>>> RFC5031 policy is hopefully fulfilled for them since they exist in two >>>> countries.**** >>>> **** >>>> I am flexible whether the actual URNs contain the sub-services propose= d >>>> above (i.e. .local and .national sub-services) or subservices based on >>>> RFC4119 (i.e. .A3 and .country sub-services).**** >>>> **** >>>> If the preference is for subservices based on RFC4119, do I need to >>>> make another IANA registration request or can we modify the URNs and t= heir >>>> description during the expert review?**** >>>> **** >>>> Kind regards**** >>>> **** >>>> Ivo Sedlacek**** >>>> **** >>>> This Communication is Confidential. We only send and receive email on >>>> the basis of the terms set out at www.ericsson.com/email_disclaimer **= * >>>> * >>>> *From:* Dan Mongrain [mailto:dan@mongrain.org] >>>> *Sent:* 19. =FAnora 2013 15:36 >>>> *To:* Winterbottom, James >>>> *Cc:* Richard Barnes; Ivo Sedlacek; ecrit@ietf.org >>>> *Subject:* Re: [Ecrit] What is the most appropriate method for >>>> registering new sub-services of urn:service:sos**** >>>> **** >>>> The problem is that different countries has different names for their >>>> political subdivisions. In the US they are states, in Canada they are >>>> provinces, etc. Same when you further subdivide. While not privy to = the >>>> discussions that came up with A1, A2, =85, A5, I have the feeling this >>>> nomenclature was picked for the same reason. Why not utilise the same >>>> naming scheme for specifying the jurisdiction you want to reach?**** >>>> **** >>>> Thanx,**** >>>> Dan**** >>>> >>>> **** >>>> On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James < >>>> James.Winterbottom@commscope.com> wrote:**** >>>> In that case, one might say state in the hierarchy, not A1.**** >>>> **** >>>> Cheers**** >>>> James**** >>>> **** >>>> **** >>>> *From:* Richard Barnes [mailto:rlb@ipv.sx] >>>> *Sent:* Tuesday, 19 February 2013 8:57 AM >>>> *To:* Winterbottom, James >>>> *Cc:* Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org**** >>>> >>>> *Subject:* Re: [Ecrit] What is the most appropriate method for >>>> registering new sub-services of urn:service:sos**** >>>> **** >>>> It might make sense if you wanted to allow the caller to explicitly >>>> select police at a different level of responsibility, e.g., the state >>>> police rather than the local police. **** >>>> >>>> **** >>>> On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James < >>>> James.Winterbottom@commscope.com> wrote:**** >>>> I think I am missing something here, A1 is part of the location, so wh= y >>>> does it need to be in the URN at all?**** >>>> As far as I understand current deployments, they use the URN to select >>>> a layer in the GIS that corresponds to the service type, and then use >>>> geographic boundaries within that layer to select the final destinatio= n. >>>> **** >>>> **** >>>> *From:* ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On >>>> Behalf Of *Dan Mongrain >>>> *Sent:* Tuesday, 19 February 2013 7:30 AM**** >>>> >>>> *To:* Ivo Sedlacek >>>> *Cc:* ecrit@ietf.org >>>> *Subject:* Re: [Ecrit] What is the most appropriate method for >>>> registering new sub-services of urn:service:sos**** >>>> **** >>>> Sorry for responding late to this thread, it kinda fell into a crack= =85 >>>> The current thread reminded me to check this old thread=85**** >>>> **** >>>> You are indicating that we need to register 77 Service URN (11 service >>>> subtypes * 7 jurisdiction types based on RFC 4119). I do not recommen= d >>>> that we create so many registrations. Instead, we should allow a serv= ice >>>> URN to be suffixed with a jurisdictional scope. So the following Serv= ice >>>> URN are all valid:**** >>>> **** >>>> urn:service:sos.police**** >>>> urn:service:sos.police.traffic**** >>>> urn:service:sos.police.A1**** >>>> urn:service:sos.police.traffic.A1**** >>>> **** >>>> Question is, do we want to leave jurisdictional scope to only be >>>> applicable to police branch or any Service URN? I=92d say the latter = as it >>>> is always up to the LoST service provisioning (based on local policy) = to >>>> determine what is locally acceptable.**** >>>> **** >>>> Thanx,**** >>>> Dan**** >>>> **** >>>> **** >>>> ** ** >>>> >>> >>> _______________________________________________ Ecrit mailing list >>> Ecrit@ietf.orghttps://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 > > --bcaec5523dccefb09904d6304445 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Yes. =A0This.

My first reaction to thes= e suggestions of chaining was "It's a provisioning problem -- just= put the same contact information under all those URNs."


On Wed, Feb 20, 2013 at 5:02 PM, Nathan = Wilcox <ngwilcox@gmail.com> wrote:
+1

=
On Feb 20, 2013, at 3:15 PM, Marc Linsner <mlinsner@cisco.com> wrote:

=
Not sure I agree with your summation. =A0In your example, .sos = IS the proper way to call .fire. =A0Just because .sos is also the proper wa= y to call .police is irrelevant.

Maybe it would be best to use a DNS-like approach. =A0N= o record =3D 'not found'. =A0No ambiguity this way. =A0Populate .so= s and .sos.fire and .sos.police all with the same uri if that is the respon= se you want. =A0If request is for .sos.help and the jurisdiction doesn'= t support .help, the response is 'not found'. =A0Why try to guess w= hat was requested?

-Marc-



From: Dan Mongrain <dan@mongrain.org>
Date: Wednesday, February 20, 2013 3:3= 2 PM
To: Marc Linsner <mlinsner@cisco.com>
Cc: "Rosen, Brian" <Brian.Rosen@neust= ar.biz>, "e= crit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] What is the m= ost appropriate method for registering new sub-services of urn:service:sos = (trimming due too large message report)

We should not infer anything from missing information especially if this in= formation is optional (as my previous message shows).=A0 Doing anything els= e is misleading at best.=A0 Requester makes a request specifying desired se= rvice nothing more.=A0 You may ask for sos.fire, but you are getting sos as= you cannot call .fire directly, local policy.=A0 If you do not like the an= swer, try again if you want with a different service (same service request = will give same response back).

Dan

On Wed, Feb 20, 2013 at 3:16 PM, = Marc Linsner <mlinsner@cisco.com> wrote:
What if I don't want A2 (I don't trust Butler County sh= eriff), if no A3 (Mars) give me A1 (PA)?

What I pr= oposed allows the requestor to tailor the request to match his desire.

The fallback is multiple requests.

=
-Marc-

From: "Rosen, Brian" <= ;Brian.Rosen@n= eustar.biz>
Date: Wednes= day, February 20, 2013 2:56 PM
To: Marc Linsner <mlinsner@cisco.com>
Cc: Dan Mongrain <dan@mongrain.org>, "ecrit@ietf.org" &l= t;ecrit@ietf.org>= ;
Subject: Re: [Ecrit] What is the m= ost appropriate method for registering new sub-services of urn:service:sos = (trimming due too large message report)

To me, this doesn't make sense.
Suppose I have a local police department in cities, but a p= rovincial police department in rural areas, as well as a national police. = =A0I ask for sos.police.A3. =A0If location was in a city, I should get sos.= police.A3

But if I was in a rural area, a request for sos.police.= A3 should return a response of sos.police.A2.

That= may or may not be the same as sos.police

Brian

On Feb 20, 2013, at 2:47 PM, Marc Linsner <mlinsner@cisco.com> wr= ote:

I understood you as requesting urn:service:sos.police.A4.
My point was that if the LoST service had no entry for A4, it = could simply check the Ax tree submitted in the location section of the req= uest. =A0So if the location included A1 & A4, the LoST service, finding= nothing for A4 would then check A1 (not A3 or A2). =A0This way the service= would be matching the hierarchy of the given location vs. an arbitrary hie= rarchy that may be different from the requestors desire.

Carry on=85

-Marc-
<= br>
From: Dan Mongrain <dan@mongrain.org>
Date: Wednesday, February 20, 2013 12:= 30 PM
To: Marc Linsner <mlinsner@cisco.com>
Cc: "Winterbottom, James" = <J= ames.Winterbottom@commscope.com>, "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] What is the m= ost appropriate method for registering new sub-services of urn:service:sos = (trimming due too large message report)

I do not understand your comment.=A0 What I am proposing is that requests d= o not specify a search pattern in the case a requested jurisdiction is not = found.=A0 It should not be to the requester which submits urn:service= :sos.police.country.A1.A2.A3.A4 to specify what to do if there is nothing c= onfigured for the A4 layer.=A0 It must be up to the LoST service to apply w= hatever policy it has in this case.=A0 If we allow this, then do we allow u= rn:service:sos.police.fire?=A0 Give me fire first but if not found give me = police?

The Service URN should specify the "desired" service in a fin= dService request and the LoST service provides a response based on local po= licies.=A0 All I am proposing is that one can specify a jurisdiction in the= case there are more then one service provider for a location.

Thanx,
Dan

On Wed, Feb 20, = 2013 at 8:48 AM, Marc Linsner <mlinsner@cisco.com> wrote:
The findService request includes location information. =A0Why w= ouldn't the LoST server simple walk the A1-A6 tree included with the lo= cation? =A0If location is geo, reverse geocode it.

What am I missing?

-Marc-

From: Dan Mongrain <dan@mongrain.org>
Date: Tuesday, February 19, 2013 11:55= PM
To: "Winterbottom, James"= ; <James.Winterbottom@commscope.com>
Cc: "ec= rit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] What is the m= ost appropriate method for registering new sub-services of urn:service:sos = (trimming due too large message report)

What I meant is that if a jurisdictional scope aware LoST service receives = a request for urn:service:sos.police.A4 and nothing is configured, it looks= for urn:service:sos.police.A3 then urn:service:sos.police.A2, etc. until i= t finds a configured service.=A0 If nothing is found for urn:service:sos.po= lice.country then it pops the last element and looks for urn:service:sos.po= lice (but then again, it is no longer jurisdictional scope aware).

I disagree that one needs to formulate the request as urn:service:sos.p= olice.country.A1.A2.A3.A4 in order for this to happen.=A0 There must be onl= y a single jurisdictional scope appended to a Service URN.

I do not = think we need a .A6 jurisdictional scope (street level).=A0 .A5 (neighborho= od, would point to a precinct for example) provides enough granularity in m= y opinion.

Thanx,
Dan


On Tue, Feb 19, 201= 3 at 11:29 PM, Winterbottom, James <James.Winterbottom@comm= scope.com> wrote:
I am sorry, I am find= ing this confusing.
=A0
RFC5139 puts a hierarchy on A1 through A6. If you wa= nt this hierarchy to work then A1 through A6 can=92t be at the same level i= f you expect A3 to fallback to A2 or A1 in the case of a service not existi= ng or a service failure of some kind. If they exist at the same level then = if A3 doesn=92t exist you will go to urn:service:sos.police=A0 unless you i= mpose the hierarchy in the urn.
=A0
=A0
=A0
=A0
=A0
<= div class=3D"MsoNormal"> From: Dan Mong= rain [mailto:dan@mong= rain.org]
Sent: Wednesday, 20 February 2013 3:23 PM
To: DRAGE, Keith= (Keith)
Cc: Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org
Subject: Re= : [Ecrit] What is the most appropriate method for registering new sub-servi= ces of urn:service:sos (trimming due too large message report)
=A0

My recommendation for handling unknown Ser= vice URN depends if LoST service implements jurisdictional scope or not.=A0= If it does not, it pops the last element and evaluates until a service is = found.=A0 If it implements jurisdictional scope, the last element is a juri= sdictional scope and it is not found, then you return the next highest leve= l defined.

While it may be true that citizens typically dial 9-1-1 to request for = help, police services such as state or provincial polices advertises number= s to call them directly (star code to dial using a mobile phone for example= ) especially to report accidents on freeways.=A0 We need an equivalent Serv= ice URN.

Also while RFC5031's scope is citizen to authorities (I am not sure= I agree with this) I do not want to re-invent the wheel to signal calls wi= thin an Emergency Services IP Network (ESInet).=A0 When I transfer a call f= rom one PSAP to another, the mechanism to determine where to send the call = is the same, using LoST.=A0 For a PSAP that covers a large area spanning mu= ltiple counties and the calltaker needs to transfer the call to the appropr= iate sheriff department for the caller's location, they only need a sin= gle transfer target (urn:service:sos.police.A2).=A0 It is not true that the= calltaker always knows the actual destination of the call, especially when= the calltaker is only a call screener.

Thanx,
Dan

On Tue, Fe= b 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com= > wrote:
The answer to James=92s question d= epends on how you code it (and also what you mean by fallback).
=A0<= u>
On any service URN, = you ignore any subtypes from the point you stop understanding it.
=A0<= u>
So if the coding is = sos.police.A2, and you do not understand A2, then the service URN would be = handled as if it was sos.police, not as sos.police.A1. And if police was no= t understood then it would be handled as sos.
=A0<= u>
If you wanted someth= ing that went back to the next larger regional coverage, then you would hav= e to code successive subtypes in sequence.
=A0<= u>
But I would also ask= for an element of sanity in this discussion, rather than total flexibility= .
=A0<= u>
For example while a = national administration may have multiple levels of police force, not all o= f them are either reachable directly as an emergency service provider, nor = are they necessarily an emergency service provider. If they are neither of = these, then they presumably do not need a special and distinct service URN.=
=A0<= u>
It would therefore n= ice to see a current use case that is anything but a choice of two, i.e. co= untrywide (following the ITU-T E.164 definition of country) versus one more= local variant. This restricted model certainly covers Ivo=92s examples of = Czeck Republic and Poland, and I believe it also covers the other example I= know of which is Italy.
=A0<= u>
While the USA has mu= ltiple levels of police force, on the PSTN, it only appears to have one lev= el of access to citizen to authority emergency service, which is 911. I see= no reason why a change to voice over IP would cause a change to this.
=A0<= u>
I would also stress = that it is important to have global expectations of what you get when you u= se a service URN. If there is not care excercised with assigning semantics = and values, A3 in one country could result in the forestry police and in an= other country the financial police responding.<= u>
=A0<= u>
Note that read the s= cope of RFC 5031 as being for end user accessing the emergency service. Whi= le it might be possible to apply RFC 5031 to further network operations aft= er the PSAP has been reached, e.g. to reach a subsidiary PSAP, I read that = as outside the scope of RFC 5031. Nor do I necessarily believe in that scen= ario that service URNs are necessarily the best solution for routeing, as t= he first PSAP should know the particular office they want to reach rather t= han just the type of emergency service.<= u>
=A0<= u>
Regards
=A0<= u>
Keith
=A0<= u>
=
From: ecrit-bounces@ietf.o= rg [mailto:= ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James
Sent: 19 February 2013 23:29
To: Ivo Sedlacek; Dan Mongrai= n
Cc: ecrit@i= etf.org
Subject: Re: [Ecrit] What is the most appropriate met= hod for registering new sub-services of urn:service:sos (trimming due too l= arge message report)
=A0
I am okay with this, providing that= the fallback order is clearly defined.<= u>
That is, does an A3 fall back to an A2 or = A1, or just back to sos?
=A0<= /u>
=A0
=A0<= /u>
From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com]
Sent: Wednesday, 20 February 2013 7:32 AM
To: Dan Mongrain=
Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: RE: [Ecr= it] What is the most appropriate method for registering new sub-services of= urn:service:sos (trimming due too large message report)
=A0=
Hello,
=A0
If we go with RFC4119 based su= b-services, would the IANA registration request be as follows?
=A0
- urn:service:sos.police.A3= =A0- The 'police.local' service refers to the emergency service= offered by the police department or other law enforcement authorities of t= he authorities=A0of a city, township, shi (JP).
- urn:service:sos.police.country=A0- = The 'police.national' service refers to the emergency service offer= ed by the police department or other law enforcement authorities of the gov= ernment=A0of a country.
=A0
Does anyone see any issue in t= hat?
=A0
If WG prefers this, it is OK f= or me.
=A0
> In the latter case, so how do I= get the county police (or state police, there can be up to 4 police servic= es for a given location in the US).=A0 <= u>
=A0
If I got it correctly, you pro= pose that we also add
- urn:service:sos.police.A2 - The = 9;police.local' service refers to the emergency service offered by the = police department or other law enforcement authorities of the authorities= =A0of county, parish, gun (JP), district (IN)"
- urn:service:sos.police.A1 - The = 9;police.local' service refers to the emergency service offered by the = police department or other law enforcement authorities of the authorities= =A0of national subdivisions (state, region, province, prefecture)&qu= ot;
=A0
While I have no problem with t= hat, I am not aware of a regulation establishing such emergency service so = I cannot argue to IANA that the RFC5031 policy is satisfied for those URNs.=
=A0
Kind regards
=A0
Ivo Sedlacek
=A0
=A0
=A0
=A0
This Communication is Confidential. We only se= nd and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer =
From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19. =FAnora 2013 21:12
To: Ivo Sedlacek
Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: Re: [Ecrit] What is t= he most appropriate method for registering new sub-services of urn:service:= sos (trimming due too large message report)<= /u>
=A0
Thing is, when there is no city police, local would give you c= ounty police (sheriff department) but in a city with a city police departme= nt local would give you city police.=A0 In the latter case, so how do I get= the county police (or state police, there can be up to 4 police services f= or a given location in the US).=A0 Note that these examples are US based, b= ut we do have 3 levels of police services in Canada and I am sure other cou= ntries have the same issue.
=A0<= /u>

There is also the terminology.=A0 There is no "national" police i= n the US or Canada but there is a federal police.=A0 Keeping the RFC 4119 t= erminology removes any "local" interpretation issues.

Dan<= span lang=3D"EN-GB">

On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek= <ivo.sed= lacek@ericsson.com> wrote:=
I agree with Richard - there are countr= ies where both the emergency service of the national police and the emergen= cy service of the municipal police are offered in a given location. =
A user would call the municipal police emerg= ency service to report e.g. pickpockets.=
A user would call the national police emerge= ncy service to report e.g. a murder.<= /u>
=A0
=A0
I submitted to IANA a request to register:
- urn:service:sos.police.local - The 'police.local' servic= e refers to the emergency service offered by the police department or other= law enforcement authorities of the local or municipal authorities.<= span lang=3D"EN-GB">
- urn:service:sos.police.national - The '= ;police.national' service refers to the emergency service offered by th= e police department or other law enforcement authorities of the national go= vernment.
=A0
RFC5031 policy is hopefully fu= lfilled for them since they exist in two countries.
=A0
I am flexible whether the actu= al URNs contain the sub-services proposed above (i.e. .local and .national = sub-services) or subservices based on RFC4119 (i.e. .A3 and .country sub-se= rvices).
=A0
If the preference is for subse= rvices based on RFC4119, do I need to make another IANA registration reques= t or can we modify the URNs and their description during the expert review?=
=A0
Kind regards
=A0
Ivo Sedlacek
=A0
This Communication is Confidenti= al. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaim= er
From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19. =FAnora 2013 15:36
To: Winterbottom, James
Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org
Subject: Re: [Ecrit] What is t= he most appropriate method for registering new sub-services of urn:service:= sos
=A0
The problem is that different countries h= as different names for their political subdivisions.=A0 In the US they are = states, in Canada they are provinces, etc.=A0 Same when you further subdivi= de.=A0 While not privy to the discussions that came up with A1, A2, =85, A5= , I have the feeling this nomenclature was picked for the same reason.=A0 W= hy not utilise the same naming scheme for specifying the jurisdiction you w= ant to reach?
=A0<= /u>
Thanx,
Dan<= /u>

=A0

On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James <James.Winterbottom@= commscope.com> wrote:
In that case, one might say state in = the hierarchy, not A1.
=A0<= /u>
Cheers
James
=A0
=A0<= /u>
From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Tuesday, 19 February 2013 8:57 AM
To: Winterbottom, = James
Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org<= /u>

Subject: Re: [Ecrit] What is the m= ost appropriate method for registering new sub-services of urn:service:sos<= span lang=3D"EN-GB">
=A0
It might make sense if you wanted to allow the caller to explicitly s= elect police at a different level of responsibility, e.g., the state police= rather than the local police. =A0

=A0

On Mon= , Feb 18, 2013 at 4:21 PM, Winterbottom, James <James.Winterbottom@commscope.= com> wrote:
I think I am missing something here, = A1 is part of the location, so why does it need to be in the URN at all?
As far as I understand current deployments= , they use the URN to select a layer in the GIS that corresponds to the ser= vice type, and then use geographic boundaries within that layer to select t= he final destination.
=A0<= /u>
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Dan M= ongrain
Sent: Tuesday, 19 February 2013 7:30 AM<= u>

To: Ivo = Sedlacek
Cc: = ecrit@ietf.org
Subject: Re: [Ecrit] What is the most appropriate method for registe= ring new sub-services of urn:service:sos=
=A0
Sorry for responding late to this thread, = it kinda fell into a=A0 crack=85=A0 The current thread reminded me to check= this old thread=85
=A0<= /u>
You are indicating that we= need to register 77 Service URN (11 service subtypes * 7 jurisdiction type= s based on RFC 4119).=A0 I do not recommend that we create so many registra= tions.=A0 Instead, we should allow a service URN to be suffixed with a juri= sdictional scope.=A0 So the following Service URN are all valid:
=A0<= /u>
urn:service:sos.police
urn:service:sos.police.traffic
urn:service:sos.police.A1=
urn:service:sos.police.traffic.A1
=A0
Question is, do we want to leave jurisdict= ional scope to only be applicable to police branch or any Service URN? =A0I= =92d say the latter as it is always up to the LoST service provisioning (ba= sed on local policy) to determine what is locally acceptable.
=A0<= /u>
Thanx,
Dan<= /u>
=A0
=A0
=A0

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

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

<= /div>
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
http= s://www.ietf.org/mailman/listinfo/ecrit


________________________= _______________________
Ecrit mailing list
Ecrit@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ecrit


--bcaec5523dccefb09904d6304445-- From brian.rosen@neustar.biz Thu Feb 21 06:44:47 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37D621F87A6 for ; Thu, 21 Feb 2013 06:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.663 X-Spam-Level: X-Spam-Status: No, score=-5.663 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Relcd3dG203D for ; Thu, 21 Feb 2013 06:44:44 -0800 (PST) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 278FF21F8CA5 for ; Thu, 21 Feb 2013 06:44:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1361457722; x=1676753779; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=0Y++xuKwsdVr58yNfdcUVv/EhYsdj7UeZ2W1fPcunS8=; b=WRZ2AlxS4OvCVUyYhJKRrdzFFOTaK0+CcNKoJKc0UVLwwbAAnH7yfHStlIG4j/ oHOIj8QGh/GWKE4mrQDonxOQ== Received: from ([10.31.13.229]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.15187428; Thu, 21 Feb 2013 09:42:00 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Thu, 21 Feb 2013 09:44:40 -0500 From: "Rosen, Brian" To: Richard Barnes Date: Thu, 21 Feb 2013 09:44:39 -0500 Thread-Topic: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) Thread-Index: Ac4QQfopvr7wPlukS+adVDHO8fZv2Q== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 9Ujx/LkJVNQvywx/57fiDw== Content-Type: multipart/alternative; boundary="_000_E7445DCAC73D4DDBABB93A86857B657Fneustarbiz_" MIME-Version: 1.0 Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 14:44:47 -0000 --_000_E7445DCAC73D4DDBABB93A86857B657Fneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I'm okay with that also. Let's make sure we understand what we are talking about - I was having a pr= ivate conversation with someone which lead me to believe we may not all und= erstand. This situation ONLY occurs in countries that don't have a single number, or= a single number for a given type of service (police for example). This situation ONLY occurs when there is non-uniform coverage. The easy ex= ample is that there are local police in large cities, but provincial police= cover rural areas, and there are separate dial strings for local and provi= ncial police. We're discussing what happens, effectively, when you dial the local number. * In some countries, you get e.g. the provincial police (that is, it automa= tically redirects) * In some countries, you get a fast busy or other intercept (that is, you d= on't get connected and have to redial) Now, we're really in a different environment. I do worry about what we are= asking phones to do. LoST returns dial strings. We need to get, in this case, the local and pro= vincial dial strings. urn:service:sos.police should return no service urn:service:sos.police.A1 should return the provincial police dial string a= nd provincial police URL urn:service:sos.police.A2 should return no service urn:service:sos.police.A3 should return the local dial string. The URL cou= ld be that of the local police, the provincial police, or it could be some = URL that results in a fast busy or other intercept. Brian On Feb 20, 2013, at 6:25 PM, Richard Barnes >= wrote: Yes. This. My first reaction to these suggestions of chaining was "It's a provisioning= problem -- just put the same contact information under all those URNs." On Wed, Feb 20, 2013 at 5:02 PM, Nathan Wilcox > wrote: +1 On Feb 20, 2013, at 3:15 PM, Marc Linsner > wrote: Not sure I agree with your summation. In your example, .sos IS the proper = way to call .fire. Just because .sos is also the proper way to call .polic= e is irrelevant. Maybe it would be best to use a DNS-like approach. No record =3D 'not foun= d'. No ambiguity this way. Populate .sos and .sos.fire and .sos.police al= l with the same uri if that is the response you want. If request is for .s= os.help and the jurisdiction doesn't support .help, the response is 'not fo= und'. Why try to guess what was requested? -Marc- From: Dan Mongrain > Date: Wednesday, February 20, 2013 3:32 PM To: Marc Linsner > Cc: "Rosen, Brian" = >, "ecrit@ietf.org" > Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) We should not infer anything from missing information especially if this in= formation is optional (as my previous message shows). Doing anything else = is misleading at best. Requester makes a request specifying desired servic= e nothing more. You may ask for sos.fire, but you are getting sos as you c= annot call .fire directly, local policy. If you do not like the answer, tr= y again if you want with a different service (same service request will giv= e same response back). Dan On Wed, Feb 20, 2013 at 3:16 PM, Marc Linsner > wrote: What if I don't want A2 (I don't trust Butler County sheriff), if no A3 (Ma= rs) give me A1 (PA)? What I proposed allows the requestor to tailor the request to match his des= ire. The fallback is multiple requests. -Marc- From: "Rosen, Brian" > Date: Wednesday, February 20, 2013 2:56 PM To: Marc Linsner > Cc: Dan Mongrain >, "ecrit@ietf.o= rg" > Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) To me, this doesn't make sense. Suppose I have a local police department in cities, but a provincial police= department in rural areas, as well as a national police. I ask for sos.po= lice.A3. If location was in a city, I should get sos.police.A3 But if I was in a rural area, a request for sos.police.A3 should return a r= esponse of sos.police.A2. That may or may not be the same as sos.police Brian On Feb 20, 2013, at 2:47 PM, Marc Linsner > wrote: I understood you as requesting urn:service:sos.police.A4. My point was that if the LoST service had no entry for A4, it could simply = check the Ax tree submitted in the location section of the request. So if = the location included A1 & A4, the LoST service, finding nothing for A4 wou= ld then check A1 (not A3 or A2). This way the service would be matching th= e hierarchy of the given location vs. an arbitrary hierarchy that may be di= fferent from the requestors desire. Carry on=85 -Marc- From: Dan Mongrain > Date: Wednesday, February 20, 2013 12:30 PM To: Marc Linsner > Cc: "Winterbottom, James" >, "ecrit@ietf.org" > Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) I do not understand your comment. What I am proposing is that requests do = not specify a search pattern in the case a requested jurisdiction is not fo= und. It should not be to the requester which submits urn:service:sos.polic= e.country.A1.A2.A3.A4 to specify what to do if there is nothing configured = for the A4 layer. It must be up to the LoST service to apply whatever poli= cy it has in this case. If we allow this, then do we allow urn:service:sos= .police.fire? Give me fire first but if not found give me police? The Service URN should specify the "desired" service in a findService reque= st and the LoST service provides a response based on local policies. All I= am proposing is that one can specify a jurisdiction in the case there are = more then one service provider for a location. Thanx, Dan On Wed, Feb 20, 2013 at 8:48 AM, Marc Linsner > wrote: The findService request includes location information. Why wouldn't the Lo= ST server simple walk the A1-A6 tree included with the location? If locati= on is geo, reverse geocode it. What am I missing? -Marc- From: Dan Mongrain > Date: Tuesday, February 19, 2013 11:55 PM To: "Winterbottom, James" > Cc: "ecrit@ietf.org" > Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) What I meant is that if a jurisdictional scope aware LoST service receives = a request for urn:service:sos.police.A4 and nothing is configured, it looks= for urn:service:sos.police.A3 then urn:service:sos.police.A2, etc. until i= t finds a configured service. If nothing is found for urn:service:sos.poli= ce.country then it pops the last element and looks for urn:service:sos.poli= ce (but then again, it is no longer jurisdictional scope aware). I disagree that one needs to formulate the request as urn:service:sos.polic= e.country.A1.A2.A3.A4 in order for this to happen. There must be only a si= ngle jurisdictional scope appended to a Service URN. I do not think we need a .A6 jurisdictional scope (street level). .A5 (nei= ghborhood, would point to a precinct for example) provides enough granulari= ty in my opinion. Thanx, Dan On Tue, Feb 19, 2013 at 11:29 PM, Winterbottom, James > wrote: I am sorry, I am finding this confusing. RFC5139 puts a hierarchy on A1 through A6. If you want this hierarchy to wo= rk then A1 through A6 can=92t be at the same level if you expect A3 to fall= back to A2 or A1 in the case of a service not existing or a service failure= of some kind. If they exist at the same level then if A3 doesn=92t exist y= ou will go to urn:service:sos.police unless you impose the hierarchy in th= e urn. From: Dan Mongrain [mailto:dan@mongrain.org] Sent: Wednesday, 20 February 2013 3:23 PM To: DRAGE, Keith (Keith) Cc: Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) My recommendation for handling unknown Service URN depends if LoST service = implements jurisdictional scope or not. If it does not, it pops the last e= lement and evaluates until a service is found. If it implements jurisdicti= onal scope, the last element is a jurisdictional scope and it is not found,= then you return the next highest level defined. While it may be true that citizens typically dial 9-1-1 to request for help= , police services such as state or provincial polices advertises numbers to= call them directly (star code to dial using a mobile phone for example) es= pecially to report accidents on freeways. We need an equivalent Service UR= N. Also while RFC5031's scope is citizen to authorities (I am not sure I agree= with this) I do not want to re-invent the wheel to signal calls within an = Emergency Services IP Network (ESInet). When I transfer a call from one PS= AP to another, the mechanism to determine where to send the call is the sam= e, using LoST. For a PSAP that covers a large area spanning multiple count= ies and the calltaker needs to transfer the call to the appropriate sheriff= department for the caller's location, they only need a single transfer tar= get (urn:service:sos.police.A2). It is not true that the calltaker always = knows the actual destination of the call, especially when the calltaker is = only a call screener. Thanx, Dan On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) > wrote: The answer to James=92s question depends on how you code it (and also what = you mean by fallback). On any service URN, you ignore any subtypes from the point you stop underst= anding it. So if the coding is sos.police.A2, and you do not understand A2, then the s= ervice URN would be handled as if it was sos.police, not as sos.police.A1. = And if police was not understood then it would be handled as sos. If you wanted something that went back to the next larger regional coverage= , then you would have to code successive subtypes in sequence. But I would also ask for an element of sanity in this discussion, rather th= an total flexibility. For example while a national administration may have multiple levels of pol= ice force, not all of them are either reachable directly as an emergency se= rvice provider, nor are they necessarily an emergency service provider. If = they are neither of these, then they presumably do not need a special and d= istinct service URN. It would therefore nice to see a current use case that is anything but a ch= oice of two, i.e. countrywide (following the ITU-T E.164 definition of coun= try) versus one more local variant. This restricted model certainly covers = Ivo=92s examples of Czeck Republic and Poland, and I believe it also covers= the other example I know of which is Italy. While the USA has multiple levels of police force, on the PSTN, it only app= ears to have one level of access to citizen to authority emergency service,= which is 911. I see no reason why a change to voice over IP would cause a = change to this. I would also stress that it is important to have global expectations of wha= t you get when you use a service URN. If there is not care excercised with = assigning semantics and values, A3 in one country could result in the fores= try police and in another country the financial police responding. Note that read the scope of RFC 5031 as being for end user accessing the em= ergency service. While it might be possible to apply RFC 5031 to further ne= twork operations after the PSAP has been reached, e.g. to reach a subsidiar= y PSAP, I read that as outside the scope of RFC 5031. Nor do I necessarily = believe in that scenario that service URNs are necessarily the best solutio= n for routeing, as the first PSAP should know the particular office they wa= nt to reach rather than just the type of emergency service. Regards Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Winterbottom, = James Sent: 19 February 2013 23:29 To: Ivo Sedlacek; Dan Mongrain Cc: ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) I am okay with this, providing that the fallback order is clearly defined. That is, does an A3 fall back to an A2 or A1, or just back to sos? From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] Sent: Wednesday, 20 February 2013 7:32 AM To: Dan Mongrain Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org Subject: RE: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) Hello, If we go with RFC4119 based sub-services, would the IANA registration reque= st be as follows? - urn:service:sos.police.A3 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of a city, township, shi (JP). - urn:service:sos.police.country - The 'police.national' service refers to = the emergency service offered by the police department or other law enforce= ment authorities of the government of a country. Does anyone see any issue in that? If WG prefers this, it is OK for me. > In the latter case, so how do I get the county police (or state police, t= here can be up to 4 police services for a given location in the US). If I got it correctly, you propose that we also add - urn:service:sos.police.A2 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of county, parish, gun (JP), district (IN)" - urn:service:sos.police.A1 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of national subdivisions (state, region, provin= ce, prefecture)" While I have no problem with that, I am not aware of a regulation establish= ing such emergency service so I cannot argue to IANA that the RFC5031 polic= y is satisfied for those URNs. 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 21:12 To: Ivo Sedlacek Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) Thing is, when there is no city police, local would give you county police = (sheriff department) but in a city with a city police department local woul= d give you city police. In the latter case, so how do I get the county pol= ice (or state police, there can be up to 4 police services for a given loca= tion in the US). Note that these examples are US based, but we do have 3 l= evels of police services in Canada and I am sure other countries have the s= ame issue. There is also the terminology. There is no "national" police in the US or = Canada but there is a federal police. Keeping the RFC 4119 terminology rem= oves any "local" interpretation issues. Dan On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek > wrote: I agree with Richard - there are countries where both the emergency service= of the national police and the emergency service of the municipal police a= re offered in a given location. A user would call the municipal police emergency service to report e.g. pic= kpockets. A user would call the national police emergency service to report e.g. a mu= rder. I submitted to IANA a request to register: - urn:service:sos.police.local - The 'police.local' service refers to the e= mergency service offered by the police department or other law enforcement = authorities of the local or municipal authorities. - urn:service:sos.police.national - The 'police.national' service refers to= the emergency service offered by the police department or other law enforc= ement authorities of the national government. RFC5031 policy is hopefully fulfilled for them since they exist in two coun= tries. I am flexible whether the actual URNs contain the sub-services proposed abo= ve (i.e. .local and .national sub-services) or subservices based on RFC4119= (i.e. .A3 and .country sub-services). If the preference is for subservices based on RFC4119, do I need to make an= other IANA registration request or can we modify the URNs and their descrip= tion during the expert review? 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 15:36 To: Winterbottom, James Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos The problem is that different countries has different names for their polit= ical subdivisions. In the US they are states, in Canada they are provinces= , etc. Same when you further subdivide. While not privy to the discussion= s that came up with A1, A2, =85, A5, I have the feeling this nomenclature w= as picked for the same reason. Why not utilise the same naming scheme for = specifying the jurisdiction you want to reach? Thanx, Dan On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James > wrote: In that case, one might say state in the hierarchy, not A1. Cheers James From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Tuesday, 19 February 2013 8:57 AM To: Winterbottom, James Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos It might make sense if you wanted to allow the caller to explicitly select = police at a different level of responsibility, e.g., the state police rathe= r than the local police. On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James > wrote: I think I am missing something here, A1 is part of the location, so why doe= s it need to be in the URN at all? As far as I understand current deployments, they use the URN to select a la= yer in the GIS that corresponds to the service type, and then use geographi= c boundaries within that layer to select the final destination. From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Dan Mongrain Sent: Tuesday, 19 February 2013 7:30 AM To: Ivo Sedlacek Cc: ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos Sorry for responding late to this thread, it kinda fell into a crack=85 T= he current thread reminded me to check this old thread=85 You are indicating that we need to register 77 Service URN (11 service subt= ypes * 7 jurisdiction types based on RFC 4119). I do not recommend that we= create so many registrations. Instead, we should allow a service URN to b= e suffixed with a jurisdictional scope. So the following Service URN are a= ll valid: urn:service:sos.police urn:service:sos.police.traffic urn:service:sos.police.A1 urn:service:sos.police.traffic.A1 Question is, do we want to leave jurisdictional scope to only be applicable= to police branch or any Service URN? I=92d say the latter as it is always= up to the LoST service provisioning (based on local policy) to determine w= hat is locally acceptable. Thanx, Dan _______________________________________________ Ecrit mailing list Ecrit@ie= tf.orghttps://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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_E7445DCAC73D4DDBABB93A86857B657Fneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I'm okay with that al= so.

Let's make sure we understand what we are talking ab= out - I was having a private conversation with someone which lead me to bel= ieve we may not all understand.

This situation ONL= Y occurs in countries that don't have a single number, or a single number f= or a given type of service (police for example).

T= his situation ONLY occurs when there is non-uniform coverage.  The eas= y example is that there are local police in large cities, but provincial po= lice cover rural areas, and there are separate dial strings for local and p= rovincial police.

We're discussing what happens, e= ffectively, when you dial the local number.
* In some countries, = you get e.g. the provincial police (that is, it automatically redirects)
* In some countries, you get a fast busy or other intercept (that i= s, you don't get connected and have to redial)

Now= , we're really in a different environment.  I do worry about what we a= re asking phones to do.  
LoST returns dial strings.  W= e need to get, in this case, the local and provincial dial strings.

urn:service:sos.police should return no service
urn:service:sos.police.A1 should return the provincial police dial string = and provincial police URL
urn:service:sos.police.A2 should return= no service
urn:service:sos.police.A3 should return the local dia= l string.  The URL could be that of the local police, the provincial p= olice, or it could be some URL that results in a fast busy or other interce= pt. 

Brian

On Feb 20, 2013, at 6:25 PM, Richard Barnes <rlb@ipv.sx> wrote:

=
Yes.  This.

<= div>My first reaction to these suggestions of chaining was "It's a provisio= ning problem -- just put the same contact information under all those URNs.= "


On Wed, Feb 20, 2013 at 5:02 PM, Nathan = Wilcox <ngwilcox@gmail.com> wrote:
+1

= On Feb 20, 2013, at 3:15 PM, Marc Linsner <mlinsner@cisco.com> wrote:

Not sure I agree with your summation.  In your example, .s= os IS the proper way to call .fire.  Just because .sos is also the pro= per way to call .police is irrelevant.

Maybe it would be best to use a DNS-like approach. &nbs= p;No record =3D 'not found'.  No ambiguity this way.  Populate .s= os and .sos.fire and .sos.police all with the same uri if that is the respo= nse you want.  If request is for .sos.help and the jurisdiction doesn'= t support .help, the response is 'not found'.  Why try to guess what w= as requested?

-Marc-




We should not infer anything from missing information especially if this in= formation is optional (as my previous message shows).  Doing anything = else is misleading at best.  Requester makes a request specifying desi= red service nothing more.  You may ask for sos.fire, but you are getti= ng sos as you cannot call .fire directly, local policy.  If you do not= like the answer, try again if you want with a different service (same serv= ice request will give same response back).

Dan

On Wed, Feb 20, 2013 at 3:16 PM, = Marc Linsner <mlinsner@cisco.com> wrote:
What if I don't want A2 (I don't trust Butler County sheriff), = if no A3 (Mars) give me A1 (PA)?

What I proposed a= llows the requestor to tailor the request to match his desire.

The fallback is multiple requests.

=
-Marc-

From: "Rosen, Brian" <Brian.Rosen@neustar.b= iz>
Date: Wednesday, Feb= ruary 20, 2013 2:56 PM
To: Marc Linsner <mlinsner@cisco.com>
Cc: Dan Mongrain <dan@mongrain.org>, "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] What is the m= ost appropriate method for registering new sub-services of urn:service:sos = (trimming due too large message report)

To me, this doesn't make sense.
Suppose I have a local police department in cities, but a provi= ncial police department in rural areas, as well as a national police.  = ;I ask for sos.police.A3.  If location was in a city, I should get sos= .police.A3

But if I was in a rural area, a request for sos.police.= A3 should return a response of sos.police.A2.

That= may or may not be the same as sos.police

Brian

On Feb 20, 2013, at 2:47 PM, Marc Linsner <mlinsner@cisco.com> wr= ote:

I understood you as requesting urn:service:sos.police.A4.
My point was that if the LoST service had no entry for A4, it = could simply check the Ax tree submitted in the location section of the req= uest.  So if the location included A1 & A4, the LoST service, find= ing nothing for A4 would then check A1 (not A3 or A2).  This way the s= ervice would be matching the hierarchy of the given location vs. an arbitra= ry hierarchy that may be different from the requestors desire.

Carry on=85

-Marc-
<= br>
From: Dan Mongrain <dan@mongrain.org>
Date: Wednesday, February 20, 2013 12:= 30 PM
To: Marc Linsner <mlinsner@cisco.com>
Cc: "Winterbottom, James" <James.Winte= rbottom@commscope.com>, "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] What is the m= ost appropriate method for registering new sub-services of urn:service:sos = (trimming due too large message report)

I do not understand your comment.  What I am proposing is that request= s do not specify a search pattern in the case a requested jurisdiction is n= ot found.  It should not be to the requester which submits urn:s= ervice:sos.police.country.A1.A2.A3.A4 to specify what to do if there is not= hing configured for the A4 layer.  It must be up to the LoST service t= o apply whatever policy it has in this case.  If we allow this, then d= o we allow urn:service:sos.police.fire?  Give me fire first but if not= found give me police?

The Service URN should specify the "desired" service in a findService r= equest and the LoST service provides a response based on local policies.&nb= sp; All I am proposing is that one can specify a jurisdiction in the case t= here are more then one service provider for a location.

Thanx,
Dan

On Wed, Feb 20, = 2013 at 8:48 AM, Marc Linsner <mlinsner@cisco.com> wrote:
The findService request includes location information.  Wh= y wouldn't the LoST server simple walk the A1-A6 tree included with the loc= ation?  If location is geo, reverse geocode it.

What am I missing?

-Marc-


What I meant is that if a jurisdictional scope aware LoST service receives = a request for urn:service:sos.police.A4 and nothing is configured, it looks= for urn:service:sos.police.A3 then urn:service:sos.police.A2, etc. until i= t finds a configured service.  If nothing is found for urn:service:sos= .police.country then it pops the last element and looks for urn:service:sos= .police (but then again, it is no longer jurisdictional scope aware).

I disagree that one needs to formulate the request as urn:service:sos.p= olice.country.A1.A2.A3.A4 in order for this to happen.  There must be = only a single jurisdictional scope appended to a Service URN.

I do n= ot think we need a .A6 jurisdictional scope (street level).  .A5 (neig= hborhood, would point to a precinct for example) provides enough granularit= y in my opinion.

Thanx,
Dan


On Tue, Feb 19, 201= 3 at 11:29 PM, Winterbottom, James <James.Winterbottom@comm= scope.com> wrote:
I am sorry, I am find= ing this confusing.
 
RFC5139 puts a hierarchy on A1 through A6. If you w= ant this hierarchy to work then A1 through A6 can=92t be at the same level = if you expect A3 to fallback to A2 or A1 in the case of a service not exist= ing or a service failure of some kind. If they exist at the same level then= if A3 doesn=92t exist you will go to urn:service:sos.police  unless y= ou impose the hierarchy in the urn.
 
 
 
 
 
=
From: Dan Mong= rain [mailto:dan@mong= rain.org]
Sent: Wednesday, 20 February 2013 3:23 PM
To: DRAGE, Keith= (Keith)
Cc: Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org
Subject: Re= : [Ecrit] What is the most appropriate method for registering new sub-servi= ces of urn:service:sos (trimming due too large message report)
 

My recommendation for handling unknown = Service URN depends if LoST service implements jurisdictional scope or not.=   If it does not, it pops the last element and evaluates until a servi= ce is found.  If it implements jurisdictional scope, the last element = is a jurisdictional scope and it is not found, then you return the next hig= hest level defined.

While it may be true that citizens typically dial 9-1-1 to request for = help, police services such as state or provincial polices advertises number= s to call them directly (star code to dial using a mobile phone for example= ) especially to report accidents on freeways.  We need an equivalent S= ervice URN.

Also while RFC5031's scope is citizen to authorities (I am not sure I a= gree with this) I do not want to re-invent the wheel to signal calls within= an Emergency Services IP Network (ESInet).  When I transfer a call fr= om one PSAP to another, the mechanism to determine where to send the call i= s the same, using LoST.  For a PSAP that covers a large area spanning = multiple counties and the calltaker needs to transfer the call to the appro= priate sheriff department for the caller's location, they only need a singl= e transfer target (urn:service:sos.police.A2).  It is not true that th= e calltaker always knows the actual destination of the call, especially whe= n the calltaker is only a call screener.

Thanx,
Dan

On Tue, Fe= b 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com= > wrote:
The answer to James=92s question d= epends on how you code it (and also what you mean by fallback).
 
On any service UR= N, you ignore any subtypes from the point you stop understanding it.=
 
So if the coding = is sos.police.A2, and you do not understand A2, then the service URN would = be handled as if it was sos.police, not as sos.police.A1. And if police was= not understood then it would be handled as sos.
 
If you wanted som= ething that went back to the next larger regional coverage, then you would = have to code successive subtypes in sequence.
 
But I would also = ask for an element of sanity in this discussion, rather than total flexibil= ity.
 
For example while= a national administration may have multiple levels of police force, not al= l of them are either reachable directly as an emergency service provider, n= or are they necessarily an emergency service provider. If they are neither = of these, then they presumably do not need a special and distinct service U= RN.
 
It would therefor= e nice to see a current use case that is anything but a choice of two, i.e.= countrywide (following the ITU-T E.164 definition of country) versus one m= ore local variant. This restricted model certainly covers Ivo=92s examples = of Czeck Republic and Poland, and I believe it also covers the other exampl= e I know of which is Italy.
 
While the USA has= multiple levels of police force, on the PSTN, it only appears to have one = level of access to citizen to authority emergency service, which is 911. I = see no reason why a change to voice over IP would cause a change to this.
 
I would also stre= ss that it is important to have global expectations of what you get when yo= u use a service URN. If there is not care excercised with assigning semanti= cs and values, A3 in one country could result in the forestry police and in= another country the financial police responding.
 
Note that read th= e scope of RFC 5031 as being for end user accessing the emergency service. = While it might be possible to apply RFC 5031 to further network operations = after the PSAP has been reached, e.g. to reach a subsidiary PSAP, I read th= at as outside the scope of RFC 5031. Nor do I necessarily believe in that s= cenario that service URNs are necessarily the best solution for routeing, a= s the first PSAP should know the particular office they want to reach rathe= r than just the type of emergency service.
 
Regards
 
Keith
 
=
From: ecrit-bounces@ietf.o= rg [mailto:= ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James
Sent: 19 February 2013 23:29
To: Ivo Sedlacek; Dan Mongrai= n
Cc: ecrit@i= etf.org
Subject: Re: [Ecrit] What is the most appropriate met= hod for registering new sub-services of urn:service:sos (trimming due too l= arge message report)
 
I am okay with this, providing t= hat the fallback order is clearly defined.
That is, does an A3 fall back to an A2 or = A1, or just back to sos?
 <= u>
 
 <= u>
From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com]
Sent: Wednesday, 20 February 2013 7:32 AM
To: Dan Mongrain=
Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: RE: [Ecr= it] What is the most appropriate method for registering new sub-services of= urn:service:sos (trimming due too large message report)
 <= /u>
Hello,
 =
If we go with RFC4119 based= sub-services, would the IANA registration request be as follows?
 =
- urn:service:sos.police= .A3 - The 'police.local' service refers to the emergency service o= ffered by the police department or other law enforcement authorities of the= authorities of a city, township, shi (JP).
- urn:service:sos.police.country = ;- The 'police.national' service refers to the emergency service offered by= the police department or other law enforcement authorities of the governme= nt of a country.
 =
Does anyone see any issue i= n that?
 =
If WG prefers this, it is O= K for me.
 =
> In the latter case, so how d= o I get the county police (or state police, there can be up to 4 police ser= vices for a given location in the US). 
 =
If I got it correctly, you = propose that we also add <= /div>
- urn:service:sos.police.A2 - The 'po= lice.local' service refers to the emergency service offered by the police d= epartment or other law enforcement authorities of the authorities o= f county, parish, gun (JP), district (IN)"<= u>
- urn:service:sos.police.A1 - The 'po= lice.local' service refers to the emergency service offered by the police d= epartment or other law enforcement authorities of the authorities o= f national subdivisions (state, region, province, prefecture)"
 =
While I have no problem wit= h that, I am not aware of a regulation establishing such emergency service = so I cannot argue to IANA that the RFC5031 policy is satisfied for those UR= Ns.
 =
Kind regards
 =
Ivo Sedlacek
 =
 
 =
 
This Communication is Confidential. We only se= nd and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer =
From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19. =FAnora 2013 21:12
To: Ivo Sedlacek
Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: Re: [Ecrit] What is t= he most appropriate method for registering new sub-services of urn:service:= sos (trimming due too large message report)<= /u>
 
Thing is, when there is no city police, local would give yo= u county police (sheriff department) but in a city with a city police depar= tment local would give you city police.  In the latter case, so how do= I get the county police (or state police, there can be up to 4 police serv= ices for a given location in the US).  Note that these examples are US= based, but we do have 3 levels of police services in Canada and I am sure = other countries have the same issue.<= /u>
 <= u>

There is also the terminology.  There is no "national" police in the U= S or Canada but there is a federal police.  Keeping the RFC 4119 termi= nology removes any "local" interpretation issues.

Dan

On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek= <ivo.sed= lacek@ericsson.com> wrote:=
I agree with Richard - there are countr= ies where both the emergency service of the national police and the emergen= cy service of the municipal police are offered in a given location. =
A user would call the municipal police emerg= ency service to report e.g. pickpockets.=
A user would call the national police emerge= ncy service to report e.g. a murder.<= /u>
 =
 
I submitted to IANA a request to register:
- urn:service:sos.police.local - The 'police.local' service refers= to the emergency service offered by the police department or other law enf= orcement authorities of the local or municipal authorities.
- urn:service:sos.police.national - The 'pol= ice.national' service refers to the emergency service offered by the police= department or other law enforcement authorities of the national government= .
 =
RFC5031 policy is hopefully= fulfilled for them since they exist in two countries.
 =
I am flexible whether the a= ctual URNs contain the sub-services proposed above (i.e. .local and .nation= al sub-services) or subservices based on RFC4119 (i.e. .A3 and .country sub= -services).
 =
If the preference is for su= bservices based on RFC4119, do I need to make another IANA registration req= uest or can we modify the URNs and their description during the expert revi= ew?
 =
Kind regards
 =
Ivo Sedlacek
 =
This Communication is Confide= ntial. We only send and receive email on the basis of the terms set out at = www.ericsson.com/email_discl= aimer
From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19. =FAnora 2013 15:36
To: Winterbottom, James
Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org
Subject: Re: [Ecrit] What is t= he most appropriate method for registering new sub-services of urn:service:= sos
 
The problem is that different countrie= s has different names for their political subdivisions.  In the US the= y are states, in Canada they are provinces, etc.  Same when you furthe= r subdivide.  While not privy to the discussions that came up with A1,= A2, =85, A5, I have the feeling this nomenclature was picked for the same = reason.  Why not utilise the same naming scheme for specifying the jur= isdiction you want to reach?
 <= u>
Thanx,
Dan<= /u>

 

On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James <James.Winterbott= om@commscope.com> wrote:
In that case, one might say state in = the hierarchy, not A1.
 <= u>
Cheers
James
 
 <= u>
From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Tuesday, 19 February 2013 8:57 AM
To: Winterbottom, = James
Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org<= /u>

Subject: Re: [Ecrit] What is the m= ost appropriate method for registering new sub-services of urn:service:sos<= span lang=3D"EN-GB">
 
It might make sense if you wanted to allow the caller to explicitl= y select police at a different level of responsibility, e.g., the state pol= ice rather than the local police.  =

 

On = Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James <James.Winterbottom@commsco= pe.com> wrote:
I think I am missing something here, = A1 is part of the location, so why does it need to be in the URN at all?
As far as I understand current deployments= , they use the URN to select a layer in the GIS that corresponds to the ser= vice type, and then use geographic boundaries within that layer to select t= he final destination.
 <= u>
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Dan M= ongrain
Sent: Tuesday, 19 February 2013 7:30 AM<= u>

To: Ivo = Sedlacek
Cc: = ecrit@ietf.org
Subject: Re: [Ecrit] What is the most appropriate method for registe= ring new sub-services of urn:service:sos=
 
Sorry for responding late to this thread, = it kinda fell into a  crack=85  The current thread reminded me to= check this old thread=85<= /div>
 <= u>
You are indicating that= we need to register 77 Service URN (11 service subtypes * 7 jurisdiction t= ypes based on RFC 4119).  I do not recommend that we create so many re= gistrations.  Instead, we should allow a service URN to be suffixed wi= th a jurisdictional scope.  So the following Service URN are all valid= :
 <= u>
urn:service:sos.police<= /span>
urn:service:sos.police.traffic
urn:service:sos.police.A1=
urn:service:sos.police.traffic.A1
 
Question is, do we want to leave jurisdict= ional scope to only be applicable to police branch or any Service URN? &nbs= p;I=92d say the latter as it is always up to the LoST service provisioning = (based on local policy) to determine what is locally acceptable.
 <= u>
Thanx,
Dan<= /u>
 
 
 

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

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

<= /div>
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
http= s://www.ietf.org/mailman/listinfo/ecrit


______________________________= _________________
Ecrit mailing list
Ecrit@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ecrit


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

= --_000_E7445DCAC73D4DDBABB93A86857B657Fneustarbiz_-- From dan@mongrain.org Thu Feb 21 07:29:28 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E71F21F8E97 for ; Thu, 21 Feb 2013 07:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.375 X-Spam-Level: X-Spam-Status: No, score=0.375 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_36=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZ5iXypKX3ma for ; Thu, 21 Feb 2013 07:29:25 -0800 (PST) Received: from mail-ia0-x22a.google.com (ia-in-x022a.1e100.net [IPv6:2607:f8b0:4001:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5D31121F8E96 for ; Thu, 21 Feb 2013 07:29:24 -0800 (PST) Received: by mail-ia0-f170.google.com with SMTP id k20so8335577iak.15 for ; Thu, 21 Feb 2013 07:29:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=L/2LCCjE9qTntOFwjJS0vCju6Zy79elnB5cy/5iSLPs=; b=eP/Uxb77Wa3gA9i8thic3R9TcM+eBNsuKlW7IJTSSYn3cZ1dWgyM20t/Ms5tt6bqUY DE9aiRdtbJmKfikPL9yTUjkuvfw4Sl7anDlLgg5I34oo+vCb7zoiUrsVvfj84B4l2xXw rZ8KrauHHjV75nGP40AsTybv3Ts6PExcZicjCZtP0UHcJfI0RIIOI6NUIcc9CnWia3X8 f5Z0xlI1zeNvLdRiIx+gelu/v6q6FIbtbOXZhpxY0mVoPXSYG9c12So+QM6yUdBkyU/A 8hJ+y4aMevh5bWC3KXPU6awXFacLzbydNIlAs4J1k1XPCosqTpAetGqBNPtfsby0w5GT /RJw== MIME-Version: 1.0 X-Received: by 10.50.37.212 with SMTP id a20mr12561125igk.88.1361460560051; Thu, 21 Feb 2013 07:29:20 -0800 (PST) Received: by 10.50.171.41 with HTTP; Thu, 21 Feb 2013 07:29:19 -0800 (PST) X-Originating-IP: [96.23.59.4] In-Reply-To: References: Date: Thu, 21 Feb 2013 10:29:19 -0500 Message-ID: From: Dan Mongrain To: Richard Barnes Content-Type: multipart/alternative; boundary=f46d04446b210ebcb304d63dbd09 X-Gm-Message-State: ALoCoQmxPi3Dy/PETh09AmIsXbfMi3lPiti8FLPv8TDYFxnMxGvppPIt02JfjWc0HJkCM5X83ORC Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 15:29:28 -0000 --f46d04446b210ebcb304d63dbd09 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable While it is a provisioning issue, we are dealing with emergency calls here. We are talking about introducing a number of subServices that may not be available in all areas. While a client SHOULD not request this subService in areas where it is not offered as it SHOULD have listed the services available when entering the area, the LoST service must be able to deal with the case the client still requests an unknown subService. It could return a Not Found and let the client deal with it (the client SHOULD be intelligent enough to handle properly and not propagate error to user). Also the LoST service SHOULD be provisioned in such a way that if it gets an unknown subService it is handled. Still a lot of SHOULDs for an emergency call to succeed. We could mandate that a LoST server must give a default handling in the case the Service URN is in the sos tree. The most sensible way to handle an unknown subService is to unroll the Service URN (i.e. pop the last element in the Service URN) and re-evaluate. Most LoST service will be provisioned for urn:service:sos (the equivalent to dialing 9-1-1 or 1-1-2) so any subService down the sos tree will be handled. While I suggested that when you get a request with an unknown jurisdictional scope you should look for the next higher jurisdiction, the more I think about it, it should be treated the same as an unknown subService. Just unroll the Service URN (pop the jurisdictional scope) and re-evaluate. Dan On Wed, Feb 20, 2013 at 6:25 PM, Richard Barnes wrote: > Yes. This. > > My first reaction to these suggestions of chaining was "It's a > provisioning problem -- just put the same contact information under all > those URNs." > > > On Wed, Feb 20, 2013 at 5:02 PM, Nathan Wilcox wrote= : > >> +1 >> >> On Feb 20, 2013, at 3:15 PM, Marc Linsner wrote: >> >> Not sure I agree with your summation. In your example, .sos IS the >> proper way to call .fire. Just because .sos is also the proper way to c= all >> .police is irrelevant. >> >> Maybe it would be best to use a DNS-like approach. No record =3D 'not >> found'. No ambiguity this way. Populate .sos and .sos.fire and >> .sos.police all with the same uri if that is the response you want. If >> request is for .sos.help and the jurisdiction doesn't support .help, the >> response is 'not found'. Why try to guess what was requested? >> >> -Marc- >> >> >> >> From: Dan Mongrain >> Date: Wednesday, February 20, 2013 3:32 PM >> To: Marc Linsner >> Cc: "Rosen, Brian" , "ecrit@ietf.org" < >> ecrit@ietf.org> >> Subject: Re: [Ecrit] What is the most appropriate method for registering >> new sub-services of urn:service:sos (trimming due too large message repo= rt) >> >> We should not infer anything from missing information especially if this >> information is optional (as my previous message shows). Doing anything >> else is misleading at best. Requester makes a request specifying desire= d >> service nothing more. You may ask for sos.fire, but you are getting sos= as >> you cannot call .fire directly, local policy. If you do not like the >> answer, try again if you want with a different service (same service >> request will give same response back). >> >> Dan >> >> On Wed, Feb 20, 2013 at 3:16 PM, Marc Linsner wrote= : >> >>> What if I don't want A2 (I don't trust Butler County sheriff), if no A3 >>> (Mars) give me A1 (PA)? >>> >>> What I proposed allows the requestor to tailor the request to match his >>> desire. >>> >>> The fallback is multiple requests. >>> >>> -Marc- >>> >>> From: "Rosen, Brian" >>> Date: Wednesday, February 20, 2013 2:56 PM >>> To: Marc Linsner >>> Cc: Dan Mongrain , "ecrit@ietf.org" >>> Subject: Re: [Ecrit] What is the most appropriate method for >>> registering new sub-services of urn:service:sos (trimming due too large >>> message report) >>> >>> To me, this doesn't make sense. >>> >>> Suppose I have a local police department in cities, but a provincial >>> police department in rural areas, as well as a national police. I ask = for >>> sos.police.A3. If location was in a city, I should get sos.police.A3 >>> >>> But if I was in a rural area, a request for sos.police.A3 should return >>> a response of sos.police.A2. >>> >>> That may or may not be the same as sos.police >>> >>> Brian >>> >>> On Feb 20, 2013, at 2:47 PM, Marc Linsner wrote: >>> >>> I understood you as requesting urn:service:sos.police.A4. >>> >>> My point was that if the LoST service had no entry for A4, it could >>> simply check the Ax tree submitted in the location section of the reque= st. >>> So if the location included A1 & A4, the LoST service, finding nothing= for >>> A4 would then check A1 (not A3 or A2). This way the service would be >>> matching the hierarchy of the given location vs. an arbitrary hierarchy >>> that may be different from the requestors desire. >>> >>> Carry on=85 >>> >>> -Marc- >>> >>> From: Dan Mongrain >>> Date: Wednesday, February 20, 2013 12:30 PM >>> To: Marc Linsner >>> Cc: "Winterbottom, James" , " >>> ecrit@ietf.org" >>> Subject: Re: [Ecrit] What is the most appropriate method for >>> registering new sub-services of urn:service:sos (trimming due too large >>> message report) >>> >>> I do not understand your comment. What I am proposing is that requests >>> do not specify a search pattern in the case a requested jurisdiction is= not >>> found. It should not be to the requester which submits urn:service:sos= .police.country.A1.A2.A3.A4 >>> to specify what to do if there is nothing configured for the A4 layer. = It >>> must be up to the LoST service to apply whatever policy it has in this >>> case. If we allow this, then do we allow urn:service:sos.police.fire? >>> Give me fire first but if not found give me police? >>> >>> The Service URN should specify the "desired" service in a findService >>> request and the LoST service provides a response based on local policie= s. >>> All I am proposing is that one can specify a jurisdiction in the case t= here >>> are more then one service provider for a location. >>> >>> Thanx, >>> Dan >>> >>> On Wed, Feb 20, 2013 at 8:48 AM, Marc Linsner wrote= : >>> >>>> The findService request includes location information. Why wouldn't >>>> the LoST server simple walk the A1-A6 tree included with the location?= If >>>> location is geo, reverse geocode it. >>>> >>>> What am I missing? >>>> >>>> -Marc- >>>> >>>> From: Dan Mongrain >>>> Date: Tuesday, February 19, 2013 11:55 PM >>>> To: "Winterbottom, James" >>>> Cc: "ecrit@ietf.org" >>>> Subject: Re: [Ecrit] What is the most appropriate method for >>>> registering new sub-services of urn:service:sos (trimming due too larg= e >>>> message report) >>>> >>>> What I meant is that if a jurisdictional scope aware LoST service >>>> receives a request for urn:service:sos.police.A4 and nothing is config= ured, >>>> it looks for urn:service:sos.police.A3 then urn:service:sos.police.A2,= etc. >>>> until it finds a configured service. If nothing is found for >>>> urn:service:sos.police.country then it pops the last element and looks= for >>>> urn:service:sos.police (but then again, it is no longer jurisdictional >>>> scope aware). >>>> >>>> I disagree that one needs to formulate the request as >>>> urn:service:sos.police.country.A1.A2.A3.A4 in order for this to happen= . >>>> There must be only a single jurisdictional scope appended to a Service= URN. >>>> >>>> I do not think we need a .A6 jurisdictional scope (street level). .A5 >>>> (neighborhood, would point to a precinct for example) provides enough >>>> granularity in my opinion. >>>> >>>> Thanx, >>>> Dan >>>> >>>> >>>> On Tue, Feb 19, 2013 at 11:29 PM, Winterbottom, James < >>>> James.Winterbottom@commscope.com> wrote: >>>> >>>>> I am sorry, I am finding this confusing.**** >>>>> ** ** >>>>> RFC5139 puts a hierarchy on A1 through A6. If you want this hierarchy >>>>> to work then A1 through A6 can=92t be at the same level if you expect= A3 to >>>>> fallback to A2 or A1 in the case of a service not existing or a servi= ce >>>>> failure of some kind. If they exist at the same level then if A3 does= n=92t >>>>> exist you will go to urn:service:sos.police unless you impose the >>>>> hierarchy in the urn.**** >>>>> ** ** >>>>> ** ** >>>>> ** ** >>>>> ** ** >>>>> ** ** >>>>> *From:* Dan Mongrain [mailto:dan@mongrain.org] >>>>> *Sent:* Wednesday, 20 February 2013 3:23 PM >>>>> *To:* DRAGE, Keith (Keith) >>>>> *Cc:* Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org >>>>> *Subject:* Re: [Ecrit] What is the most appropriate method for >>>>> registering new sub-services of urn:service:sos (trimming due too lar= ge >>>>> message report)**** >>>>> ** ** >>>>> >>>>> My recommendation for handling unknown Service URN depends if LoST >>>>> service implements jurisdictional scope or not. If it does not, it p= ops >>>>> the last element and evaluates until a service is found. If it imple= ments >>>>> jurisdictional scope, the last element is a jurisdictional scope and = it is >>>>> not found, then you return the next highest level defined. >>>>> >>>>> While it may be true that citizens typically dial 9-1-1 to request fo= r >>>>> help, police services such as state or provincial polices advertises >>>>> numbers to call them directly (star code to dial using a mobile phone= for >>>>> example) especially to report accidents on freeways. We need an equi= valent >>>>> Service URN. >>>>> >>>>> Also while RFC5031's scope is citizen to authorities (I am not sure I >>>>> agree with this) I do not want to re-invent the wheel to signal calls >>>>> within an Emergency Services IP Network (ESInet). When I transfer a = call >>>>> from one PSAP to another, the mechanism to determine where to send th= e call >>>>> is the same, using LoST. For a PSAP that covers a large area spannin= g >>>>> multiple counties and the calltaker needs to transfer the call to the >>>>> appropriate sheriff department for the caller's location, they only n= eed a >>>>> single transfer target (urn:service:sos.police.A2). It is not true t= hat >>>>> the calltaker always knows the actual destination of the call, especi= ally >>>>> when the calltaker is only a call screener. >>>>> >>>>> Thanx, >>>>> Dan**** >>>>> On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) < >>>>> keith.drage@alcatel-lucent.com> wrote:**** >>>>> The answer to James=92s question depends on how you code it (and also >>>>> what you mean by fallback).**** >>>>> **** >>>>> On any service URN, you ignore any subtypes from the point you stop >>>>> understanding it.**** >>>>> **** >>>>> So if the coding is sos.police.A2, and you do not understand A2, then >>>>> the service URN would be handled as if it was sos.police, not as >>>>> sos.police.A1. And if police was not understood then it would be hand= led as >>>>> sos.**** >>>>> **** >>>>> If you wanted something that went back to the next larger regional >>>>> coverage, then you would have to code successive subtypes in sequence= . >>>>> **** >>>>> **** >>>>> But I would also ask for an element of sanity in this discussion, >>>>> rather than total flexibility.**** >>>>> **** >>>>> For example while a national administration may have multiple levels >>>>> of police force, not all of them are either reachable directly as an >>>>> emergency service provider, nor are they necessarily an emergency ser= vice >>>>> provider. If they are neither of these, then they presumably do not n= eed a >>>>> special and distinct service URN. **** >>>>> **** >>>>> It would therefore nice to see a current use case that is anything bu= t >>>>> a choice of two, i.e. countrywide (following the ITU-T E.164 definiti= on of >>>>> country) versus one more local variant. This restricted model certain= ly >>>>> covers Ivo=92s examples of Czeck Republic and Poland, and I believe i= t also >>>>> covers the other example I know of which is Italy.**** >>>>> **** >>>>> While the USA has multiple levels of police force, on the PSTN, it >>>>> only appears to have one level of access to citizen to authority emer= gency >>>>> service, which is 911. I see no reason why a change to voice over IP = would >>>>> cause a change to this.**** >>>>> **** >>>>> I would also stress that it is important to have global expectations >>>>> of what you get when you use a service URN. If there is not care exce= rcised >>>>> with assigning semantics and values, A3 in one country could result i= n the >>>>> forestry police and in another country the financial police respondin= g. >>>>> **** >>>>> **** >>>>> Note that read the scope of RFC 5031 as being for end user accessing >>>>> the emergency service. While it might be possible to apply RFC 5031 t= o >>>>> further network operations after the PSAP has been reached, e.g. to r= each a >>>>> subsidiary PSAP, I read that as outside the scope of RFC 5031. Nor do= I >>>>> necessarily believe in that scenario that service URNs are necessaril= y the >>>>> best solution for routeing, as the first PSAP should know the particu= lar >>>>> office they want to reach rather than just the type of emergency serv= ice. >>>>> **** >>>>> **** >>>>> Regards**** >>>>> **** >>>>> Keith**** >>>>> **** >>>>> ------------------------------ >>>>> *From:* ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On >>>>> Behalf Of *Winterbottom, James >>>>> *Sent:* 19 February 2013 23:29 >>>>> *To:* Ivo Sedlacek; Dan Mongrain >>>>> *Cc:* ecrit@ietf.org >>>>> *Subject:* Re: [Ecrit] What is the most appropriate method for >>>>> registering new sub-services of urn:service:sos (trimming due too lar= ge >>>>> message report)**** >>>>> **** >>>>> I am okay with this, providing that the fallback order is clearly >>>>> defined.**** >>>>> That is, does an A3 fall back to an A2 or A1, or just back to sos?***= * >>>>> **** >>>>> **** >>>>> **** >>>>> *From:* Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] >>>>> *Sent:* Wednesday, 20 February 2013 7:32 AM >>>>> *To:* Dan Mongrain >>>>> *Cc:* Winterbottom, James; Richard Barnes; ecrit@ietf.org >>>>> *Subject:* RE: [Ecrit] What is the most appropriate method for >>>>> registering new sub-services of urn:service:sos (trimming due too lar= ge >>>>> message report)**** >>>>> **** >>>>> Hello,**** >>>>> **** >>>>> If we go with RFC4119 based sub-services, would the IANA registration >>>>> request be as follows?**** >>>>> **** >>>>> - urn:service:sos.police*.A3* - The 'police.local' service refers to >>>>> the emergency service offered by the police department or other law >>>>> enforcement authorities of the authorities *of a city, township, shi >>>>> (JP)*.**** >>>>> - urn:service:sos.police*.country* - The 'police.national' service >>>>> refers to the emergency service offered by the police department or o= ther >>>>> law enforcement authorities of the government *of a country*.**** >>>>> **** >>>>> Does anyone see any issue in that?**** >>>>> **** >>>>> If WG prefers this, it is OK for me.**** >>>>> **** >>>>> > In the latter case, so how do I get the county police (or state >>>>> police, there can be up to 4 police services for a given location in = the >>>>> US). **** >>>>> **** >>>>> If I got it correctly, you propose that we also add **** >>>>> - urn:service:sos.police*.A2* - The 'police.local' service refers to >>>>> the emergency service offered by the police department or other law >>>>> enforcement authorities of the authorities *of county, parish, gun >>>>> (JP), district (IN)*"**** >>>>> - urn:service:sos.police*.A1* - The 'police.local' service refers to >>>>> the emergency service offered by the police department or other law >>>>> enforcement authorities of the authorities *of national subdivisions >>>>> (state, region, province, prefecture)*"**** >>>>> **** >>>>> While I have no problem with that, I am not aware of a regulation >>>>> establishing such emergency service so I cannot argue to IANA that th= e >>>>> RFC5031 policy is satisfied for those URNs.**** >>>>> **** >>>>> Kind regards**** >>>>> **** >>>>> Ivo Sedlacek**** >>>>> **** >>>>> **** >>>>> **** >>>>> **** >>>>> This Communication is Confidential. We only send and receive email on >>>>> the basis of the terms set out at www.ericsson.com/email_disclaimer *= * >>>>> ** >>>>> *From:* Dan Mongrain [mailto:dan@mongrain.org ] >>>>> *Sent:* 19. =FAnora 2013 21:12 >>>>> *To:* Ivo Sedlacek >>>>> *Cc:* Winterbottom, James; Richard Barnes; ecrit@ietf.org >>>>> *Subject:* Re: [Ecrit] What is the most appropriate method for >>>>> registering new sub-services of urn:service:sos (trimming due too lar= ge >>>>> message report)**** >>>>> **** >>>>> Thing is, when there is no city police, local would give you county >>>>> police (sheriff department) but in a city with a city police departme= nt >>>>> local would give you city police. In the latter case, so how do I ge= t the >>>>> county police (or state police, there can be up to 4 police services = for a >>>>> given location in the US). Note that these examples are US based, bu= t we >>>>> do have 3 levels of police services in Canada and I am sure other cou= ntries >>>>> have the same issue.**** >>>>> **** >>>>> >>>>> There is also the terminology. There is no "national" police in the >>>>> US or Canada but there is a federal police. Keeping the RFC 4119 >>>>> terminology removes any "local" interpretation issues. >>>>> >>>>> Dan**** >>>>> On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek < >>>>> ivo.sedlacek@ericsson.com> wrote:**** >>>>> I agree with Richard - there are countries where both the emergency >>>>> service of the national police and the emergency service of the munic= ipal >>>>> police are offered in a given location. **** >>>>> A user would call the municipal police emergency service to report >>>>> e.g. pickpockets.**** >>>>> A user would call the national police emergency service to report e.g= . >>>>> a murder.**** >>>>> **** >>>>> **** >>>>> I submitted to IANA a request to register:**** >>>>> - urn:service:sos.police.local - The 'police.local' service refers to >>>>> the emergency service offered by the police department or other law >>>>> enforcement authorities of the local or municipal authorities.**** >>>>> - urn:service:sos.police.national - The 'police.national' service >>>>> refers to the emergency service offered by the police department or o= ther >>>>> law enforcement authorities of the national government.**** >>>>> **** >>>>> RFC5031 policy is hopefully fulfilled for them since they exist in tw= o >>>>> countries.**** >>>>> **** >>>>> I am flexible whether the actual URNs contain the sub-services >>>>> proposed above (i.e. .local and .national sub-services) or subservice= s >>>>> based on RFC4119 (i.e. .A3 and .country sub-services).**** >>>>> **** >>>>> If the preference is for subservices based on RFC4119, do I need to >>>>> make another IANA registration request or can we modify the URNs and = their >>>>> description during the expert review?**** >>>>> **** >>>>> Kind regards**** >>>>> **** >>>>> Ivo Sedlacek**** >>>>> **** >>>>> This Communication is Confidential. We only send and receive email on >>>>> the basis of the terms set out at www.ericsson.com/email_disclaimer *= * >>>>> ** >>>>> *From:* Dan Mongrain [mailto:dan@mongrain.org] >>>>> *Sent:* 19. =FAnora 2013 15:36 >>>>> *To:* Winterbottom, James >>>>> *Cc:* Richard Barnes; Ivo Sedlacek; ecrit@ietf.org >>>>> *Subject:* Re: [Ecrit] What is the most appropriate method for >>>>> registering new sub-services of urn:service:sos**** >>>>> **** >>>>> The problem is that different countries has different names for their >>>>> political subdivisions. In the US they are states, in Canada they ar= e >>>>> provinces, etc. Same when you further subdivide. While not privy to= the >>>>> discussions that came up with A1, A2, =85, A5, I have the feeling thi= s >>>>> nomenclature was picked for the same reason. Why not utilise the sam= e >>>>> naming scheme for specifying the jurisdiction you want to reach?**** >>>>> **** >>>>> Thanx,**** >>>>> Dan**** >>>>> >>>>> **** >>>>> On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James < >>>>> James.Winterbottom@commscope.com> wrote:**** >>>>> In that case, one might say state in the hierarchy, not A1.**** >>>>> **** >>>>> Cheers**** >>>>> James**** >>>>> **** >>>>> **** >>>>> *From:* Richard Barnes [mailto:rlb@ipv.sx] >>>>> *Sent:* Tuesday, 19 February 2013 8:57 AM >>>>> *To:* Winterbottom, James >>>>> *Cc:* Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org**** >>>>> >>>>> *Subject:* Re: [Ecrit] What is the most appropriate method for >>>>> registering new sub-services of urn:service:sos**** >>>>> **** >>>>> It might make sense if you wanted to allow the caller to explicitly >>>>> select police at a different level of responsibility, e.g., the state >>>>> police rather than the local police. **** >>>>> >>>>> **** >>>>> On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James < >>>>> James.Winterbottom@commscope.com> wrote:**** >>>>> I think I am missing something here, A1 is part of the location, so >>>>> why does it need to be in the URN at all?**** >>>>> As far as I understand current deployments, they use the URN to selec= t >>>>> a layer in the GIS that corresponds to the service type, and then use >>>>> geographic boundaries within that layer to select the final destinati= on. >>>>> **** >>>>> **** >>>>> *From:* ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On >>>>> Behalf Of *Dan Mongrain >>>>> *Sent:* Tuesday, 19 February 2013 7:30 AM**** >>>>> >>>>> *To:* Ivo Sedlacek >>>>> *Cc:* ecrit@ietf.org >>>>> *Subject:* Re: [Ecrit] What is the most appropriate method for >>>>> registering new sub-services of urn:service:sos**** >>>>> **** >>>>> Sorry for responding late to this thread, it kinda fell into a >>>>> crack=85 The current thread reminded me to check this old thread=85*= *** >>>>> **** >>>>> You are indicating that we need to register 77 Service URN (11 servic= e >>>>> subtypes * 7 jurisdiction types based on RFC 4119). I do not recomme= nd >>>>> that we create so many registrations. Instead, we should allow a ser= vice >>>>> URN to be suffixed with a jurisdictional scope. So the following Ser= vice >>>>> URN are all valid:**** >>>>> **** >>>>> urn:service:sos.police**** >>>>> urn:service:sos.police.traffic**** >>>>> urn:service:sos.police.A1**** >>>>> urn:service:sos.police.traffic.A1**** >>>>> **** >>>>> Question is, do we want to leave jurisdictional scope to only be >>>>> applicable to police branch or any Service URN? I=92d say the latter= as it >>>>> is always up to the LoST service provisioning (based on local policy)= to >>>>> determine what is locally acceptable.**** >>>>> **** >>>>> Thanx,**** >>>>> Dan**** >>>>> **** >>>>> **** >>>>> ** ** >>>>> >>>> >>>> _______________________________________________ Ecrit mailing list >>>> Ecrit@ietf.orghttps://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 >> >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > --f46d04446b210ebcb304d63dbd09 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable While it is a provisioning issue, we are dealing with emergency calls here.= =A0 We are talking about introducing a number of subServices that may not b= e available in all areas.=A0 While a client SHOULD not request this subServ= ice in areas where it is not offered as it SHOULD have listed the services = available when entering the area, the LoST service must be able to deal wit= h the case the client still requests an unknown subService.=A0 It could ret= urn a Not Found and let the client deal with it (the client SHOULD be intel= ligent enough to handle properly and not propagate error to user).=A0 Also = the LoST service SHOULD be provisioned in such a way that if it gets an unk= nown subService it is handled. Still a lot of SHOULDs for an emergency call= to succeed.

We could mandate that a LoST server must give a default handling in the= case the Service URN is in the sos tree.=A0 The most sensible way to handl= e an unknown subService is to unroll the Service URN (i.e. pop the last ele= ment in the Service URN) and re-evaluate.=A0 Most LoST service will be prov= isioned for urn:service:sos (the equivalent to dialing 9-1-1 or 1-1-2) so a= ny subService down the sos tree will be handled.=A0 While I suggested that = when you get a request with an unknown jurisdictional scope you should look= for the next higher jurisdiction, the more I think about it, it should be = treated the same as an unknown subService.=A0 Just unroll the Service URN (= pop the jurisdictional scope) and re-evaluate.=A0

Dan

On Wed, Feb 20, 2013 at 6:25 PM, = Richard Barnes <rlb@ipv.sx> wrote:
Yes. =A0This.

My first reaction to thes= e suggestions of chaining was "It's a provisioning problem -- just= put the same contact information under all those URNs."


On Wed, Feb 20, 2013 at 5:02 PM, Nathan = Wilcox <ngwilcox@gmail.com> wrote:
+1

On Feb 2= 0, 2013, at 3:15 PM, Marc Linsner <mlinsner@cisco.com> wrote:

Not sure I agree with your summation. =A0In your example, .sos = IS the proper way to call .fire. =A0Just because .sos is also the proper wa= y to call .police is irrelevant.

Maybe it would be best to use a DNS-like approach. =A0N= o record =3D 'not found'. =A0No ambiguity this way. =A0Populate .so= s and .sos.fire and .sos.police all with the same uri if that is the respon= se you want. =A0If request is for .sos.help and the jurisdiction doesn'= t support .help, the response is 'not found'. =A0Why try to guess w= hat was requested?

-Marc-



From: Dan Mongrain <dan@mongrain.org>
Date: Wednesday, February 20, 2013 3:3= 2 PM
To: Marc Linsner <mlinsner@cisco.com>
Cc: "Rosen, Brian" <Brian.Rosen@neust= ar.biz>, "e= crit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] What is the m= ost appropriate method for registering new sub-services of urn:service:sos = (trimming due too large message report)

We should not infer anything from missing information especially if this in= formation is optional (as my previous message shows).=A0 Doing anything els= e is misleading at best.=A0 Requester makes a request specifying desired se= rvice nothing more.=A0 You may ask for sos.fire, but you are getting sos as= you cannot call .fire directly, local policy.=A0 If you do not like the an= swer, try again if you want with a different service (same service request = will give same response back).

Dan

On Wed, Feb 20, 2013 at 3:16 PM, = Marc Linsner <mlinsner@cisco.com> wrote:
What if I don't want A2 (I don't trust Butler County sh= eriff), if no A3 (Mars) give me A1 (PA)?

What I pr= oposed allows the requestor to tailor the request to match his desire.

The fallback is multiple requests.

=
-Marc-

From: "Rosen, Brian" <= ;Brian.Rosen@n= eustar.biz>
Date: Wednes= day, February 20, 2013 2:56 PM
To: Marc Linsner <mlinsner@cisco.com>
Cc: Dan Mongrain <dan@mongrain.org>, "ecrit@ietf.org" &l= t;ecrit@ietf.org>= ;
Subject: Re: [Ecrit] What is the m= ost appropriate method for registering new sub-services of urn:service:sos = (trimming due too large message report)

To me, this doesn't make sense.
Suppose I have a local police department in cities, but a p= rovincial police department in rural areas, as well as a national police. = =A0I ask for sos.police.A3. =A0If location was in a city, I should get sos.= police.A3

But if I was in a rural area, a request for sos.police.= A3 should return a response of sos.police.A2.

That= may or may not be the same as sos.police

Brian

On Feb 20, 2013, at 2:47 PM, Marc Linsner <mlinsner@cisco.com> wr= ote:

I understood you as requesting urn:service:sos.police.A4.
My point was that if the LoST service had no entry for A4, it = could simply check the Ax tree submitted in the location section of the req= uest. =A0So if the location included A1 & A4, the LoST service, finding= nothing for A4 would then check A1 (not A3 or A2). =A0This way the service= would be matching the hierarchy of the given location vs. an arbitrary hie= rarchy that may be different from the requestors desire.

Carry on=85

-Marc-
<= br>
From: Dan Mongrain <dan@mongrain.org>
Date: Wednesday, February 20, 2013 12:= 30 PM
To: Marc Linsner <mlinsner@cisco.com>
Cc: "Winterbottom, James" = <J= ames.Winterbottom@commscope.com>, "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] What is the m= ost appropriate method for registering new sub-services of urn:service:sos = (trimming due too large message report)

I do not understand your comment.=A0 What I am proposing is that requests d= o not specify a search pattern in the case a requested jurisdiction is not = found.=A0 It should not be to the requester which submits urn:service= :sos.police.country.A1.A2.A3.A4 to specify what to do if there is nothing c= onfigured for the A4 layer.=A0 It must be up to the LoST service to apply w= hatever policy it has in this case.=A0 If we allow this, then do we allow u= rn:service:sos.police.fire?=A0 Give me fire first but if not found give me = police?

The Service URN should specify the "desired" service in a fin= dService request and the LoST service provides a response based on local po= licies.=A0 All I am proposing is that one can specify a jurisdiction in the= case there are more then one service provider for a location.

Thanx,
Dan

On Wed, Feb 20, = 2013 at 8:48 AM, Marc Linsner <mlinsner@cisco.com> wrote:
The findService request includes location information. =A0Why w= ouldn't the LoST server simple walk the A1-A6 tree included with the lo= cation? =A0If location is geo, reverse geocode it.

What am I missing?

-Marc-

From: Dan Mongrain <dan@mongrain.org>
Date: Tuesday, February 19, 2013 11:55= PM
To: "Winterbottom, James"= ; <James.Winterbottom@commscope.com>
Cc: "ec= rit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] What is the m= ost appropriate method for registering new sub-services of urn:service:sos = (trimming due too large message report)

What I meant is that if a jurisdictional scope aware LoST service receives = a request for urn:service:sos.police.A4 and nothing is configured, it looks= for urn:service:sos.police.A3 then urn:service:sos.police.A2, etc. until i= t finds a configured service.=A0 If nothing is found for urn:service:sos.po= lice.country then it pops the last element and looks for urn:service:sos.po= lice (but then again, it is no longer jurisdictional scope aware).

I disagree that one needs to formulate the request as urn:service:sos.p= olice.country.A1.A2.A3.A4 in order for this to happen.=A0 There must be onl= y a single jurisdictional scope appended to a Service URN.

I do not = think we need a .A6 jurisdictional scope (street level).=A0 .A5 (neighborho= od, would point to a precinct for example) provides enough granularity in m= y opinion.

Thanx,
Dan


On Tue, Feb 19, 201= 3 at 11:29 PM, Winterbottom, James <James.Winterbottom@comm= scope.com> wrote:
I am sorry, I am find= ing this confusing.
=A0
RFC5139 puts a hierarchy on A1 through A6. If you wa= nt this hierarchy to work then A1 through A6 can=92t be at the same level i= f you expect A3 to fallback to A2 or A1 in the case of a service not existi= ng or a service failure of some kind. If they exist at the same level then = if A3 doesn=92t exist you will go to urn:service:sos.police=A0 unless you i= mpose the hierarchy in the urn.
=A0
=A0
=A0
=A0
=A0
<= div class=3D"MsoNormal"> From: Dan Mong= rain [mailto:dan@mong= rain.org]
Sent: Wednesday, 20 February 2013 3:23 PM
To: DRAGE, Keith= (Keith)
Cc: Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org
Subject: Re= : [Ecrit] What is the most appropriate method for registering new sub-servi= ces of urn:service:sos (trimming due too large message report)
=A0

My recommendation for handling unknown Ser= vice URN depends if LoST service implements jurisdictional scope or not.=A0= If it does not, it pops the last element and evaluates until a service is = found.=A0 If it implements jurisdictional scope, the last element is a juri= sdictional scope and it is not found, then you return the next highest leve= l defined.

While it may be true that citizens typically dial 9-1-1 to request for = help, police services such as state or provincial polices advertises number= s to call them directly (star code to dial using a mobile phone for example= ) especially to report accidents on freeways.=A0 We need an equivalent Serv= ice URN.

Also while RFC5031's scope is citizen to authorities (I am not sure= I agree with this) I do not want to re-invent the wheel to signal calls wi= thin an Emergency Services IP Network (ESInet).=A0 When I transfer a call f= rom one PSAP to another, the mechanism to determine where to send the call = is the same, using LoST.=A0 For a PSAP that covers a large area spanning mu= ltiple counties and the calltaker needs to transfer the call to the appropr= iate sheriff department for the caller's location, they only need a sin= gle transfer target (urn:service:sos.police.A2).=A0 It is not true that the= calltaker always knows the actual destination of the call, especially when= the calltaker is only a call screener.

Thanx,
Dan

On Tue, Fe= b 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com= > wrote:
The answer to James=92s question d= epends on how you code it (and also what you mean by fallback).
=A0<= u>
On any service URN, = you ignore any subtypes from the point you stop understanding it.
=A0<= u>
So if the coding is = sos.police.A2, and you do not understand A2, then the service URN would be = handled as if it was sos.police, not as sos.police.A1. And if police was no= t understood then it would be handled as sos.
=A0<= u>
If you wanted someth= ing that went back to the next larger regional coverage, then you would hav= e to code successive subtypes in sequence.
=A0<= u>
But I would also ask= for an element of sanity in this discussion, rather than total flexibility= .
=A0<= u>
For example while a = national administration may have multiple levels of police force, not all o= f them are either reachable directly as an emergency service provider, nor = are they necessarily an emergency service provider. If they are neither of = these, then they presumably do not need a special and distinct service URN.=
=A0<= u>
It would therefore n= ice to see a current use case that is anything but a choice of two, i.e. co= untrywide (following the ITU-T E.164 definition of country) versus one more= local variant. This restricted model certainly covers Ivo=92s examples of = Czeck Republic and Poland, and I believe it also covers the other example I= know of which is Italy.
=A0<= u>
While the USA has mu= ltiple levels of police force, on the PSTN, it only appears to have one lev= el of access to citizen to authority emergency service, which is 911. I see= no reason why a change to voice over IP would cause a change to this.
=A0<= u>
I would also stress = that it is important to have global expectations of what you get when you u= se a service URN. If there is not care excercised with assigning semantics = and values, A3 in one country could result in the forestry police and in an= other country the financial police responding.<= u>
=A0<= u>
Note that read the s= cope of RFC 5031 as being for end user accessing the emergency service. Whi= le it might be possible to apply RFC 5031 to further network operations aft= er the PSAP has been reached, e.g. to reach a subsidiary PSAP, I read that = as outside the scope of RFC 5031. Nor do I necessarily believe in that scen= ario that service URNs are necessarily the best solution for routeing, as t= he first PSAP should know the particular office they want to reach rather t= han just the type of emergency service.<= u>
=A0<= u>
Regards
=A0<= u>
Keith
=A0<= u>
=
From: ecrit-bounces@ietf.o= rg [mailto:= ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James
Sent: 19 February 2013 23:29
To: Ivo Sedlacek; Dan Mongrai= n
Cc: ecrit@i= etf.org
Subject: Re: [Ecrit] What is the most appropriate met= hod for registering new sub-services of urn:service:sos (trimming due too l= arge message report)
=A0
I am okay with this, providing that= the fallback order is clearly defined.<= u>
That is, does an A3 fall back to an A2 or = A1, or just back to sos?
=A0<= /u>
=A0
=A0<= /u>
From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com]
Sent: Wednesday, 20 February 2013 7:32 AM
To: Dan Mongrain=
Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: RE: [Ecr= it] What is the most appropriate method for registering new sub-services of= urn:service:sos (trimming due too large message report)
=A0=
Hello,
=A0
If we go with RFC4119 based su= b-services, would the IANA registration request be as follows?
=A0
- urn:service:sos.police.A3= =A0- The 'police.local' service refers to the emergency service= offered by the police department or other law enforcement authorities of t= he authorities=A0of a city, township, shi (JP).
- urn:service:sos.police.country=A0- = The 'police.national' service refers to the emergency service offer= ed by the police department or other law enforcement authorities of the gov= ernment=A0of a country.
=A0
Does anyone see any issue in t= hat?
=A0
If WG prefers this, it is OK f= or me.
=A0
> In the latter case, so how do I= get the county police (or state police, there can be up to 4 police servic= es for a given location in the US).=A0 <= u>
=A0
If I got it correctly, you pro= pose that we also add
- urn:service:sos.police.A2 - The = 9;police.local' service refers to the emergency service offered by the = police department or other law enforcement authorities of the authorities= =A0of county, parish, gun (JP), district (IN)"
- urn:service:sos.police.A1 - The = 9;police.local' service refers to the emergency service offered by the = police department or other law enforcement authorities of the authorities= =A0of national subdivisions (state, region, province, prefecture)&qu= ot;
=A0
While I have no problem with t= hat, I am not aware of a regulation establishing such emergency service so = I cannot argue to IANA that the RFC5031 policy is satisfied for those URNs.=
=A0
Kind regards
=A0
Ivo Sedlacek
=A0
=A0
=A0
=A0
This Communication is Confidential. We only se= nd and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer =
From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19. =FAnora 2013 21:12
To: Ivo Sedlacek
Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: Re: [Ecrit] What is t= he most appropriate method for registering new sub-services of urn:service:= sos (trimming due too large message report)<= /u>
=A0
Thing is, when there is no city police, local would give you c= ounty police (sheriff department) but in a city with a city police departme= nt local would give you city police.=A0 In the latter case, so how do I get= the county police (or state police, there can be up to 4 police services f= or a given location in the US).=A0 Note that these examples are US based, b= ut we do have 3 levels of police services in Canada and I am sure other cou= ntries have the same issue.
=A0<= /u>

There is also the terminology.=A0 There is no "national" police i= n the US or Canada but there is a federal police.=A0 Keeping the RFC 4119 t= erminology removes any "local" interpretation issues.

Dan<= span lang=3D"EN-GB">

On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek= <ivo.sed= lacek@ericsson.com> wrote:=
I agree with Richard - there are countr= ies where both the emergency service of the national police and the emergen= cy service of the municipal police are offered in a given location. =
A user would call the municipal police emerg= ency service to report e.g. pickpockets.=
A user would call the national police emerge= ncy service to report e.g. a murder.<= /u>
=A0
=A0
I submitted to IANA a request to register:
- urn:service:sos.police.local - The 'police.local' service r= efers to the emergency service offered by the police department or other la= w enforcement authorities of the local or municipal authorities.
- urn:service:sos.police.national - The '= ;police.national' service refers to the emergency service offered by th= e police department or other law enforcement authorities of the national go= vernment.
=A0
RFC5031 policy is hopefully fu= lfilled for them since they exist in two countries.
=A0
I am flexible whether the actu= al URNs contain the sub-services proposed above (i.e. .local and .national = sub-services) or subservices based on RFC4119 (i.e. .A3 and .country sub-se= rvices).
=A0
If the preference is for subse= rvices based on RFC4119, do I need to make another IANA registration reques= t or can we modify the URNs and their description during the expert review?=
=A0
Kind regards
=A0
Ivo Sedlacek
=A0
This Communication is Confidenti= al. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaim= er
From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: 19. =FAnora 2013 15:36
To: Winterbottom, James
Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org
Subject: Re: [Ecrit] What is t= he most appropriate method for registering new sub-services of urn:service:= sos
=A0
The problem is that different countries h= as different names for their political subdivisions.=A0 In the US they are = states, in Canada they are provinces, etc.=A0 Same when you further subdivi= de.=A0 While not privy to the discussions that came up with A1, A2, =85, A5= , I have the feeling this nomenclature was picked for the same reason.=A0 W= hy not utilise the same naming scheme for specifying the jurisdiction you w= ant to reach?
=A0<= /u>
Thanx,
Dan<= /u>

=A0

On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James <James.Winterbottom@= commscope.com> wrote:
In that case, one might say state in = the hierarchy, not A1.
=A0<= /u>
Cheers
James
=A0
=A0<= /u>
From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Tuesday, 19 February 2013 8:57 AM
To: Winterbottom, = James
Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org<= /u>

Subject: Re: [Ecrit] What is the m= ost appropriate method for registering new sub-services of urn:service:sos<= span lang=3D"EN-GB">
=A0
It might make sense if you wanted to allow the caller to explicitly s= elect police at a different level of responsibility, e.g., the state police= rather than the local police. =A0

=A0

On Mon= , Feb 18, 2013 at 4:21 PM, Winterbottom, James <James.Winterbottom@commscope.= com> wrote:
I think I am missing something here, = A1 is part of the location, so why does it need to be in the URN at all?
As far as I understand current deployments= , they use the URN to select a layer in the GIS that corresponds to the ser= vice type, and then use geographic boundaries within that layer to select t= he final destination.
=A0<= /u>
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Dan M= ongrain
Sent: Tuesday, 19 February 2013 7:30 AM<= u>

To: Ivo = Sedlacek
Cc: = ecrit@ietf.org
Subject: Re: [Ecrit] What is the most appropriate method for registe= ring new sub-services of urn:service:sos=
=A0
Sorry for responding late to this thread, = it kinda fell into a=A0 crack=85=A0 The current thread reminded me to check= this old thread=85
=A0<= /u>
You are indicating that we= need to register 77 Service URN (11 service subtypes * 7 jurisdiction type= s based on RFC 4119).=A0 I do not recommend that we create so many registra= tions.=A0 Instead, we should allow a service URN to be suffixed with a juri= sdictional scope.=A0 So the following Service URN are all valid:
=A0<= /u>
urn:service:sos.police
urn:service:sos.police.traffic
urn:service:sos.police.A1=
urn:service:sos.police.traffic.A1
=A0
Question is, do we want to leave jurisdict= ional scope to only be applicable to police branch or any Service URN? =A0I= =92d say the latter as it is always up to the LoST service provisioning (ba= sed on local policy) to determine what is locally acceptable.
=A0<= /u>
Thanx,
Dan<= /u>
=A0
=A0
=A0

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

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

<= /div>
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
http= s://www.ietf.org/mailman/listinfo/ecrit


________________________= _______________________
Ecrit mailing list
Ecrit@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ecrit



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


--f46d04446b210ebcb304d63dbd09-- From James.Winterbottom@commscope.com Thu Feb 21 15:19:06 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12D721E803D for ; Thu, 21 Feb 2013 15:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[AWL=-0.394, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HD3lFyW-YDqT for ; Thu, 21 Feb 2013 15:18:55 -0800 (PST) Received: from cdcsmgw01.commscope.com (cdcsmgw01.commscope.com [198.135.207.232]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0B721E8039 for ; Thu, 21 Feb 2013 15:18:55 -0800 (PST) X-AuditID: 0a0404e8-b7f8f6d0000051af-b6-5126ab5d233a Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Messaging Gateway) with SMTP id B1.70.20911.D5BA6215; Thu, 21 Feb 2013 17:18:53 -0600 (CST) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 21 Feb 2013 17:18:52 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 22 Feb 2013 07:18:49 +0800 From: "Winterbottom, James" To: Richard Barnes , Nathan Wilcox Date: Fri, 22 Feb 2013 07:18:47 +0800 Thread-Topic: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) Thread-Index: Ac4PwZBwXaC37HisRQ6LHxk00oCM/QAx/o/A Message-ID: <5A55A45AE77F5941B18E5457ECAC81880121407714FE@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC81880121407714FESISPE7MB1co_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA01Sa0hTYRju287mcXjiOLV9rfrRyTQ1dUqEhElYwggEDRITRI/bcRvsIjve Flgzi0gqw9Ryf1xeU6upmHgJwqk/VFJJUBG7qqkTjYTygmnnorZ/z/u+z+V7v+9DhdItkRzV GbMps5HUE2IJIkny1YSmNgckKiY/KKIqBseFUYXV86Ko4Z5VJKr88cVLiLLL9slDWVu7KVA+ bbUhyk7rgjABSZFEqym9Lpcyh8ekS7Ql48Mg62G/KN/a4BBZwdstpBh4ohA/B6c6CoU8PgLH PjvExUCCSvEeALur3oj4ogXAb02rAr5wAPh1ZFvASsR4DOxzTHFyX/wy7KwbFbFYiCdCu/0H hxH8NNwtc3FiH7wCwO1NG1f44s8ArOudFvPqSDjzc5dRoCiGX4P9xSif1ghgzcd2LsGTcXVN r3OugDns+tArAZ8mg9NzVQJ+CRzWvhvdW8gPLs3u7PH94Mx9B+D5Jjix8oDrY7g3HKyc4y5D iofCO12/RU+AzOZma3OT2NwkfD8MTpWXiXkcAutfLAt5HAqf7zgR974deDQBmUqtog2aPEVE mMpkMNAqUxbFojbAPjWCLHaC4ZYQJ8BRQHhh1isBiVIRmUtbDE5wFBUQfljGS6Z1OMOktmhJ WptmztFTtBNAVEj4YuHXmRmmJi03KbNpf3QGRfHhuS9DQI4YTUaKgBjRxNC8zZSGys/U6Zmf tk8VoJ6slRdj5cNyMDqLNNA6DT8fAiGofeL7IkCLGhYWgZSzk8uwIJaKs1RtjvHAzQVkzAo+ 2FojM/ViPvSBj4uJEDARrxtOsRHZ5P+R3Aos8ZOgI3Jp7VDsQEN6cqL6uDgzvijtwqxHYPZs bEqB/40gbVhaHLlR6ArAHt3aSbg9MK71p1uLIqRbaeLzC7R5wlYpzkMLPE/WBI+ZqxMUuT3v 7/UmEaUrx1pSm7sn7qZmzyjbRn5djT47b/wTF3jIsZGsPlFS2mdYtrT/rU8hEFpLRgQLzTT5 D6z4tVyNAwAA Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] What is the most appropriate method for registering new sub-services of urn:service:sos (trimming due too large message report) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 23:19:07 -0000 --_000_5A55A45AE77F5941B18E5457ECAC81880121407714FESISPE7MB1co_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Wouldn't the LoST server simply include the response with a warning if the = mapping was substituted? This then let's URN pruning occur and the UE still gets something as well a= s a notification that it wasn't what they asked for. Cheers James From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of R= ichard Barnes Sent: Thursday, 21 February 2013 10:25 AM To: Nathan Wilcox Cc: Rosen, Brian; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) Yes. This. My first reaction to these suggestions of chaining was "It's a provisioning= problem -- just put the same contact information under all those URNs." On Wed, Feb 20, 2013 at 5:02 PM, Nathan Wilcox > wrote: +1 On Feb 20, 2013, at 3:15 PM, Marc Linsner > wrote: Not sure I agree with your summation. In your example, .sos IS the proper = way to call .fire. Just because .sos is also the proper way to call .polic= e is irrelevant. Maybe it would be best to use a DNS-like approach. No record =3D 'not foun= d'. No ambiguity this way. Populate .sos and .sos.fire and .sos.police al= l with the same uri if that is the response you want. If request is for .s= os.help and the jurisdiction doesn't support .help, the response is 'not fo= und'. Why try to guess what was requested? -Marc- From: Dan Mongrain > Date: Wednesday, February 20, 2013 3:32 PM To: Marc Linsner > Cc: "Rosen, Brian" = >, "ecrit@ietf.org" > Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) We should not infer anything from missing information especially if this in= formation is optional (as my previous message shows). Doing anything else = is misleading at best. Requester makes a request specifying desired servic= e nothing more. You may ask for sos.fire, but you are getting sos as you c= annot call .fire directly, local policy. If you do not like the answer, tr= y again if you want with a different service (same service request will giv= e same response back). Dan On Wed, Feb 20, 2013 at 3:16 PM, Marc Linsner > wrote: What if I don't want A2 (I don't trust Butler County sheriff), if no A3 (Ma= rs) give me A1 (PA)? What I proposed allows the requestor to tailor the request to match his des= ire. The fallback is multiple requests. -Marc- From: "Rosen, Brian" > Date: Wednesday, February 20, 2013 2:56 PM To: Marc Linsner > Cc: Dan Mongrain >, "ecrit@ietf.o= rg" > Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) To me, this doesn't make sense. Suppose I have a local police department in cities, but a provincial police= department in rural areas, as well as a national police. I ask for sos.po= lice.A3. If location was in a city, I should get sos.police.A3 But if I was in a rural area, a request for sos.police.A3 should return a r= esponse of sos.police.A2. That may or may not be the same as sos.police Brian On Feb 20, 2013, at 2:47 PM, Marc Linsner > wrote: I understood you as requesting urn:service:sos.police.A4. My point was that if the LoST service had no entry for A4, it could simply = check the Ax tree submitted in the location section of the request. So if = the location included A1 & A4, the LoST service, finding nothing for A4 wou= ld then check A1 (not A3 or A2). This way the service would be matching th= e hierarchy of the given location vs. an arbitrary hierarchy that may be di= fferent from the requestors desire. Carry on... -Marc- From: Dan Mongrain > Date: Wednesday, February 20, 2013 12:30 PM To: Marc Linsner > Cc: "Winterbottom, James" >, "ecrit@ietf.org" > Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) I do not understand your comment. What I am proposing is that requests do = not specify a search pattern in the case a requested jurisdiction is not fo= und. It should not be to the requester which submits urn:service:sos.polic= e.country.A1.A2.A3.A4 to specify what to do if there is nothing configured = for the A4 layer. It must be up to the LoST service to apply whatever poli= cy it has in this case. If we allow this, then do we allow urn:service:sos= .police.fire? Give me fire first but if not found give me police? The Service URN should specify the "desired" service in a findService reque= st and the LoST service provides a response based on local policies. All I= am proposing is that one can specify a jurisdiction in the case there are = more then one service provider for a location. Thanx, Dan On Wed, Feb 20, 2013 at 8:48 AM, Marc Linsner > wrote: The findService request includes location information. Why wouldn't the Lo= ST server simple walk the A1-A6 tree included with the location? If locati= on is geo, reverse geocode it. What am I missing? -Marc- From: Dan Mongrain > Date: Tuesday, February 19, 2013 11:55 PM To: "Winterbottom, James" > Cc: "ecrit@ietf.org" > Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) What I meant is that if a jurisdictional scope aware LoST service receives = a request for urn:service:sos.police.A4 and nothing is configured, it looks= for urn:service:sos.police.A3 then urn:service:sos.police.A2, etc. until i= t finds a configured service. If nothing is found for urn:service:sos.poli= ce.country then it pops the last element and looks for urn:service:sos.poli= ce (but then again, it is no longer jurisdictional scope aware). I disagree that one needs to formulate the request as urn:service:sos.polic= e.country.A1.A2.A3.A4 in order for this to happen. There must be only a si= ngle jurisdictional scope appended to a Service URN. I do not think we need a .A6 jurisdictional scope (street level). .A5 (nei= ghborhood, would point to a precinct for example) provides enough granulari= ty in my opinion. Thanx, Dan On Tue, Feb 19, 2013 at 11:29 PM, Winterbottom, James > wrote: I am sorry, I am finding this confusing. RFC5139 puts a hierarchy on A1 through A6. If you want this hierarchy to wo= rk then A1 through A6 can't be at the same level if you expect A3 to fallba= ck to A2 or A1 in the case of a service not existing or a service failure o= f some kind. If they exist at the same level then if A3 doesn't exist you w= ill go to urn:service:sos.police unless you impose the hierarchy in the ur= n. From: Dan Mongrain [mailto:dan@mongrain.org] Sent: Wednesday, 20 February 2013 3:23 PM To: DRAGE, Keith (Keith) Cc: Winterbottom, James; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) My recommendation for handling unknown Service URN depends if LoST service = implements jurisdictional scope or not. If it does not, it pops the last e= lement and evaluates until a service is found. If it implements jurisdicti= onal scope, the last element is a jurisdictional scope and it is not found,= then you return the next highest level defined. While it may be true that citizens typically dial 9-1-1 to request for help= , police services such as state or provincial polices advertises numbers to= call them directly (star code to dial using a mobile phone for example) es= pecially to report accidents on freeways. We need an equivalent Service UR= N. Also while RFC5031's scope is citizen to authorities (I am not sure I agree= with this) I do not want to re-invent the wheel to signal calls within an = Emergency Services IP Network (ESInet). When I transfer a call from one PS= AP to another, the mechanism to determine where to send the call is the sam= e, using LoST. For a PSAP that covers a large area spanning multiple count= ies and the calltaker needs to transfer the call to the appropriate sheriff= department for the caller's location, they only need a single transfer tar= get (urn:service:sos.police.A2). It is not true that the calltaker always = knows the actual destination of the call, especially when the calltaker is = only a call screener. Thanx, Dan On Tue, Feb 19, 2013 at 7:18 PM, DRAGE, Keith (Keith) > wrote: The answer to James's question depends on how you code it (and also what yo= u mean by fallback). On any service URN, you ignore any subtypes from the point you stop underst= anding it. So if the coding is sos.police.A2, and you do not understand A2, then the s= ervice URN would be handled as if it was sos.police, not as sos.police.A1. = And if police was not understood then it would be handled as sos. If you wanted something that went back to the next larger regional coverage= , then you would have to code successive subtypes in sequence. But I would also ask for an element of sanity in this discussion, rather th= an total flexibility. For example while a national administration may have multiple levels of pol= ice force, not all of them are either reachable directly as an emergency se= rvice provider, nor are they necessarily an emergency service provider. If = they are neither of these, then they presumably do not need a special and d= istinct service URN. It would therefore nice to see a current use case that is anything but a ch= oice of two, i.e. countrywide (following the ITU-T E.164 definition of coun= try) versus one more local variant. This restricted model certainly covers = Ivo's examples of Czeck Republic and Poland, and I believe it also covers t= he other example I know of which is Italy. While the USA has multiple levels of police force, on the PSTN, it only app= ears to have one level of access to citizen to authority emergency service,= which is 911. I see no reason why a change to voice over IP would cause a = change to this. I would also stress that it is important to have global expectations of wha= t you get when you use a service URN. If there is not care excercised with = assigning semantics and values, A3 in one country could result in the fores= try police and in another country the financial police responding. Note that read the scope of RFC 5031 as being for end user accessing the em= ergency service. While it might be possible to apply RFC 5031 to further ne= twork operations after the PSAP has been reached, e.g. to reach a subsidiar= y PSAP, I read that as outside the scope of RFC 5031. Nor do I necessarily = believe in that scenario that service URNs are necessarily the best solutio= n for routeing, as the first PSAP should know the particular office they wa= nt to reach rather than just the type of emergency service. Regards Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Winterbottom, = James Sent: 19 February 2013 23:29 To: Ivo Sedlacek; Dan Mongrain Cc: ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) I am okay with this, providing that the fallback order is clearly defined. That is, does an A3 fall back to an A2 or A1, or just back to sos? From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] Sent: Wednesday, 20 February 2013 7:32 AM To: Dan Mongrain Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org Subject: RE: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) Hello, If we go with RFC4119 based sub-services, would the IANA registration reque= st be as follows? - urn:service:sos.police.A3 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of a city, township, shi (JP). - urn:service:sos.police.country - The 'police.national' service refers to = the emergency service offered by the police department or other law enforce= ment authorities of the government of a country. Does anyone see any issue in that? If WG prefers this, it is OK for me. > In the latter case, so how do I get the county police (or state police, t= here can be up to 4 police services for a given location in the US). If I got it correctly, you propose that we also add - urn:service:sos.police.A2 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of county, parish, gun (JP), district (IN)" - urn:service:sos.police.A1 - The 'police.local' service refers to the emer= gency service offered by the police department or other law enforcement aut= horities of the authorities of national subdivisions (state, region, provin= ce, prefecture)" While I have no problem with that, I am not aware of a regulation establish= ing such emergency service so I cannot argue to IANA that the RFC5031 polic= y is satisfied for those URNs. 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 21:12 To: Ivo Sedlacek Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report) Thing is, when there is no city police, local would give you county police = (sheriff department) but in a city with a city police department local woul= d give you city police. In the latter case, so how do I get the county pol= ice (or state police, there can be up to 4 police services for a given loca= tion in the US). Note that these examples are US based, but we do have 3 l= evels of police services in Canada and I am sure other countries have the s= ame issue. There is also the terminology. There is no "national" police in the US or = Canada but there is a federal police. Keeping the RFC 4119 terminology rem= oves any "local" interpretation issues. Dan On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek > wrote: I agree with Richard - there are countries where both the emergency service= of the national police and the emergency service of the municipal police a= re offered in a given location. A user would call the municipal police emergency service to report e.g. pic= kpockets. A user would call the national police emergency service to report e.g. a mu= rder. I submitted to IANA a request to register: - urn:service:sos.police.local - The 'police.local' service refers to the e= mergency service offered by the police department or other law enforcement = authorities of the local or municipal authorities. - urn:service:sos.police.national - The 'police.national' service refers to= the emergency service offered by the police department or other law enforc= ement authorities of the national government. RFC5031 policy is hopefully fulfilled for them since they exist in two coun= tries. I am flexible whether the actual URNs contain the sub-services proposed abo= ve (i.e. .local and .national sub-services) or subservices based on RFC4119= (i.e. .A3 and .country sub-services). If the preference is for subservices based on RFC4119, do I need to make an= other IANA registration request or can we modify the URNs and their descrip= tion during the expert review? 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 From: Dan Mongrain [mailto:dan@mongrain.org] Sent: 19. =FAnora 2013 15:36 To: Winterbottom, James Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos The problem is that different countries has different names for their polit= ical subdivisions. In the US they are states, in Canada they are provinces= , etc. Same when you further subdivide. While not privy to the discussion= s that came up with A1, A2, ..., A5, I have the feeling this nomenclature w= as picked for the same reason. Why not utilise the same naming scheme for = specifying the jurisdiction you want to reach? Thanx, Dan On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James > wrote: In that case, one might say state in the hierarchy, not A1. Cheers James From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Tuesday, 19 February 2013 8:57 AM To: Winterbottom, James Cc: Dan Mongrain; Ivo Sedlacek; ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos It might make sense if you wanted to allow the caller to explicitly select = police at a different level of responsibility, e.g., the state police rathe= r than the local police. On Mon, Feb 18, 2013 at 4:21 PM, Winterbottom, James > wrote: I think I am missing something here, A1 is part of the location, so why doe= s it need to be in the URN at all? As far as I understand current deployments, they use the URN to select a la= yer in the GIS that corresponds to the service type, and then use geographi= c boundaries within that layer to select the final destination. From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Dan Mongrain Sent: Tuesday, 19 February 2013 7:30 AM To: Ivo Sedlacek Cc: ecrit@ietf.org Subject: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos Sorry for responding late to this thread, it kinda fell into a crack... T= he current thread reminded me to check this old thread... You are indicating that we need to register 77 Service URN (11 service subt= ypes * 7 jurisdiction types based on RFC 4119). I do not recommend that we= create so many registrations. Instead, we should allow a service URN to b= e suffixed with a jurisdictional scope. So the following Service URN are a= ll valid: urn:service:sos.police urn:service:sos.police.traffic urn:service:sos.police.A1 urn:service:sos.police.traffic.A1 Question is, do we want to leave jurisdictional scope to only be applicable= to police branch or any Service URN? I'd say the latter as it is always u= p to the LoST service provisioning (based on local policy) to determine wha= t is locally acceptable. Thanx, Dan _______________________________________________ Ecrit mailing list Ecrit@ie= tf.orghttps://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_5A55A45AE77F5941B18E5457ECAC81880121407714FESISPE7MB1co_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 


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

 

= --_000_5A55A45AE77F5941B18E5457ECAC81880121407714FESISPE7MB1co_-- From bernard_aboba@hotmail.com Thu Feb 21 22:02:22 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB17A21F8D0B for ; Thu, 21 Feb 2013 22:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.652 X-Spam-Level: X-Spam-Status: No, score=-101.652 tagged_above=-999 required=5 tests=[AWL=-0.449, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJ0ctaRPnGSO for ; Thu, 21 Feb 2013 22:02:22 -0800 (PST) Received: from blu0-omc3-s30.blu0.hotmail.com (blu0-omc3-s30.blu0.hotmail.com [65.55.116.105]) by ietfa.amsl.com (Postfix) with ESMTP id 0531D21F8C75 for ; Thu, 21 Feb 2013 22:02:21 -0800 (PST) Received: from BLU405-EAS323 ([65.55.116.74]) by blu0-omc3-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Feb 2013 22:02:21 -0800 X-EIP: [N/PRbLJFW//GSpegbJT0pTAVuebGkr7J] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Bernard Aboba Date: Thu, 21 Feb 2013 22:02:23 -0800 To: ecrit MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 22 Feb 2013 06:02:21.0123 (UTC) FILETIME=[2D5F1930:01CE10C2] Subject: [Ecrit] IETF 86 Technical Plenary Topic: The End of POTS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 06:02:22 -0000 The IAB has selected the topic for the IETF 86 Technical Plenary: The End of= Plain Old Telephone Service (POTS). For more details, see:=20 http://www.iab.org/2013/02/22/ietf-86-technical-plenary-topic-the-end-of-pla= in-old-telephone-service-pots/=20 =20 In enable members of the community to share information on the staus of the P= OTS transition worldwide (including next generation emergency services deplo= yment plans), the IAB has established a Wiki:=20 http://trac.tools.ietf.org/group/iab/trac/wiki.=20 =20 Contributions welcome. From internet-drafts@ietf.org Mon Feb 25 02:13:26 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84C121F8F39; Mon, 25 Feb 2013 02:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6JZaENXHFQq; Mon, 25 Feb 2013 02:13:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706D521F8FCE; Mon, 25 Feb 2013 02:13:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225101325.25069.60264.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 02:13:25 -0800 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-psap-callback-08.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 10:13:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Public Safety Answering Point (PSAP) Callback Author(s) : Henning Schulzrinne Hannes Tschofenig Christer Holmberg Milan Patel Filename : draft-ietf-ecrit-psap-callback-08.txt Pages : 19 Date : 2013-02-25 Abstract: After an emergency call is completed (either prematurely terminated by the emergency caller or normally by the call taker) it is possible that the call taker feels the need for further communication. For example, the call may have been dropped by accident without the call taker having sufficient information about the current situation of a wounded person. A call taker may trigger a callback towards the emergency caller using the contact information provided with the initial emergency call. This callback could, under certain circumstances, be treated like any other call and as a consequence it may get blocked by authorization policies or may get forwarded to an answering machine. The IETF emergency services architecture specification already offers a solution approach for allowing PSAP callbacks to bypass authorization policies to reach the caller without unnecessary delays. Unfortunately, the specified mechanism only supports limited scenarios. This document discusses shortcomings of the current mechanisms and illustrates additional scenarios where better-than- normal call treatment behavior would be desirable. A solution based on a new header field value, called "psap-callback", for the SIP Priority header field is specified to accomplish the PSAP callback marking. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-psap-callback-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-psap-callback-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hannes.tschofenig@gmx.net Mon Feb 25 02:42:15 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BB221F9240 for ; Mon, 25 Feb 2013 02:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WJ83aOICcE4 for ; Mon, 25 Feb 2013 02:42:14 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCC121F927D for ; Mon, 25 Feb 2013 02:42:14 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.1]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LdKAB-1UaDv13bPN-00iQl4 for ; Mon, 25 Feb 2013 11:42:10 +0100 Received: (qmail invoked by alias); 25 Feb 2013 10:42:10 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.100]) [88.115.219.140] by mail.gmx.net (mp001) with SMTP; 25 Feb 2013 11:42:10 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+TenEHSeGTDuUoJdOsGXN2qiUMiuJAXlO79tJtiI xsdH+79/3e6MiP From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Feb 2013 12:42:09 +0200 Message-Id: <3317504E-7742-4688-AC91-A309CA22E148@gmx.net> To: "ecrit@ietf.org Org" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [Ecrit] draft-ietf-ecrit-psap-callback-08.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 10:42:15 -0000 Hi all,=20 I submitted version -08 of the PSAP callback draft. The WGLC ended on = the 12th February and only Bernard spotted one minor bug in the = document, see=20 http://www.ietf.org/mail-archive/web/ecrit/current/msg08291.html I would therefore recommend to submit the document to the IESG for = publication.=20 Ciao Hannes From christer.holmberg@ericsson.com Mon Feb 25 02:54:31 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F87021F92AE for ; Mon, 25 Feb 2013 02:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.256 X-Spam-Level: X-Spam-Status: No, score=-6.256 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WijU+3GzKmh for ; Mon, 25 Feb 2013 02:54:30 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E8FE321F92AC for ; Mon, 25 Feb 2013 02:54:29 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-38-512b42e4a970 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id EF.E4.32353.4E24B215; Mon, 25 Feb 2013 11:54:28 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 11:54:27 +0100 From: Christer Holmberg To: "ecrit@ietf.org" Thread-Topic: Draft new version: draft-holmberg-ecrit-country-emg-urn-01 Thread-Index: Ac4TRihzTH80bKVyTc6Jt+P7fL6PxA== Date: Mon, 25 Feb 2013 10:54:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B105DFB@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B105DFBESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+Jvje4TJ+1Ag8nzVCwaFz1ldWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvMVl9kK2iUrJu9VaGCcKtbFyMkhIWAi8frWMiYIW0ziwr31 bF2MXBxCAocYJfb9PswM4SxmlLjY9xCoioODTcBCovufNkiDiICqxIYzKxlBbGEBZ4m3pxpZ IeIeEls7p7FB2HoS25+BxDk4WIDqP340AwnzCnhLnOlazQ5iMwLt/X5qDdgNzALiEreezIe6 R0BiyZ7zzBC2qMTLx/9YIWxFiavTl0PV50u8W/OEBWKmoMTJmU9YJjAKzUIyahaSsllIyiDi OhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRvbcxMyc9HLzTYzAkD+45bfBDsZN98UOMUpz sCiJ84a7XggQEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwFiQtMAkpfTOtEQuRekisSqT9raF kSXmKoyzYnzPWm32b14XbmNp36zsHhQ29fF05uJte9Ytaza13et/fK/w7wPOiUaT1GaZHLcy nnf/mrXPURYDoU1yi13uHf5f80T6zzJNjzwbi/eVO4+vviW8Y0209/IDBy9xb8s3mfr3+G4j r9/aziu3SyixFGckGmoxFxUnAgBCyBXWRwIAAA== Subject: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 10:54:31 -0000 --_000_7594FB04B1934943A5C02806D1A2204B105DFBESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version (-01) of draft-holmberg-ecrit-country-emg-urn-= 01. The only change is a tiny editorial fix. Note, that due to a timing issue, I wasn't able to add the alternative of r= elaxing the registration rules for the existing registry, but that alternat= ive WILL be on the slides for Orlando. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B105DFBESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve submitted a new version (-01) of draft-ho= lmberg-ecrit-country-emg-urn-01.

 

The only change is a tiny editorial fix.<= /p>

 

Note, that due to a timing issue, I wasn’t abl= e to add the alternative of relaxing the registration rules for the existin= g registry, but that alternative WILL be on the slides for Orlando.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B105DFBESESSMB209ericsso_-- From mserra@ravemobilesafety.com Mon Feb 25 11:43:21 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C66A21F932A for ; Mon, 25 Feb 2013 11:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOClD0fkaJGK for ; Mon, 25 Feb 2013 11:43:20 -0800 (PST) Received: from server505.appriver.com (server505a.appriver.com [98.129.35.4]) by ietfa.amsl.com (Postfix) with ESMTP id D9D4921F9327 for ; Mon, 25 Feb 2013 11:43:17 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/25/2013 1:43:16 PM X-Policy: GLOBAL - ravemobilesafety.com X-Policy: GLOBAL - ravemobilesafety.com X-Primary: mserra@ravemobilesafety.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: @ravemobilesafety.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES X-Note-Sending-IP: 98.129.35.1 X-Note-Reverse-DNS: smtp.exg5.exghost.com X-Note-Return-Path: mserra@ravemobilesafety.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G328 G329 G330 G331 G335 G336 G347 G443 X-Note: Encrypt Rule Hits: X-Note: Mail Class: ALLOWEDSENDER X-Note: Headers Injected Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 6.0.1) with ESMTPS id 360717106; Mon, 25 Feb 2013 13:43:16 -0600 Received: from MBX05.exg5.exghost.com ([169.254.1.177]) by HT09-e5.exg5.exghost.com ([98.129.23.242]) with mapi; Mon, 25 Feb 2013 13:43:12 -0600 From: Matt Serra To: "ecrit@ietf.org" Date: Mon, 25 Feb 2013 13:43:10 -0600 Thread-Topic: NENA Feedback on draft-ietf-ecrit-additional-data-06 Thread-Index: Ac4TkFc+jhUyVqK2S6aQlKxhqoX+4g== Message-ID: <6B92B1E73D1E7B468E5C97CAE569CBA12152E74663@MBX05.exg5.exghost.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6B92B1E73D1E7B468E5C97CAE569CBA12152E74663MBX05exg5exgh_" MIME-Version: 1.0 Cc: Addl Data WG Subject: [Ecrit] NENA Feedback on draft-ietf-ecrit-additional-data-06 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 19:43:21 -0000 --_000_6B92B1E73D1E7B468E5C97CAE569CBA12152E74663MBX05exg5exgh_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We discussed draft-ietf-ecrit-additional-data-06 document on today's NENA A= dditional Data Work Group call. Our comments are listed by v06 Section hea= dings: 1 Introduction. a. While # data types was changed from Four to Three, there is still = a reference to PSAP in the first sentence of the 2nd paragraph. b. NIT: in paragraph beginning "This document focuses on additional d= ata with an emergent call" should read as "emergency" 7.1 Device Classification (NIT): There is a redundant "the" in this phrase= "This information describes the the" It looks like two additional section 7.x need to be added back to the docum= ent: In v05, there were fields defined in sections 6.6 "Device/Service Spe= cific Additional Data Structure" and 6.7 "Device/Service Specific Additiona= l Data Structure Type" which were dropped when moving from v06 to v07 of t= his document. 14.7 VCard Parameter Value Registration. In the section title, as well as = the first paragraphs, references to "vCARD" remain. I believe these should= be "xCARD" now. Matthew A. Serra, ENP Chair, NENA Additional Data Work Group Sr. Director, Product Management Rave Mobile Safety | Smart911 Mobile: 201.245.1557 mserra@ravemobilesafety.com --_000_6B92B1E73D1E7B468E5C97CAE569CBA12152E74663MBX05exg5exgh_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We discussed dra= ft-ietf-ecrit-additional-data-06 document on today’s NENA Additional = Data Work Group call.  Our comments are listed by v06 Section headings= :

 

1 Introduction. 

a.       While # data types was changed from Four to Three, there is still a refer= ence to PSAP in the first sentence of the 2nd paragraph.

b.   &= nbsp;  NIT:  in paragraph beginning ̶= 0;This document focuses on additional data with an emergent call”  should read as “emergency”

 

7.1 Device Classification (NIT):  There is= a redundant “the” in this phrase “This information descr= ibes the the”

 

It looks like two additional = section 7.x need to be added back to the document:  In v05, there were= fields defined in sections 6.6 “Device/Service Specific Additional D= ata Structure” and 6.7 “Device/Service Specific Additional Data= Structure Type”  which were dropped when moving from v06 to v07= of this document. 

 

14.7 VCard Parameter Value Registration.  In the = section title, as well as the first paragraphs, references to “vCARD&= #8221; remain.  I believe these should be “xCARD” now.

 

<= o:p> 

Matthew A. Serra, ENP

Chair, NENA Additional = Data Work Group


Sr. Director, Product Management
Rave = Mobile Safety | Smart911
Mobile:  201.245.1557
mserra@ravemo= bilesafety.com

= --_000_6B92B1E73D1E7B468E5C97CAE569CBA12152E74663MBX05exg5exgh_-- From brian.rosen@neustar.biz Mon Feb 25 12:36:05 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD93721E80B8 for ; Mon, 25 Feb 2013 12:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.963 X-Spam-Level: X-Spam-Status: No, score=-5.963 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0zOmHTIgqCU for ; Mon, 25 Feb 2013 12:36:04 -0800 (PST) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6D721E8084 for ; Mon, 25 Feb 2013 12:36:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1361824998; x=1677183424; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=8yT685XtSCTM9NimzMLmyIRR8u0UQjkePM5evVN1whM=; b=G/ZDQB2eYmiNz+RtbFlehkKj9+jxquLBodBQIXnHCDqvNPJQnbJLmTa7L19P+/ prx2xxY8tmQ1xYdqQJEU4UsA== Received: from ([10.31.13.242]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.20928043; Mon, 25 Feb 2013 15:43:17 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Mon, 25 Feb 2013 15:36:01 -0500 From: "Rosen, Brian" To: Matt Serra Date: Mon, 25 Feb 2013 15:36:00 -0500 Thread-Topic: [Ecrit] NENA Feedback on draft-ietf-ecrit-additional-data-06 Thread-Index: Ac4Tl7k0jSNImy++T/iABWnkpJxiQA== Message-ID: <9325287F-0C99-4965-A1C7-0CE337FB7CA8@neustar.biz> References: <6B92B1E73D1E7B468E5C97CAE569CBA12152E74663@MBX05.exg5.exghost.com> In-Reply-To: <6B92B1E73D1E7B468E5C97CAE569CBA12152E74663@MBX05.exg5.exghost.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 4/5bYia5NaJ8cTFwIWuW8g== Content-Type: multipart/alternative; boundary="_000_9325287F0C994965A1C70CE337FB7CA8neustarbiz_" MIME-Version: 1.0 Cc: Addl Data WG , "ecrit@ietf.org" Subject: Re: [Ecrit] NENA Feedback on draft-ietf-ecrit-additional-data-06 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 20:36:05 -0000 --_000_9325287F0C994965A1C70CE337FB7CA8neustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks. I'm consulting with my co-authors to figure out what happened to the two mi= ssing sections. I don't remember if we intended to move them, or just made= an inadvertent deletion. These are important elements, and we'll put the= m back, hopefully before today's deadline. We'll fix the nits in the next version, whenever that is. Brian On Feb 25, 2013, at 2:43 PM, Matt Serra > wrote: We discussed draft-ietf-ecrit-additional-data-06 document on today=92s NENA= Additional Data Work Group call. Our comments are listed by v06 Section h= eadings: 1 Introduction. a. While # data types was changed from Four to Three, there is still = a reference to PSAP in the first sentence of the 2nd paragraph. b. NIT: in paragraph beginning =93This document focuses on additional= data with an emergent call=94 should read as =93emergency=94 7.1 Device Classification (NIT): There is a redundant =93the=94 in this ph= rase =93This information describes the the=94 It looks like two additional section 7.x need to be added back to the docum= ent: In v05, there were fields defined in sections 6.6 =93Device/Service S= pecific Additional Data Structure=94 and 6.7 =93Device/Service Specific Add= itional Data Structure Type=94 which were dropped when moving from v06 to = v07 of this document. 14.7 VCard Parameter Value Registration. In the section title, as well as = the first paragraphs, references to =93vCARD=94 remain. I believe these sh= ould be =93xCARD=94 now. Matthew A. Serra, ENP Chair, NENA Additional Data Work Group Sr. Director, Product Management Rave Mobile Safety | Smart911 Mobile: 201.245.1557 mserra@ravemobilesafety.com _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_9325287F0C994965A1C70CE337FB7CA8neustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks.

I'm consulting with my co-authors to fig= ure out what happened to the two missing sections.  I don't remember i= f we intended to move them, or just made an inadvertent deletion.   Th= ese are important elements, and we'll put them back, hopefully before today= 's deadline.

We'll fix the nits in the next versio= n, whenever that is.

Brian

On Feb 25, 2013, at 2:43 PM, Matt Serra <mserra@ravemobilesafety.com> wrote:

We discussed draft-ietf-ecrit-additional-data-06 document on= today=92s NENA Additional Data Work Group call.  Our comments are lis= ted by v06 Section headings:
 <= /o:p>
1 Introduction. 
a.     &n= bsp; While = # data types was changed from Four to Three, there is still a reference to = PSAP in the first sentence of the 2nd paragraph.
b.      NIT:  in paragraph begi= nning =93This document focuses on additional data with an emergent call=94  should r= ead as =93emergency=94
=
 
7.1 Device C= lassification (NIT):  There is a redundant =93the=94 in this phrase = =93This information describes the&nbs= p;the=94
 
It looks like two addit= ional section 7.x need to be added back to the document:  In v05, ther= e were fields defined in sections 6.6 =93Device/Service Specific Additional= Data Structure=94 and 6.7 =93Device/Service Specific Additional Data Struc= ture Type=94  which were dropped when moving from v06 to v07 of this d= ocument. 
 
14.7 VCard Parameter Value Registration.  In the sectio= n title, as well as the first paragraphs, references to =93vCARD=94 remain.=   I believe these should be =93xCARD=94 now.
 
 
Matthew A. Serra, EN= P
Chair, NENA Additional Data Work Group

S= r. Director, Product Management =
Rave Mobile Safety | Smart911
Mobile:  201.245.1557=
mserra@ravemobi= lesafety.com
______________________= _________________________
Ecrit mailing list
Ecrit@ietf.= org
https://www.ietf.org/mailman/= listinfo/ecrit

= --_000_9325287F0C994965A1C70CE337FB7CA8neustarbiz_-- From internet-drafts@ietf.org Mon Feb 25 15:18:11 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459F321F9363; Mon, 25 Feb 2013 15:18:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zp2E4qykUm+l; Mon, 25 Feb 2013 15:18:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50A221E80F6; Mon, 25 Feb 2013 15:18:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225231810.11207.36963.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 15:18:10 -0800 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-07.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 23:18:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Additional Data related to an Emergency Call Author(s) : Brian Rosen Hannes Tschofenig Roger Marshall Randall Gellens Filename : draft-ietf-ecrit-additional-data-07.txt Pages : 63 Date : 2013-02-25 Abstract: When an emergency call is sent to a Public Safety Answering Point (PSAP), the device that sends it, as well as any service provider in the path of the call, or access network through which the call originated may have information about the call which the PSAP may be able to use. This document describes an XML data structure to contains such data and a Uniform Resource Identifier (URI) for conveying the data to the PSAP. The URI may point to either an external resource, or the body of the SIP message. 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Feb 25 15:18:25 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3300D21E814E; Mon, 25 Feb 2013 15:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLHEXr5F6rIY; Mon, 25 Feb 2013 15:18:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B119921E8139; Mon, 25 Feb 2013 15:18:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225231824.31128.26801.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 15:18:24 -0800 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-05.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 23:18:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Data-Only Emergency Calls Author(s) : Brian Rosen Henning Schulzrinne Hannes Tschofenig Filename : draft-ietf-ecrit-data-only-ea-05.txt Pages : 25 Date : 2013-02-25 Abstract: RFC 6443 'Framework for Emergency Calling Using Internet Multimedia' describes how devices use the Internet to place emergency calls and how Public Safety Answering Points (PSAPs) can handle Internet multimedia emergency calls natively. The exchange of multimedia traffic typically involves a SIP session establishment starting with a SIP INVITE that negotiates various parameters for that session. In some cases, however, the transmission of application data is everything that is needed. Examples of such environments include a temperature sensors issuing alerts, or vehicles sending crash data. Often these alerts are conveyed as one-shot data transmissions. These type of interactions are called 'data-only emergency calls'. This document describes a container for the data based on the Common Alerting Protocol (CAP) and its transmission using the SIP MESSAGE transaction. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-data-only-ea-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From RMarshall@telecomsys.com Mon Feb 25 15:23:44 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F338021F90EC for ; Mon, 25 Feb 2013 15:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2OBmXW2AF8W for ; Mon, 25 Feb 2013 15:23:43 -0800 (PST) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1928C21E8158 for ; Mon, 25 Feb 2013 15:23:43 -0800 (PST) Received: from SEA-EXCAS-2.telecomsys.com (exc2010-local2.telecomsys.com [10.32.12.187]) by sea-mx-02.telecomsys.com (8.14.1/8.14.1) with ESMTP id r1PNNdAQ016845 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 25 Feb 2013 15:23:39 -0800 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.134]) by SEA-EXCAS-2.telecomsys.com ([10.32.12.187]) with mapi id 14.01.0355.002; Mon, 25 Feb 2013 15:23:39 -0800 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: Draft Agenda: IETF 86 - Orlando Thread-Index: AQHOE68kR2mxazyfNkKGpD9pWO5xWA== Date: Mon, 25 Feb 2013 23:23:39 +0000 Message-ID: References: In-Reply-To: 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_FBD5AAFFD0978846BF6D3FAB4C892ACC204C4ASEAEXMB1telecomsy_" MIME-Version: 1.0 Subject: [Ecrit] Draft Agenda: IETF 86 - Orlando X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 23:23:44 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC204C4ASEAEXMB1telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See the ECRIT draft agenda below. If you believe there is something missing, or misallocated, let us know rig= ht away. Thanks. Roger & Marc. *** ECRIT Agenda - 13:00-15:00, Wednesday March 13, 2013 10 min * Agenda Bashing, Draft Status Update (Marc Linsner, Roger Marshall) 10 min * Additional Data related to an Emergency Call (Brian) http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ Intention: Discuss latest changes and if ready for WGLC 10 min * Common Alerting Protocol (CAP) based Data-Only Emergency Alerts us= ing the Session Initiation Protocol (Brian) http://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ Intention: Discuss latest changes 20 min. * Internet Protocol-based In-Vehicle Emergency Call (Hannes) http://datatracker.ietf.org/doc/draft-rosen-ecrit-ecall/ Intention: Discuss whether candidate for WG adoption 15 min. * Extensions to the Emergency Services Architecture for dealing wit= h Unauthenticated and Unauthorized Devices (Hannes) http://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access/ Intention: Discuss changes 15 min. * Trustworthy Location Information (Hannes) http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/ Intention: Discuss changes 20 min * URN For Country Specific Emergency Services (Christer) http://datatracker.ietf.org/doc/draft-holmberg-ecrit-country-emg-urn/ Intention: Discuss new draft 5 min * Resource Priority Header (RPH) Registry Management Policy to IETF R= eview (Brian) http://datatracker.ietf.org/doc/draft-rosen-rph-reg-policy-00.txt/ Intention: Discussion on draft 15 min * Open Discussion From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of R= oger Marshall Sent: Wednesday, February 20, 2013 11:19 AM To: ecrit@ietf.org Subject: [Ecrit] Draft Agenda creation for Orlando meeting - IETF 86 We're putting together the agenda for the Orlando ECRIT WG meeting, if you = have a presentation for a draft and want agenda time, please let us know. = An email to the list works good enough. Thanks, Marc & Roger CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC204C4ASEAEXMB1telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

See the ECRIT draft ag= enda below. 

If you believe there i= s something missing, or misallocated, let us know right away.

 

Thanks.

 

Roger & Marc.=

 

***<= /p>

 

ECRIT Agenda - 13:00-1= 5:00, Wednesday March 13, 2013

 

10 min * Agenda Bashin= g, Draft Status Update (Marc Linsner, Roger Marshall)

 

10 min * Additional Da= ta related to an Emergency Call (Brian)

http://datatracker.iet= f.org/doc/draft-ietf-ecrit-additional-data/

Intention: Discuss lat= est changes and if ready for WGLC

 

10 min * Common Alerti= ng Protocol (CAP) based Data-Only Emergency Alerts using the Session Initia= tion Protocol (Brian)

http://datatracker.iet= f.org/doc/draft-ietf-ecrit-data-only-ea/

Intention: Discuss lat= est changes

 

20 min. * Internet Pro= tocol-based In-Vehicle Emergency Call (Hannes)

http://datatracker.iet= f.org/doc/draft-rosen-ecrit-ecall/

Intention: Discuss whe= ther candidate for WG adoption

 

15 min. * Extensions t= o the Emergency Services Architecture for dealing with Unauthenticated and = Unauthorized Devices (Hannes)

http://datatracker.iet= f.org/doc/draft-ietf-ecrit-unauthenticated-access/

Intention: Discuss cha= nges

 

15 min. * Trustworthy = Location Information (Hannes)

http://datatracker.iet= f.org/doc/draft-ietf-ecrit-trustworthy-location/

Intention: Discuss cha= nges

 

20 min * URN For Count= ry Specific Emergency Services (Christer)

http://datatracker.iet= f.org/doc/draft-holmberg-ecrit-country-emg-urn/

Intention: Discuss new= draft

 

5 min * Resource Prior= ity Header (RPH) Registry Management Policy to IETF Review (Brian)

http://datatracker.iet= f.org/doc/draft-rosen-rph-reg-policy-00.txt/

Intention: Discussion = on draft

 

15 min * Open Discussi= on

 

 

From: ecrit-bo= unces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall
Sent: Wednesday, February 20, 2013 11:19 AM
To: ecrit@ietf.org
Subject: [Ecrit] Draft Agenda creation for Orlando meeting - IETF 86=

 

We're putting together the agenda fo= r the Orlando ECRIT WG meeting, if you have a presentation for a draft and = want agenda time, please let us know.  An email to the list works good enough.

 

Thanks,

 

Marc & Roger

 

 

CONFIDENTIALITY NOTIC= E: The information contained in this message may be privileged and/or confi= dential. If you are not the intended recipient, or responsible for deliveri= ng this message to the intended recipient, any review, forwarding, dissemin= ation, distribution or copying of this communication or any attachment(s) i= s strictly prohibited. If you have received this message in error, please n= otify the sender immediately, and delete it and all attachments from your c= omputer and network.

--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC204C4ASEAEXMB1telecomsy_-- From James.Winterbottom@commscope.com Mon Feb 25 15:46:01 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A23621E8179 for ; Mon, 25 Feb 2013 15:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2PSR7gZgxj4 for ; Mon, 25 Feb 2013 15:45:59 -0800 (PST) Received: from cdcsmgw01.commscope.com (cdcsmgw01.commscope.com [198.135.207.232]) by ietfa.amsl.com (Postfix) with ESMTP id 05A2821E818F for ; Mon, 25 Feb 2013 15:45:58 -0800 (PST) X-AuditID: 0a0404e8-b7f8f6d0000051af-33-512bf7b64c3a Received: from CDCE10HC2.commscope.com ( [10.86.28.22]) by cdcsmgw01.commscope.com (Symantec Messaging Gateway) with SMTP id D5.C1.20911.6B7FB215; Mon, 25 Feb 2013 17:45:58 -0600 (CST) Received: from SISPE7HC1.commscope.com (10.97.4.12) by CDCE10HC2.commscope.com (10.86.28.22) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 25 Feb 2013 17:45:57 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 26 Feb 2013 07:45:55 +0800 From: "Winterbottom, James" To: Christer Holmberg , "ecrit@ietf.org" Date: Tue, 26 Feb 2013 07:45:53 +0800 Thread-Topic: Draft new version: draft-holmberg-ecrit-country-emg-urn-01 Thread-Index: Ac4TRihzTH80bKVyTc6Jt+P7fL6PxAAakOOg Message-ID: <5A55A45AE77F5941B18E5457ECAC818801214077171C@SISPE7MB1.commscope.com> References: <7594FB04B1934943A5C02806D1A2204B105DFB@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B105DFB@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC818801214077171CSISPE7MB1co_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKKsWRmVeSWpSXmKPExsXCFSYjprvtu3agwauTwhYXZh5mtGhc9JTV gcnj19erbB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo43vyNvaDFreLO4UlMDYwvbboYOTkkBEwk Pv/vZISwxSQu3FvPBmILCexilPh2lbOLkQvI3gBkz5rGCOGsY5SYevw6O0gVm4CdxOH1N5hB bBGBaImjV7cxgdgsAqoSvz62gtnCAu4Sp17NgqrxkNjaOY0NwjaSeNh/EWwOr0CQRPeba0A2 B9ACb4mdF6tAwpwCPhLnXlwCK2cEOu77qTVgI5kFxCVuPZnPBHG0gMSSPeeZIWxRiZeP/7FC 1ItK3GlfzwhRny/xb9YfZohVghInZz5hgXhSV6Jp51fWCYxis5CMnYWkZRaSFoi4jsSC3Z/Y IGxtiWULXzPD2GcOPGZCFl/AyL6KUTw5Jbk4N73cwFAvOT83tzg5vyAVxNrECIpFFpYXOxhP b9A+xCjAwajEw3uhVTtQiDWxrLgy9xCjJAeTkiivwhegEF9SfkplRmJxRnxRaU5q8SFGCQ5m JRFezgygHG9KYmVValE+TEqDg0Pg9JP7pxilWPLy81KVJHhrvgGVCRalpqdWpGXmABMRTCkT ByfIKB6gUQYgNbzFBYm5xZnpEPlTjNocr64/e8HI0bz8+QtGIbBxUuK8S0BKBUBKM0rz4Ka9 YhQHekGYVxQkywNMq3BzXgGtYAJasUgEbEVJIkJKqoFRsH92oNaWqV5pwXknarMbtDj+lF7a fWL1x6kZXjf+O/NOyXL7Nk9Nz2a2IYv9LZ2t+7hun7KRjk/WOJx3KjApVrhL03+C0u81O5Ty Y2Wnvz/mcuT2+W25spuVNurNv835d/aU+XpbSwolfriH3BSROzA9Kv3zby93s39Hc7+23Xkq /d3s611FJZbijERDLeai4kQA9fwnKGgDAAA= Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 23:46:01 -0000 --_000_5A55A45AE77F5941B18E5457ECAC818801214077171CSISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Christer, I have read the new version of the draft and I am unconvinced that these th= ere is a need for these to be country specific. I can certainly see a need to register additional sub-service types under t= he sos service urn, but what makes the kidnapping service in Columbia diffe= rent from a kidnapping service in say Somalia? I am concerned with the proposed solution described in section 6.1 as this = presupposes that the service URN included in the query to the LoST server i= ncludes a country indicator, and this requires the client to understand whe= re it is and what service types are available in that area. While a query t= o LoST does require the client to have a location, it does not necessarily = require the client to "understand" that location, changing the service URNs= in the manner you are proposing undermines this. Further, in the case of t= he device only having a geodetic location it now needs to be able to revers= e-geocode this somehow to arrive at a country code. I think that for this draft to progress on the pretext being proposed then = some degree of specific country-level service differentiation needs to be d= emonstrated and I am not seeing this. I think that it is perfectly valid to say that some service, the reporting-= spies for example, are required services but do they all necessarily fall u= nder the sos service tree? Some of this leads back to the service categoriz= ation discussion that we had a number of IETFs ago. I can see that a gov se= rvice URN might be valid, but not a country one. Cheers James From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of C= hrister Holmberg Sent: Monday, 25 February 2013 9:54 PM To: ecrit@ietf.org Subject: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-01 Hi, I've submitted a new version (-01) of draft-holmberg-ecrit-country-emg-urn-= 01. The only change is a tiny editorial fix. Note, that due to a timing issue, I wasn't able to add the alternative of r= elaxing the registration rules for the existing registry, but that alternat= ive WILL be on the slides for Orlando. Regards, Christer --_000_5A55A45AE77F5941B18E5457ECAC818801214077171CSISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Christer,

 

I have read the new version of the draft and I = am unconvinced that these there is a need for these to be country specific.=

I = can certainly see a need to register additional sub-service types under the= sos service urn, but what makes the kidnapping service in Columbia differe= nt from a kidnapping service in say Somalia?

 

I am concerned with the prop= osed solution described in section 6.1 as this presupposes that the service= URN included in the query to the LoST server includes a country indicator,= and this requires the client to understand where it is and what service ty= pes are available in that area. While a query to LoST does require the clie= nt to have a location, it does not necessarily require the client to “= ;understand” that location, changing the service URNs in the manner y= ou are proposing undermines this. Further, in the case of the device only h= aving a geodetic location it now needs to be able to reverse-geocode this s= omehow to arrive at a country code.

 

I think that for this draft to progre= ss on the pretext being proposed then some degree of specific country-level= service differentiation needs to be demonstrated and I am not seeing this.=

 

I think that it is perfectly valid to say that some service, the reportin= g-spies for example, are required services but do they all necessarily fall= under the sos service tree? Some of this leads back to the service categor= ization discussion that we had a number of IETFs ago. I can see that a gov = service URN might be valid, but not a country one.

 

Cheers

James

 

 <= /o:p>

&nb= sp;

 

=  

 

From:<= /b> ecri= t-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Chri= ster Holmberg
Sent: Monday, 25 February 2013 9:54 PM
To: ecrit@ietf.org
Subject: [Ecrit] Draft new version: draft-holmbe= rg-ecrit-country-emg-urn-01

 

Hi,

 

I’ve submitted a new version (-01) of draft= -holmberg-ecrit-country-emg-urn-01.

 

The only change is a tiny editorial f= ix.

 

Note, that due to a timing issue, I wasn’t able to add the alte= rnative of relaxing the registration rules for the existing registry, but t= hat alternative WILL be on the slides for Orlando.

 

Regards,<= /p>

 

Christer<= o:p>

= --_000_5A55A45AE77F5941B18E5457ECAC818801214077171CSISPE7MB1co_-- From keith.drage@alcatel-lucent.com Mon Feb 25 16:25:45 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D588C21E81A9 for ; Mon, 25 Feb 2013 16:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.17 X-Spam-Level: X-Spam-Status: No, score=-107.17 tagged_above=-999 required=5 tests=[AWL=-0.922, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEeVv28zPrLs for ; Mon, 25 Feb 2013 16:25:43 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 455ED21E818F for ; Mon, 25 Feb 2013 16:25:43 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1Q0PcmC019096 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 26 Feb 2013 01:25:38 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 26 Feb 2013 01:25:38 +0100 From: "DRAGE, Keith (Keith)" To: "Winterbottom, James" , Christer Holmberg , "ecrit@ietf.org" Date: Tue, 26 Feb 2013 01:25:38 +0100 Thread-Topic: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-01 Thread-Index: Ac4TRihzTH80bKVyTc6Jt+P7fL6PxAAakOOgAADy48A= Message-ID: References: <7594FB04B1934943A5C02806D1A2204B105DFB@ESESSMB209.ericsson.se> <5A55A45AE77F5941B18E5457ECAC818801214077171C@SISPE7MB1.commscope.com> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC818801214077171C@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE210701F20ECFRMRSSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 00:25:46 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE210701F20ECFRMRSSXCHMBSC_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Any subtype has to fulfil the requirement of the top level type, and there = is a fairly rigorous definition of what constitutes "sos". If the subtype d= oes not fulfil this, then it should not be used. But to me the main criteria for existence of these subtypes is that we have= an emergency service in a country that is fairly unique. If we have multip= le countries using an emergency service that can be combined in a single de= finition, then we should invent a new subtype. So I believe we need this dr= aft, but the usage should not be so endemic as you imply. Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of W= interbottom, James Sent: 25 February 2013 23:46 To: Christer Holmberg; ecrit@ietf.org Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-ur= n-01 Hi Christer, I have read the new version of the draft and I am unconvinced that these th= ere is a need for these to be country specific. I can certainly see a need to register additional sub-service types under t= he sos service urn, but what makes the kidnapping service in Columbia diffe= rent from a kidnapping service in say Somalia? I am concerned with the proposed solution described in section 6.1 as this = presupposes that the service URN included in the query to the LoST server i= ncludes a country indicator, and this requires the client to understand whe= re it is and what service types are available in that area. While a query t= o LoST does require the client to have a location, it does not necessarily = require the client to "understand" that location, changing the service URNs= in the manner you are proposing undermines this. Further, in the case of t= he device only having a geodetic location it now needs to be able to revers= e-geocode this somehow to arrive at a country code. I think that for this draft to progress on the pretext being proposed then = some degree of specific country-level service differentiation needs to be d= emonstrated and I am not seeing this. I think that it is perfectly valid to say that some service, the reporting-= spies for example, are required services but do they all necessarily fall u= nder the sos service tree? Some of this leads back to the service categoriz= ation discussion that we had a number of IETFs ago. I can see that a gov se= rvice URN might be valid, but not a country one. Cheers James From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of C= hrister Holmberg Sent: Monday, 25 February 2013 9:54 PM To: ecrit@ietf.org Subject: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-01 Hi, I've submitted a new version (-01) of draft-holmberg-ecrit-country-emg-urn-= 01. The only change is a tiny editorial fix. Note, that due to a timing issue, I wasn't able to add the alternative of r= elaxing the registration rules for the existing registry, but that alternat= ive WILL be on the slides for Orlando. Regards, Christer --_000_EDC0A1AE77C57744B664A310A0B23AE210701F20ECFRMRSSXCHMBSC_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Any subtype has to fulfil the requirem= ent of the top level type, and there is a fairly rigorous definition of what constitutes “sos”. If the subtype does not fulfil this, then it= should not be used.

 

But to me the main criteria for existe= nce of these subtypes is that we have an emergency service in a country that is fairly unique. If we have multiple countries using an emergency service tha= t can be combined in a single definition, then we should invent a new subtype= . So I believe we need this draft, but the usage should not be so endemic as you imply.

 

Keith

 

From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Winterbottom, James
Sent: 25 February 2013 23:46=
To: Christer Holmberg; ecrit@ietf.org
Subject: Re: [Ecrit] Draft n= ew version: draft-holmberg-ecrit-country-emg-urn-01

 

Hi Christer,

 

I have read the new version of the= draft and I am unconvinced that these there is a need for these to be country specific.

I can certainly see a need to regi= ster additional sub-service types under the sos service urn, but what makes the kidnapping service in Columbia different f= rom a kidnapping service in say Somalia?<= /p>

 

I am concerned with the proposed solution described in section 6.1 as this presupposes that the service URN included in the query to the LoST server includes a country indicator, and = this requires the client to understand where it is and what service types are available in that area. While a query to LoST does require the client to ha= ve a location, it does not necessarily require the client to “understand&#= 8221; that location, changing the service URNs in the manner you are proposing undermi= nes this. Further, in the case of the device only having a geodetic location it= now needs to be able to reverse-geocode this somehow to arrive at a country cod= e.

 

I think that for this draft to pro= gress on the pretext being proposed then some degree of specific country-level service differentiation needs to be demonstrated and I am not seeing this.<= o:p>

 

I think that it is perfectly valid= to say that some service, the reporting-spies for example, are required servic= es but do they all necessarily fall under the sos service tree? Some of this l= eads back to the service categorization discussion that we had a number of IETFs ago. I can see that a gov service URN might be valid, but not a country one= .

 

Cheers

James

 

 

 

 

 

 

From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Monday, 25 February 20= 13 9:54 PM
To: ecrit@ietf.org
Subject: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-01

 

Hi,

 

I’ve submitted a new version (-01) of draft-holmberg-ecrit-country-emg-urn-01.

 

The only change is a tiny editorial fix.

 

Note, that due to a timing issue, I wasn’t able to add the al= ternative of relaxing the registration rules for the existing registry, but that alternative WILL be on the slides for Orlando.

 

Regards,

 

Christer

--_000_EDC0A1AE77C57744B664A310A0B23AE210701F20ECFRMRSSXCHMBSC_-- From pkyzivat@alum.mit.edu Mon Feb 25 16:46:59 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1561A21E81A0 for ; Mon, 25 Feb 2013 16:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nllkjjXd7mL for ; Mon, 25 Feb 2013 16:46:58 -0800 (PST) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 7B31721E8198 for ; Mon, 25 Feb 2013 16:46:57 -0800 (PST) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 4eWL1l0061ZMdJ4A1omxbf; Tue, 26 Feb 2013 00:46:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([60.186.111.79]) by omta16.emeryville.ca.mail.comcast.net with comcast id 4oka1l00L1iq0dG8cokgmy; Tue, 26 Feb 2013 00:44:52 +0000 Message-ID: <512C056F.90200@alum.mit.edu> Date: Tue, 26 Feb 2013 08:44:31 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: ecrit@ietf.org References: <7594FB04B1934943A5C02806D1A2204B105DFB@ESESSMB209.ericsson.se> <5A55A45AE77F5941B18E5457ECAC818801214077171C@SISPE7MB1.commscope.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361839617; bh=mvKanGwcZzX9VMdpntieBzbTCmZKGkBzdQx16dSY6CY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=s7fbiBBWvKYh/KiTfY+r1sZBacbXm8P561a2jimDTTxTE2HeeXW+GorEIaSLS4m7D ws25PMMdshONuWT53ctVqKHDTMaezsuxQIq0ylCErrJ1ySqMTZsd7t4Mw4pOamjfPT 4ADu0K41mWZIuGC/NlUNzTc90IaI6jzk4tKJ6l39CFSa8phra4AaSKz+xHyiW88r05 dmNrF4TKAXNBz8vjM7RKlmqmz2AJniiEohohbVhSEXnV/ZRX8pVucTQntDsMsrWSa2 NHb8KpZB9Q40CaHqZmglUlRmGkyM/KPoYtfzzpLRWB2UJsQF8ZNDmaWACU4D5kKAlt 3KUFcU2QMGcOQ== Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 00:46:59 -0000 On 2/26/13 8:25 AM, DRAGE, Keith (Keith) wrote: > Any subtype has to fulfil the requirement of the top level type, and > there is a fairly rigorous definition of what constitutes “sos”. If the > subtype does not fulfil this, then it should not be used. > > But to me the main criteria for existence of these subtypes is that we > have an emergency service in a country that is fairly unique. If we have > multiple countries using an emergency service that can be combined in a > single definition, then we should invent a new subtype. So I believe we > need this draft, but the usage should not be so endemic as you imply. ISTM that having a country-coded service would only make sense if the service is unique to country and it would never make sense for another country to have an analogous service. It is hard for me to imagine such a case. If another country *did* want to introduce an analogous service, then what would it do? The choices seem to be to either define another country-specific service with the same semantics, or else use the existing name defined for a different country. Neither seems like a good choice. So, ISTM that it would be better to change the rules to allow defining a new service even in cases where it initially will only be used in one country. This sounds like a good place for expert review to help ensure that the new service isn't redundant, and that it is defined as broadly as possible to encourage reuse. Thanks, Paul > Keith > > ------------------------------------------------------------------------ > > *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behalf > Of *Winterbottom, James > *Sent:* 25 February 2013 23:46 > *To:* Christer Holmberg; ecrit@ietf.org > *Subject:* Re: [Ecrit] Draft new version: > draft-holmberg-ecrit-country-emg-urn-01 > > Hi Christer, > > I have read the new version of the draft and I am unconvinced that these > there is a need for these to be country specific. > > I can certainly see a need to register additional sub-service types > under the sos service urn, but what makes the kidnapping service in > Columbia different from a kidnapping service in say Somalia? > > I am concerned with the proposed solution described in section 6.1 as > this presupposes that the service URN included in the query to the LoST > server includes a country indicator, and this requires the client to > understand where it is and what service types are available in that > area. While a query to LoST does require the client to have a location, > it does not necessarily require the client to “understand” that > location, changing the service URNs in the manner you are proposing > undermines this. Further, in the case of the device only having a > geodetic location it now needs to be able to reverse-geocode this > somehow to arrive at a country code. > > I think that for this draft to progress on the pretext being proposed > then some degree of specific country-level service differentiation needs > to be demonstrated and I am not seeing this. > > I think that it is perfectly valid to say that some service, the > reporting-spies for example, are required services but do they all > necessarily fall under the sos service tree? Some of this leads back to > the service categorization discussion that we had a number of IETFs ago. > I can see that a gov service URN might be valid, but not a country one. > > Cheers > > James > > *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behalf > Of *Christer Holmberg > *Sent:* Monday, 25 February 2013 9:54 PM > *To:* ecrit@ietf.org > *Subject:* [Ecrit] Draft new version: > draft-holmberg-ecrit-country-emg-urn-01 > > Hi, > > I’ve submitted a new version (-01) of > draft-holmberg-ecrit-country-emg-urn-01. > > The only change is a tiny editorial fix. > > Note, that due to a timing issue, I wasn’t able to add the alternative > of relaxing the registration rules for the existing registry, but that > alternative WILL be on the slides for Orlando. > > Regards, > > Christer > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From brian.rosen@neustar.biz Mon Feb 25 16:47:53 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09CC21E8191; Mon, 25 Feb 2013 16:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.246 X-Spam-Level: X-Spam-Status: No, score=-6.246 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9-NFaRw4kGS; Mon, 25 Feb 2013 16:47:53 -0800 (PST) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id AF2D921E80D6; Mon, 25 Feb 2013 16:47:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1361839512; x=1677168375; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=302s+ap5Rw4EOqnxUI4sv 6IxCMPqHwufVyc9Ilgbkkw=; b=Ge1T0KPS1rAZQPiJks4PGo1RBy4PvoOs75+H2 y8ZzMWGIwlTwKv/JzCXIGguigjY9FFARs1ZLd23hD0zKkz9Vg== Received: from ([10.31.13.229]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.15334443; Mon, 25 Feb 2013 19:45:11 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Mon, 25 Feb 2013 19:47:48 -0500 From: "Rosen, Brian" To: "internet-drafts@ietf.org" Date: Mon, 25 Feb 2013 19:47:46 -0500 Thread-Topic: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-07.txt Thread-Index: Ac4TuuUe8Dqk0uNeQaCIH8/AHlAMMg== Message-ID: <403DEEBE-9DC0-4424-B89F-373259C22AFE@neustar.biz> References: <20130225231810.11207.36963.idtracker@ietfa.amsl.com> In-Reply-To: <20130225231810.11207.36963.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: tZAK74nNVuej4sSYM0BTpA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" , "i-d-announce@ietf.org" Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-07.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 00:47:54 -0000 I updated this to replace the missing sections from device data. I think w= e were talking about moving them to a block by themselves, but rather than = lose it, I opted to just replace them where they were. I also fixed the nits Matt found. Brian On Feb 25, 2013, at 6:18 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Emergency Context Resolution with Intern= et Technologies Working Group of the IETF. >=20 > Title : Additional Data related to an Emergency Call > Author(s) : Brian Rosen > Hannes Tschofenig > Roger Marshall > Randall Gellens > Filename : draft-ietf-ecrit-additional-data-07.txt > Pages : 63 > Date : 2013-02-25 >=20 > Abstract: > When an emergency call is sent to a Public Safety Answering Point > (PSAP), the device that sends it, as well as any service provider in > the path of the call, or access network through which the call > originated may have information about the call which the PSAP may be > able to use. This document describes an XML data structure to > contains such data and a Uniform Resource Identifier (URI) for > conveying the data to the PSAP. The URI may point to either an > external resource, or the body of the SIP message. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-07 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-07 >=20 >=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 brian.rosen@neustar.biz Mon Feb 25 16:52:38 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591E621E8191 for ; Mon, 25 Feb 2013 16:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtT7aTnG3rY2 for ; Mon, 25 Feb 2013 16:52:30 -0800 (PST) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4F921E81A0 for ; Mon, 25 Feb 2013 16:52:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1361840375; x=1677192382; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=aIUdXOrceo1Pp+EnfXtSg LMKYaYtRFHd01QA7WDq6C4=; b=IUhwTFEteHurjinGgeBtUbGSa73U9R+ipJ9Su Tsc/WNOgvV1TD1YYE1gz8IDIc2B/UB3dercqnMRvtv2g5Txhg== Received: from ([10.31.13.242]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.20937604; Mon, 25 Feb 2013 19:59:34 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Mon, 25 Feb 2013 19:52:18 -0500 From: "Rosen, Brian" To: "ecrit@ietf.org Org" Date: Mon, 25 Feb 2013 19:52:16 -0500 Thread-Topic: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-05.txt Thread-Index: Ac4Tu4YDfUOVDRirReGcwyl+CQERNg== Message-ID: <32A5A8D7-0D8D-4441-B554-0F58A2A8F81E@neustar.biz> References: <20130225231824.31128.26801.idtracker@ietfa.amsl.com> In-Reply-To: <20130225231824.31128.26801.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: gLGEPQhPjOZN7963yPbMyw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-05.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 00:52:40 -0000 This revision sticks to the scope of the document as it was. I clearly separated the CAP-as-body text from the transport in a MESSAGE. = I actually allowed use in other SIP messages, but explicitly did not define= any meaning to such use. I added text to explicitly bring in the phonebcp= mechanisms applied to MESSAGE for use as a data-only call. I restricted the mechanism to a single alert (no session, no update mechani= sm specified). I plan to create a new document that extends the use with INVITE for data += media, and to add the SUB/NOT package for updates. Brian On Feb 25, 2013, at 6:18 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Emergency Context Resolution with Intern= et Technologies Working Group of the IETF. >=20 > Title : Data-Only Emergency Calls > Author(s) : Brian Rosen > Henning Schulzrinne > Hannes Tschofenig > Filename : draft-ietf-ecrit-data-only-ea-05.txt > Pages : 25 > Date : 2013-02-25 >=20 > Abstract: > RFC 6443 'Framework for Emergency Calling Using Internet Multimedia' > describes how devices use the Internet to place emergency calls and > how Public Safety Answering Points (PSAPs) can handle Internet > multimedia emergency calls natively. The exchange of multimedia > traffic typically involves a SIP session establishment starting with > a SIP INVITE that negotiates various parameters for that session. >=20 > In some cases, however, the transmission of application data is > everything that is needed. Examples of such environments include a > temperature sensors issuing alerts, or vehicles sending crash data. > Often these alerts are conveyed as one-shot data transmissions. > These type of interactions are called 'data-only emergency calls'. > This document describes a container for the data based on the Common > Alerting Protocol (CAP) and its transmission using the SIP MESSAGE > transaction. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-data-only-ea-05 >=20 >=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 James.Winterbottom@commscope.com Mon Feb 25 17:53:50 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 705D921F9189 for ; Mon, 25 Feb 2013 17:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odfyeTbSqQ9q for ; Mon, 25 Feb 2013 17:53:49 -0800 (PST) Received: from cdcsmgw01.commscope.com (cdcsmgw01.commscope.com [198.135.207.232]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC6C21F9140 for ; Mon, 25 Feb 2013 17:53:49 -0800 (PST) X-AuditID: 0a0404e8-b7f8f6d0000051af-b2-512c15ac97b3 Received: from CDCE10HC2.commscope.com ( [10.86.28.22]) by cdcsmgw01.commscope.com (Symantec Messaging Gateway) with SMTP id B1.D3.20911.CA51C215; Mon, 25 Feb 2013 19:53:48 -0600 (CST) Received: from SISPE7HC1.commscope.com (10.97.4.12) by CDCE10HC2.commscope.com (10.86.28.22) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 25 Feb 2013 19:53:48 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 26 Feb 2013 09:53:45 +0800 From: "Winterbottom, James" To: Paul Kyzivat , "ecrit@ietf.org" Date: Tue, 26 Feb 2013 09:53:42 +0800 Thread-Topic: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-01 Thread-Index: Ac4Tus0Al8ltNXARSPOovbt0y2ZZiQACTEQg Message-ID: <5A55A45AE77F5941B18E5457ECAC8188012140771749@SISPE7MB1.commscope.com> References: <7594FB04B1934943A5C02806D1A2204B105DFB@ESESSMB209.ericsson.se> <5A55A45AE77F5941B18E5457ECAC818801214077171C@SISPE7MB1.commscope.com> <512C056F.90200@alum.mit.edu> In-Reply-To: <512C056F.90200@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPKsWRmVeSWpSXmKPExsXCFSYjprtGVCfQYPMCA4vGRU9ZLVZsOMDq wOTx9/0HJo8lS34yBTBFcdmkpOZklqUW6dslcGVMnnaYreCiWsXi2/9ZGhjXyXcxcnJICJhI fLp0lw3CFpO4cG89kM3FISSwi1Fi8uNmdghnA6NE+8dGRghnHaPEyufX2EFa2ATsJA6vv8EM YosIeEv8+f0NbBSLgKrEmjUTmUBsYYFAiYdXf7NB1ARJvOu/wwRhG0n0T1sF1ssLFH+x5BUT xIIuJoltnftYuxg5ODgFtCT+XQ4HqWEEOu/7qTVgvcwC4hK3nsxngjhbQGLJnvPMELaoxMvH /1gh6kUl7rSvZ4So15FYsPsTG4StLbFs4WuovYISJ2c+YQGxhQR0JZp2fmWdwCg+C8mKWUja ZyFpn4WkfQEjyypG8eSU5OLc9HIDQ73k/Nzc4uT8glQQaxMjKL5YWF7sYDy9QfsQowAHoxIP 74VW7UAh1sSy4srcQ4ySHExKoryzmXUChfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwcmYAlfOm JFZWpRblw6Q0ODgETj+5f4pRiiUvPy9VSYJ3lgjQCMGi1PTUirTMHGBygSll4uAEGcUDNKoF pIa3uCAxtzgzHSJ/ilGb49X1Zy8YOZqXP3/BKAQ2TkqcdzJIqQBIaUZpHty0V4ziQC8I8y4D yfIAUyXcnFdAK5iAViwSAbm2uCQRISXVwOjse1Bod1HnrVV3b13csrXRb80UP0OF2v+uxnof Px+7/f+t7cN6K9f+A1nJcnHutZ97VcpMJmczWD1oVnp3wdZ57ZLUtOisrKh3hbxyPAuefb4/ 0/lOzKKqKfFp+sd2tzY0/dQJjRG/zTGzKizO+fZLudwVyWcEfTc7rtNuTHjMard9u5fvDCWW 4oxEQy3mouJEAEaLw5VSAwAA Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 01:53:50 -0000 Thanks Paul, I think that this is more or less what I was thinking. I think that there are very few service that could only possibly exist in o= ne country. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of P= aul Kyzivat Sent: Tuesday, 26 February 2013 11:45 AM To: ecrit@ietf.org Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-ur= n-01 On 2/26/13 8:25 AM, DRAGE, Keith (Keith) wrote: > Any subtype has to fulfil the requirement of the top level type, and=20 > there is a fairly rigorous definition of what constitutes "sos". If=20 > the subtype does not fulfil this, then it should not be used. > > But to me the main criteria for existence of these subtypes is that we=20 > have an emergency service in a country that is fairly unique. If we=20 > have multiple countries using an emergency service that can be=20 > combined in a single definition, then we should invent a new subtype.=20 > So I believe we need this draft, but the usage should not be so endemic a= s you imply. ISTM that having a country-coded service would only make sense if the servi= ce is unique to country and it would never make sense for another country t= o have an analogous service. It is hard for me to imagine such a case. If another country *did* want to introduce an analogous service, then what = would it do? The choices seem to be to either define another country-specif= ic service with the same semantics, or else use the existing name defined f= or a different country. Neither seems like a good choice. So, ISTM that it would be better to change the rules to allow defining a ne= w service even in cases where it initially will only be used in one country= . This sounds like a good place for expert review to help ensure that the n= ew service isn't redundant, and that it is defined as broadly as possible t= o encourage reuse. Thanks, Paul > Keith > > ---------------------------------------------------------------------- > -- > > *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On=20 > Behalf Of *Winterbottom, James > *Sent:* 25 February 2013 23:46 > *To:* Christer Holmberg; ecrit@ietf.org > *Subject:* Re: [Ecrit] Draft new version: > draft-holmberg-ecrit-country-emg-urn-01 > > Hi Christer, > > I have read the new version of the draft and I am unconvinced that=20 > these there is a need for these to be country specific. > > I can certainly see a need to register additional sub-service types=20 > under the sos service urn, but what makes the kidnapping service in=20 > Columbia different from a kidnapping service in say Somalia? > > I am concerned with the proposed solution described in section 6.1 as=20 > this presupposes that the service URN included in the query to the=20 > LoST server includes a country indicator, and this requires the client=20 > to understand where it is and what service types are available in that=20 > area. While a query to LoST does require the client to have a=20 > location, it does not necessarily require the client to "understand"=20 > that location, changing the service URNs in the manner you are=20 > proposing undermines this. Further, in the case of the device only=20 > having a geodetic location it now needs to be able to reverse-geocode=20 > this somehow to arrive at a country code. > > I think that for this draft to progress on the pretext being proposed=20 > then some degree of specific country-level service differentiation=20 > needs to be demonstrated and I am not seeing this. > > I think that it is perfectly valid to say that some service, the=20 > reporting-spies for example, are required services but do they all=20 > necessarily fall under the sos service tree? Some of this leads back=20 > to the service categorization discussion that we had a number of IETFs ag= o. > I can see that a gov service URN might be valid, but not a country one. > > Cheers > > James > > *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On=20 > Behalf Of *Christer Holmberg > *Sent:* Monday, 25 February 2013 9:54 PM > *To:* ecrit@ietf.org > *Subject:* [Ecrit] Draft new version: > draft-holmberg-ecrit-country-emg-urn-01 > > Hi, > > I've submitted a new version (-01) of > draft-holmberg-ecrit-country-emg-urn-01. > > The only change is a tiny editorial fix. > > Note, that due to a timing issue, I wasn't able to add the alternative=20 > of relaxing the registration rules for the existing registry, but that=20 > alternative WILL be on the slides for Orlando. > > Regards, > > Christer > > > > _______________________________________________ > 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 From christer.holmberg@ericsson.com Tue Feb 26 00:24:22 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C0C21F8895 for ; Tue, 26 Feb 2013 00:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.256 X-Spam-Level: X-Spam-Status: No, score=-6.256 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moJWSPiR4RCf for ; Tue, 26 Feb 2013 00:24:21 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id ECEA221F8891 for ; Tue, 26 Feb 2013 00:24:20 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-76-512c71339a4e Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 2A.68.10459.3317C215; Tue, 26 Feb 2013 09:24:20 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0318.004; Tue, 26 Feb 2013 09:24:19 +0100 From: Christer Holmberg To: "Winterbottom, James" , Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-01 Thread-Index: AQHOE8QigSehxU4GnEW99X9REL570JiLyb2Q Date: Tue, 26 Feb 2013 08:24:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B107BD9@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B105DFB@ESESSMB209.ericsson.se> <5A55A45AE77F5941B18E5457ECAC818801214077171C@SISPE7MB1.commscope.com> <512C056F.90200@alum.mit.edu> <5A55A45AE77F5941B18E5457ECAC8188012140771749@SISPE7MB1.commscope.com> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188012140771749@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+Jvja5JoU6gQd8yJovGRU9ZLa5f07ZY seEAqwOzx9/3H5g8Xq29w+6xZMlPpgDmKC6blNSczLLUIn27BK6Mk0uqCybqVVze3MHcwHhI tYuRk0NCwETi1ZufzBC2mMSFe+vZuhi5OIQEDjFKzGs6wAjhLGaUeN+6DyjDwcEmYCHR/U8b JC4i0M4osaf7DhNIt7BAoMTSwy3sILaIQJBE05HXzCD1IgJGEvfWOoKEWQRUJRbvfwBWzivg LbH72HmoZZeZJF70z2YBqecUCJbo7TYGqWEEOuj7qTVg9cwC4hK3nsxngjhUQGLJnvNQR4tK vHz8jxXCVpS4On05VL2OxILdn9ggbG2JZQtfM0PsFZQ4OfMJywRG0VlIxs5C0jILScssJC0L GFlWMbLnJmbmpJcbbmIExsbBLb91dzCeOidyiFGag0VJnDfM9UKAkEB6YklqdmpqQWpRfFFp TmrxIUYmDk6pBka/S5LzGu4ZftvwPPKqXMjbJtZj+lFXJ5nNlua377exE1JbfLJW7saMnKQ9 O+prxPw+y5jfCQhKi+HSef47TMeUefn6t9/jfHvOTJt7ykKI88zPjcFlkV2llt1xvtO6ZzSe FIrdH/VMw11LWXXe3yUXzgru6T+5J7smZIb3Q+PoBc57W1rLNJRYijMSDbWYi4oTAcg3oI9b AgAA Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 08:24:22 -0000 Hi, Please note that it has been suggested that, instead of creating a subtree = for the emergency URNs for the country specific emergency services, we simp= ly relax the policy for registration of any emergency URNs - as Paul also s= uggests. That would allow the registration of a URN that, AT THE TIME OF REGISTRATIO= N, is unique to a single country. Then, later, other countries can also use= the URN. And, in this case the URN would not need to include "country-specific", or = the name of the country. Regards, Christer -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of W= interbottom, James Sent: 26. helmikuuta 2013 3:54 To: Paul Kyzivat; ecrit@ietf.org Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-ur= n-01 Thanks Paul, I think that this is more or less what I was thinking. I think that there are very few service that could only possibly exist in o= ne country. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of P= aul Kyzivat Sent: Tuesday, 26 February 2013 11:45 AM To: ecrit@ietf.org Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-ur= n-01 On 2/26/13 8:25 AM, DRAGE, Keith (Keith) wrote: > Any subtype has to fulfil the requirement of the top level type, and=20 > there is a fairly rigorous definition of what constitutes "sos". If=20 > the subtype does not fulfil this, then it should not be used. > > But to me the main criteria for existence of these subtypes is that we=20 > have an emergency service in a country that is fairly unique. If we=20 > have multiple countries using an emergency service that can be=20 > combined in a single definition, then we should invent a new subtype. > So I believe we need this draft, but the usage should not be so endemic a= s you imply. ISTM that having a country-coded service would only make sense if the servi= ce is unique to country and it would never make sense for another country t= o have an analogous service. It is hard for me to imagine such a case. If another country *did* want to introduce an analogous service, then what = would it do? The choices seem to be to either define another country-specif= ic service with the same semantics, or else use the existing name defined f= or a different country. Neither seems like a good choice. So, ISTM that it would be better to change the rules to allow defining a ne= w service even in cases where it initially will only be used in one country= . This sounds like a good place for expert review to help ensure that the n= ew service isn't redundant, and that it is defined as broadly as possible t= o encourage reuse. Thanks, Paul > Keith > > ---------------------------------------------------------------------- > -- > > *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On=20 > Behalf Of *Winterbottom, James > *Sent:* 25 February 2013 23:46 > *To:* Christer Holmberg; ecrit@ietf.org > *Subject:* Re: [Ecrit] Draft new version: > draft-holmberg-ecrit-country-emg-urn-01 > > Hi Christer, > > I have read the new version of the draft and I am unconvinced that=20 > these there is a need for these to be country specific. > > I can certainly see a need to register additional sub-service types=20 > under the sos service urn, but what makes the kidnapping service in=20 > Columbia different from a kidnapping service in say Somalia? > > I am concerned with the proposed solution described in section 6.1 as=20 > this presupposes that the service URN included in the query to the=20 > LoST server includes a country indicator, and this requires the client=20 > to understand where it is and what service types are available in that=20 > area. While a query to LoST does require the client to have a=20 > location, it does not necessarily require the client to "understand" > that location, changing the service URNs in the manner you are=20 > proposing undermines this. Further, in the case of the device only=20 > having a geodetic location it now needs to be able to reverse-geocode=20 > this somehow to arrive at a country code. > > I think that for this draft to progress on the pretext being proposed=20 > then some degree of specific country-level service differentiation=20 > needs to be demonstrated and I am not seeing this. > > I think that it is perfectly valid to say that some service, the=20 > reporting-spies for example, are required services but do they all=20 > necessarily fall under the sos service tree? Some of this leads back=20 > to the service categorization discussion that we had a number of IETFs ag= o. > I can see that a gov service URN might be valid, but not a country one. > > Cheers > > James > > *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On=20 > Behalf Of *Christer Holmberg > *Sent:* Monday, 25 February 2013 9:54 PM > *To:* ecrit@ietf.org > *Subject:* [Ecrit] Draft new version: > draft-holmberg-ecrit-country-emg-urn-01 > > Hi, > > I've submitted a new version (-01) of > draft-holmberg-ecrit-country-emg-urn-01. > > The only change is a tiny editorial fix. > > Note, that due to a timing issue, I wasn't able to add the alternative=20 > of relaxing the registration rules for the existing registry, but that=20 > alternative WILL be on the slides for Orlando. > > Regards, > > Christer > > > > _______________________________________________ > 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 From hgs@cs.columbia.edu Tue Feb 26 04:42:30 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0A221F895F for ; Tue, 26 Feb 2013 04:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-wbWmwalTIn for ; Tue, 26 Feb 2013 04:42:29 -0800 (PST) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id F17E421F8922 for ; Tue, 26 Feb 2013 04:42:28 -0800 (PST) Received: from [10.0.1.2] (c-98-204-176-168.hsd1.va.comcast.net [98.204.176.168]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r1QCgJ3w029593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Feb 2013 07:42:21 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <7594FB04B1934943A5C02806D1A2204B107BD9@ESESSMB209.ericsson.se> Date: Tue, 26 Feb 2013 07:42:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <905AAAA4-6727-4754-9DD1-D24B4757BE9F@cs.columbia.edu> References: <7594FB04B1934943A5C02806D1A2204B105DFB@ESESSMB209.ericsson.se> <5A55A45AE77F5941B18E5457ECAC818801214077171C@SISPE7MB1.commscope.com> <512C056F.90200@alum.mit.edu> <5A55A45AE77F5941B18E5457ECAC8188012140771749@SISPE7MB1.commscope.com> <7594FB04B1934943A5C02806D1A2204B107BD9@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1283) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 12:42:30 -0000 Since the reason for the registration rule was to prevent numerous = registrations for emergency services that were, in role and mission, = very similar, I favor Christer's approach. We've had not-so-great = experiences with separate namespaces, such as experimental, with the SIP = P- headers being one recent example. As problems, such as child abuse, = terrorism or environmental issues, emerge, such services may well = proliferate beyond national borders.=20 Henning On Feb 26, 2013, at 3:24 AM, Christer Holmberg wrote: > Hi, >=20 > Please note that it has been suggested that, instead of creating a = subtree for the emergency URNs for the country specific emergency = services, we simply relax the policy for registration of any emergency = URNs - as Paul also suggests. >=20 > That would allow the registration of a URN that, AT THE TIME OF = REGISTRATION, is unique to a single country. Then, later, other = countries can also use the URN. >=20 > And, in this case the URN would not need to include = "country-specific", or the name of the country. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Winterbottom, James > Sent: 26. helmikuuta 2013 3:54 > To: Paul Kyzivat; ecrit@ietf.org > Subject: Re: [Ecrit] Draft new version: = draft-holmberg-ecrit-country-emg-urn-01 >=20 > Thanks Paul, I think that this is more or less what I was thinking. > I think that there are very few service that could only possibly exist = in one country. >=20 >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Paul Kyzivat > Sent: Tuesday, 26 February 2013 11:45 AM > To: ecrit@ietf.org > Subject: Re: [Ecrit] Draft new version: = draft-holmberg-ecrit-country-emg-urn-01 >=20 > On 2/26/13 8:25 AM, DRAGE, Keith (Keith) wrote: >> Any subtype has to fulfil the requirement of the top level type, and=20= >> there is a fairly rigorous definition of what constitutes "sos". If=20= >> the subtype does not fulfil this, then it should not be used. >>=20 >> But to me the main criteria for existence of these subtypes is that = we=20 >> have an emergency service in a country that is fairly unique. If we=20= >> have multiple countries using an emergency service that can be=20 >> combined in a single definition, then we should invent a new subtype. >> So I believe we need this draft, but the usage should not be so = endemic as you imply. >=20 > ISTM that having a country-coded service would only make sense if the = service is unique to country and it would never make sense for another = country to have an analogous service. It is hard for me to imagine such = a case. >=20 > If another country *did* want to introduce an analogous service, then = what would it do? The choices seem to be to either define another = country-specific service with the same semantics, or else use the = existing name defined for a different country. Neither seems like a good = choice. >=20 > So, ISTM that it would be better to change the rules to allow defining = a new service even in cases where it initially will only be used in one = country. This sounds like a good place for expert review to help ensure = that the new service isn't redundant, and that it is defined as broadly = as possible to encourage reuse. >=20 > Thanks, > Paul >=20 >> Keith >>=20 >> = ---------------------------------------------------------------------- >> -- >>=20 >> *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On=20 >> Behalf Of *Winterbottom, James >> *Sent:* 25 February 2013 23:46 >> *To:* Christer Holmberg; ecrit@ietf.org >> *Subject:* Re: [Ecrit] Draft new version: >> draft-holmberg-ecrit-country-emg-urn-01 >>=20 >> Hi Christer, >>=20 >> I have read the new version of the draft and I am unconvinced that=20 >> these there is a need for these to be country specific. >>=20 >> I can certainly see a need to register additional sub-service types=20= >> under the sos service urn, but what makes the kidnapping service in=20= >> Columbia different from a kidnapping service in say Somalia? >>=20 >> I am concerned with the proposed solution described in section 6.1 as=20= >> this presupposes that the service URN included in the query to the=20 >> LoST server includes a country indicator, and this requires the = client=20 >> to understand where it is and what service types are available in = that=20 >> area. While a query to LoST does require the client to have a=20 >> location, it does not necessarily require the client to "understand" >> that location, changing the service URNs in the manner you are=20 >> proposing undermines this. Further, in the case of the device only=20 >> having a geodetic location it now needs to be able to reverse-geocode=20= >> this somehow to arrive at a country code. >>=20 >> I think that for this draft to progress on the pretext being proposed=20= >> then some degree of specific country-level service differentiation=20 >> needs to be demonstrated and I am not seeing this. >>=20 >> I think that it is perfectly valid to say that some service, the=20 >> reporting-spies for example, are required services but do they all=20 >> necessarily fall under the sos service tree? Some of this leads back=20= >> to the service categorization discussion that we had a number of = IETFs ago. >> I can see that a gov service URN might be valid, but not a country = one. >>=20 >> Cheers >>=20 >> James >>=20 >> *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On=20 >> Behalf Of *Christer Holmberg >> *Sent:* Monday, 25 February 2013 9:54 PM >> *To:* ecrit@ietf.org >> *Subject:* [Ecrit] Draft new version: >> draft-holmberg-ecrit-country-emg-urn-01 >>=20 >> Hi, >>=20 >> I've submitted a new version (-01) of >> draft-holmberg-ecrit-country-emg-urn-01. >>=20 >> The only change is a tiny editorial fix. >>=20 >> Note, that due to a timing issue, I wasn't able to add the = alternative=20 >> of relaxing the registration rules for the existing registry, but = that=20 >> alternative WILL be on the slides for Orlando. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 > _______________________________________________ > 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 christer.holmberg@ericsson.com Tue Feb 26 05:50:05 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA26F21F89D2 for ; Tue, 26 Feb 2013 05:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.255 X-Spam-Level: X-Spam-Status: No, score=-6.255 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ktdy7fzSXeJm for ; Tue, 26 Feb 2013 05:50:03 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D0D6A21F888B for ; Tue, 26 Feb 2013 05:49:51 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-b3-512cbd7e83ff Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 0E.82.32353.E7DBC215; Tue, 26 Feb 2013 14:49:50 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0318.004; Tue, 26 Feb 2013 14:49:49 +0100 From: Christer Holmberg To: "ecrit@ietf.org" Thread-Topic: RFC 5031 text modification suggestion [was: Draft new version: draft-holmberg-ecrit-country-emg-urn-01] Thread-Index: Ac4UJ9bQvF+YvuZ5SlmbeMngbH+OJw== Date: Tue, 26 Feb 2013 13:49:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B108425@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B108425ESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+JvjW7dXp1Ag30bNC0aFz1ldWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxquzF9gKbuRXTDrew9jA2JDcxcjJISFgIjGr+wEjhC0mceHe erYuRi4OIYFDjBKPfm9ihHAWM0rMPfkIyOHgYBOwkOj+pw3SICKgKrHhzEqwZmGBIokNk/6D lYgIlEtsOuIIUaIn8f7PArASFqDya0sXsoLYvALeEh+6P4PFGYH2fj+1hgnEZhYQl7j1ZD4T xD0CEkv2nGeGsEUlXj7+xwphK0pcnb4cqj5f4sDmbnaImYISJ2c+YZnAKDQLyahZSMpmISmD iOtILNj9iQ3C1pZYtvA1M4x95sBjJmTxBYzsqxjZcxMzc9LLzTcxAoP+4JbfBjsYN90XO8Qo zcGiJM4b7nohQEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjtMrMmtKp4Uvn79qULhG0WWbG V8WwnYf6mVx3nChed47BbjJrX/WqF6+sZr3SteXcue5pfwd/daffkYkmpmnti2eLTplldfZw lYz2vQvF5oEad7u5SiflmRsVHHhzuu/ALD5e9fKsnNIrEY9erzq4ZQZLg9dDPYe1Zhob/oV4 OqtknH9lnbFUiaU4I9FQi7moOBEADC8lPkgCAAA= Subject: [Ecrit] RFC 5031 text modification suggestion [was: Draft new version: draft-holmberg-ecrit-country-emg-urn-01] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 13:50:06 -0000 --_000_7594FB04B1934943A5C02806D1A2204B108425ESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Below is a suggestion how the text in RFC 5031 could be modified, in order = to allow registration of emergency URNs that, at the time of registration, = are specific to one country. Regards, Christer --------------------------------- OLD TEXT: -------------- 4.2. Sub-Services for the 'sos' Service This section defines the first service registration within the IANA registry defined in Section 4.1, using the top-level service label 'sos'. The 'sos' service type describes emergency services requiring an immediate response, typically offered by various branches of the government or other public institutions. Additional sub-services can be added after expert review and must be of general public interest and have a similar emergency nature. The expert is designated by the ECRIT working group, its successor, or, in their absence, the IESG. The expert review should only approve emergency services that are offered widely and in different countries, with approximately the same caller expectation in terms of services rendered. The 'sos' service is not meant to invoke general government, public information, counseling, or social services. urn:service:sos The generic 'sos' service reaches a public safety answering point (PSAP), which in turn dispatches aid appropriate to the emergency. It encompasses all of the services listed below. NEW TEXT: -------------- 4.2. Sub-Services for the 'sos' Service This section defines the first service registration within the IANA registry defined in Section 4.1, using the top-level service label 'sos'. The 'sos' service type describes emergency services requiring an immediate response, typically offered by various branches of the government or other public institutions. Additional sub-services can be added after expert review. The expert is designated by the ECRIT working group, its successor, or, in their absence, the IESG. The expert review should only approve services that have emergency natur= e, that are offered in at least one country, that do not match description of any ex= isting service URN with the 'sos' service type, and where the service descripti= on and the URN are defined as broadly as possible to encourage reuse. The 'sos' service is not meant to invoke general government, public information, counseling, or social services. urn:service:sos The generic 'sos' service reaches a public safety answering point (PSAP), which in turn dispatches aid appropriate to the emergency. It encompasses all of the services listed below. --_000_7594FB04B1934943A5C02806D1A2204B108425ESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Below is a suggestion how the text in RFC 5031 could= be modified, in order to allow registration of emergency URNs that, at the= time of registration, are specific to one country.

 

Regards,

 

Christer

 

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

 

OLD TEXT:

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

 

4.2.  Sub-Services for the 'sos' Service

 

   This section defines the first service regist= ration within the IANA

   registry defined in Section 4.1, using the to= p-level service label

   'sos'.

 

   The 'sos' service type describes emergency se= rvices requiring an

   immediate response, typically offered by vari= ous branches of the

   government or other public institutions. = ; Additional sub-services can

   be added after expert review and must be of g= eneral public interest

   and have a similar emergency nature.  Th= e expert is designated by the

   ECRIT working group, its successor, or, in th= eir absence, the IESG.

   The expert review should only approve emergen= cy services that are

   offered widely and in different countries, wi= th approximately the

   same caller expectation in terms of services = rendered.  The 'sos'

   service is not meant to invoke general govern= ment, public

   information, counseling, or social services.<= o:p>

 

   urn:service:sos  The generic 'sos' servi= ce reaches a public safety

      answering point (PSAP), whi= ch in turn dispatches aid appropriate

      to the emergency.  It = encompasses all of the services listed

      below.

 

NEW TEXT:

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

 

4.2.  Sub-Services for the 'sos' Service

 

   This section defines the first service regist= ration within the IANA

   registry defined in Section 4.1, using the to= p-level service label

   'sos'.

 

   The 'sos' service type describes emergency se= rvices requiring an

   immediate response, typically offered by vari= ous branches of the

   government or other public institutions. = ; Additional sub-services can

   be added after expert review.  The exper= t is designated by the

   ECRIT working group, its successor, or, in th= eir absence, the IESG.

   The expert review should only approve service= s that have emergency nature, that are

   offered in at least one country, that do not = match description of any existing

   service URN with the 'sos' service type,= and where the service description and the

   URN are defined as broadly as possible t= o encourage reuse.  The 'sos'

   service is not meant to invoke general govern= ment, public

   information, counseling, or social services.<= o:p>

 

   urn:service:sos  The generic 'sos' servi= ce reaches a public safety

      answering point (PSAP), whi= ch in turn dispatches aid appropriate

      to the emergency.  It = encompasses all of the services listed

      below.

 

 

--_000_7594FB04B1934943A5C02806D1A2204B108425ESESSMB209ericsso_-- From jmpolk@cisco.com Tue Feb 26 12:40:55 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C377F21F8995 for ; Tue, 26 Feb 2013 12:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.433 X-Spam-Level: X-Spam-Status: No, score=-110.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjJcPgjfjd3s for ; Tue, 26 Feb 2013 12:40:55 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id E8A7C21F8994 for ; Tue, 26 Feb 2013 12:40:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3213; q=dns/txt; s=iport; t=1361911255; x=1363120855; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=QD1u4N1aCG/5khpPTZMZ+EJdWr2Ec1rG15sMczTnoLY=; b=ju+sHJTFT4Qh9qE8rq9Q1euFzjMtVNiOVPaPvggn24jB22rf7qP3qFlI u41MJHDm2JmSKdvCezie+ZoTibg+MADOaDKMuhpcQF1a84Gzfos4fDREI j2PZQFhVolHWSu7oHPveuucjItSlKw5K3/wcOmWrWByJHBZpKRO5JH848 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAB0dLVGtJV2a/2dsb2JhbABFwXV/FnOCHwEBAQQBAQE1AjEDGwcEGAkVBQsPCg4wBgESiBMMr0E9kAsEjxuDQAOIaooVlCmBUoFV X-IronPort-AV: E=Sophos;i="4.84,743,1355097600"; d="scan'208";a="181507614" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 26 Feb 2013 20:40:44 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8717.cisco.com [10.99.80.24]) (authenticated bits=0) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1QKehEm029435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Feb 2013 20:40:44 GMT Message-Id: <201302262040.r1QKehEm029435@rcdn-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 26 Feb 2013 14:40:43 -0600 To: Christer Holmberg , "ecrit@ietf.org" From: James Polk In-Reply-To: <7594FB04B1934943A5C02806D1A2204B108425@ESESSMB209.ericsson .se> References: <7594FB04B1934943A5C02806D1A2204B108425@ESESSMB209.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [Ecrit] RFC 5031 text modification suggestion [was: Draft new version: draft-holmberg-ecrit-country-emg-urn-01] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 20:40:55 -0000 Christer write a bis, see if it flies James At 07:49 AM 2/26/2013, Christer Holmberg wrote: >Content-Language: en-US >Content-Type: multipart/alternative; > >boundary="_000_7594FB04B1934943A5C02806D1A2204B108425ESESSMB209ericsso_" > >Hi, > >Below is a suggestion how the text in RFC 5031 could be modified, in >order to allow registration of emergency URNs that, at the time of >registration, are specific to one country. > >Regards, > >Christer > >--------------------------------- > >OLD TEXT: >-------------- > >4.2. Sub-Services for the 'sos' Service > > This section defines the first service registration within the IANA > registry defined in Section 4.1, using the top-level service label > 'sos'. > > The 'sos' service type describes emergency services requiring an > immediate response, typically offered by various branches of the > government or other public institutions. Additional sub-services can > be added after expert review and must be of general public interest > and have a similar emergency nature. The expert is designated by the > ECRIT working group, its successor, or, in their absence, the IESG. > The expert review should only approve emergency services that are > offered widely and in different countries, with approximately the > same caller expectation in terms of services rendered. The 'sos' > service is not meant to invoke general government, public > information, counseling, or social services. > > urn:service:sos The generic 'sos' service reaches a public safety > answering point (PSAP), which in turn dispatches aid appropriate > to the emergency. It encompasses all of the services listed > below. > >NEW TEXT: >-------------- > >4.2. Sub-Services for the 'sos' Service > > This section defines the first service registration within the IANA > registry defined in Section 4.1, using the top-level service label > 'sos'. > > The 'sos' service type describes emergency services requiring an > immediate response, typically offered by various branches of the > government or other public institutions. Additional sub-services can > be added after expert review. The expert is designated by the > ECRIT working group, its successor, or, in their absence, the IESG. > The expert review should only approve services that have > emergency nature, that are > offered in at least one country, that do not match description > of any existing > service URN with the 'sos' service type, and where the service > description and the > URN are defined as broadly as possible to encourage reuse. The 'sos' > service is not meant to invoke general government, public > information, counseling, or social services. > > urn:service:sos The generic 'sos' service reaches a public safety > answering point (PSAP), which in turn dispatches aid appropriate > to the emergency. It encompasses all of the services listed > below. > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From rlb@ipv.sx Tue Feb 26 13:00:20 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6665021F85FD for ; Tue, 26 Feb 2013 13:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzYcbGZnBIN7 for ; Tue, 26 Feb 2013 13:00:19 -0800 (PST) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id B815921F85C3 for ; Tue, 26 Feb 2013 13:00:18 -0800 (PST) Received: by mail-oa0-f50.google.com with SMTP id l20so6232547oag.37 for ; Tue, 26 Feb 2013 13:00:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=e7zlqj2bvxPvvuKWxz5Mji6XW3c5iocDaQGK8WHlwD8=; b=UhrnT4pq0dvZlDo7jTxQFdMx5B2QA5RpfHotwl+R6eluiBZRS7K/MPd5Kt9vcQj+HX r+/+c/yttPkGIUxd9e3EcX0N4ljo9u78x+CuVIYkNWm9CDwBJcVs4bodvYaQZ5Moavge Yy5ExHh3ysYwXBmv1MkcnmCnVcn7yK3HxGqg+ikoSjsnPnGiaDu7H635Sel3NPDSNaFX uVxmVkRKtM/HOT45sv0K2QORO97KlcQ9ea0JH7aKSKrArTxcDCnHXGzAFF2yu3/DiWhh CkbSaUujCC/ExmtM7uzvGZinu658MqOzYco4KSCtrM4ImegjxuMHq54a4bwtudKPvI/8 JEAA== MIME-Version: 1.0 X-Received: by 10.60.12.41 with SMTP id v9mr2896979oeb.75.1361912417551; Tue, 26 Feb 2013 13:00:17 -0800 (PST) Received: by 10.60.60.98 with HTTP; Tue, 26 Feb 2013 13:00:17 -0800 (PST) X-Originating-IP: [192.1.255.180] In-Reply-To: <201302262040.r1QKehEm029435@rcdn-core-3.cisco.com> References: <7594FB04B1934943A5C02806D1A2204B108425@ESESSMB209.ericsson.se> <201302262040.r1QKehEm029435@rcdn-core-3.cisco.com> Date: Tue, 26 Feb 2013 16:00:17 -0500 Message-ID: From: Richard Barnes To: James Polk Content-Type: multipart/alternative; boundary=e89a8ff255d4dd1eaf04d6a6f145 X-Gm-Message-State: ALoCoQkgnHTlgmUPTx9gjQMj8tesUQ9ffNqOMhaTPDyWb1BNzOSmvPnOBuZrWM8US4xPaBvfno5t Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] RFC 5031 text modification suggestion [was: Draft new version: draft-holmberg-ecrit-country-emg-urn-01] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 21:00:20 -0000 --e89a8ff255d4dd1eaf04d6a6f145 Content-Type: text/plain; charset=ISO-8859-1 I think this is the proposed content of the -bis :) On a quick read, this text looks pretty good to me. --Richard On Tue, Feb 26, 2013 at 3:40 PM, James Polk wrote: > Christer > > write a bis, see if it flies > > James > > At 07:49 AM 2/26/2013, Christer Holmberg wrote: > >> Content-Language: en-US >> Content-Type: multipart/alternative; >> >> boundary="_000_**7594FB04B1934943A5C02806D1A220** >> 4B108425ESESSMB209ericsso_" >> >> >> Hi, >> >> Below is a suggestion how the text in RFC 5031 could be modified, in >> order to allow registration of emergency URNs that, at the time of >> registration, are specific to one country. >> >> Regards, >> >> Christer >> >> ------------------------------**--- >> >> OLD TEXT: >> -------------- >> >> 4.2. Sub-Services for the 'sos' Service >> >> This section defines the first service registration within the IANA >> registry defined in Section 4.1, using the top-level service label >> 'sos'. >> >> The 'sos' service type describes emergency services requiring an >> immediate response, typically offered by various branches of the >> government or other public institutions. Additional sub-services can >> be added after expert review and must be of general public interest >> and have a similar emergency nature. The expert is designated by the >> ECRIT working group, its successor, or, in their absence, the IESG. >> The expert review should only approve emergency services that are >> offered widely and in different countries, with approximately the >> same caller expectation in terms of services rendered. The 'sos' >> service is not meant to invoke general government, public >> information, counseling, or social services. >> >> urn:service:sos The generic 'sos' service reaches a public safety >> answering point (PSAP), which in turn dispatches aid appropriate >> to the emergency. It encompasses all of the services listed >> below. >> >> NEW TEXT: >> -------------- >> >> 4.2. Sub-Services for the 'sos' Service >> >> This section defines the first service registration within the IANA >> registry defined in Section 4.1, using the top-level service label >> 'sos'. >> >> The 'sos' service type describes emergency services requiring an >> immediate response, typically offered by various branches of the >> government or other public institutions. Additional sub-services can >> be added after expert review. The expert is designated by the >> ECRIT working group, its successor, or, in their absence, the IESG. >> The expert review should only approve services that have emergency >> nature, that are >> offered in at least one country, that do not match description of any >> existing >> service URN with the 'sos' service type, and where the service >> description and the >> URN are defined as broadly as possible to encourage reuse. The 'sos' >> service is not meant to invoke general government, public >> information, counseling, or social services. >> >> urn:service:sos The generic 'sos' service reaches a public safety >> answering point (PSAP), which in turn dispatches aid appropriate >> to the emergency. It encompasses all of the services listed >> below. >> >> >> ______________________________**_________________ >> 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 > --e89a8ff255d4dd1eaf04d6a6f145 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think this is the proposed content of the -bis :)

On a= quick read, this text looks pretty good to me.

--= Richard



On Tue,= Feb 26, 2013 at 3:40 PM, James Polk <jmpolk@cisco.com> wrote= :
Christer

write a bis, see if it flies

James

At 07:49 AM 2/26/2013, Christer Holmberg wrote:
Content-Language: en-US
Content-Type: multipart/alternative;

boundary=3D"_000_7594FB04B1934943A5C02806D1A2204B108425E= SESSMB209ericsso_"


Hi,

Below is a suggestion how the text in RFC 5031 could be modified, in order = to allow registration of emergency URNs that, at the time of registration, = are specific to one country.

Regards,

Christer

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

OLD TEXT:
--------------

4.2. =A0Sub-Services for the 'sos' Service

=A0 =A0This section defines the first service registration within the IANA<= br> =A0 =A0registry defined in Section 4.1, using the top-level service label =A0 =A0'sos'.

=A0 =A0The 'sos' service type describes emergency services requirin= g an
=A0 =A0immediate response, typically offered by various branches of the
=A0 =A0government or other public institutions. =A0Additional sub-services = can
=A0 =A0be added after expert review and must be of general public interest<= br> =A0 =A0and have a similar emergency nature. =A0The expert is designated by = the
=A0 =A0ECRIT working group, its successor, or, in their absence, the IESG.<= br> =A0 =A0The expert review should only approve emergency services that are =A0 =A0offered widely and in different countries, with approximately the =A0 =A0same caller expectation in terms of services rendered. =A0The 's= os'
=A0 =A0service is not meant to invoke general government, public
=A0 =A0information, counseling, or social services.

=A0 =A0urn:service:sos =A0The generic 'sos' service reaches a publi= c safety
=A0 =A0 =A0 answering point (PSAP), which in turn dispatches aid appropriat= e
=A0 =A0 =A0 to the emergency. =A0It encompasses all of the services listed<= br> =A0 =A0 =A0 below.

NEW TEXT:
--------------

4.2. =A0Sub-Services for the 'sos' Service

=A0 =A0This section defines the first service registration within the IANA<= br> =A0 =A0registry defined in Section 4.1, using the top-level service label =A0 =A0'sos'.

=A0 =A0The 'sos' service type describes emergency services requirin= g an
=A0 =A0immediate response, typically offered by various branches of the
=A0 =A0government or other public institutions. =A0Additional sub-services = can
=A0 =A0be added after expert review. =A0The expert is designated by the
=A0 =A0ECRIT working group, its successor, or, in their absence, the IESG.<= br> =A0 =A0The expert review should only approve services that have emergency n= ature, that are
=A0 =A0offered in at least one country, that do not match description of an= y existing
=A0 =A0service URN with the 'sos' service type, and where the servi= ce description and the
=A0 =A0URN are defined as broadly as possible to encourage reuse. =A0The &#= 39;sos'
=A0 =A0service is not meant to invoke general government, public
=A0 =A0information, counseling, or social services.

=A0 =A0urn:service:sos =A0The generic 'sos' service reaches a publi= c safety
=A0 =A0 =A0 answering point (PSAP), which in turn dispatches aid appropriat= e
=A0 =A0 =A0 to the emergency. =A0It encompasses all of the services listed<= br> =A0 =A0 =A0 below.


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

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

--e89a8ff255d4dd1eaf04d6a6f145-- From jmpolk@cisco.com Tue Feb 26 13:36:04 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24A121F8617 for ; Tue, 26 Feb 2013 13:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.438 X-Spam-Level: X-Spam-Status: No, score=-110.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGGMbPZixKy5 for ; Tue, 26 Feb 2013 13:36:04 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D9FB421F85D9 for ; Tue, 26 Feb 2013 13:36:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3873; q=dns/txt; s=iport; t=1361914564; x=1363124164; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=V8Zvm/wNeoixi4xABbNkBknmwdOqIzzVzNgELKBfAD0=; b=cyVgqK0Cl/QR7WbewA+XjqIWsc4qf7UPT29ESQ+aZFc/Ql8Y6dabb24E 7PP22gHXo3EdiOHkDB8KqSoZxpewLMaT2Lucm+fNlDnpapjuDc0GVG3gW uVX1vRvyRmdk4EX8QdHYHGz6pO+CUow8iSh6J1d3PXfSX9x/fKXMezVBQ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAI0pLVGtJV2a/2dsb2JhbABFwXWBARZzgh8BAQEEAQEBNQIxAwsQBwQOCgkVBQQHDwoOHxEGE4gTDK9IPZALBI8UB4NAA4hqihWUKYFSgVU X-IronPort-AV: E=Sophos;i="4.84,743,1355097600"; d="scan'208";a="181482327" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 26 Feb 2013 21:36:03 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8717.cisco.com [10.99.80.24]) (authenticated bits=0) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1QLa2cl009174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Feb 2013 21:36:03 GMT Message-Id: <201302262136.r1QLa2cl009174@rcdn-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 26 Feb 2013 15:36:02 -0600 To: Richard Barnes From: James Polk In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B108425@ESESSMB209.ericsson.se> <201302262040.r1QKehEm029435@rcdn-core-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] RFC 5031 text modification suggestion [was: Draft new version: draft-holmberg-ecrit-country-emg-urn-01] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 21:36:04 -0000 My point was, write the actual draft "with that text included" and see if it reaches WG consensus, as there is no measurable consensus if not already in draft form. James At 03:00 PM 2/26/2013, Richard Barnes wrote: >I think this is the proposed content of the -bis :) > >On a quick read, this text looks pretty good to me. > >--Richard > > > >On Tue, Feb 26, 2013 at 3:40 PM, James Polk ><jmpolk@cisco.com> wrote: >Christer > >write a bis, see if it flies > >James > >At 07:49 AM 2/26/2013, Christer Holmberg wrote: >Content-Language: en-US >Content-Type: multipart/alternative; > >boundary="_000_7594FB04B1934943A5C02806D1A2204B108425ESESSMB209ericsso_" > > >Hi, > >Below is a suggestion how the text in RFC 5031 could be modified, in >order to allow registration of emergency URNs that, at the time of >registration, are specific to one country. > >Regards, > >Christer > >--------------------------------- > >OLD TEXT: >-------------- > >4.2. Sub-Services for the 'sos' Service > > This section defines the first service registration within the IANA > registry defined in Section 4.1, using the top-level service label > 'sos'. > > The 'sos' service type describes emergency services requiring an > immediate response, typically offered by various branches of the > government or other public institutions. Additional sub-services can > be added after expert review and must be of general public interest > and have a similar emergency nature. The expert is designated by the > ECRIT working group, its successor, or, in their absence, the IESG. > The expert review should only approve emergency services that are > offered widely and in different countries, with approximately the > same caller expectation in terms of services rendered. The 'sos' > service is not meant to invoke general government, public > information, counseling, or social services. > > urn:service:sos The generic 'sos' service reaches a public safety > answering point (PSAP), which in turn dispatches aid appropriate > to the emergency. It encompasses all of the services listed > below. > >NEW TEXT: >-------------- > >4.2. Sub-Services for the 'sos' Service > > This section defines the first service registration within the IANA > registry defined in Section 4.1, using the top-level service label > 'sos'. > > The 'sos' service type describes emergency services requiring an > immediate response, typically offered by various branches of the > government or other public institutions. Additional sub-services can > be added after expert review. The expert is designated by the > ECRIT working group, its successor, or, in their absence, the IESG. > The expert review should only approve services that have > emergency nature, that are > offered in at least one country, that do not match description > of any existing > service URN with the 'sos' service type, and where the service > description and the > URN are defined as broadly as possible to encourage reuse. The 'sos' > service is not meant to invoke general government, public > information, counseling, or social services. > > urn:service:sos The generic 'sos' service reaches a public safety > answering point (PSAP), which in turn dispatches aid appropriate > to the emergency. It encompasses all of the services listed > below. > > >_______________________________________________ >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 > From pkyzivat@alum.mit.edu Tue Feb 26 13:54:02 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5725D21F8712 for ; Tue, 26 Feb 2013 13:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZiqtaSLu7l7 for ; Tue, 26 Feb 2013 13:54:01 -0800 (PST) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:243]) by ietfa.amsl.com (Postfix) with ESMTP id 3E92F21F8626 for ; Tue, 26 Feb 2013 13:53:56 -0800 (PST) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta13.emeryville.ca.mail.comcast.net with comcast id 52qV1l0071Y3wxoAD9twHM; Tue, 26 Feb 2013 21:53:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([115.192.168.149]) by omta15.emeryville.ca.mail.comcast.net with comcast id 59rm1l0013DkNMf8b9rpqs; Tue, 26 Feb 2013 21:51:54 +0000 Message-ID: <512D2E71.5030600@alum.mit.edu> Date: Wed, 27 Feb 2013 05:51:45 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: ecrit@ietf.org References: <7594FB04B1934943A5C02806D1A2204B108425@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B108425@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361915636; bh=oPhQl7UtNUwavfp+WaLaKccc5vmpe9Lglx7lmTvCEj0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VvjkDmu+ZMmdJEgCf4T0HUvLNLcZbyLLs3nfcP0PGt8hFLof0EWfoa0LMSNzdeKyM 5Tcg4WkvIdA1WuJ8qFzmhIZcBlFvaBR5INZbV/Rgwp36yZREi0RZT9MDGCfJs0UXPB 3NVytkVXe95e2OzMq+td5S8kiNwTD2uqG1Q5hkLUmFSgqzadpJKR7Y3MHPdZ3cW+J0 kv1P7hP5X9vjibTaRvKgq8qoyEW5wvRyMhkCGhS5f8X9aB/6bUqQjrtul/FLEYS3Ax a57D8+tF25cyCOTD4FwJmsELEH5EBrib8o6xQ16ak4vg2+c0upwbIKjWtJBrj0Zjwm KSwYluZ8eJpHQ== Subject: Re: [Ecrit] RFC 5031 text modification suggestion [was: Draft new version: draft-holmberg-ecrit-country-emg-urn-01] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 21:54:02 -0000 WFM On 2/26/13 9:49 PM, Christer Holmberg wrote: > Hi, > > Below is a suggestion how the text in RFC 5031 could be modified, in > order to allow registration of emergency URNs that, at the time of > registration, are specific to one country. > > Regards, > > Christer > > --------------------------------- > > OLD TEXT: > > -------------- > > 4.2. Sub-Services for the 'sos' Service > > This section defines the first service registration within the IANA > > registry defined in Section 4.1, using the top-level service label > > 'sos'. > > The 'sos' service type describes emergency services requiring an > > immediate response, typically offered by various branches of the > > government or other public institutions. Additional sub-services can > > be added after expert review and must be of general public interest > > and have a similar emergency nature. The expert is designated by the > > ECRIT working group, its successor, or, in their absence, the IESG. > > The expert review should only approve emergency services that are > > offered widely and in different countries, with approximately the > > same caller expectation in terms of services rendered. The 'sos' > > service is not meant to invoke general government, public > > information, counseling, or social services. > > urn:service:sos The generic 'sos' service reaches a public safety > > answering point (PSAP), which in turn dispatches aid appropriate > > to the emergency. It encompasses all of the services listed > > below. > > NEW TEXT: > > -------------- > > 4.2. Sub-Services for the 'sos' Service > > This section defines the first service registration within the IANA > > registry defined in Section 4.1, using the top-level service label > > 'sos'. > > The 'sos' service type describes emergency services requiring an > > immediate response, typically offered by various branches of the > > government or other public institutions. Additional sub-services can > > be added after expert review. The expert is designated by the > > ECRIT working group, its successor, or, in their absence, the IESG. > > The expert review should only approve services that have emergency > nature, that are > > offered in at least one country, that do not match description of > any existing > > service URN with the 'sos' service type, and where the service > description and the > > URN are defined as broadly as possible to encourage reuse. The 'sos' > > service is not meant to invoke general government, public > > information, counseling, or social services. > > urn:service:sos The generic 'sos' service reaches a public safety > > answering point (PSAP), which in turn dispatches aid appropriate > > to the emergency. It encompasses all of the services listed > > below. > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From christer.holmberg@ericsson.com Wed Feb 27 01:45:32 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8651721F8596 for ; Wed, 27 Feb 2013 01:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.252 X-Spam-Level: X-Spam-Status: No, score=-6.252 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-UF1Cf8CMAY for ; Wed, 27 Feb 2013 01:45:31 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 448B221F859A for ; Wed, 27 Feb 2013 01:45:31 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-37-512dd5b903e0 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id ED.17.32353.9B5DD215; Wed, 27 Feb 2013 10:45:30 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0318.004; Wed, 27 Feb 2013 10:45:29 +0100 From: Christer Holmberg To: James Polk , Richard Barnes Thread-Topic: [Ecrit] RFC 5031 text modification suggestion [was: Draft new version: draft-holmberg-ecrit-country-emg-urn-01] Thread-Index: AQHOFGlIKWHvStnClEmG5wwr3MlLcZiNcvzA Date: Wed, 27 Feb 2013 09:45:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B10AE05@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B108425@ESESSMB209.ericsson.se> <201302262040.r1QKehEm029435@rcdn-core-3.cisco.com> <201302262136.r1QLa2cl009174@rcdn-core-3.cisco.com> In-Reply-To: <201302262136.r1QLa2cl009174@rcdn-core-3.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvje6uq7qBBrOfSlg0LnrKarFjTaHF 1D5bB2aPKb83snosWfKTyWPyxlksAcxRXDYpqTmZZalF+nYJXBk3lq5gKjijWHH4zG+mBsZL Ul2MnBwSAiYSd6+eZoOwxSQu3FsPZHNxCAkcYpRYsekMK4SzmFFiz7IpQBkODjYBC4nuf9og DSICdhJzWz4ygtjMAqoS5xofs4DYwgL1El2nz7CD9IoINDBKHLh2nQWiwUji252zzCBzWIAa +n54gpi8At4SS2+mQKz6xyhxcOU0sHJOAQeJF1d2g9mMQMd9P7WGCWKXuMStJ/OZII4WkFiy 5zwzhC0q8fLxP1YIW1Hi6vTlUPU6Egt2f2KDsLUlli18DVbPKyAocXLmE5YJjGKzkIydhaRl FpKWWUhaFjCyrGJkz03MzEkvN9/ECIyZg1t+G+xg3HRf7BCjNAeLkjhvuOuFACGB9MSS1OzU 1ILUovii0pzU4kOMTBycUg2MlgbPp/4LCE9v+BRsycuj/qJmSUaFv5FO2cxVW3Y+YvpW/d97 5wTLvNSUhbfkhD4mJfOenJ6oX5jBGr/LyURZ/0TvHMvfU0rE9B562tSrhB/N9WFbwlh52aZ3 e3hPXt0+jh0/gyVV707xV/50P8VGK7Gyd0F3Fp996cr5db9WyAjGapR9UFJiKc5INNRiLipO BACo7GzHZwIAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] RFC 5031 text modification suggestion [was: Draft new version: draft-holmberg-ecrit-country-emg-urn-01] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 09:45:32 -0000 Hi James, >My point was, write the actual draft "with that text included" and see if = it reaches WG consensus, as there is no measurable consensus if not already= in draft form. Unfortunately it's too late to submit a new version of the draft before Orl= ando. But, I think we can still discuss suggested text changes, eventhough = "official consensus" cannot be done :) We also need to think about whether the text would go into a bis, or whethe= r we would produce a separate document which simply updates the affected se= ction in RFC 5031. Regards, Christer At 03:00 PM 2/26/2013, Richard Barnes wrote: >I think this is the proposed content of the -bis :) > >On a quick read, this text looks pretty good to me. > >--Richard > > > >On Tue, Feb 26, 2013 at 3:40 PM, James Polk=20 ><jmpolk@cisco.com> wrote: >Christer > >write a bis, see if it flies > >James > >At 07:49 AM 2/26/2013, Christer Holmberg wrote: >Content-Language: en-US >Content-Type: multipart/alternative; > >boundary=3D"_000_7594FB04B1934943A5C02806D1A2204B108425ESESSMB209ericsso_" > > >Hi, > >Below is a suggestion how the text in RFC 5031 could be modified, in=20 >order to allow registration of emergency URNs that, at the time of=20 >registration, are specific to one country. > >Regards, > >Christer > >--------------------------------- > >OLD TEXT: >-------------- > >4.2. Sub-Services for the 'sos' Service > > This section defines the first service registration within the IANA > registry defined in Section 4.1, using the top-level service label > 'sos'. > > The 'sos' service type describes emergency services requiring an > immediate response, typically offered by various branches of the > government or other public institutions. Additional sub-services can > be added after expert review and must be of general public interest > and have a similar emergency nature. The expert is designated by the > ECRIT working group, its successor, or, in their absence, the IESG. > The expert review should only approve emergency services that are > offered widely and in different countries, with approximately the > same caller expectation in terms of services rendered. The 'sos' > service is not meant to invoke general government, public > information, counseling, or social services. > > urn:service:sos The generic 'sos' service reaches a public safety > answering point (PSAP), which in turn dispatches aid appropriate > to the emergency. It encompasses all of the services listed > below. > >NEW TEXT: >-------------- > >4.2. Sub-Services for the 'sos' Service > > This section defines the first service registration within the IANA > registry defined in Section 4.1, using the top-level service label > 'sos'. > > The 'sos' service type describes emergency services requiring an > immediate response, typically offered by various branches of the > government or other public institutions. Additional sub-services can > be added after expert review. The expert is designated by the > ECRIT working group, its successor, or, in their absence, the IESG. > The expert review should only approve services that have emergency=20 > nature, that are > offered in at least one country, that do not match description of=20 > any existing > service URN with the 'sos' service type, and where the service=20 > description and the > URN are defined as broadly as possible to encourage reuse. The 'sos' > service is not meant to invoke general government, public > information, counseling, or social services. > > urn:service:sos The generic 'sos' service reaches a public safety > answering point (PSAP), which in turn dispatches aid appropriate > to the emergency. It encompasses all of the services listed > below. > > >_______________________________________________ >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 > From brian.rosen@neustar.biz Wed Feb 27 06:04:11 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C279F21F8573 for ; Wed, 27 Feb 2013 06:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.02 X-Spam-Level: X-Spam-Status: No, score=-6.02 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oERTsDdwGkM for ; Wed, 27 Feb 2013 06:04:11 -0800 (PST) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id ACE8621F856F for ; Wed, 27 Feb 2013 06:04:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1361974039; x=1677327081; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=4wJFxBUP29ATpeKCRbURC +9N5ZxFQS3QHQLAzv+vFyk=; b=YdBTkALHem/vS3kZVndTTL0DaOCy7cvW8jpQG xNmOEI0Ojlwq7pFCIsGv1whgE+GHh8bLnwS32Zm7yP02YP8bw== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.20282392; Wed, 27 Feb 2013 09:07:18 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Wed, 27 Feb 2013 09:04:05 -0500 From: "Rosen, Brian" To: Christer Holmberg Date: Wed, 27 Feb 2013 09:04:04 -0500 Thread-Topic: [Ecrit] RFC 5031 text modification suggestion [was: Draft new version: draft-holmberg-ecrit-country-emg-urn-01] Thread-Index: Ac4U801rexwb1/O/Toa1jgk2aP/w5A== Message-ID: <08FA77EA-A129-4A51-8213-963A928A1F18@neustar.biz> References: <7594FB04B1934943A5C02806D1A2204B108425@ESESSMB209.ericsson.se> <201302262040.r1QKehEm029435@rcdn-core-3.cisco.com> <201302262136.r1QLa2cl009174@rcdn-core-3.cisco.com> <7594FB04B1934943A5C02806D1A2204B10AE05@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B10AE05@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 5Ne0r69waOmWkvTLgPzt1A== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] RFC 5031 text modification suggestion [was: Draft new version: draft-holmberg-ecrit-country-emg-urn-01] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 14:04:11 -0000 could go in urn-policy On Feb 27, 2013, at 4:45 AM, Christer Holmberg wrote: >=20 > Hi James, >=20 >> My point was, write the actual draft "with that text included" and see i= f it reaches WG consensus, as there is no measurable consensus if not alrea= dy in draft form. >=20 > Unfortunately it's too late to submit a new version of the draft before O= rlando. But, I think we can still discuss suggested text changes, eventhoug= h "official consensus" cannot be done :) >=20 > We also need to think about whether the text would go into a bis, or whet= her we would produce a separate document which simply updates the affected = section in RFC 5031. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > At 03:00 PM 2/26/2013, Richard Barnes wrote: >> I think this is the proposed content of the -bis :) >>=20 >> On a quick read, this text looks pretty good to me. >>=20 >> --Richard >>=20 >>=20 >>=20 >> On Tue, Feb 26, 2013 at 3:40 PM, James Polk=20 >> <jmpolk@cisco.com> wrote: >> Christer >>=20 >> write a bis, see if it flies >>=20 >> James >>=20 >> At 07:49 AM 2/26/2013, Christer Holmberg wrote: >> Content-Language: en-US >> Content-Type: multipart/alternative; >>=20 >> boundary=3D"_000_7594FB04B1934943A5C02806D1A2204B108425ESESSMB209ericsso= _" >>=20 >>=20 >> Hi, >>=20 >> Below is a suggestion how the text in RFC 5031 could be modified, in=20 >> order to allow registration of emergency URNs that, at the time of=20 >> registration, are specific to one country. >>=20 >> Regards, >>=20 >> Christer >>=20 >> --------------------------------- >>=20 >> OLD TEXT: >> -------------- >>=20 >> 4.2. Sub-Services for the 'sos' Service >>=20 >> This section defines the first service registration within the IANA >> registry defined in Section 4.1, using the top-level service label >> 'sos'. >>=20 >> The 'sos' service type describes emergency services requiring an >> immediate response, typically offered by various branches of the >> government or other public institutions. Additional sub-services can >> be added after expert review and must be of general public interest >> and have a similar emergency nature. The expert is designated by the >> ECRIT working group, its successor, or, in their absence, the IESG. >> The expert review should only approve emergency services that are >> offered widely and in different countries, with approximately the >> same caller expectation in terms of services rendered. The 'sos' >> service is not meant to invoke general government, public >> information, counseling, or social services. >>=20 >> urn:service:sos The generic 'sos' service reaches a public safety >> answering point (PSAP), which in turn dispatches aid appropriate >> to the emergency. It encompasses all of the services listed >> below. >>=20 >> NEW TEXT: >> -------------- >>=20 >> 4.2. Sub-Services for the 'sos' Service >>=20 >> This section defines the first service registration within the IANA >> registry defined in Section 4.1, using the top-level service label >> 'sos'. >>=20 >> The 'sos' service type describes emergency services requiring an >> immediate response, typically offered by various branches of the >> government or other public institutions. Additional sub-services can >> be added after expert review. The expert is designated by the >> ECRIT working group, its successor, or, in their absence, the IESG. >> The expert review should only approve services that have emergency=20 >> nature, that are >> offered in at least one country, that do not match description of=20 >> any existing >> service URN with the 'sos' service type, and where the service=20 >> description and the >> URN are defined as broadly as possible to encourage reuse. The 'sos' >> service is not meant to invoke general government, public >> information, counseling, or social services. >>=20 >> urn:service:sos The generic 'sos' service reaches a public safety >> answering point (PSAP), which in turn dispatches aid appropriate >> to the emergency. It encompasses all of the services listed >> below. >>=20 >>=20 >> _______________________________________________ >> 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 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From rlb@ipv.sx Wed Feb 27 06:33:32 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C447F21F84AB for ; Wed, 27 Feb 2013 06:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgONWNauDyt6 for ; Wed, 27 Feb 2013 06:33:30 -0800 (PST) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id C341721F8459 for ; Wed, 27 Feb 2013 06:33:29 -0800 (PST) Received: by mail-oa0-f46.google.com with SMTP id k1so1241221oag.5 for ; Wed, 27 Feb 2013 06:33:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=XGyPoIAS+Ci6DMAHI05MOC5/HJ6SpeYzv3BSbvyD+lE=; b=nEruvJxpSNbH4CBogQMLh92B94KM+KxX07jL//Tw4cSO0VF8GB89EqC7txvyimL4ZE JjSnxlpg1Tvw/FjVkm2DG0SvMkEXWrsWxYGPTWmu6GZVP9Nn11SMiqB4iWc///Z23r0T njlm3HIaQQkE7oRm1GvLnY1HExXQlAD3yCsNmVYQmfm3JVXef5q5RZyyTYZzdIva7HJV StkQpchcfKyFyVMTA9ZM88XmCgX+dy2wybxk66/8E/mHbMPrM2iqct4nG/4h4fEt9yrR FH3AkMlxClHhZOq3V7K3nevyg/PVPPSWZcnstTYXoNCDpY1Ow/9XX9bgNpAkf+xploo9 wjPQ== MIME-Version: 1.0 X-Received: by 10.60.11.168 with SMTP id r8mr2163084oeb.136.1361975609280; Wed, 27 Feb 2013 06:33:29 -0800 (PST) Received: by 10.60.60.98 with HTTP; Wed, 27 Feb 2013 06:33:29 -0800 (PST) X-Originating-IP: [192.1.51.63] In-Reply-To: <08FA77EA-A129-4A51-8213-963A928A1F18@neustar.biz> References: <7594FB04B1934943A5C02806D1A2204B108425@ESESSMB209.ericsson.se> <201302262040.r1QKehEm029435@rcdn-core-3.cisco.com> <201302262136.r1QLa2cl009174@rcdn-core-3.cisco.com> <7594FB04B1934943A5C02806D1A2204B10AE05@ESESSMB209.ericsson.se> <08FA77EA-A129-4A51-8213-963A928A1F18@neustar.biz> Date: Wed, 27 Feb 2013 09:33:29 -0500 Message-ID: From: Richard Barnes To: "Rosen, Brian" Content-Type: multipart/alternative; boundary=e89a8fb1f35a62609804d6b5a8f9 X-Gm-Message-State: ALoCoQlFug/wnIpUiu2Idy+UCZ6nL7ZwXUgUUdSyXMDfdW6YNjWyMUhk01vLd84Org2CqxXDm8eg Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] RFC 5031 text modification suggestion [was: Draft new version: draft-holmberg-ecrit-country-emg-urn-01] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 14:33:32 -0000 --e89a8fb1f35a62609804d6b5a8f9 Content-Type: text/plain; charset=ISO-8859-1 Well, urn-policy is more general. Also, it's currently BCP, so it would need to chance to Proposed Standard to update RFC 5031. My slight preference is for a short document that just does the specific update. That way, when someone reads RFC 5031 and sees "Updated by...", they don't have to dig through all of urn-policy to see what the change is. On Wed, Feb 27, 2013 at 9:04 AM, Rosen, Brian wrote: > could go in urn-policy > On Feb 27, 2013, at 4:45 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > > > > Hi James, > > > >> My point was, write the actual draft "with that text included" and see > if it reaches WG consensus, as there is no measurable consensus if not > already in draft form. > > > > Unfortunately it's too late to submit a new version of the draft before > Orlando. But, I think we can still discuss suggested text changes, > eventhough "official consensus" cannot be done :) > > > > We also need to think about whether the text would go into a bis, or > whether we would produce a separate document which simply updates the > affected section in RFC 5031. > > > > Regards, > > > > Christer > > > > > > > > At 03:00 PM 2/26/2013, Richard Barnes wrote: > >> I think this is the proposed content of the -bis :) > >> > >> On a quick read, this text looks pretty good to me. > >> > >> --Richard > >> > >> > >> > >> On Tue, Feb 26, 2013 at 3:40 PM, James Polk > >> <jmpolk@cisco.com> wrote: > >> Christer > >> > >> write a bis, see if it flies > >> > >> James > >> > >> At 07:49 AM 2/26/2013, Christer Holmberg wrote: > >> Content-Language: en-US > >> Content-Type: multipart/alternative; > >> > >> boundary="_000_7594FB04B1934943A5C02806D1A2204B108425ESESSMB209ericsso_" > >> > >> > >> Hi, > >> > >> Below is a suggestion how the text in RFC 5031 could be modified, in > >> order to allow registration of emergency URNs that, at the time of > >> registration, are specific to one country. > >> > >> Regards, > >> > >> Christer > >> > >> --------------------------------- > >> > >> OLD TEXT: > >> -------------- > >> > >> 4.2. Sub-Services for the 'sos' Service > >> > >> This section defines the first service registration within the IANA > >> registry defined in Section 4.1, using the top-level service label > >> 'sos'. > >> > >> The 'sos' service type describes emergency services requiring an > >> immediate response, typically offered by various branches of the > >> government or other public institutions. Additional sub-services can > >> be added after expert review and must be of general public interest > >> and have a similar emergency nature. The expert is designated by the > >> ECRIT working group, its successor, or, in their absence, the IESG. > >> The expert review should only approve emergency services that are > >> offered widely and in different countries, with approximately the > >> same caller expectation in terms of services rendered. The 'sos' > >> service is not meant to invoke general government, public > >> information, counseling, or social services. > >> > >> urn:service:sos The generic 'sos' service reaches a public safety > >> answering point (PSAP), which in turn dispatches aid appropriate > >> to the emergency. It encompasses all of the services listed > >> below. > >> > >> NEW TEXT: > >> -------------- > >> > >> 4.2. Sub-Services for the 'sos' Service > >> > >> This section defines the first service registration within the IANA > >> registry defined in Section 4.1, using the top-level service label > >> 'sos'. > >> > >> The 'sos' service type describes emergency services requiring an > >> immediate response, typically offered by various branches of the > >> government or other public institutions. Additional sub-services can > >> be added after expert review. The expert is designated by the > >> ECRIT working group, its successor, or, in their absence, the IESG. > >> The expert review should only approve services that have emergency > >> nature, that are > >> offered in at least one country, that do not match description of > >> any existing > >> service URN with the 'sos' service type, and where the service > >> description and the > >> URN are defined as broadly as possible to encourage reuse. The 'sos' > >> service is not meant to invoke general government, public > >> information, counseling, or social services. > >> > >> urn:service:sos The generic 'sos' service reaches a public safety > >> answering point (PSAP), which in turn dispatches aid appropriate > >> to the emergency. It encompasses all of the services listed > >> below. > >> > >> > >> _______________________________________________ > >> 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 > > --e89a8fb1f35a62609804d6b5a8f9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well, urn-policy is more general. =A0Also, it's currently BCP, so it wo= uld need to chance to Proposed Standard to update RFC 5031. =A0=A0

=
My slight preference is for a short document that just does the = specific update. =A0That way, when someone reads RFC 5031 and sees "Up= dated by...", they don't have to dig through all of urn-policy to = see what the change is.


On Wed, Feb 27, 2013 at 9:04 AM, Ro= sen, Brian <Brian.Rosen@neustar.biz> wrote:
could go in urn-policy
On Feb 27, 2013, at 4:45 AM, Christ= er Holmberg <christer.= holmberg@ericsson.com> wrote:

>
> Hi James,
>
>> My point was, write the actual draft "with that text included= " and see if it reaches WG consensus, as there is no measurable consen= sus if not already in draft form.
>
> Unfortunately it's too late to submit a new version of the draft b= efore Orlando. But, I think we can still discuss suggested text changes, ev= enthough "official consensus" cannot be done :)
>
> We also need to think about whether the text would go into a bis, or w= hether we would produce a separate document which simply updates the affect= ed section in RFC 5031.
>
> Regards,
>
> Christer
>
>
>
> At 03:00 PM 2/26/2013, Richard Barnes wrote:
>> I think this is the proposed content of the -bis :)
>>
>> On a quick read, this text looks pretty good to me.
>>
>> --Richard
>>
>>
>>
>> On Tue, Feb 26, 2013 at 3:40 PM, James Polk
>> <<mailto:jmpolk@cisco.co= m>jmpolk@cisco.com> wrote= :
>> Christer
>>
>> write a bis, see if it flies
>>
>> James
>>
>> At 07:49 AM 2/26/2013, Christer Holmberg wrote:
>> Content-Language: en-US
>> Content-Type: multipart/alternative;
>>
>> boundary=3D"_000_7594FB04B1934943A5C02806D1A2204B108425ESESSM= B209ericsso_"
>>
>>
>> Hi,
>>
>> Below is a suggestion how the text in RFC 5031 could be modified, = in
>> order to allow registration of emergency URNs that, at the time of=
>> registration, are specific to one country.
>>
>> Regards,
>>
>> Christer
>>
>> ---------------------------------
>>
>> OLD TEXT:
>> --------------
>>
>> 4.2. =A0Sub-Services for the 'sos' Service
>>
>> =A0 This section defines the first service registration within the= IANA
>> =A0 registry defined in Section 4.1, using the top-level service l= abel
>> =A0 'sos'.
>>
>> =A0 The 'sos' service type describes emergency services re= quiring an
>> =A0 immediate response, typically offered by various branches of t= he
>> =A0 government or other public institutions. =A0Additional sub-ser= vices can
>> =A0 be added after expert review and must be of general public int= erest
>> =A0 and have a similar emergency nature. =A0The expert is designat= ed by the
>> =A0 ECRIT working group, its successor, or, in their absence, the = IESG.
>> =A0 The expert review should only approve emergency services that = are
>> =A0 offered widely and in different countries, with approximately = the
>> =A0 same caller expectation in terms of services rendered. =A0The = 'sos'
>> =A0 service is not meant to invoke general government, public
>> =A0 information, counseling, or social services.
>>
>> =A0 urn:service:sos =A0The generic 'sos' service reaches a= public safety
>> =A0 =A0 =A0answering point (PSAP), which in turn dispatches aid ap= propriate
>> =A0 =A0 =A0to the emergency. =A0It encompasses all of the services= listed
>> =A0 =A0 =A0below.
>>
>> NEW TEXT:
>> --------------
>>
>> 4.2. =A0Sub-Services for the 'sos' Service
>>
>> =A0 This section defines the first service registration within the= IANA
>> =A0 registry defined in Section 4.1, using the top-level service l= abel
>> =A0 'sos'.
>>
>> =A0 The 'sos' service type describes emergency services re= quiring an
>> =A0 immediate response, typically offered by various branches of t= he
>> =A0 government or other public institutions. =A0Additional sub-ser= vices can
>> =A0 be added after expert review. =A0The expert is designated by t= he
>> =A0 ECRIT working group, its successor, or, in their absence, the = IESG.
>> =A0 The expert review should only approve services that have emerg= ency
>> nature, that are
>> =A0 offered in at least one country, that do not match description= of
>> any existing
>> =A0 service URN with the 'sos' service type, and where the= service
>> description and the
>> =A0 URN are defined as broadly as possible to encourage reuse. =A0= The 'sos'
>> =A0 service is not meant to invoke general government, public
>> =A0 information, counseling, or social services.
>>
>> =A0 urn:service:sos =A0The generic 'sos' service reaches a= public safety
>> =A0 =A0 =A0answering point (PSAP), which in turn dispatches aid ap= propriate
>> =A0 =A0 =A0to the emergency. =A0It encompasses all of the services= listed
>> =A0 =A0 =A0below.
>>
>>
>> _______________________________________________
>> Ecrit mailing list
>> <mailto:Ecrit@ietf.org>= ;Ecrit@ietf.org
>> 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


--e89a8fb1f35a62609804d6b5a8f9-- From christer.holmberg@ericsson.com Wed Feb 27 06:42:03 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2425721F856D for ; Wed, 27 Feb 2013 06:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.252 X-Spam-Level: X-Spam-Status: No, score=-6.252 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIav8FB7UtPg for ; Wed, 27 Feb 2013 06:42:02 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id DFA9F21F8561 for ; Wed, 27 Feb 2013 06:42:00 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-b9-512e1b372017 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 48.D6.19728.73B1E215; Wed, 27 Feb 2013 15:41:59 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0318.004; Wed, 27 Feb 2013 15:41:59 +0100 From: Christer Holmberg To: Richard Barnes , "Rosen, Brian" Thread-Topic: [Ecrit] RFC 5031 text modification suggestion [was: Draft new version: draft-holmberg-ecrit-country-emg-urn-01] Thread-Index: AQHOFM8yyQAucD40WE6fMDo57/cIZZiNrDcAgAAIOICAABK9IA== Date: Wed, 27 Feb 2013 14:41:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B10B2D3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B108425@ESESSMB209.ericsson.se> <201302262040.r1QKehEm029435@rcdn-core-3.cisco.com> <201302262136.r1QLa2cl009174@rcdn-core-3.cisco.com> <7594FB04B1934943A5C02806D1A2204B10AE05@ESESSMB209.ericsson.se> <08FA77EA-A129-4A51-8213-963A928A1F18@neustar.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+Jvja65tF6gwbejVhbTTl5mtmhc9JTV YseaQoupfbYOLB5Tfm9k9Viy5CeTx+SNs1g8djQ8Zw5gieKySUnNySxLLdK3S+DKWPlyMlvB Ca2Kvh3vGRsYDyt1MXJySAiYSLRues4IYYtJXLi3nq2LkYtDSOAQo8Sdy9OhnMWMErM+nmHq YuTgYBOwkOj+pw3SICLgKfFs/ydmEJtZwEXi9KX5zCAlwgJ1Epu/lYGYIgL1EqdnhkNUO0k8 Wd/NBGKzCKhK3P7+lBXE5hXwlph1/hQLxKY9zBJLV00FG8kpECjRe/MXWAMj0G3fT61hglgl LnHryXwmiJsFJJbsOc8MYYtKvHz8jxXCVpS4On05VL2exI2pU9ggbG2JZQtfM0MsFpQ4OfMJ ywRGsVlIxs5C0jILScssJC0LGFlWMbLnJmbmpJcbbWIERtHBLb9VdzDeOSdyiFGag0VJnDfc 9UKAkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsb5D57UlO8obPz1Z/4LI7tVmXWn40Jbrcov 3X5YtDfl2Nb/4hNYt52qea3ixXzGPf5rnFFod0J5xDGn980K2T76Km9cS8Q+Fa9pkWdTncey +N5cCSX7Da2T5zydJDpnjZyb9oMpWZ9TN5+rSracLq3oJfB0vp/g3rlqC6I/yi4pEr0afK17 x3slluKMREMt5qLiRADN2XTucAIAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] RFC 5031 text modification suggestion [was: Draft new version: draft-holmberg-ecrit-country-emg-urn-01] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 14:42:03 -0000 Hi, > Well, urn-policy is more general. =A0Also, it's currently BCP, so it woul= d need to chance to Proposed Standard to update RFC 5031. =A0=A0 > > My slight preference is for a short document that just does the specific = update. =A0That way, when someone reads RFC 5031 and sees=20 > "Updated by...", they don't have to dig through all of urn-policy to see = what the change is. That would be my preference also. Making a 5031bis would be "overkill" in my opinion, as we are only modifyin= g one chapter. Regards, Christer On Wed, Feb 27, 2013 at 9:04 AM, Rosen, Brian wro= te: could go in urn-policy On Feb 27, 2013, at 4:45 AM, Christer Holmberg wrote: > > Hi James, > >> My point was, write the actual draft "with that text included" and see i= f it reaches WG consensus, as there is no measurable consensus if not alrea= dy in draft form. > > Unfortunately it's too late to submit a new version of the draft before O= rlando. But, I think we can still discuss suggested text changes, eventhoug= h "official consensus" cannot be done :) > > We also need to think about whether the text would go into a bis, or whet= her we would produce a separate document which simply updates the affected = section in RFC 5031. > > Regards, > > Christer > > > > At 03:00 PM 2/26/2013, Richard Barnes wrote: >> I think this is the proposed content of the -bis :) >> >> On a quick read, this text looks pretty good to me. >> >> --Richard >> >> >> >> On Tue, Feb 26, 2013 at 3:40 PM, James Polk >> <jmpolk@cisco.com> wrote: >> Christer >> >> write a bis, see if it flies >> >> James >> >> At 07:49 AM 2/26/2013, Christer Holmberg wrote: >> Content-Language: en-US >> Content-Type: multipart/alternative; >> >> boundary=3D"_000_7594FB04B1934943A5C02806D1A2204B108425ESESSMB209ericsso= _" >> >> >> Hi, >> >> Below is a suggestion how the text in RFC 5031 could be modified, in >> order to allow registration of emergency URNs that, at the time of >> registration, are specific to one country. >> >> Regards, >> >> Christer >> >> --------------------------------- >> >> OLD TEXT: >> -------------- >> >> 4.2. =A0Sub-Services for the 'sos' Service >> >> =A0 This section defines the first service registration within the IANA >> =A0 registry defined in Section 4.1, using the top-level service label >> =A0 'sos'. >> >> =A0 The 'sos' service type describes emergency services requiring an >> =A0 immediate response, typically offered by various branches of the >> =A0 government or other public institutions. =A0Additional sub-services = can >> =A0 be added after expert review and must be of general public interest >> =A0 and have a similar emergency nature. =A0The expert is designated by = the >> =A0 ECRIT working group, its successor, or, in their absence, the IESG. >> =A0 The expert review should only approve emergency services that are >> =A0 offered widely and in different countries, with approximately the >> =A0 same caller expectation in terms of services rendered. =A0The 'sos' >> =A0 service is not meant to invoke general government, public >> =A0 information, counseling, or social services. >> >> =A0 urn:service:sos =A0The generic 'sos' service reaches a public safety >> =A0 =A0 =A0answering point (PSAP), which in turn dispatches aid appropri= ate >> =A0 =A0 =A0to the emergency. =A0It encompasses all of the services liste= d >> =A0 =A0 =A0below. >> >> NEW TEXT: >> -------------- >> >> 4.2. =A0Sub-Services for the 'sos' Service >> >> =A0 This section defines the first service registration within the IANA >> =A0 registry defined in Section 4.1, using the top-level service label >> =A0 'sos'. >> >> =A0 The 'sos' service type describes emergency services requiring an >> =A0 immediate response, typically offered by various branches of the >> =A0 government or other public institutions. =A0Additional sub-services = can >> =A0 be added after expert review. =A0The expert is designated by the >> =A0 ECRIT working group, its successor, or, in their absence, the IESG. >> =A0 The expert review should only approve services that have emergency >> nature, that are >> =A0 offered in at least one country, that do not match description of >> any existing >> =A0 service URN with the 'sos' service type, and where the service >> description and the >> =A0 URN are defined as broadly as possible to encourage reuse. =A0The 's= os' >> =A0 service is not meant to invoke general government, public >> =A0 information, counseling, or social services. >> >> =A0 urn:service:sos =A0The generic 'sos' service reaches a public safety >> =A0 =A0 =A0answering point (PSAP), which in turn dispatches aid appropri= ate >> =A0 =A0 =A0to the emergency. =A0It encompasses all of the services liste= d >> =A0 =A0 =A0below. >> >> >> _______________________________________________ >> 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 From James.Winterbottom@commscope.com Wed Feb 27 12:03:19 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F326F21F84F5 for ; Wed, 27 Feb 2013 12:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aq2Be4kZcagG for ; Wed, 27 Feb 2013 12:03:18 -0800 (PST) Received: from cdcsmgw02.commscope.com (smtp1.andrew.com [198.135.207.233]) by ietfa.amsl.com (Postfix) with ESMTP id CA90B21F84C9 for ; Wed, 27 Feb 2013 12:03:17 -0800 (PST) X-AuditID: 0a0404e9-b7f6a6d00000448a-bc-512e667fd713 Received: from CDCE10HC1.commscope.com ( [10.86.28.21]) by cdcsmgw02.commscope.com (Symantec Messaging Gateway) with SMTP id 41.8F.17546.F766E215; Wed, 27 Feb 2013 14:03:11 -0600 (CST) Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC1.commscope.com (10.86.28.21) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 27 Feb 2013 14:03:15 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 28 Feb 2013 04:03:12 +0800 From: "Winterbottom, James" To: Christer Holmberg , James Polk , Richard Barnes Date: Thu, 28 Feb 2013 04:03:10 +0800 Thread-Topic: [Ecrit] RFC 5031 text modification suggestion [was: Draft new version: draft-holmberg-ecrit-country-emg-urn-01] Thread-Index: AQHOFGlIKWHvStnClEmG5wwr3MlLcZiNcvzAgACvEmA= Message-ID: <5A55A45AE77F5941B18E5457ECAC8188012140771944@SISPE7MB1.commscope.com> References: <7594FB04B1934943A5C02806D1A2204B108425@ESESSMB209.ericsson.se> <201302262040.r1QKehEm029435@rcdn-core-3.cisco.com> <201302262136.r1QLa2cl009174@rcdn-core-3.cisco.com> <7594FB04B1934943A5C02806D1A2204B10AE05@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B10AE05@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIKsWRmVeSWpSXmKPExsXCFSYjqlufphdoMLFRyOLCzMOMFo2LnrJa 7FhTaDG1z9aBxWPK742sHr++XmXzWLLkJ5PH5I2zWAJYorhsUlJzMstSi/TtErgyJl9uYC94 qFpxaM5plgbGeXJdjJwcEgImErNuPmGDsMUkLtxbD2RzcQgJ7GKUeDT/BROEs4FRom3dHKjM ekaJE1vfgLWwCdhJHF5/g7mLkYNDRKBEYv66YJAws4CqxLnGxywgNguQfe/RX1aQEmGBOonN 38ogquslTs8MB6kQEbCSON8+AayaVyBI4t/i21CbDjBJnGr7CJbgFPCRODKnF8xmBDr0+6k1 TBCrxCVuPZnPBPGAgMSSPeeZIWxRiZeP/7FC1ItK3GlfzwhRryOxYPcnNghbW2LZwtfMEIsF JU7OfAI2X0hAV6Jp51fWCYwSs5CsmIWkfRaS9llI2hcwsqxiFE9OSS7OTS83MNJLzs/NLU7O L0gFsTYxguKSheXlDsazG7QPMQpwMCrx8HaY6AUKsSaWFVfmHmKU5GBSEuWVjwUK8SXlp1Rm JBZnxBeV5qQWH2KU4GBWEuH1CAbK8aYkVlalFuXDpDQ4OAROP7l/ilGKJS8/L1VJgndeKlCZ YFFqempFWmYOMCnBlDJxcIKM4gEaFQFSw1tckJhbnJkOkT/FaMix5NqzF4wcHf9AZPPy5y8Y hcCGSonz/kkBahAAacgozYOb+YpRHOgRYd7tIFkeYLqFm/YKaBET0KLEqzogi0oSEVJSDYyL usPyVhz+oLuj8V6n7HZ5/qa5s0TPb3nnqRz+P8bxt6q4pkdzDgdjcN/1AO2KSfJCtfyZC610 l15rWJvV8HWBxxzhmaz/b7kG/zraNCnA6Jqj2jzRL1OndC/ye6wWc90q2+uO696HVlc6jJnK Nh2IVGN6+PNUkveFL/mnP1x6zB9cw3xRP1aJpTgj0VCLuag4EQDiaMxjdAMAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] RFC 5031 text modification suggestion [was: Draft new version: draft-holmberg-ecrit-country-emg-urn-01] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 20:03:19 -0000 I would support this approach Christer... *8) -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of C= hrister Holmberg Sent: Wednesday, 27 February 2013 8:45 PM To: James Polk; Richard Barnes Cc: ecrit@ietf.org Subject: Re: [Ecrit] RFC 5031 text modification suggestion [was: Draft new = version: draft-holmberg-ecrit-country-emg-urn-01] Hi James, >My point was, write the actual draft "with that text included" and see if = it reaches WG consensus, as there is no measurable consensus if not already= in draft form. Unfortunately it's too late to submit a new version of the draft before Orl= ando. But, I think we can still discuss suggested text changes, eventhough = "official consensus" cannot be done :) We also need to think about whether the text would go into a bis, or whethe= r we would produce a separate document which simply updates the affected se= ction in RFC 5031. Regards, Christer At 03:00 PM 2/26/2013, Richard Barnes wrote: >I think this is the proposed content of the -bis :) > >On a quick read, this text looks pretty good to me. > >--Richard > > > >On Tue, Feb 26, 2013 at 3:40 PM, James Polk=20 ><jmpolk@cisco.com> wrote: >Christer > >write a bis, see if it flies > >James > >At 07:49 AM 2/26/2013, Christer Holmberg wrote: >Content-Language: en-US >Content-Type: multipart/alternative; > >boundary=3D"_000_7594FB04B1934943A5C02806D1A2204B108425ESESSMB209ericsso_" > > >Hi, > >Below is a suggestion how the text in RFC 5031 could be modified, in=20 >order to allow registration of emergency URNs that, at the time of=20 >registration, are specific to one country. > >Regards, > >Christer > >--------------------------------- > >OLD TEXT: >-------------- > >4.2. Sub-Services for the 'sos' Service > > This section defines the first service registration within the IANA > registry defined in Section 4.1, using the top-level service label > 'sos'. > > The 'sos' service type describes emergency services requiring an > immediate response, typically offered by various branches of the > government or other public institutions. Additional sub-services can > be added after expert review and must be of general public interest > and have a similar emergency nature. The expert is designated by the > ECRIT working group, its successor, or, in their absence, the IESG. > The expert review should only approve emergency services that are > offered widely and in different countries, with approximately the > same caller expectation in terms of services rendered. The 'sos' > service is not meant to invoke general government, public > information, counseling, or social services. > > urn:service:sos The generic 'sos' service reaches a public safety > answering point (PSAP), which in turn dispatches aid appropriate > to the emergency. It encompasses all of the services listed > below. > >NEW TEXT: >-------------- > >4.2. Sub-Services for the 'sos' Service > > This section defines the first service registration within the IANA > registry defined in Section 4.1, using the top-level service label > 'sos'. > > The 'sos' service type describes emergency services requiring an > immediate response, typically offered by various branches of the > government or other public institutions. Additional sub-services can > be added after expert review. The expert is designated by the > ECRIT working group, its successor, or, in their absence, the IESG. > The expert review should only approve services that have emergency=20 > nature, that are > offered in at least one country, that do not match description of=20 > any existing > service URN with the 'sos' service type, and where the service=20 > description and the > URN are defined as broadly as possible to encourage reuse. The 'sos' > service is not meant to invoke general government, public > information, counseling, or social services. > > urn:service:sos The generic 'sos' service reaches a public safety > answering point (PSAP), which in turn dispatches aid appropriate > to the emergency. It encompasses all of the services listed > below. > > >_______________________________________________ >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 From trac+ecrit@trac.tools.ietf.org Wed Feb 27 20:10:26 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF8121F8A96 for ; Wed, 27 Feb 2013 20:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojnOFts8832G for ; Wed, 27 Feb 2013 20:10:25 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 0648421F8A6B for ; Wed, 27 Feb 2013 20:10:24 -0800 (PST) Received: from localhost ([127.0.0.1]:53979 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UAuow-0002D4-F5; Thu, 28 Feb 2013 05:10:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "ecrit issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Thu, 28 Feb 2013 04:10:14 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/ecrit/trac/ticket/9#comment:2 Message-ID: <080.777d4ce2c78f3d46bd3667fffd006c6b@trac.tools.ietf.org> References: <065.c0b237b6a3acfb6124e1635e9c46707f@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <065.c0b237b6a3acfb6124e1635e9c46707f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #9: Definition of Trustworthy X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 04:10:26 -0000 #9: Definition of Trustworthy Comment (by bernard_aboba@hotmail.com): Here is the proposed replacement for the terminology Section 1.1, including the definition of "trustworthy location": 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The definition for "Target" is taken from RFC 3693 [RFC3693]. The term "location determination method" refers to the mechanism used to determine the location of a Target. This may be something employed by a location information server (LIS), or by the Target itself. It specifically does not refer to the location configuration protocol (LCP) used to deliver location information either to the Target or the Recipient. This term is re-used from RFC 5491 [RFC5491]. The term "source" is used to refer to the LIS, node, or device from which a Recipient (Target or Third-Party) obtains location information. Additionally, the terms Location-by-Value (LbyV), Location-by- Reference (LbyR), Location Configuration Protocol, Location Dereference Protocol, and Location URI are re-used from RFC 5808 [RFC5808]. "Trustworthy Location" is defined as location information that is inherently secure and reliable. For location to be trustworthy, it must have been securely obtained from a trustworthy source, and must also have been securely conveyed. As noted in Section 3, signed location by Value, location by Reference and proxy-provided location can be used to securely convey location information. However, since these mechanisms do not provide assurances relating to the validity or provenance of location data, the trustworthiness of the location source is important. For example, in an emergency situation, location provided by a Location Information Server (LIS) whose administrator has an established history of meeting emergency location accuracy requirements (e.g. Phase II) may be considered more reliable than location information provided by a third party Location Service Provider (LSP) that disclaims use of location information for emergency purposes. However, even where an LSP cannot meet the accuracy requirements for emergency location, it still may be able to provide information useful in assessing about how reliable location information is likely to be. For example, was location determined based on the nearest cell tower or 802.11 Access Point (AP), or was a triangulation method used? If based on cell tower or AP location data, was the information obtained from an authoritative source (e.g. the tower or AP owner) and when was the last time that the location of the tower or access point was verified? "Location Trust Assessment" refers to the process by which the trustworthiness of location information can be assessed. Where location is not trustworthy (such as when location is provided by value, but is not signed), it may still be possible to assess the level of trust that can be placed in the location, by correlation of the location value against other data, such as using the caller's IP address or information provided in SIP headers. This is discussed in Section 3.4. Caller accountability is also an important aspect of trust assessment. Can the individual purchasing the device or activating service be identified or did the call originate from a non-service initialized (NSI) device whose owner cannot be determined? Prior to the call, was the caller authenticated at the network or application layer? In the event of a prank call, can audit logs be made available to an investigator, or can information relating to the owner of an unlinked pseudonym be provided, enabling investigators to unravel the chain of events that lead to the attack? In practice, accountability has proven to be quite important. For example, where emergency calls have been allowed from handsets lacking a SIM card, or where ownership of the SIM card cannot be determined, the frequency of nuisance calls has often been unacceptably high [TASMANIA][UK][SA]. -- -------------------------------------+------------------------------------- Reporter: | Owner: bernard_aboba@hotmail.com | bernard_aboba@hotmail.com Type: defect | Status: new Priority: blocker | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Wed Feb 27 20:13:51 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D584721F8AB4 for ; Wed, 27 Feb 2013 20:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmYGEQLEIpqk for ; Wed, 27 Feb 2013 20:13:51 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 22CD821F8AA0 for ; Wed, 27 Feb 2013 20:13:49 -0800 (PST) Received: from localhost ([127.0.0.1]:54365 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UAusI-0003xN-Ne; Thu, 28 Feb 2013 05:13:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "ecrit issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Thu, 28 Feb 2013 04:13:42 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/ecrit/trac/ticket/11 Message-ID: <065.d156318b3ab2945d708e7ec4a0418a53@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, hannes.tschofenig@gmx.net, hgs@cs.columbia.edu Resent-Message-Id: <20130228041349.22CD821F8AA0@ietfa.amsl.com> Resent-Date: Wed, 27 Feb 2013 20:13:49 -0800 (PST) Resent-From: trac+ecrit@trac.tools.ietf.org Cc: ecrit@ietf.org Subject: [Ecrit] [ecrit] #11: Solutions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 04:13:52 -0000 #11: Solutions As Brian Rosen has noted, the draft does not reflect our best and current thinking about proposed solutions. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-ecrit- bernard_aboba@hotmail.com | trustworthy-location@tools.ietf.org Type: defect | Status: new Priority: blocker | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Wed Feb 27 20:21:04 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F6E21F8ABD for ; Wed, 27 Feb 2013 20:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbjGnL+e-hcC for ; Wed, 27 Feb 2013 20:20:44 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1D06521F8991 for ; Wed, 27 Feb 2013 20:20:31 -0800 (PST) Received: from localhost ([127.0.0.1]:54862 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UAuyq-0002pU-Eu; Thu, 28 Feb 2013 05:20:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "ecrit issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Thu, 28 Feb 2013 04:20:28 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/11#comment:1 Message-ID: <080.4ba206ed69ac240f1402c901433bd203@trac.tools.ietf.org> References: <065.d156318b3ab2945d708e7ec4a0418a53@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <065.d156318b3ab2945d708e7ec4a0418a53@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, hannes.tschofenig@gmx.net, hgs@cs.columbia.edu Resent-Message-Id: <20130228042032.1D06521F8991@ietfa.amsl.com> Resent-Date: Wed, 27 Feb 2013 20:20:31 -0800 (PST) Resent-From: trac+ecrit@trac.tools.ietf.org Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #11: Solutions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 04:21:04 -0000 #11: Solutions Comment (by bernard_aboba@hotmail.com): Here is a proposed replacement for the solutions section: 3. Solutions This section presents three mechanisms which can be used to convey location: signed location by value (Section 4.1), location by reference (Section 4.2) and proxy added location (Section 4.3). In addition, this section discusses mechanisms for location trust assessment (Section 4.4). In order for to provide authentication and integrity protection for the SIP messages conveying location, several security approaches are available. While it is possible for proxies to use security mechanisms such as SIP Identity [RFC4474] to ensure that modifications to the location in transit can be detected by the location recipient (e.g., the PSAP), compatibility with Session Border Controllers (SBCs) that modify integrity-protected headers has proven to be an issue in practice. As a result, the use of SIP over TLS is at present a more likely mechanism to provide per-message authentication and integrity protection. 3.1. Signed Location by Value With location signing, a location server signs the location information before it is sent to the end host, (the entity subject to the location determination process). The signed location information is then verified by the location recipient and not by the target. Figure 1 shows the communication model with the target requesting signed location in step (a), the location server returns it in step (b) and it is then conveyed to the location recipient in step (c) who verifies it. For SIP, the procedures described in RFC 6442 [RFC6442] are applicable for location conveyance. +-----------+ +-----------+ | | | Location | | LIS | | Recipient | | | | | +-+-------+-+ +----+------+ ^ | --^ | | -- Geopriv |Req. | -- Location |Signed |Signed -- Geopriv Configuration |Loc. |Loc. -- Using Protocol Protocol |(a) |(b) -- (e.g., SIP) | v -- (c) +-+-------+-+ -- | Target / | -- | End Host + | | +-----------+ Figure 1: Location Signing In order to limit replay attacks, additional information, such as timestamps or expiration times, has to be included together with the signed location. If the location is retrieved from a location server, even a stationary end host has to periodically obtain a fresh signed location, or incur the additional delay of querying during the emergency call. While bot-nets are unlikely to be deterred by location signing, accurate location information would limit the subset of the bot-net that could be used for an attack, as only hosts within the PSAP serving area would be useful in placing emergency calls. To prevent location-swapping attacks it is necessary to include some some target-specific identity information. The required information depends on whether the goal is real-time verification by the location recipient or post-mortem analysis (where the goal is determination of the legal entity responsible for the attack). As argued in Section 3.4, real-time verification is difficult. Location signing is unlikely to deter attacks launched by bot-nets, since the work required to verify the location signature is considerable. Location signing is also difficult when the host obtains location via mechanisms such as GPS, unless trusted computing approaches, with tamper-proof GPS modules, can be applied. Otherwise, an end-host can pretend to have a GPS device, and the recipient will need to rely on its ability to assess the level of trust that should be placed in the endhost location claim. A straw-man proposal for location signing is provided in [I- D.thomson-geopriv-location-dependability], and [NENA-i2] Section 3.7 includes operational recommendations relating to location signing: Location determination is out of scope for NENA, but we can offer guidance on what should be considered when designing mechanisms to report location: 1. The location object should be digitally signed. 2. The certificate for the signer (LIS operator) should be rooted in VESA. For this purpose, VPC and ERDB operators should issue certs to LIS operators. 3. The signature should include a timestamp. 4. Where possible, the Location Object should be refreshed periodically, with the signature (and thus the timestamp) being refreshed as a consequence. 5. Anti-spoofing mechanisms should be applied to the Location Reporting method. [Note: The term Valid Emergency Services Authority (VESA) refers to the root certificate authority.] As noted above, signing of location objects implies the development of a trust hierarchy that would enable a certificate chain provided by the LIS operator to be verified by the PSAP. Rooting the trust hierarchy in VESA can be accomplished either by having the VESA directly sign the LIS certificates, or by the creation of intermediate CAs certified by the VESA, which will then issue certificates to the LIS. In terms of the workload imposed on the VESA, the latter approach is highly preferable. However, this raises the question of who would operate the intermediate CAs and what the expectations would be. In particular, the question arises as to the requirements for LIS certificate issuance, and whether they are significantly different from say, requirements for issuance of an SSL/TLS web certificate. 3.2. Location by Reference Location-by-reference was developed so that end hosts can avoid having to periodically query the location server for up- to-date location information in a mobile environment. Additionally, if operators do not want to disclose location information to the end host without charging them, location-by-reference provides a reasonable alternative. As noted in RFC 6753 [RFC6753], a location reference can be obtained via HTTP-Enabled Location Delivery (HELD) [RFC5985] or the Dynamic Host Configuration Protocol (DHCP) location URI option [DHCP-URI-OPT]. Figure 2 shows the communication model with the target requesting a location reference in step (a), the location server returns the reference in step (b), and it is then conveyed to the location recipient in step (c). The location recipient needs to resolve the reference with a request in step (d). Finally, location information is returned to the Location Recipient afterwards. For location conveyance in SIP, the procedures described in [RFC6442] are applicable. +-----------+ Geopriv +-----------+ | | Location | Location | | LIS +<------------->+ Recipient | | | Dereferencing | | +-+-------+-+ Protocol (d) +----+------+ ^ | --^ | | -- Geopriv |Req. | -- Location |LbyR |LbyR -- Geopriv Configuration |(a) |(b) -- Using Protocol Protocol | | -- (e.g., SIP) | V -- (c) +-+-------+-+ -- | Target / | -- | End Host + | | +-----------+ Figure 2: Location by Reference Where location by reference is provided, the recipient needs to deference the LbyR in order to obtain location. The details for the dereferencing operations vary with the type of reference, such as a HTTP, HTTPS, SIP, SIPS URI or a SIP presence URI. For location-by-reference, the location server needs to maintain one or several URIs for each target, timing out these URIs after a certain amount of time. References need to expire to prevent the recipient of such a URL from being able to permanently track a host and to offer garbage collection functionality for the location server. Off-path adversaries must be prevented from obtaining the target's location. The reference contains a randomized component that prevents third parties from guessing it. When the location recipient fetches up-to-date location information from the location server, it can also be assured that the location information is fresh and not replayed. However, this does not address location swapping. With respect to the security of the de-reference operation, [RFC6753] Section 6 states: TLS MUST be used for dereferencing location URIs unless confidentiality and integrity are provided by some other mechanism, as discussed in Section 3. Location Recipients MUST authenticate the host identity using the domain name included in the location URI, using the procedure described in Section 3.1 of [RFC2818]. Local policy determines what a Location Recipient does if authentication fails or cannot be attempted. The authorization by possession model (Section 4.1) further relies on TLS when transmitting the location URI to protect the secrecy of the URI. Possession of such a URI implies the same privacy considerations as possession of the PIDF-LO document that the URI references. Location URIs MUST only be disclosed to authorized Location Recipients. The GEOPRIV architecture [RFC6280] designates the Rule Maker to authorize disclosure of the URI. Protection of the location URI is necessary, since the policy attached to such a location URI permits anyone who has the URI to view the associated location information. This aspect of security is covered in more detail in the specification of location conveyance protocols, such as [RFC6442]. For authorizing access to location-by-reference, two authorization models were developed: "Authorization by Possession" and "Authorization via Access Control Lists". With respect to "Authorization by Possession" [RFC6753] Section 4.1 notes: In this model, possession -- or knowledge -- of the location URI is used to control access to location information. A location URI might be constructed such that it is hard to guess (see C8 of [RFC5808]), and the set of entities that it is disclosed to can be limited. The only authentication this would require by the LS is evidence of possession of the URI. The LS could immediately authorize any request that indicates this URI. Authorization by possession does not require direct interaction with Rule Maker; it is assumed that the Rule Maker is able to exert control over the distribution of the location URI. Therefore, the LIS can operate with limited policy input from a Rule Maker. Limited disclosure is an important aspect of this authorization model. The location URI is a secret; therefore, ensuring that adversaries are not able to acquire this information is paramount. Encryption, such as might be offered by TLS [RFC5246] or S/MIME [RFC5751], protects the information from eavesdroppers. Using possession as a basis for authorization means that, once granted, authorization cannot be easily revoked. Cancellation of a location URI ensures that legitimate users are also affected; application of additional policy is theoretically possible but could be technically infeasible. Expiration of location URIs limits the usable time for a location URI, requiring that an attacker continue o learn new location URIs to retain access to current location information. In situations where "Authorization by Possession" is not suitable (such as where location hiding [RFC6444] is required), the "Authorization via Access Control Lists" model may be preferred. Without the introduction of hierarchy, it would be necessary for the PSAP to manage client certificates or Digest credentials for all the LISes in its coverage area, to enable it to successfully dereference LbyRs. However, while PIDF-LO signing credentials are provided to the LIS operator and can be validated by the PSAP using the VESA trust anchor, in the case of de-referencing, without hierarchy the PSAP would need to obtain credentials for each LIS. As a result, without the introduction of hierarchy, the operational considerations of "Authorization via Access Control Lists" are more formidable than validation of signed PIDF-LOs. As with PIDF-LO signing, the operational issues of LbyR can be addressed to some extent by introduction of hierarchy. Rather than requiring the PSAP to obtain credentials for accessing each LIS, the local LIS could be required to upload location information to location aggregation points who would in turn manage the relationships with the PSAP. This would shift the management burden from the PSAPs to the location aggregation points. 3.3. Proxy Adding Location Instead of relying upon the endhost to provide location, is possible for a proxy that has the ability to determine the location of the end point (e.g., based on the endhost IP or MAC address) to retrieve and add or override location information. The use of proxy-added location is primarily applicable in scenarios where the endhost does not provide location. As noted in [RFC6442] Section 4.1: A SIP intermediary SHOULD NOT add location to a SIP request that already contains location. This will quite often lead to confusion within LRs. However, if a SIP intermediary adds location, even if location was not previously present in a SIP request, that SIP intermediary is fully responsible for addressing the concerns of any 424 (Bad Location Information) SIP response it receives about this location addition and MUST NOT pass on (upstream) the 424 response. A SIP intermediary that adds a locationValue MUST position the new locationValue as the last locationValue within the Geolocation header field of the SIP request. A SIP intermediary MAY add a Geolocation header field if one is not present -- for example, when a user agent does not support the Geolocation mechanism but their outbound proxy does and knows the Target's location, or any of a number of other use cases (see Section 3). As noted in [RFC6442] Section 3.3: This document takes a "you break it, you bought it" approach to dealing with second locations placed into a SIP request by an intermediary entity. That entity becomes completely responsible for all location within that SIP request (more on this in Section 4). While it is possible for the proxy to override location included by the endhost, [RFC6442] Section 3.4 notes the operational limitations: Overriding location information provided by the user requires a deployment where an intermediary necessarily knows better than an end user -- after all, it could be that Alice has an on-board GPS, and the SIP intermediary only knows her nearest cell tower. Which is more accurate location information? Currently, there is no way to tell which entity is more accurate or which is wrong, for that matter. This document will not specify how to indicate which location is more accurate than another. The disadvantage of this approach is the need to deploy application layer entities, such as SIP proxies, at AIPs or associated with AIPs. This requires a standardized VoIP profile to be deployed at every end device and at every AIP. This might impose interoperability challenges. Additionally, the AIP needs to take responsibility for emergency calls, even for customers they have no direct or indirect relationship with. To provide identity information about the emergency caller from the VSP it would be necessary to let the AIP and the VSP to interact for authentication (see, for example, [RFC4740]). This interaction along the Authentication, Authorization and Accounting infrastructure is often based on business relationships between the involved entities. The AIP and the VSP are very likely to have no such business relationship, particularly when talking about an arbitrary VSP somewhere on the Internet. In case that the interaction between the AIP and the VSP fails due to the lack of a business relationship then typically a fall-back would be provided where no emergency caller identity information is made available to the PSAP and the emergency call still has to be completed. 3.4. Location Trust Assessment Where location is not inherently trustworthy (such as where location- by-value is used without location signing), it still may be possible to assess the level of trustworthiness of the conveyed location information. For real-time validation, information in the signaling and media packets can be cross checked against location information. For example, it may be possible to determine the region associated with the IP address included within SIP Via: or Contact: headers, or the media source address, and compare this against the location information reported by the caller or conveyed in the PIDF-LO. While a a CAPTCHA-style test may be applied to suspicious calls to lower the risk from bot-nets, this is quite controversial for emergency services, due to the risk of delaying or rejecting valid calls. By design, PIDF-LO objects limit the information available for real- time attribution,. As noted in [RFC5985] Section 6.6: The LIS MUST NOT include any means of identifying the Device in the PIDF-LO unless it is able to verify that the identifier is correct and inclusion of identity is expressly permitted by a Rule Maker. Therefore, PIDF parameters that contain identity are either omitted or contain unlinked pseudonyms [RFC3693]. A unique, unlinked presentity URI SHOULD be generated by the LIS for the mandatory presence "entity" attribute of the PIDF document. Optional parameters such as the "contact" and "deviceID" elements [RFC4479] are not used. As a result, typically the location recipient will be unable to verify in real-time whether the entity on whose behalf location was determined represents the same entity conveying location to the recipient. This is true even where "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)" [RFC4474] is used, allowing the recipient to verify the identity assertion in the From: header. The lack of binding between the entity obtaining the PIDF-LO and the entity conveying the PIDF-LO to the recipient enables cut and paste attacks which would enable an attacker to assert a bogus location, even where both the SIP message and PIDF-LO are signed. As a result, even implementation of both [RFC4474] and location signing does not guarantee that location can be tied to a specific endpoint in real- time. As noted in [RFC6442] Section 1: In no way does this document assume that the SIP user agent client that sends a request containing a location object is necessarily the Target. The location of a Target conveyed within SIP typically corresponds to that of a device controlled by the Target, for example, a mobile phone, but such devices can be separated from their owners, and moreover, in some cases, the user agent may not know its own location. However, although real-time validation based on PIDF-LO elements is challenging, where LIS audit logs are available (such as where a law enforcement agency can present a subpoena), linking of a pseudonym to the device obtaining location can be accomplished in a post-mortem. Similarly, real-time validation of the timestamp contained within PIDF-LO objects (reflecting the time at which the location was determined) is challenging. Even if the PIDF-LO is signed the timestamp only represents an assertion by the LIS, which may or may not be trustworthy. For example, the recipient of the signed PIDF-LO may not know whether the LIS supports time synchronization, or whether it is possible to reset the LIS clock manually without detection. Even if the timestamp was valid at the time location was determined, a time period may elapse between when the PIDF-LO was provided and when it is conveyed to the recipient. Periodically refreshing location information to renew the timestamp even though the location information itself is unchanged puts additional load on LISes. As a result, recipients need to validate the timestamp in order to determine whether it is credible. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-ecrit- bernard_aboba@hotmail.com | trustworthy-location@tools.ietf.org Type: defect | Status: new Priority: blocker | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: ecrit From bernard_aboba@hotmail.com Thu Feb 28 14:16:31 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A68C21F8B4C for ; Thu, 28 Feb 2013 14:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.36 X-Spam-Level: X-Spam-Status: No, score=-102.36 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqvccctF-afo for ; Thu, 28 Feb 2013 14:16:30 -0800 (PST) Received: from blu0-omc3-s3.blu0.hotmail.com (blu0-omc3-s3.blu0.hotmail.com [65.55.116.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD1E21F8B06 for ; Thu, 28 Feb 2013 14:16:30 -0800 (PST) Received: from BLU160-W17 ([65.55.116.74]) by blu0-omc3-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Feb 2013 14:16:29 -0800 X-EIP: [xLc/MHws9/40QdkoFHVMPWE7WSdvw+yU] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_2aad7479-bd7f-484e-b14c-c0c20ba00e5c_" From: Bernard Aboba To: "ecrit@ietf.org" Date: Thu, 28 Feb 2013 14:16:29 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 28 Feb 2013 22:16:29.0878 (UTC) FILETIME=[4205D560:01CE1601] Subject: [Ecrit] Updated "Trustworthy Location" draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 22:16:31 -0000 --_2aad7479-bd7f-484e-b14c-c0c20ba00e5c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Based on the discussion at IETF 85=2C Hannes and I have produced a strawman= update of the "Trustworthy Location" draft: http://internaut.com:8080/~baboba/ecrit/draft-ietf-ecrit-trustworthy-locati= on-05.txt In addition to substantially reorganizing the text=2C this revision defines= the meaning of the term "trustworthy location". Comments welcome.=20 = --_2aad7479-bd7f-484e-b14c-c0c20ba00e5c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Based on the discussion at IETF = 85=2C Hannes and I have produced a strawman update of the "Trustworthy Loca= tion" draft:
http://internaut.co= m:8080/~baboba/ecrit/draft-ietf-ecrit-trustworthy-location-05.txt
In addition to substantially reorganizing the text=2C this revision defin= es the meaning of the term "trustworthy location".

Comments welcome.=


= --_2aad7479-bd7f-484e-b14c-c0c20ba00e5c_-- From trac+ecrit@trac.tools.ietf.org Thu Feb 28 14:25:26 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35A821F859A for ; Thu, 28 Feb 2013 14:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+oToW3FW783 for ; Thu, 28 Feb 2013 14:25:25 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 32EB521F8589 for ; Thu, 28 Feb 2013 14:25:24 -0800 (PST) Received: from localhost ([127.0.0.1]:48758 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UBBul-0000Tz-3X; Thu, 28 Feb 2013 23:25:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "ecrit issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Thu, 28 Feb 2013 22:25:23 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/ecrit/trac/ticket/9#comment:3 Message-ID: <080.928789a0f7f15770ef31a70960741714@trac.tools.ietf.org> References: <065.c0b237b6a3acfb6124e1635e9c46707f@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <065.c0b237b6a3acfb6124e1635e9c46707f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #9: Definition of Trustworthy X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 22:25:26 -0000 #9: Definition of Trustworthy Comment (by bernard_aboba@hotmail.com): Here is a somewhat more terse proposal for the terminology section: 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The definition for "Target" is taken from "Geopriv Requirements" [RFC3693]. The term "location determination method" refers to the mechanism used to determine the location of a Target. This may be something employed by a location information server (LIS), or by the Target itself. It specifically does not refer to the location configuration protocol (LCP) used to deliver location information either to the Target or the Recipient. This term is re-used from "GEOPRIV PIDF-LO Usage Clarification, Considerations, and Recommendations" [RFC5491]. The term "source" is used to refer to the LIS, node, or device from which a Recipient (Target or Third-Party) obtains location information. Additionally, the terms Location-by-Value (LbyV), Location-by- Reference (LbyR), Location Configuration Protocol, Location Dereference Protocol, and Location URI are re-used from "Requirements for a Location-by-Reference Mechanism" [RFC5808]. "Trustworthy Location" is defined as location information that is inherently secure and reliable. For location to be trustworthy, it must have been securely obtained from a trusted source, and must also have been securely conveyed. "Location Trust Assessment" refers to the process by which the reliability of location information can be assessed. This topic is discussed in Section 3.4. -- -------------------------------------+------------------------------------- Reporter: | Owner: bernard_aboba@hotmail.com | bernard_aboba@hotmail.com Type: defect | Status: new Priority: blocker | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Thu Feb 28 14:25:41 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B3F21F85CE for ; Thu, 28 Feb 2013 14:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vtHCfQrwOe2 for ; Thu, 28 Feb 2013 14:25:40 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8048D21F8589 for ; Thu, 28 Feb 2013 14:25:40 -0800 (PST) Received: from localhost ([127.0.0.1]:48813 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UBBv1-0005pg-NQ; Thu, 28 Feb 2013 23:25:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "ecrit issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Thu, 28 Feb 2013 22:25:39 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/9#comment:4 Message-ID: <080.d4cc874e4572f311c879d3e5ee2e3be2@trac.tools.ietf.org> References: <065.c0b237b6a3acfb6124e1635e9c46707f@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <065.c0b237b6a3acfb6124e1635e9c46707f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #9: Definition of Trustworthy X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 22:25:41 -0000 #9: Definition of Trustworthy Changes (by bernard_aboba@hotmail.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: bernard_aboba@hotmail.com | bernard_aboba@hotmail.com Type: defect | Status: closed Priority: blocker | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Thu Feb 28 14:29:11 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEA521F8A9B for ; Thu, 28 Feb 2013 14:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAyubg-TsU1f for ; Thu, 28 Feb 2013 14:29:09 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 269F821F8563 for ; Thu, 28 Feb 2013 14:29:09 -0800 (PST) Received: from localhost ([127.0.0.1]:48868 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UBByK-0002E2-Uh; Thu, 28 Feb 2013 23:29:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "ecrit issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Thu, 28 Feb 2013 22:29:04 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/ecrit/trac/ticket/11#comment:2 Message-ID: <080.f8a261d00ddafc2272335f84368514d4@trac.tools.ietf.org> References: <065.d156318b3ab2945d708e7ec4a0418a53@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <065.d156318b3ab2945d708e7ec4a0418a53@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, hannes.tschofenig@gmx.net, hgs@cs.columbia.edu Resent-Message-Id: <20130228222909.269F821F8563@ietfa.amsl.com> Resent-Date: Thu, 28 Feb 2013 14:29:09 -0800 (PST) Resent-From: trac+ecrit@trac.tools.ietf.org Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #11: Solutions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 22:29:11 -0000 #11: Solutions Comment (by bernard_aboba@hotmail.com): Another revision below: 3. Solutions This section presents three mechanisms which can be used to convey location: signed location by value (Section 4.1), location by reference (Section 4.2) and proxy added location (Section 4.3). In addition, this section discusses mechanisms for location trust assessment (Section 4.4). In order for to provide authentication and integrity protection for the SIP messages conveying location, several security approaches are available. While it is possible for proxies to use security mechanisms such as SIP Identity [RFC4474] to ensure that modifications to the location in transit can be detected by the location recipient (e.g., the PSAP), compatibility with Session Border Controllers (SBCs) that modify integrity-protected headers has proven to be an issue in practice. As a result, the use of SIP over TLS is at present a more likely mechanism to provide per-message authentication and integrity protection. 3.1. Signed Location by Value With location signing, a location server signs the location information before it is sent to the end host, (the entity subject to the location determination process). The signed location information is then verified by the location recipient and not by the target. Figure 1 shows the communication model with the target requesting signed location in step (a), the location server returns it in step (b) and it is then conveyed to the location recipient in step (c) who verifies it. For SIP, the procedures described in "Location Conveyance for the Session Initiation Protocol" [RFC6442] are applicable for location conveyance. +-----------+ +-----------+ | | | Location | | LIS | | Recipient | | | | | +-+-------+-+ +----+------+ ^ | --^ | | -- Geopriv |Req. | -- Location |Signed |Signed -- Geopriv Configuration |Loc. |Loc. -- Using Protocol Protocol |(a) |(b) -- (e.g., SIP) | v -- (c) +-+-------+-+ -- | Target / | -- | End Host + | | +-----------+ Figure 1: Location Signing In order to limit replay attacks, additional information, such as timestamps or expiration times, has to be included together with the signed location. If the location is retrieved from a location server, even a stationary end host has to periodically obtain a fresh signed location, or incur the additional delay of querying during the emergency call. While bot-nets are unlikely to be deterred by location signing, accurate location information would limit the subset of the bot-net that could be used for an attack, as only hosts within the PSAP serving area would be useful in placing emergency calls. To prevent location-swapping attacks it is necessary to include some some target-specific identity information. The required information depends on whether the goal is real-time verification by the location recipient or post-mortem analysis (where the goal is determination of the legal entity responsible for the attack). As argued in Section 3.4, real-time verification is not always possible. Location signing is unlikely to deter attacks launched by bot-nets, since the work required to verify the location signature is considerable. Location signing is also difficult when the host obtains location via mechanisms such as GPS, unless trusted computing approaches, with tamper-proof GPS modules, can be applied. Otherwise, an end host can pretend to have a GPS device, and the recipient will need to rely on its ability to assess the level of trust that should be placed in the end host location claim. A straw-man proposal for location signing is provided in [I- D.thomson-geopriv-location-dependability], and [NENA-i2] Section 3.7 includes operational recommendations relating to location signing: Location determination is out of scope for NENA, but we can offer guidance on what should be considered when designing mechanisms to report location: 1. The location object should be digitally signed. 2. The certificate for the signer (LIS operator) should be rooted in VESA. For this purpose, VPC and ERDB operators should issue certs to LIS operators. 3. The signature should include a timestamp. 4. Where possible, the Location Object should be refreshed periodically, with the signature (and thus the timestamp) being refreshed as a consequence. 5. Anti-spoofing mechanisms should be applied to the Location Reporting method. [Note: The term Valid Emergency Services Authority (VESA) refers to the root certificate authority.] As noted above, signing of location objects implies the development of a trust hierarchy that would enable a certificate chain provided by the LIS operator to be verified by the PSAP. Rooting the trust hierarchy in VESA can be accomplished either by having the VESA directly sign the LIS certificates, or by the creation of intermediate CAs certified by the VESA, which will then issue certificates to the LIS. In terms of the workload imposed on the VESA, the latter approach is highly preferable. However, this raises the question of who would operate the intermediate CAs and what the expectations would be. In particular, the question arises as to the requirements for LIS certificate issuance, and whether they are significantly different from say, requirements for issuance of an SSL/TLS web certificate. 3.2. Location by Reference Location-by-reference was developed so that end hosts can avoid having to periodically query the location server for up- to-date location information in a mobile environment. Additionally, if operators do not want to disclose location information to the end host without charging them, location-by-reference provides a reasonable alternative. As noted in "A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD)" [RFC6753], a location reference can be obtained via HTTP-Enabled Location Delivery (HELD) [RFC5985] or the Dynamic Host Configuration Protocol (DHCP) location URI option [DHCP-URI-OPT]. Figure 2 shows the communication model with the target requesting a location reference in step (a), the location server returns the reference in step (b), and it is then conveyed to the location recipient in step (c). The location recipient needs to resolve the reference with a request in step (d). Finally, location information is returned to the Location Recipient afterwards. For location conveyance in SIP, the procedures described in [RFC6442] are applicable. +-----------+ Geopriv +-----------+ | | Location | Location | | LIS +<------------->+ Recipient | | | Dereferencing | | +-+-------+-+ Protocol (d) +----+------+ ^ | --^ | | -- Geopriv |Req. | -- Location |LbyR |LbyR -- Geopriv Configuration |(a) |(b) -- Using Protocol Protocol | | -- (e.g., SIP) | V -- (c) +-+-------+-+ -- | Target / | -- | End Host + | | +-----------+ Figure 2: Location by Reference Where location by reference is provided, the recipient needs to deference the LbyR in order to obtain location. The details for the dereferencing operations vary with the type of reference, such as a HTTP, HTTPS, SIP, SIPS URI or a SIP presence URI. For location-by-reference, the location server needs to maintain one or several URIs for each target, timing out these URIs after a certain amount of time. References need to expire to prevent the recipient of such a URL from being able to permanently track a host and to offer garbage collection functionality for the location server. Off-path adversaries must be prevented from obtaining the target's location. The reference contains a randomized component that prevents third parties from guessing it. When the location recipient fetches up-to-date location information from the location server, it can also be assured that the location information is fresh and not replayed. However, this does not address location swapping. With respect to the security of the de-reference operation, [RFC6753] Section 6 states: TLS MUST be used for dereferencing location URIs unless confidentiality and integrity are provided by some other mechanism, as discussed in Section 3. Location Recipients MUST authenticate the host identity using the domain name included in the location URI, using the procedure described in Section 3.1 of [RFC2818]. Local policy determines what a Location Recipient does if authentication fails or cannot be attempted. The authorization by possession model (Section 4.1) further relies on TLS when transmitting the location URI to protect the secrecy of the URI. Possession of such a URI implies the same privacy considerations as possession of the PIDF-LO document that the URI references. Location URIs MUST only be disclosed to authorized Location Recipients. The GEOPRIV architecture [RFC6280] designates the Rule Maker to authorize disclosure of the URI. Protection of the location URI is necessary, since the policy attached to such a location URI permits anyone who has the URI to view the associated location information. This aspect of security is covered in more detail in the specification of location conveyance protocols, such as [RFC6442]. For authorizing access to location-by-reference, two authorization models were developed: "Authorization by Possession" and "Authorization via Access Control Lists". With respect to "Authorization by Possession" [RFC6753] Section 4.1 notes: In this model, possession -- or knowledge -- of the location URI is used to control access to location information. A location URI might be constructed such that it is hard to guess (see C8 of [RFC5808]), and the set of entities that it is disclosed to can be limited. The only authentication this would require by the LS is evidence of possession of the URI. The LS could immediately authorize any request that indicates this URI. Authorization by possession does not require direct interaction with Rule Maker; it is assumed that the Rule Maker is able to exert control over the distribution of the location URI. Therefore, the LIS can operate with limited policy input from a Rule Maker. Limited disclosure is an important aspect of this authorization model. The location URI is a secret; therefore, ensuring that adversaries are not able to acquire this information is paramount. Encryption, such as might be offered by TLS [RFC5246] or S/MIME [RFC5751], protects the information from eavesdroppers. Using possession as a basis for authorization means that, once granted, authorization cannot be easily revoked. Cancellation of a location URI ensures that legitimate users are also affected; application of additional policy is theoretically possible but could be technically infeasible. Expiration of location URIs limits the usable time for a location URI, requiring that an attacker continue o learn new location URIs to retain access to current location information. In situations where "Authorization by Possession" is not suitable (such as where location hiding [RFC6444] is required), the "Authorization via Access Control Lists" model may be preferred. Without the introduction of hierarchy, it would be necessary for the PSAP to manage client certificates or Digest credentials for all the LISes in its coverage area, to enable it to successfully dereference LbyRs. However, while PIDF-LO signing credentials are provided to the LIS operator and can be validated by the PSAP using the VESA trust anchor, in the case of de-referencing, without hierarchy the PSAP would need to obtain credentials for each LIS. As a result, without the introduction of hierarchy, the operational considerations of "Authorization via Access Control Lists" are more formidable than validation of signed PIDF-LOs. As with PIDF-LO signing, the operational issues of LbyR can be addressed to some extent by introduction of hierarchy. Rather than requiring the PSAP to obtain credentials for accessing each LIS, the local LIS could be required to upload location information to location aggregation points who would in turn manage the relationships with the PSAP. This would shift the management burden from the PSAPs to the location aggregation points. 3.3. Proxy Adding Location Instead of relying upon the end host to provide location, is possible for a proxy that has the ability to determine the location of the end point (e.g., based on the end host IP or MAC address) to retrieve and add or override location information. The use of proxy-added location is primarily applicable in scenarios where the end host does not provide location. As noted in [RFC6442] Section 4.1: A SIP intermediary SHOULD NOT add location to a SIP request that already contains location. This will quite often lead to confusion within LRs. However, if a SIP intermediary adds location, even if location was not previously present in a SIP request, that SIP intermediary is fully responsible for addressing the concerns of any 424 (Bad Location Information) SIP response it receives about this location addition and MUST NOT pass on (upstream) the 424 response. A SIP intermediary that adds a locationValue MUST position the new locationValue as the last locationValue within the Geolocation header field of the SIP request. A SIP intermediary MAY add a Geolocation header field if one is not present -- for example, when a user agent does not support the Geolocation mechanism but their outbound proxy does and knows the Target's location, or any of a number of other use cases (see Section 3). As noted in [RFC6442] Section 3.3: This document takes a "you break it, you bought it" approach to dealing with second locations placed into a SIP request by an intermediary entity. That entity becomes completely responsible for all location within that SIP request (more on this in Section 4). While it is possible for the proxy to override location included by the end host, [RFC6442] Section 3.4 notes the operational limitations: Overriding location information provided by the user requires a deployment where an intermediary necessarily knows better than an end user -- after all, it could be that Alice has an on-board GPS, and the SIP intermediary only knows her nearest cell tower. Which is more accurate location information? Currently, there is no way to tell which entity is more accurate or which is wrong, for that matter. This document will not specify how to indicate which location is more accurate than another. The disadvantage of this approach is the need to deploy application layer entities, such as SIP proxies, at AIPs or associated with AIPs. This requires a standardized VoIP profile to be deployed at every end device and at every AIP. This might impose interoperability challenges. Additionally, the AIP needs to take responsibility for emergency calls, even for customers they have no direct or indirect relationship with. To provide identity information about the emergency caller from the VSP it would be necessary to let the AIP and the VSP to interact for authentication (see, for example, [RFC4740]). This interaction along the Authentication, Authorization and Accounting infrastructure is often based on business relationships between the involved entities. The AIP and the VSP are very likely to have no such business relationship, particularly when talking about an arbitrary VSP somewhere on the Internet. In case that the interaction between the AIP and the VSP fails due to the lack of a business relationship then typically a fall-back would be provided where no emergency caller identity information is made available to the PSAP and the emergency call still has to be completed. 3.4. Location Trust Assessment The ability to assess the level of trustworthiness of conveyed location information is important, since this makes it possible to understand how much value should be placed on location information, as part of the decision making process. As an example, if automated location information is understood to be highly suspect, a call taker can put more effort into obtaining location information from the caller. Caller accountability is another important aspect of trust assessment. Can the individual purchasing the device or activating service be identified or did the call originate from a non-service initialized (NSI) device whose owner cannot be determined? Prior to the call, was the caller authenticated at the network or application layer? In the event of a prank call, can audit logs be made available to an investigator, or can information relating to the owner of an unlinked pseudonym be provided, enabling investigators to unravel the chain of events that lead to the attack? In practice, the ability to identify a caller may decrease the likelihood of caller misbehavior. For example, where emergency calls have been allowed from handsets lacking a SIM card, or where ownership of the SIM card cannot be determined, the frequency of nuisance calls has often been unacceptably high [TASMANIA][UK][SA]. Note that location trust assessment has value regardless of whether the location has been conveyed securely (via signed location, location-by-reference or proxy-added location) or not (via location- by-value without location signing), since secure conveyance does not provide assurance relating to the validity or provenance of location data. In practice, the source of the location data is important for location trust assessment. For example, location provided by a Location Information Server (LIS) whose administrator has an established history of meeting emergency location accuracy requirements (e.g. Phase II) may be considered more reliable than location information provided by a third party Location Service Provider (LSP) that disclaims use of location information for emergency purposes. However, even where an LSP does not attempt to meet the accuracy requirements for emergency location, it still may be able to provide information useful in assessing about how reliable location information is likely to be. For example, was location determined based on the nearest cell tower or 802.11 Access Point (AP), or was a triangulation method used? If based on cell tower or AP location data, was the information obtained from an authoritative source (e.g. the tower or AP owner) and when was the last time that the location of the tower or access point was verified? For real-time validation, information in the signaling and media packets can be cross checked against location information. For example, it may be possible to determine the region associated with the IP address included within SIP Via: or Contact: headers, or the media source address, and compare this against the location information reported by the caller or conveyed in the PIDF-LO. While a a CAPTCHA-style test may be applied to suspicious calls to lower the risk from bot-nets, this is quite controversial for emergency services, due to the risk of delaying or rejecting valid calls. By design, PIDF-LO objects limit the information available for real- time attribution,. As noted in [RFC5985] Section 6.6: The LIS MUST NOT include any means of identifying the Device in the PIDF-LO unless it is able to verify that the identifier is correct and inclusion of identity is expressly permitted by a Rule either omitted or contain unlinked pseudonyms [RFC3693]. A unique, unlinked presentity URI SHOULD be generated by the LIS for the mandatory presence "entity" attribute of the PIDF document. Optional parameters such as the "contact" and "deviceID" elements [RFC4479] are not used. As a result, typically the location recipient will be unable to verify in real-time whether the entity on whose behalf location was determined represents the same entity conveying location to the recipient. This is true even where "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)" [RFC4474] is used, allowing the recipient to verify the identity assertion in the From: header. The lack of binding between the entity obtaining the PIDF-LO and the entity conveying the PIDF-LO to the recipient enables cut and paste attacks which would enable an attacker to assert a bogus location, even where both the SIP message and PIDF-LO are signed. As a result, even implementation of both "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)" [RFC4474] and location signing does not guarantee that location can be tied to a specific endpoint in real-time. As noted in [RFC6442] Section 1: In no way does this document assume that the SIP user agent client that sends a request containing a location object is necessarily the Target. The location of a Target conveyed within SIP typically corresponds to that of a device controlled by the Target, for example, a mobile phone, but such devices can be separated from their owners, and moreover, in some cases, the user agent may not know its own location. However, although real-time validation based on PIDF-LO elements is challenging, where LIS audit logs are available (such as where a law enforcement agency can present a subpoena), linking of a pseudonym to the device obtaining location can be accomplished in a post-mortem. Similarly, real-time validation of the timestamp contained within PIDF-LO objects (reflecting the time at which the location was determined) is challenging. Even if the PIDF-LO is signed the timestamp only represents an assertion by the LIS, which may or may not be trustworthy. For example, the recipient of the signed PIDF-LO may not know whether the LIS supports time synchronization, or whether it is possible to reset the LIS clock manually without detection. Even if the timestamp was valid at the time location was determined, a time period may elapse between when the PIDF-LO was provided and when it is conveyed to the recipient. Periodically refreshing location information to renew the timestamp even though the location information itself is unchanged puts additional load on LISes. As a result, recipients need to validate the timestamp in order to determine whether it is credible. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-ecrit- bernard_aboba@hotmail.com | trustworthy-location@tools.ietf.org Type: defect | Status: new Priority: blocker | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Thu Feb 28 14:29:16 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB7D21F8BCD for ; Thu, 28 Feb 2013 14:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMkZnaFTBYCg for ; Thu, 28 Feb 2013 14:29:16 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id ED44321F8B14 for ; Thu, 28 Feb 2013 14:29:15 -0800 (PST) Received: from localhost ([127.0.0.1]:48875 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UBByT-0004ug-Dg; Thu, 28 Feb 2013 23:29:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "ecrit issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Thu, 28 Feb 2013 22:29:13 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/ecrit/trac/ticket/11#comment:3 Message-ID: <080.158ac34368ff2ee245d6dff08e8f9463@trac.tools.ietf.org> References: <065.d156318b3ab2945d708e7ec4a0418a53@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <065.d156318b3ab2945d708e7ec4a0418a53@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, hannes.tschofenig@gmx.net, hgs@cs.columbia.edu Resent-Message-Id: <20130228222915.ED44321F8B14@ietfa.amsl.com> Resent-Date: Thu, 28 Feb 2013 14:29:15 -0800 (PST) Resent-From: trac+ecrit@trac.tools.ietf.org Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #11: Solutions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 22:29:16 -0000 #11: Solutions Changes (by bernard_aboba@hotmail.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-ecrit- bernard_aboba@hotmail.com | trustworthy-location@tools.ietf.org Type: defect | Status: closed Priority: blocker | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Thu Feb 28 14:30:38 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787C621F88F0 for ; Thu, 28 Feb 2013 14:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtHXhwqyUUgl for ; Thu, 28 Feb 2013 14:30:38 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id CFD5021F88B6 for ; Thu, 28 Feb 2013 14:30:37 -0800 (PST) Received: from localhost ([127.0.0.1]:48961 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UBBzp-00013f-5P; Thu, 28 Feb 2013 23:30:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "ecrit issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Thu, 28 Feb 2013 22:30:37 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/4#comment:1 Message-ID: <080.1138c82ce5bee0942bd3e82e4b970fb9@trac.tools.ietf.org> References: <065.2714ac9a8b39105b6514f2472e116155@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <065.2714ac9a8b39105b6514f2472e116155@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 22:30:38 -0000 #4: Untrusted location and provider intent Comment (by bernard_aboba@hotmail.com): In Section 3.4 we have now included two paragraphs relating to the source of the location information: In practice, the source of the location data is important for location trust assessment. For example, location provided by a Location Information Server (LIS) whose administrator has an established history of meeting emergency location accuracy requirements (e.g. Phase II) may be considered more reliable than location information provided by a third party Location Service Provider (LSP) that disclaims use of location information for emergency purposes. However, even where an LSP does not attempt to meet the accuracy requirements for emergency location, it still may be able to provide information useful in assessing about how reliable location information is likely to be. For example, was location determined based on the nearest cell tower or 802.11 Access Point (AP), or was a triangulation method used? If based on cell tower or AP location data, was the information obtained from an authoritative source (e.g. the tower or AP owner) and when was the last time that the location of the tower or access point was verified? -- ---------------------------------------+------------------------- Reporter: bernard_aboba@hotmail.com | Owner: Type: defect | Status: new Priority: blocker | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Resolution: Keywords: | ---------------------------------------+------------------------- Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Thu Feb 28 14:30:43 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79A821F89B2 for ; Thu, 28 Feb 2013 14:30:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CauKGasNxWVO for ; Thu, 28 Feb 2013 14:30:43 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 53D3621F8991 for ; Thu, 28 Feb 2013 14:30:43 -0800 (PST) Received: from localhost ([127.0.0.1]:48965 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UBBzu-0004b0-Ld; Thu, 28 Feb 2013 23:30:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "ecrit issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Thu, 28 Feb 2013 22:30:42 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/4#comment:2 Message-ID: <080.9d379be49ec18424c4a63aa5307af6f8@trac.tools.ietf.org> References: <065.2714ac9a8b39105b6514f2472e116155@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <065.2714ac9a8b39105b6514f2472e116155@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 22:30:44 -0000 #4: Untrusted location and provider intent Changes (by bernard_aboba@hotmail.com): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------- Reporter: bernard_aboba@hotmail.com | Owner: Type: defect | Status: closed Priority: blocker | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------- Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Thu Feb 28 14:32:36 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3944F21F8833 for ; Thu, 28 Feb 2013 14:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLIgkRpZk-m6 for ; Thu, 28 Feb 2013 14:32:35 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 73B0B21F866F for ; Thu, 28 Feb 2013 14:32:35 -0800 (PST) Received: from localhost ([127.0.0.1]:49091 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UBC1g-0004yQ-R7; Thu, 28 Feb 2013 23:32:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "ecrit issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Thu, 28 Feb 2013 22:32:32 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/ecrit/trac/ticket/12 Message-ID: <065.a74dbc7676ca3af6c9ab1365df20dd33@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, hannes.tschofenig@gmx.net, hgs@cs.columbia.edu Resent-Message-Id: <20130228223235.73B0B21F866F@ietfa.amsl.com> Resent-Date: Thu, 28 Feb 2013 14:32:35 -0800 (PST) Resent-From: trac+ecrit@trac.tools.ietf.org Cc: ecrit@ietf.org Subject: [Ecrit] [ecrit] #12: Introduction X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 22:32:36 -0000 #12: Introduction Currently the introduction does not do a very good job of introducing the problem to be solved, and why it is important. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-ecrit- bernard_aboba@hotmail.com | trustworthy-location@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Thu Feb 28 14:33:14 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A43721F8883 for ; Thu, 28 Feb 2013 14:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzw7lqDgJFmT for ; Thu, 28 Feb 2013 14:33:13 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E179721F8833 for ; Thu, 28 Feb 2013 14:33:12 -0800 (PST) Received: from localhost ([127.0.0.1]:49206 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UBC2E-0000zW-W5; Thu, 28 Feb 2013 23:33:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "ecrit issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Thu, 28 Feb 2013 22:33:06 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/12#comment:1 Message-ID: <080.f48a999499dd6fb46ff84e76aa7f446e@trac.tools.ietf.org> References: <065.a74dbc7676ca3af6c9ab1365df20dd33@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <065.a74dbc7676ca3af6c9ab1365df20dd33@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, hannes.tschofenig@gmx.net, hgs@cs.columbia.edu Resent-Message-Id: <20130228223312.E179721F8833@ietfa.amsl.com> Resent-Date: Thu, 28 Feb 2013 14:33:12 -0800 (PST) Resent-From: trac+ecrit@trac.tools.ietf.org Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #12: Introduction X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 22:33:14 -0000 #12: Introduction Comment (by bernard_aboba@hotmail.com): Here is a proposed revision to Section 1 that may help: 1. Introduction Several public and commercial services depend upon location information in their operations. This includes emergency services (such as fire, ambulance and police) as well as commercial services such as food delivery and roadside assistance. Services that depend on location commonly experience security issues today. While prank calls have been a problem for emergency services dating back to the time of street corner call boxes, with the move to IP-based emergency services, the ability to launch automated attacks has increased. As the European Emergency Number Association (EENA) has noted: "False emergency calls divert emergency services away from people who may be in life-threatening situations and who need urgent help. This can mean the difference between life and death for someone in trouble." EENA [EENA] has attempted to define terminology and describe best current practices for dealing with false emergency calls, which in certain European countries can constitute as much as 70% of all emergency calls. Reducing the number of prank calls represents a challenge, since emergency services authorities in most countries are required to answer every call (whenever possible). Where the caller cannot be identified, the ability to prosecute is limited. Since prank emergency calls can endanger bystanders or emergency services personnel, or divert resources away from legitimate emergencies, they can be life threatening. A particularly dangerous form of prank call is "swatting" - an prank emergency call that draws a response from law enforcement (e.g. a fake hostage situation that results in dispatching of a "Special Weapons And Tactics" (SWAT) team). The recent increase in the frequency and sophistication of these attacks has lead to the FBI issuing a warning [Swatting]. Many documented cases of "swatting" involve not only the faking of an emergency, but also the absence of accurate caller identification and the delivery of misleading location data. Today these attacks are often carried out by providing false caller identification, since for circuit-switched calls from landlines, location provided to the PSAP is determined from a lookup using the calling telephone number. With IP-based emergency services, in addition to the potential for false caller identification, it is also possible to attach misleading location information to the emergency call. Ideally, a call taker at a PSAP should be put in the position to assess, in real-time, the level of trust that can be placed on the information provided within a call. This includes automated location conveyed along with the call and location information communicated by the caller, as well as identity information about the caller. Where real-time assessment is not possible, it is important to be able to determine the source of the call in a post-mortem, so as to be able to enforce accountability. This document defines terminology (including the meaning of "trustworthy location") in Section 1.1, investigates security threats in Section 2, outlines potential solutions in Section 3 and discusses security considerations in Section 4. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-ecrit- bernard_aboba@hotmail.com | trustworthy-location@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Thu Feb 28 14:35:38 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C286521F86B8 for ; Thu, 28 Feb 2013 14:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thEBZpOYfAvi for ; Thu, 28 Feb 2013 14:35:38 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id EC7C921F8630 for ; Thu, 28 Feb 2013 14:35:37 -0800 (PST) Received: from localhost ([127.0.0.1]:49648 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UBC4f-0001zO-1d; Thu, 28 Feb 2013 23:35:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "ecrit issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: drat-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Thu, 28 Feb 2013 22:35:37 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/13 Message-ID: <065.d65107e0f04ba3b145e66d2b8bae348c@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: drat-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: ecrit@ietf.org Subject: [Ecrit] [ecrit] #13: Location Trust Assessment X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 22:35:38 -0000 #13: Location Trust Assessment Regardless of whether location is conveyed in a secure and reliable manner, questions will persist about the reliability of the location data. Therefore the document does need to provide guidance about how location trustworthiness can be assessed. -- -------------------------------------+------------------------------------- Reporter: | Owner: drat-ietf-ecrit- bernard_aboba@hotmail.com | trustworthy-location@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Thu Feb 28 14:36:51 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C77121F8700 for ; Thu, 28 Feb 2013 14:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUn5ee+rZ4FK for ; Thu, 28 Feb 2013 14:36:50 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id C15F821F8630 for ; Thu, 28 Feb 2013 14:36:49 -0800 (PST) Received: from localhost ([127.0.0.1]:49674 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UBC5p-0003fI-19; Thu, 28 Feb 2013 23:36:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "ecrit issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: drat-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Thu, 28 Feb 2013 22:36:49 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/ecrit/trac/ticket/13#comment:1 Message-ID: <080.2b2a65400e8c82248ec9ad2723528e21@trac.tools.ietf.org> References: <065.d65107e0f04ba3b145e66d2b8bae348c@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <065.d65107e0f04ba3b145e66d2b8bae348c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: drat-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #13: Location Trust Assessment X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 22:36:51 -0000 #13: Location Trust Assessment Comment (by bernard_aboba@hotmail.com): Here is a proposal for a Section 3.4 on Trust Assessment: 3.4. Location Trust Assessment The ability to assess the level of trustworthiness of conveyed location information is important, since this makes it possible to understand how much value should be placed on location information, as part of the decision making process. As an example, if automated location information is understood to be highly suspect, a call taker can put more effort into obtaining location information from the caller. Caller accountability is another important aspect of trust assessment. Can the individual purchasing the device or activating service be identified or did the call originate from a non-service initialized (NSI) device whose owner cannot be determined? Prior to the call, was the caller authenticated at the network or application layer? In the event of a prank call, can audit logs be made available to an investigator, or can information relating to the owner of an unlinked pseudonym be provided, enabling investigators to unravel the chain of events that lead to the attack? In practice, the ability to identify a caller may decrease the likelihood of caller misbehavior. For example, where emergency calls have been allowed from handsets lacking a SIM card, or where ownership of the SIM card cannot be determined, the frequency of nuisance calls has often been unacceptably high [TASMANIA][UK][SA]. Note that location trust assessment has value regardless of whether the location has been conveyed securely (via signed location, location-by-reference or proxy-added location) or not (via location- by-value without location signing), since secure conveyance does not provide assurance relating to the validity or provenance of location data. In practice, the source of the location data is important for location trust assessment. For example, location provided by a Location Information Server (LIS) whose administrator has an established history of meeting emergency location accuracy requirements (e.g. Phase II) may be considered more reliable than location information provided by a third party Location Service Provider (LSP) that disclaims use of location information for emergency purposes. However, even where an LSP does not attempt to meet the accuracy requirements for emergency location, it still may be able to provide information useful in assessing about how reliable location information is likely to be. For example, was location determined based on the nearest cell tower or 802.11 Access Point (AP), or was a triangulation method used? If based on cell tower or AP location data, was the information obtained from an authoritative source (e.g. the tower or AP owner) and when was the last time that the location of the tower or access point was verified? For real-time validation, information in the signaling and media packets can be cross checked against location information. For example, it may be possible to determine the region associated with the IP address included within SIP Via: or Contact: headers, or the media source address, and compare this against the location information reported by the caller or conveyed in the PIDF-LO. While a a CAPTCHA-style test may be applied to suspicious calls to lower the risk from bot-nets, this is quite controversial for emergency services, due to the risk of delaying or rejecting valid calls. By design, PIDF-LO objects limit the information available for real- time attribution,. As noted in [RFC5985] Section 6.6: The LIS MUST NOT include any means of identifying the Device in the PIDF-LO unless it is able to verify that the identifier is correct and inclusion of identity is expressly permitted by a Rule Maker. Therefore, PIDF parameters that contain identity are either omitted or contain unlinked pseudonyms [RFC3693]. A unique, unlinked presentity URI SHOULD be generated by the LIS for the mandatory presence "entity" attribute of the PIDF document. Optional parameters such as the "contact" and "deviceID" elements [RFC4479] are not used. As a result, typically the location recipient will be unable to verify in real-time whether the entity on whose behalf location was determined represents the same entity conveying location to the recipient. This is true even where "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)" [RFC4474] is used, allowing the recipient to verify the identity assertion in the From: header. The lack of binding between the entity obtaining the PIDF-LO and the entity conveying the PIDF-LO to the recipient enables cut and paste attacks which would enable an attacker to assert a bogus location, even where both the SIP message and PIDF-LO are signed. As a result, even implementation of both "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)" [RFC4474] and location signing does not guarantee that location can be tied to a specific endpoint in real-time. As noted in [RFC6442] Section 1: In no way does this document assume that the SIP user agent client that sends a request containing a location object is necessarily the Target. The location of a Target conveyed within SIP typically corresponds to that of a device controlled by the Target, for example, a mobile phone, but such devices can be separated from their owners, and moreover, in some cases, the user agent may not know its own location. However, although real-time validation based on PIDF-LO elements is challenging, where LIS audit logs are available (such as where a law enforcement agency can present a subpoena), linking of a pseudonym to the device obtaining location can be accomplished in a post-mortem. Similarly, real-time validation of the timestamp contained within PIDF-LO objects (reflecting the time at which the location was determined) is challenging. Even if the PIDF-LO is signed the timestamp only represents an assertion by the LIS, which may or may not be trustworthy. For example, the recipient of the signed PIDF-LO may not know whether the LIS supports time synchronization, or whether it is possible to reset the LIS clock manually without detection. Even if the timestamp was valid at the time location was determined, a time period may elapse between when the PIDF-LO was provided and when it is conveyed to the recipient. Periodically refreshing location information to renew the timestamp even though the location information itself is unchanged puts additional load on LISes. As a result, recipients need to validate the timestamp in order to determine whether it is credible. -- -------------------------------------+------------------------------------- Reporter: | Owner: drat-ietf-ecrit- bernard_aboba@hotmail.com | trustworthy-location@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Thu Feb 28 14:37:45 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 185E021F89CC for ; Thu, 28 Feb 2013 14:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLY48-Rf33tL for ; Thu, 28 Feb 2013 14:37:44 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3583D21F8883 for ; Thu, 28 Feb 2013 14:37:44 -0800 (PST) Received: from localhost ([127.0.0.1]:49690 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UBC6h-000456-D6; Thu, 28 Feb 2013 23:37:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "ecrit issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Thu, 28 Feb 2013 22:37:43 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/10#comment:1 Message-ID: <080.9e71626dcd4775150c890a1227ab890a@trac.tools.ietf.org> References: <065.1b52482104271a8066bcf9a9f5f1b8f3@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <065.1b52482104271a8066bcf9a9f5f1b8f3@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #10: Section 5 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 22:37:45 -0000 #10: Section 5 Comment (by bernard_aboba@hotmail.com): The Section has been deleted from the document. -- -------------------------------------+------------------------------------- Reporter: | Owner: bernard_aboba@hotmail.com | bernard_aboba@hotmail.com Type: defect | Status: new Priority: major | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Thu Feb 28 14:37:50 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B611E21F8B4A for ; Thu, 28 Feb 2013 14:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2p9G4nbOCx-0 for ; Thu, 28 Feb 2013 14:37:50 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2783F21F8AEA for ; Thu, 28 Feb 2013 14:37:50 -0800 (PST) Received: from localhost ([127.0.0.1]:49693 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UBC6n-0007vt-FZ; Thu, 28 Feb 2013 23:37:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "ecrit issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Thu, 28 Feb 2013 22:37:49 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/10#comment:2 Message-ID: <080.3126921f3234b0946bba94423fa5e57a@trac.tools.ietf.org> References: <065.1b52482104271a8066bcf9a9f5f1b8f3@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <065.1b52482104271a8066bcf9a9f5f1b8f3@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #10: Section 5 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 22:37:50 -0000 #10: Section 5 Changes (by bernard_aboba@hotmail.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: bernard_aboba@hotmail.com | bernard_aboba@hotmail.com Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Thu Feb 28 14:39:59 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9958921F8555 for ; Thu, 28 Feb 2013 14:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7emsnKuqWDL for ; Thu, 28 Feb 2013 14:39:59 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1689921F84F0 for ; Thu, 28 Feb 2013 14:39:59 -0800 (PST) Received: from localhost ([127.0.0.1]:49737 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UBC8l-00006g-Ns; Thu, 28 Feb 2013 23:39:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "ecrit issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Thu, 28 Feb 2013 22:39:51 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/ecrit/trac/ticket/14 Message-ID: <065.a9d5155d47366b7fa2e2b595220d3bd2@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, hannes.tschofenig@gmx.net, hgs@cs.columbia.edu Resent-Message-Id: <20130228223959.1689921F84F0@ietfa.amsl.com> Resent-Date: Thu, 28 Feb 2013 14:39:59 -0800 (PST) Resent-From: trac+ecrit@trac.tools.ietf.org Cc: ecrit@ietf.org Subject: [Ecrit] [ecrit] #14: Security Considerations X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 22:39:59 -0000 #14: Security Considerations The current security considerations document does not describe why this document is fundamentally different from previous threat analyses done in ECRIT and GEOPRIV. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-ecrit- bernard_aboba@hotmail.com | trustworthy-location@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: ecrit From James.Winterbottom@commscope.com Thu Feb 28 21:17:27 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA80721F87BA for ; Thu, 28 Feb 2013 21:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXPKazEUGx1N for ; Thu, 28 Feb 2013 21:17:20 -0800 (PST) Received: from cdcsmgw02.commscope.com (cdcsmgw02.commscope.com [198.135.207.233]) by ietfa.amsl.com (Postfix) with ESMTP id A58F321F8717 for ; Thu, 28 Feb 2013 21:17:20 -0800 (PST) X-AuditID: 0a0404e9-b7f6a6d00000448a-9a-513039dfd013 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw02.commscope.com (Symantec Messaging Gateway) with SMTP id 22.C1.17546.FD930315; Thu, 28 Feb 2013 23:17:19 -0600 (CST) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 28 Feb 2013 23:17:18 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 1 Mar 2013 13:17:15 +0800 From: "Winterbottom, James" To: "ecrit@ietf.org" Date: Fri, 1 Mar 2013 13:17:14 +0800 Thread-Topic: Request for draft-ietf-ecrit-additional-data-07 Thread-Index: Ac4WPAjULhB6rll3Th6dCwnilNTjiw== Message-ID: <5A55A45AE77F5941B18E5457ECAC8188012140771AC2@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5A55A45AE77F5941B18E5457ECAC8188012140771AC2SISPE7MB1co_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHKsWRmVeSWpSXmKPExsXCFSaSpnvf0iDQ4MUkHYvGRU9ZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsWz2JZaCX/oVs9evZG1gfKvZxcjJISFgIvHx7TZGCFtM4sK9 9WxdjFwcQgK7GSUez7jMDuFsYJR4s2YKM0iVkMBaRok7q0xBbDYBO4nD62+AxUUEVCU2nFkJ NolFQEXi4YMPrCC2sICFxPuHi1kgamwlVr67yQ5h60l8XXMEzOYVCJL4/r0NzGYEuuL7qTVM IDazgLjErSfzmSCuE5BYsuc8M4QtKvHy8T9WiHpRiTvt6xkh6vMlOqfPZoSYKShxcuYTFoib dSWadn5lncAoMgvJ2FlIWmYhaYGI60gs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGMWTU5KL c9PLDYz0kvNzc4uT8wtSQaxNjKBIYmF5uYPx7AbtQ4wCHIxKPLwBVfqBQqyJZcWVuYcYJTmY lER5nU0NAoX4kvJTKjMSizPii0pzUosPMUpwMCuJ8Fa+ASrnTUmsrEotyodJaXBwCJx+cv8U oxRLXn5eqpIE73QLoBGCRanpqRVpmTnANAJTysTBCTKKB2hUHkgNb3FBYm5xZjpE/hSjKkfz 8ucvGIXABkmJ8xaAFAmAFGWU5sHNecUoDnS8MG89SJYHmAjhJrwCGs4ENDzxqg7I8JJEhJRU A6Ofa997SYdl1701pWNFb8rW9vl9bHo1cXOdwOmXThsLD7GYOzasvZsYYSYmYX7YV5OvIbr8 2MU6EUknzp5Z2y0SrKKDX37xupSV0vz60PIV8pwfJ53nS53xcMEslg/3BPeyljB0f/wcabpo 6zF5ZweBAzZnrjI0fulmV5o22XKuaPvOYvGIACWW4oxEQy3mouJEAOVHHNhBAwAA Subject: [Ecrit] Request for draft-ietf-ecrit-additional-data-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 05:17:27 -0000 --_000_5A55A45AE77F5941B18E5457ECAC8188012140771AC2SISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I have been looking at this specification with an eye to implementation. It= is much better than earlier versions and I thank the authors for that. The= re are however some countries that have fields in their existing service or= der provisioning data sets that are not obviously mapped into the specific = fields defined in this document. I think that with regional or national profiling most of this can be addres= sed, however, there is likely to always be a case where this just doesn't w= ork. When this is the case there will be need a need to add further informa= tion to one or more of the data bundles defined in this document, and as cu= rrently specified this isn't possible because none of the schemas provide a= n extension point to allow this to happen. To avoid having to up version these schemas in the future, I think it would= be good to add an extension point at the end of each of the sequences of t= he type: This should be done for each of the following data structures: emergencyCall.ProviderInfo emergencyCall.SvcInfo emergencyCall.DevInfo emergencyCall.SubInfo emergencyCall.Comment Cheers James --_000_5A55A45AE77F5941B18E5457ECAC8188012140771AC2SISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I have= been looking at this specification with an eye to implementation. It is mu= ch better than earlier versions and I thank the authors for that. There are= however some countries that have fields in their existing service order pr= ovisioning data sets that are not obviously mapped into the specific fields= defined in this document.

 

I think that with regional or national profili= ng most of this can be addressed, however, there is likely to always be a c= ase where this just doesn’t work. When this is the case there will be= need a need to add further information to one or more of the data bundles = defined in this document, and as currently specified this isn’t possi= ble because none of the schemas provide an extension point to allow this to= happen.

 

To avoid having to up version these schemas in the future, I t= hink it would be good to add an extension point at the end of each of the s= equences of the type:

<xs:any namespace=3D"##oth= er" processContents=3D"lax"

 =             &nb= sp;      minOccurs=3D"0" maxOccurs=3D&qu= ot;unbounded"/>

&nbs= p;

 

= This should be done for each of the following data structures:

emergencyCall.ProviderInfo
emergencyCall.SvcInf=
o
emergencyCall.DevInfo

emergency= Call.SubInfo

emergencyCall.Comment

 

=  

Cheers

James

 

= --_000_5A55A45AE77F5941B18E5457ECAC8188012140771AC2SISPE7MB1co_--

Wouldn= 217;t the LoST server simply include the response with a warning if the map= ping was substituted?

This= then let’s URN pruning occur and the UE still gets something as well= as a notification that it wasn’t what they asked for.

 

Cheers

Jam= es

 

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] = On Behalf Of Richard Barnes
Sent: Thursday, 21 February 20= 13 10:25 AM
To: Nathan Wilcox
Cc: Rosen, Brian; ecrit@i= etf.org
Subject: Re: [Ecrit] What is the most appropriate method = for registering new sub-services of urn:service:sos (trimming due too large= message report)

 = ;

Yes.  This.

 

My = first reaction to these suggestions of chaining was "It's a provisioni= ng problem -- just put the same contact information under all those URNs.&q= uot;

 

On Wed, Feb 20,= 2013 at 5:02 PM, Nathan Wilcox <ngwilcox@gmail.com> wrote:

+1

&= nbsp;

On Feb 20, 2013, at 3:15 PM, = Marc Linsner <ml= insner@cisco.com> wrote:


Not sure I agree with your summ= ation.  In your example, .sos IS the proper way to call .fire.  J= ust because .sos is also the proper way to call .police is irrelevant.=

 

=

Maybe it would be best to use a DNS-like approach.  = No record =3D 'not found'.  No ambiguity this way.  Populate .sos= and .sos.fire and .sos.police all with the same uri if that is the respons= e you want.  If request is for .sos.help and the jurisdiction doesn't = support .help, the response is 'not found'.  Why try to guess what was= requested?

 <= /span>

-Marc-

 

 <= /o:p>

 

<= div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0= cm 0cm'>

From: Dan Mongrain <dan@mongrain.org>
Date: Wed= nesday, February 20, 2013 3:32 PM
To: Marc Linsner <mlinsner@cisco.com>Cc: "Rosen, Brian" <Brian.Rosen@neustar.biz>, "ecrit@ietf.org" <<= a href=3D"mailto:ecrit@ietf.org" target=3D"_blank">ecrit@ietf.org>Subject: Re: [Ecrit] What is the most appropriate method for regis= tering new sub-services of urn:service:sos (trimming due too large message = report)

 

We should not infer anything from missing = information especially if this information is optional (as my previous mess= age shows).  Doing anything else is misleading at best.  Requeste= r makes a request specifying desired service nothing more.  You may as= k for sos.fire, but you are getting sos as you cannot call .fire directly, = local policy.  If you do not like the answer, try again if you want wi= th a different service (same service request will give same response back).=

Dan

On Wed, Feb 20, 2013 at = 3:16 PM, Marc Linsner <mlinsner@cisco.com> wrote:

=

What if I don't want A2 (I don't trust Butler County sher= iff), if no A3 (Mars) give me A1 (PA)?

 

What I propose= d allows the requestor to tailor the request to match his desire.

 

=

The fallback is multiple requests.

=

 

-Marc= -

 

=

From: "Rosen, Brian" <Brian.Rosen@neusta= r.biz>
Date: Wednesday, February 20, 2013 2:56 PM
To= : Marc Linsner <mlinsner@cisco.com>
Cc: Dan Mongrain <dan@mongrain.org>, "ecrit@ietf.org" = <ecrit@ietf.org&= gt;
Subject: Re: [Ecrit] What is the most appropriate method for = registering new sub-services of urn:service:sos (trimming due too large mes= sage report)

 =

<= p class=3DMsoNormal>To me, this doesn't make sense.

 

Suppose I have = a local police department in cities, but a provincial police department in = rural areas, as well as a national police.  I ask for sos.police.A3. &= nbsp;If location was in a city, I should get sos.police.A3

 

But if I was in a rural area, a request for sos.police.A3 should retu= rn a response of sos.police.A2.

 

That may or may not= be the same as sos.police

 

Brian

 

On Feb 20, 2013, at 2:47 PM, Marc Linsner <mlinsner@cisco.com> wrote:



I understood you as requesting urn:service:sos.police.A4.

 

My point was that if the LoST service had no entry for A4, it cou= ld simply check the Ax tree submitted in the location section of the reques= t.  So if the location included A1 & A4, the LoST service, finding= nothing for A4 would then check A1 (not A3 or A2).  This way the serv= ice would be matching the hierarchy of the given location vs. an arbitrary = hierarchy that may be different from the requestors desire.

 

Carry on…

&n= bsp;

-Marc-

 

I do not understand your comment.&= nbsp; What I am proposing is that requests do not specify a search pattern = in the case a requested jurisdiction is not found.  It should not be t= o the requester which submits urn:service:sos.police.country.A1.A2.A3.A4 to= specify what to do if there is nothing configured for the A4 layer.  = It must be up to the LoST service to apply whatever policy it has in this c= ase.  If we allow this, then do we allow urn:service:sos.police.fire?&= nbsp; Give me fire first but if not found give me police?

The Servic= e URN should specify the "desired" service in a findService reque= st and the LoST service provides a response based on local policies.  = All I am proposing is that one can specify a jurisdiction in the case there= are more then one service provider for a location.

Thanx,
Dan

On Wed, Feb 20, 2013 at 8:48 AM, Marc = Linsner <mlinsne= r@cisco.com> wrote:

The findService request includes location information.  Why would= n't the LoST server simple walk the A1-A6 tree included with the location? =  If location is geo, reverse geocode it.

 

What am= I missing?

 <= /span>

-Marc-

 

= From= : Dan Mongrain <dan@mongrain.org>
Date: Tuesday, February 19, 2013 11:55= PM
To: "Winterbottom, James" <James.Winterbottom@commsco= pe.com>
Cc: "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] Wha= t is the most appropriate method for registering new sub-services of urn:se= rvice:sos (trimming due too large message report)

 

= What I meant is that if a jurisdictional scope aware LoST service receives = a request for urn:service:sos.police.A4 and nothing is configured, it looks= for urn:service:sos.police.A3 then urn:service:sos.police.A2, etc. until i= t finds a configured service.  If nothing is found for urn:service:sos= .police.country then it pops the last element and looks for urn:service:sos= .police (but then again, it is no longer jurisdictional scope aware).
I disagree that one needs to formulate the request as urn:service:sos.pol= ice.country.A1.A2.A3.A4 in order for this to happen.  There must be on= ly a single jurisdictional scope appended to a Service URN.

I do not= think we need a .A6 jurisdictional scope (street level).  .A5 (neighb= orhood, would point to a precinct for example) provides enough granularity = in my opinion.

Thanx,
Dan

On Tue, Feb 19, 2013 at 11:29 PM, Winterbottom, James <James.Winter= bottom@commscope.com> wrote:

=

I am sorry, I am finding this confusing.=

 

RFC5139 puts a hierarchy on A1 = through A6. If you want this hierarchy to work then A1 through A6 can’= ;t be at the same level if you expect A3 to fallback to A2 or A1 in the cas= e of a service not existing or a service failure of some kind. If they exis= t at the same level then if A3 doesn’t exist you will go to urn:servi= ce:sos.police  unless you impose the hierarchy in the urn.

 

=

 

 

 

 

= From: Dan Mongrain [mailto:dan@mongrain.org]
Sent: Wednesday, 20 February 2013= 3:23 PM
To: DRAGE, Keith (Keith)
Cc: Winterbottom, Jam= es; Ivo Sedlacek; ecrit= @ietf.org
Subject: Re: [Ecrit] What is the most appropriate m= ethod for registering new sub-services of urn:service:sos (trimming due too= large message report)

&n= bsp;

My recommendation for handling unknown Ser= vice URN depends if LoST service implements jurisdictional scope or not.&nb= sp; If it does not, it pops the last element and evaluates until a service = is found.  If it implements jurisdictional scope, the last element is = a jurisdictional scope and it is not found, then you return the next highes= t level defined.

While it may be true that citizens typically dial 9= -1-1 to request for help, police services such as state or provincial polic= es advertises numbers to call them directly (star code to dial using a mobi= le phone for example) especially to report accidents on freeways.  We = need an equivalent Service URN.

Also while RFC5031's scope is citize= n to authorities (I am not sure I agree with this) I do not want to re-inve= nt the wheel to signal calls within an Emergency Services IP Network (ESIne= t).  When I transfer a call from one PSAP to another, the mechanism to= determine where to send the call is the same, using LoST.  For a PSAP= that covers a large area spanning multiple counties and the calltaker need= s to transfer the call to the appropriate sheriff department for the caller= 's location, they only need a single transfer target (urn:service:sos.polic= e.A2).  It is not true that the calltaker always knows the actual dest= ination of the call, especially when the calltaker is only a call screener.=

Thanx,
Dan

On Tue, Feb 19, = 2013 at 7:18 PM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> w= rote:

The answer to James’s question depends on how you code it (and a= lso what you mean by fallback).

 

On any service URN, you ignore any subtypes from the= point you stop understanding it.

 

So if the coding is sos.police.A2, and you do n= ot understand A2, then the service URN would be handled as if it was sos.po= lice, not as sos.police.A1. And if police was not understood then it would = be handled as sos.

 

If you wanted something that went back to the next larger regiona= l coverage, then you would have to code successive subtypes in sequence.

 

But I wou= ld also ask for an element of sanity in this discussion, rather than total = flexibility.

 

For example while a national administration may have multiple levels o= f police force, not all of them are either reachable directly as an emergen= cy service provider, nor are they necessarily an emergency service provider= . If they are neither of these, then they presumably do not need a special = and distinct service URN.

 

It would therefore nice to see a current use case that is= anything but a choice of two, i.e. countrywide (following the ITU-T E.164 = definition of country) versus one more local variant. This restricted model= certainly covers Ivo’s examples of Czeck Republic and Poland, and I = believe it also covers the other example I know of which is Italy.

 =

While the USA has= multiple levels of police force, on the PSTN, it only appears to have one = level of access to citizen to authority emergency service, which is 911. I = see no reason why a change to voice over IP would cause a change to this.

 

I would a= lso stress that it is important to have global expectations of what you get= when you use a service URN. If there is not care excercised with assigning= semantics and values, A3 in one country could result in the forestry polic= e and in another country the financial police responding.<= /p>

 <= /p>

Note that read the scope = of RFC 5031 as being for end user accessing the emergency service. While it= might be possible to apply RFC 5031 to further network operations after th= e PSAP has been reached, e.g. to reach a subsidiary PSAP, I read that as ou= tside the scope of RFC 5031. Nor do I necessarily believe in that scenario = that service URNs are necessarily the best solution for routeing, as the fi= rst PSAP should know the particular office they want to reach rather than j= ust the type of emergency service.

 

Regards

 

Keith

 

From:= ecrit-bounces@ietf.org= [mailto:ec= rit-bounces@ietf.org] On Behalf Of Winterbottom, James
Sen= t: 19 February 2013 23:29
To: Ivo Sedlacek; Dan Mongrain
<= b>Cc: ecrit@ietf.or= g
Subject: Re: [Ecrit] What is the most appropriate method fo= r registering new sub-services of urn:service:sos (trimming due too large m= essage report)

 

I am= okay with this, providing that the fallback order is clearly defined.<= /o:p>

That is, does an A3 = fall back to an A2 or A1, or just back to sos?

 

 

 

From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com]
Sent: W= ednesday, 20 February 2013 7:32 AM
To: Dan Mongrain
Cc:= Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subject: RE: [Ecrit] What is th= e most appropriate method for registering new sub-services of urn:service:s= os (trimming due too large message report)

=

 

Hello,

 

If we = go with RFC4119 based sub-services, would the IANA registration request be = as follows?

 = <= o:p>

- urn:service:sos= .police.A3 - The 'police.local' service refers to the emergency= service offered by the police department or other law enforcement authorit= ies of the authorities of a city, township, shi (JP).=

- urn:service:sos.police= .country - The 'police.national' service refers to the emergency s= ervice offered by the police department or other law enforcement authoritie= s of the government of a country.

 

Does anyone see any issue in that?

 

If WG prefers this, it is OK for me.

 

> In the latter case, so how do I get th= e county police (or state police, there can be up to 4 police services for = a given location in the US). 

 

If I got it correctly, you propose that we also add

- urn:service:sos.police.A2 - The 'police.local' service refers to the emergency service offered by t= he police department or other law enforcement authorities of the authoritie= s of county, parish, gun (JP), district (IN)"

- urn:service:sos.police.A1= - The 'police.local' service refers to the emergency service offered b= y the police department or other law enforcement authorities of the authori= ties of national subdivisions (state, region, province, prefecture)= "

 = <= o:p>

While I have no p= roblem with that, I am not aware of a regulation establishing such emergenc= y service so I cannot argue to IANA that the RFC5031 policy is satisfied fo= r those URNs.

&nbs= p;

Kind regards

 

Ivo Sedlacek<= /p>

 

 

 

 = ;=

This Communicatio= n is Confidential. We only send and receive email on the basis of the terms= set out at www.ericsson.com= /email_disclaimer

= From:= Dan Mongrain [mai= lto:dan@mongrain.org]
Sent: 19. =FAnora 2013 21:12
To:= Ivo Sedlacek
Cc: Winterbottom, James; Richard Barnes; ecrit@ietf.org
Subj= ect: Re: [Ecrit] What is the most appropriate method for registering ne= w sub-services of urn:service:sos (trimming due too large message report)

 

Thing is, when there is no city police, local would gi= ve you county police (sheriff department) but in a city with a city police = department local would give you city police.  In the latter case, so h= ow do I get the county police (or state police, there can be up to 4 police= services for a given location in the US).  Note that these examples a= re US based, but we do have 3 levels of police services in Canada and I am = sure other countries have the same issue.

 

There is also t= he terminology.  There is no "national" police in the US or = Canada but there is a federal police.  Keeping the RFC 4119 terminolog= y removes any "local" interpretation issues.

Dan

On Tue, Feb 19, 2013 at 2:31 PM, Ivo Sedlacek &= lt;ivo.sedla= cek@ericsson.com> wrote:

I agree with Richard - there are countries where both t= he emergency service of the national police and the emergency service of th= e municipal police are offered in a given location.

A user would call the municipal police e= mergency service to report e.g. pickpockets.

A user would call the national police emergency = service to report e.g. a murder.

 

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#C050= 4D'> 

I subm= itted to IANA a request to register:

- urn:service:sos.police.local - The 'police.local' serv= ice refers to the emergency service offered by the police department or oth= er law enforcement authorities of the local or municipal authorities.

- urn:service:sos.polic= e.national - The 'police.national' service refers to the emergency service = offered by the police department or other law enforcement authorities of th= e national government.

=  

RFC503= 1 policy is hopefully fulfilled for them since they exist in two countries.= <= o:p>

 <= /span>

I am flexible whether the ac= tual URNs contain the sub-services proposed above (i.e. .local and .nationa= l sub-services) or subservices based on RFC4119 (i.e. .A3 and .country sub-= services).

 = <= o:p>

If the preference= is for subservices based on RFC4119, do I need to make another IANA regist= ration request or can we modify the URNs and their description during the e= xpert review?

&nbs= p;

Kind regards

 

Ivo Sedlacek<= /p>

 

This Communication is Confidential. We only sen= d and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer <= span style=3D'font-size:8.5pt;font-family:"Calibri","sans-serif"'>

From: Dan Mongrain [mailto:dan@mongrain.org]
= Sent: 19. =FAnora 2013 15:36
To: Winterbottom, James
Cc: Richard Barnes; Ivo Sedlacek; ecrit@ietf.org
Subject: Re: [Ecrit] What is t= he most appropriate method for registering new sub-services of urn:service:= sos

 

The problem is that different count= ries has different names for their political subdivisions.  In the US = they are states, in Canada they are provinces, etc.  Same when you fur= ther subdivide.  While not privy to the discussions that came up with = A1, A2, …, A5, I have the feeling this nomenclature was picked for th= e same reason.  Why not utilise the same naming scheme for specifying = the jurisdiction you want to reach?

 

Thanx,

Dan

 

On Mon, Feb 18, 2013 at 5:01 PM, Winterbottom, James <James.Winterbottom@co= mmscope.com> wrote:

In that case, one might say state in the hierarchy, not A1= .=

 <= span style=3D'font-size:8.5pt;font-family:"Calibri","sans-serif"'>

Cheers=

James

=

 

 

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Tuesday, 19 February 2013= 8:57 AM
To: Winterbottom, James
Cc: Dan Mongrain; Ivo = Sedlacek; ecrit@ietf.or= g


Subject:= Re: [Ecrit] What is the most appropriate method for registering new sub-se= rvices of urn:service:sos

=

 

It mi= ght make sense if you wanted to allow the caller to explicitly select polic= e at a different level of responsibility, e.g., the state police rather tha= n the local police.  

 <= o:p>

On Mon, Feb 18, 2013 at 4:21 PM, Winte= rbottom, James <James.Winterbottom@commscope.com> wrote:

I think I am missing so= mething here, A1 is part of the location, so why does it need to be in the = URN at all?

As f= ar as I understand current deployments, they use the URN to select a layer = in the GIS that corresponds to the service type, and then use geographic bo= undaries within that layer to select the final destination.

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] <= b>On Behalf Of Dan Mongrain
Sent: Tuesday, 19 February 2013 7= :30 AM


To: Ivo = Sedlacek
Cc: = ecrit@ietf.org
Subject: Re: [Ecrit] What is the most appropri= ate method for registering new sub-services of urn:service:sos

 <= /p>

Sorry for responding late to this= thread, it kinda fell into a  crack…  The current thread r= eminded me to check this old thread…

<= p class=3DMsoNormal> 

You are indicating that we need to register 77 Service = URN (11 service subtypes * 7 jurisdiction types based on RFC 4119).  I= do not recommend that we create so many registrations.  Instead, we s= hould allow a service URN to be suffixed with a jurisdictional scope. = So the following Service URN are all valid:

 

urn:service:sos.police

<= p class=3DMsoNormal>urn:service:sos.police.traffic<= /p>

urn:service:sos.police.A1<= span style=3D'font-size:8.5pt;font-family:"Calibri","sans-serif"'>

urn:service:sos.police.= traffic.A1

&nbs= p;

Question is, = do we want to leave jurisdictional scope to only be applicable to police br= anch or any Service URN?  I’d say the latter as it is always up = to the LoST service provisioning (based on local policy) to determine what = is locally acceptable.

=  

Th= anx,

Dan<= span style=3D'font-size:8.5pt;font-family:"Calibri","sans-serif"'>

 

 =

 =


_______________________= ________________________ Ecrit mailing list Ecrit@ietf.orghttps://www.ietf.org/mailman/listinfo= /ecrit

=  

___________________= ____________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ecrit

 = ;

&n= bsp;

______________= _________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.o= rg/mailman/listinfo/ecrit