From christer.holmberg@ericsson.com Sat Mar 2 03:51: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 009D121F8F9F for ; Sat, 2 Mar 2013 03:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.247 X-Spam-Level: X-Spam-Status: No, score=-6.247 tagged_above=-999 required=5 tests=[AWL=0.002, 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 xXCa36vtqoXk for ; Sat, 2 Mar 2013 03:51:56 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2A23921F9106 for ; Sat, 2 Mar 2013 03:51:53 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-ff-5131e7d8fa69 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D8.48.10459.8D7E1315; Sat, 2 Mar 2013 12:51:53 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0318.004; Sat, 2 Mar 2013 12:51:52 +0100 From: Christer Holmberg To: Richard Barnes Thread-Topic: [Ecrit] RFC 5031 text modification suggestion [was: Draft new version: draft-holmberg-ecrit-country-emg-urn-01] Thread-Index: AQHOFM8yyQAucD40WE6fMDo57/cIZZiOEIwAgAQ92Ik= Date: Sat, 2 Mar 2013 11:51:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B10EF60@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>, <5A55A45AE77F5941B18E5457ECAC8188012140771944@SISPE7MB1.commscope.com> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188012140771944@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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvje7N54aBBh+ns1s0LnrKajG1z9aB yWPJkp9MHpM3zmIJYIrisklJzcksSy3St0vgyvj4q5W94B1TxYSXZ1kaGNcxdTFyckgImEj8 ePSHHcIWk7hwbz1bFyMXh5DAIUaJe6fnMUM4ixglTp59BJTh4GATsJDo/qcN0iAiIC9x+voD VhCbWUBV4lzjYxaQEmGBOonN38pATBGBeonTM8Mhqq0kvj/8yAZiswioSPyaP5ERxOYV8Jb4 cqQHalM7s8Szqw/AijgFgiVe/DsEZjMC3fb91BomiFXiEreezIe6X0BiyZ7zzBC2qMTLx/9Y QfZKCChKLO+XgyjXkViw+xMbhK0tsWzha2aIvYISJ2c+YZnAKDYLydRZSFpmIWmZhaRlASPL Kkb23MTMnPRyw02MwOg4uOW37g7GU+dEDjFKc7AoifOGuV4IEBJITyxJzU5NLUgtii8qzUkt PsTIxMEp1cCo9TzX+j+n4CqRg0bM0+Wsa9fPeftevl4+atrTyiPVZ47nF3r7qngmFt3ccJV7 eWHEWo3o/x/Zv67sa3nuec1LIbSt2iMv8eUi73AGrk+h/j1qGw5dENLOeuQz7bTAmaodDstn H006r77tyqyzasrimWx8CQa3DUO2Fq/cEfF3pbZV6RoJ0eNKLMUZiYZazEXFiQCTSHD9XAIA AA== 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: Sat, 02 Mar 2013 11:51:57 -0000 Hi, I've generated a new version (-02) of draft-holmberg-ecrit-country-emg-urn,= which now updates section 4.2 of RFC 5031. As the draft submission window is closed at the moment, I can't submit it t= o IETF, but it can be found at: http://users.piuha.net/cholmber/drafts/draft-holmberg-ecrit-country-emg-urn= -02-noSubmit.txt Regards, Christer= From prvs=7777af10ef=jbakker@blackberry.com Wed Mar 6 12:31:00 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 10A9521F8440 for ; Wed, 6 Mar 2013 12:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.122 X-Spam-Level: X-Spam-Status: No, score=-5.122 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0x56ITZ4o0u for ; Wed, 6 Mar 2013 12:30:55 -0800 (PST) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4955021F8470 for ; Wed, 6 Mar 2013 12:30:55 -0800 (PST) X-AuditID: 0a41282f-b7f866d000007ef0-e9-5137a772995b Received: from XCT103ADS.rim.net (xct103ads.rim.net [10.67.111.44]) by mhs060cnc.rim.net (SBG) with SMTP id 1D.79.32496.277A7315; Wed, 6 Mar 2013 14:30:42 -0600 (CST) Received: from XMB103ADS.rim.net ([fe80::e54b:97d9:3777:f8dc]) by XCT103ADS.rim.net ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.02.0328.009; Wed, 6 Mar 2013 14:30:42 -0600 From: John-Luc Bakker To: Christer Holmberg , Richard Barnes Thread-Topic: [Ecrit] RFC 5031 text modification suggestion [was: Draft new version: draft-holmberg-ecrit-country-emg-urn-01] Thread-Index: AQHOFGlGvF+YvuZ5SlmbeMngbH+OJ5iN2hsAgACslgCABC26AIAGdXwg Date: Wed, 6 Mar 2013 20:30:41 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA35D11F19@XMB103ADS.rim.net> References: <7594FB04B1934943A5C02806D1A2204B108425@ESESSMB209.ericsson.se> <201302262040.r1QKehEm029435@rcdn-core-3.cisco.com> <201302262136.r1QLa2cl009174@rcdn-core-3.cisco.com> <7594FB04B1934943A5C02806D1A2204B10AE05@ESESSMB209.ericsson.se>, <5A55A45AE77F5941B18E5457ECAC8188012140771944@SISPE7MB1.commscope.com> <7594FB04B1934943A5C02806D1A2204B10EF60@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B10EF60@ESESSMB209.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.251] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOKsWRmVeSWpSXmKPExsXC5Zyvo1u03DzQ4ESbvsWFmYcZLRoXPWW1 mNpn68Ds8evrVTaPJUt+MnlM3jiLJYA5qoHRJimxpCw4Mz1P384mMS8vvySxJFUhJbU42VbJ JzU9MUchoCizLDG5UsElszg5JzEzN7VISSEzxVbJREmhICcxOTU3Na/EVimxoCA1L0XJjksB A9gAlWXmKaTmJeenZOal2yp5BvvrWliYWuoaKtnpJnTyZCzrYS9Yz1PRsYq1gXE1VxcjJ4eE gInEu+cXGSFsMYkL99azdTFycQgJrGSU2Dr7MyOEs4VRYtP1m2wgVWwCehIrJq8C6xARCJW4 sHEvM4jNLKAqca7xMUsXIweHsECdxOZvZSCmiEC9xOmZ4RDVbhInHx1jAbFZBFQkDr68zgRi 8wLFt8xbAzZFSOAMs0T3GlsQm1PAR+LvwWdgcUYBWYndZyHqmQXEJW49mc8EcbOAxJI955kh bFGJl4//sULYihIz9sxnhajXkViw+xMbhK0tsWzha2aIvYISJ2c+YZnAKDYLydhZSFpmIWmZ haRlASPLKkbB3IxiAzOD5LxkvaLMXL281JJNjKCU4aihv4Px7XuLQ4wCHIxKPLwTZ5oHCrEm lhVX5h5ilOBgVhLhvbsEKMSbklhZlVqUH19UmpNafIjRFRgqE5mluJPzgeksryTe2MAAN0dJ nFckUDRQSCAdmI6yU1MLUotg5jBxcILs4ZISKQYmldSixNKSjHhQ6osvBiY/qQbG9X1PH8a1 /O7kdrt0MMk8M+aOZe68u4a1h/9k+0dN0lS7wquze1ZGzwu5DpuYaKsAy3l/At5WZPNt2Wxo yq591TvQuG3uzbXbW9x1HR97eIX5XnexEQutnXjyTsqx7bIWs247yzxMVet46rbbbm/wdMPM o2Hnbn44sl8jd5vsOuHTYmtLrB8rsRRnJBpqMRcVJwIAsOnaOloDAAA= 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, 06 Mar 2013 20:31:00 -0000 Hi, This draft excludes the country specific extension as originally proposed in= draft-holmberg-ecrit-country-emg-urn-01. Without a country specific extension, any countries' regulator would have to= bring a proposal to the IANA to have a URN for their "new and different" em= ergency service. This may be undesirable from a regulator's perspective, reduce the country's= perception of sovereignty, and hinder the adoption of the specifications th= at depend on the RFC. While I have no problems with exploring possible modifications to the policy= that governs the registering of emergency URNs, I continue to support the o= riginal proposal to allow for "regulator jurisdiction" specific URNs. Kind regards, John-Luc -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Ch= rister Holmberg Sent: Saturday, March 02, 2013 5:52 AM To: Richard Barnes Cc: ecrit@ietf.org Subject: Re: [Ecrit] RFC 5031 text modification suggestion [was: Draft new v= ersion: draft-holmberg-ecrit-country-emg-urn-01] Hi, I've generated a new version (-02) of draft-holmberg-ecrit-country-emg-urn,= which now updates section 4.2 of RFC 5031. As the draft submission window is closed at the moment, I can't submit it to= IETF, but it can be found at: http://users.piuha.net/cholmber/drafts/draft-holmberg-ecrit-country-emg-urn-= 02-noSubmit.txt Regards, Christer _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --------------------------------------------------------------------- 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. From hgs@cs.columbia.edu Wed Mar 6 12: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 9BA1B21F8746 for ; Wed, 6 Mar 2013 12:54:02 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiU+VCtmtwoS for ; Wed, 6 Mar 2013 12:53:58 -0800 (PST) Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF7F21F854E for ; Wed, 6 Mar 2013 12:53:55 -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 rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r26KrnWK020242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 6 Mar 2013 15:53:51 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <155970D1DA8E174F9E46039E10E2AA35D11F19@XMB103ADS.rim.net> Date: Wed, 6 Mar 2013 15:53:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9667C6B8-9653-449B-8D71-B8679703E569@cs.columbia.edu> References: <7594FB04B1934943A5C02806D1A2204B108425@ESESSMB209.ericsson.se> <201302262040.r1QKehEm029435@rcdn-core-3.cisco.com> <201302262136.r1QLa2cl009174@rcdn-core-3.cisco.com> <7594FB04B1934943A5C02806D1A2204B10AE05@ESESSMB209.ericsson.se>, <5A55A45AE77F5941B18E5457ECAC8188012140771944@SISPE7MB1.commscope.com> <7594FB04B1934943A5C02806D1A2204B10EF60@ESESSMB209.ericsson.se> <155970D1DA8E174F9E46039E10E2AA35D11F19@XMB103ADS.rim.net> To: John-Luc Bakker X-Mailer: Apple Mail (2.1283) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5 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, 06 Mar 2013 20:54:02 -0000 It is not obvious to me that there is a natural entity that would manage = country-specific URNs in many places. For example, emergency services in = the US are managed by states and sometimes counties (or multiple = counties). If a state wants to set up a special number for turkey = disasters on Thanksgiving or to report illegal garage sales, I don't = think a national regulator (say, the FCC) is going to keep that from = happening or even get involved. These semi-emergency services are often = very regional, given that they depend on very specific local = circumstances. Thus, if you want to allow such very narrow public = services, you're probably talking county-level and below, not country. =46rom a user interface perspective, I'm not sure how well a = proliferation of services that have similar functions and different = names would work. In general, there has been a tendency towards fewer = user-facing services, with 211 (social services), 311 (non-emergency = services) and 911 as examples in the US. On Mar 6, 2013, at 3:30 PM, John-Luc Bakker wrote: > Hi, >=20 > This draft excludes the country specific extension as originally = proposed in draft-holmberg-ecrit-country-emg-urn-01. > Without a country specific extension, any countries' regulator would = have to bring a proposal to the IANA to have a URN for their "new and = different" emergency service. >=20 > This may be undesirable from a regulator's perspective, reduce the = country's perception of sovereignty, and hinder the adoption of the = specifications that depend on the RFC. >=20 > While I have no problems with exploring possible modifications to the = policy that governs the registering of emergency URNs, I continue to = support the original proposal to allow for "regulator jurisdiction" = specific URNs. >=20 > Kind regards, >=20 > John-Luc >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Christer Holmberg > Sent: Saturday, March 02, 2013 5:52 AM > To: 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] >=20 >=20 > Hi, >=20 > I've generated a new version (-02) of = draft-holmberg-ecrit-country-emg-urn, which now updates section 4.2 of = RFC 5031. >=20 > As the draft submission window is closed at the moment, I can't submit = it to IETF, but it can be found at: >=20 > = http://users.piuha.net/cholmber/drafts/draft-holmberg-ecrit-country-emg-ur= n-02-noSubmit.txt >=20 > Regards, >=20 > Christer > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > --------------------------------------------------------------------- > 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 your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From rlb@ipv.sx Wed Mar 6 17:54:39 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 0E09B21F8589 for ; Wed, 6 Mar 2013 17:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.661 X-Spam-Level: X-Spam-Status: No, score=0.661 tagged_above=-999 required=5 tests=[AWL=3.637, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDvZkwNGenB7 for ; Wed, 6 Mar 2013 17:54:38 -0800 (PST) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id 377AA21F8525 for ; Wed, 6 Mar 2013 17:54:38 -0800 (PST) Received: by mail-oa0-f45.google.com with SMTP id o6so13341158oag.4 for ; Wed, 06 Mar 2013 17:54:37 -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=ZF+1xEBHrI4p24/p3PN+js6qF1knFxXkwWJztwUBUDE=; b=McPQxtZISYtWAn6rG5qJ4K0s6UCGM/8aw8JdWzP572BMr/rfciK4JbBLHxYyEIbTWw 94Jf6X39+HidRlwDdobL1Nsonpi5xCUVd9mFzGUcy2gRvHNAEg9aDlETY8JNwOnh7H0k oFavNa0/a4qqy2ka0nEKNfjwRT3K7ic1uV95VAHMXbLUbFnPob7rBc4odwY4g2wwUWZK AFCtFGSesdO6hgMIGJYckKr1+45wb2qXjwsAFAKTfZ4KEKQ74gSDNGhxsMVI+nsRnify rU3OudtFF4AbZ6hCjuPVULM7XybeTvPt4S62YCXtSz49eb3efkk5snNtVoM9YlqjImSj 2vNQ== MIME-Version: 1.0 X-Received: by 10.60.10.226 with SMTP id l2mr25330147oeb.67.1362621277713; Wed, 06 Mar 2013 17:54:37 -0800 (PST) Received: by 10.60.150.131 with HTTP; Wed, 6 Mar 2013 17:54:37 -0800 (PST) X-Originating-IP: [108.18.40.68] In-Reply-To: <155970D1DA8E174F9E46039E10E2AA35D11F19@XMB103ADS.rim.net> References: <7594FB04B1934943A5C02806D1A2204B108425@ESESSMB209.ericsson.se> <201302262040.r1QKehEm029435@rcdn-core-3.cisco.com> <201302262136.r1QLa2cl009174@rcdn-core-3.cisco.com> <7594FB04B1934943A5C02806D1A2204B10AE05@ESESSMB209.ericsson.se> <5A55A45AE77F5941B18E5457ECAC8188012140771944@SISPE7MB1.commscope.com> <7594FB04B1934943A5C02806D1A2204B10EF60@ESESSMB209.ericsson.se> <155970D1DA8E174F9E46039E10E2AA35D11F19@XMB103ADS.rim.net> Date: Wed, 6 Mar 2013 20:54:37 -0500 Message-ID: From: Richard Barnes To: John-Luc Bakker Content-Type: multipart/alternative; boundary=e89a8fb1f8d038d43204d74bfd70 X-Gm-Message-State: ALoCoQmgbTCY9z0ptr2oW5U+EEcVl+We5DkjZFdgMAc4yA5pxXiNhzO8d8Le3W2xjCu3w+KhCAKR 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: Thu, 07 Mar 2013 01:54:39 -0000 --e89a8fb1f8d038d43204d74bfd70 Content-Type: text/plain; charset=ISO-8859-1 How do regulators get IP addresses? Or telephone numbers? This is not a reduction in sovereignty -- they can freely use non-standard URIs. It's just that they won't interoperable with the rest of the world if they choose to their own way instead of doing what everyone else has agreed to do. On Wednesday, March 6, 2013, John-Luc Bakker wrote: > Hi, > > This draft excludes the country specific extension as originally proposed > in draft-holmberg-ecrit-country-emg-urn-01. > Without a country specific extension, any countries' regulator would have > to bring a proposal to the IANA to have a URN for their "new and different" > emergency service. > > This may be undesirable from a regulator's perspective, reduce the > country's perception of sovereignty, and hinder the adoption of the > specifications that depend on the RFC. > > While I have no problems with exploring possible modifications to the > policy that governs the registering of emergency URNs, I continue to > support the original proposal to allow for "regulator jurisdiction" > specific URNs. > > Kind regards, > > John-Luc > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Christer Holmberg > Sent: Saturday, March 02, 2013 5:52 AM > To: 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, > > I've generated a new version (-02) of > draft-holmberg-ecrit-country-emg-urn, which now updates section 4.2 of RFC > 5031. > > As the draft submission window is closed at the moment, I can't submit it > to IETF, but it can be found at: > > > http://users.piuha.net/cholmber/drafts/draft-holmberg-ecrit-country-emg-urn-02-noSubmit.txt > > Regards, > > Christer > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > --------------------------------------------------------------------- > 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 > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. > --e89a8fb1f8d038d43204d74bfd70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable How do regulators get IP addresses? =A0Or telephone numbers?

=
This is not a reduction in sovereignty -- they can freely use non-stan= dard URIs. =A0It's just that they won't interoperable with the rest= of the world if they choose to their own way instead of doing what everyon= e else has agreed to do. =A0



On Wednesday, March 6, 2013, John-Luc Bakker w= rote:
Hi,

This draft excludes the country specific extension as originally proposed i= n draft-holmberg-ecrit-country-emg-urn-01.
Without a country specific extension, any countries' regulator would ha= ve to bring a proposal to the IANA to have a URN for their "new and di= fferent" emergency service.

This may be undesirable from a regulator's perspective, reduce the coun= try's perception of sovereignty, and hinder the adoption of the specifi= cations that depend on the RFC.

While I have no problems with exploring possible modifications to the polic= y that governs the registering of emergency URNs, I continue to support the= original proposal to allow for "regulator jurisdiction" specific= URNs.

Kind regards,

=A0 =A0 =A0 =A0 John-Luc

-----Original Message-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Saturday, March 02, 2013 5:52 AM
To: 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,

I've generated a new version (-02) of draft-holmberg-ecrit-country-emg-= urn, which now updates section 4.2 of RFC 5031.

As the draft submission window is closed at the moment, I can't submit = it to IETF, but it can be found at:

http://users.piuha.net/cholm= ber/drafts/draft-holmberg-ecrit-country-emg-urn-02-noSubmit.txt

Regards,

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

---------------------------------------------------------------------
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.
--e89a8fb1f8d038d43204d74bfd70-- From prvs=97780b13c3=jbakker@blackberry.com Wed Mar 6 19:05: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 6BF1721F84F3 for ; Wed, 6 Mar 2013 19:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.142 X-Spam-Level: X-Spam-Status: No, score=-5.142 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFJEyywXfYcs for ; Wed, 6 Mar 2013 19:05:51 -0800 (PST) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id EF2D921F86A5 for ; Wed, 6 Mar 2013 19:05:50 -0800 (PST) X-AuditID: 0a41282f-b7f866d000007ef0-4f-51380405e9c2 Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) by mhs060cnc.rim.net (SBG) with SMTP id B0.B1.32496.50408315; Wed, 6 Mar 2013 21:05:41 -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; Wed, 6 Mar 2013 21:05:40 -0600 From: John-Luc Bakker To: Richard Barnes Thread-Topic: [Ecrit] RFC 5031 text modification suggestion [was: Draft new version: draft-holmberg-ecrit-country-emg-urn-01] Thread-Index: AQHOFGlGvF+YvuZ5SlmbeMngbH+OJ5iN2hsAgACslgCABC26AIAGdXwggAC/TYCAABPZgA== Date: Thu, 7 Mar 2013 03:05:40 +0000 Message-ID: <20130307030539.5427346.5742.1295@blackberry.com> References: <7594FB04B1934943A5C02806D1A2204B108425@ESESSMB209.ericsson.se> <201302262040.r1QKehEm029435@rcdn-core-3.cisco.com> <201302262136.r1QLa2cl009174@rcdn-core-3.cisco.com> <7594FB04B1934943A5C02806D1A2204B10AE05@ESESSMB209.ericsson.se> <5A55A45AE77F5941B18E5457ECAC8188012140771944@SISPE7MB1.commscope.com> <7594FB04B1934943A5C02806D1A2204B10EF60@ESESSMB209.ericsson.se> <155970D1DA8E174F9E46039E10E2AA35D11F19@XMB103ADS.rim.net> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <8FDC2F5A3FEB6F4886F05358137F7978@rim.com> content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOKsWRmVeSWpSXmKPExsXC5ZyvpcvKYhFo8OmwksWFmYcZLRoXPWW1 mNpn68Ds8evrVTaPJUt+MnlM3jiLJYA5qoHRJimxpCw4Mz1P384mMS8vvySxJFUhJbU42VbJ JzU9MUchoCizLDG5UsElszg5JzEzN7VISSEzxVbJREmhICcxOTU3Na/EVimxoCA1L0XJjksB A9gAlWXmKaTmJeenZOal2yp5BvvrWliYWuoaKtnpJnTyZHQ/fsdccEam4mHzAuYGxjPiXYyc HBICJhJ/n/UwQthiEhfurWfrYuTiEBJYySjxefEZdghnC6PEs4W/WUGq2AT0JFZMXgXWISIg L3H6+gOwOLNAtMTqJ1/AbGGBOom3v58DTeIAqqmXOD0zHKI8TGLa9zPMIDaLgIrE2vVX2EBs XgFbiYs3FjND7DrPIrHo3CqwIk6BQIm+GavYQWxGAVmJ3WevM0HsEpfYN383M8TVAhJL9pyH skUlXj7+B3WPjsSC3Z/YIGwziTMrpzJD2NoSyxa+ZoZYLChxcuYTlgmMYrOQjJ2FpH0WkvZZ SNpnIWlfwMi6ilEwN6PYwMwgOS9ZrygzVy8vtWQTIyilOGro72B8+97iEKMAB6MSD+/3XeaB QqyJZcWVuYcYJTiYlUR47y4BCvGmJFZWpRblxxeV5qQWH2J0BQbRRGYp7uR8YLrLK4k3NjDA zVES5xUJFA0UEkgHpqvs1NSC1CKYOUwcnCB7uKREioFJJ7UosbQkIx6UGuOLgclRqoFRabum dLwV73+m3nuMdi4C8dPfLptQcViU68qDIm4//lvbl4U8iPv3Z8YbRcVk6/q2m2GsUjPqngYc vvXKLmfH4aM8sgWZTtNmqrLmmYpeXZ98MEv799bPfcoO33tadqlLbHskf+DDv572j+x35JYE 9gs86l94+ti5+/k9PJtnPL5ZLbPc4cp1JZbijERDLeai4kQAtmQl2GoDAAA= 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: Thu, 07 Mar 2013 03:05:52 -0000 Hi, That seems to be the problem, the requirement to have everybody agree to a U= RN before it can be used in a set of networks part of the regulator's jurisd= iction. A service URN is NOT intended to be entered by a user via the keypad, so a u= ser is unlikely to be confused if the URN contains e.g. a country code. If l= ater a URN is reserved via RFC5031 procedures then two URNs can be used in t= hat country to identify the particular emergency services offered by the PSA= P. There seems no downside to enabling country specific URNs as originally prop= osed in this internet draft, it adds flexibility and timeliness. Regards, John-Luc Sent from my BlackBerry 10 smartphone. From: Richard Barnes Sent: Wednesday, March 6, 2013 7:54 PM To: John-Luc Bakker Cc: Christer Holmberg; ecrit@ietf.org Subject: Re: [Ecrit] RFC 5031 text modification suggestion [was: Draft new v= ersion: draft-holmberg-ecrit-country-emg-urn-01] How do regulators get IP addresses? Or telephone numbers? This is not a reduction in sovereignty -- they can freely use non-standard U= RIs. It's just that they won't interoperable with the rest of the world if= they choose to their own way instead of doing what everyone else has agreed= to do. On Wednesday, March 6, 2013, John-Luc Bakker wrote: Hi, This draft excludes the country specific extension as originally proposed in= draft-holmberg-ecrit-country-emg-urn-01. Without a country specific extension, any countries' regulator would have to= bring a proposal to the IANA to have a URN for their "new and different" em= ergency service. This may be undesirable from a regulator's perspective, reduce the country's= perception of sovereignty, and hinder the adoption of the specifications th= at depend on the RFC. While I have no problems with exploring possible modifications to the policy= that governs the registering of emergency URNs, I continue to support the o= riginal proposal to allow for "regulator jurisdiction" specific URNs. Kind regards, John-Luc -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Saturday, March 02, 2013 5:52 AM To: Richard Barnes Cc: ecrit@ietf.org Subject: Re: [Ecrit] RFC 5031 text modification suggestion [was: Draft new v= ersion: draft-holmberg-ecrit-country-emg-urn-01] Hi, I've generated a new version (-02) of draft-holmberg-ecrit-country-emg-urn,= which now updates section 4.2 of RFC 5031. As the draft submission window is closed at the moment, I can't submit it to= IETF, but it can be found at: http://users.piuha.net/cholmber/drafts/draft-holmberg-ecrit-country-emg-urn-= 02-noSubmit.txt Regards, Christer _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --------------------------------------------------------------------- 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. From hgs@cs.columbia.edu Wed Mar 6 19:38: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 2307E11E80A3 for ; Wed, 6 Mar 2013 19:38:26 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zE+yr6w5VoQ6 for ; Wed, 6 Mar 2013 19:38:25 -0800 (PST) Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB7C21F8614 for ; Wed, 6 Mar 2013 19:38:24 -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 paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r273cIS7023445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 6 Mar 2013 22:38:19 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <20130307030539.5427346.5742.1295@blackberry.com> Date: Wed, 6 Mar 2013 22:38:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3CF5664A-FBEF-4FE5-B0A4-BE7EA92934AC@cs.columbia.edu> References: <7594FB04B1934943A5C02806D1A2204B108425@ESESSMB209.ericsson.se> <201302262040.r1QKehEm029435@rcdn-core-3.cisco.com> <201302262136.r1QLa2cl009174@rcdn-core-3.cisco.com> <7594FB04B1934943A5C02806D1A2204B10AE05@ESESSMB209.ericsson.se> <5A55A45AE77F5941B18E5457ECAC8188012140771944@SISPE7MB1.commscope.com> <7594FB04B1934943A5C02806D1A2204B10EF60@ESESSMB209.ericsson.se> <155970D1DA8E174F9E46039E10E2AA35D11F19@XMB103ADS.rim.net> <20130307030539.5427346.5742.1295@blackberry.com> To: John-Luc Bakker X-Mailer: Apple Mail (2.1283) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4 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: Thu, 07 Mar 2013 03:38:26 -0000 This seems to solve a hypothetical problem, namely that registration of = a "global" URN is somehow too cumbersome. We have no such cases to = judge, so the downside, namely duplication of the same services under = multiple country-specific name and the absence of national entities to = police this, remains. If IANA gets a registration request for such a = country-specific service, submitted by Washington County, MD, whom = should it contact to validate that the person submitting the = registration is authorized to speak for the county and that the state = and country implicated approves of that service? Should it mediate if = two counties submit similar-sounding services under different names? Or = adjudicate if the state of Maryland then decides that this registration = was a bad idea? In the US, should FEMA, NTIA, DOT or the FCC be allowed = to register new URNs? In my current day job, conflicts between jurisdictions or agencies are = not uncommon. (We have had historical issues with conflicts about ccTLD = administrators, if you want another example.) Henning On Mar 6, 2013, at 10:05 PM, John-Luc Bakker wrote: > Hi, >=20 > That seems to be the problem, the requirement to have everybody agree = to a URN before it can be used in a set of networks part of the = regulator's jurisdiction. >=20 > A service URN is NOT intended to be entered by a user via the keypad, = so a user is unlikely to be confused if the URN contains e.g. a country = code. If later a URN is reserved via RFC5031 procedures then two URNs = can be used in that country to identify the particular emergency = services offered by the PSAP. >=20 > There seems no downside to enabling country specific URNs as = originally proposed in this internet draft, it adds flexibility and = timeliness. >=20 > Regards, >=20 > John-Luc >=20 > Sent from my BlackBerry 10 smartphone. >=20 > From: Richard Barnes > Sent: Wednesday, March 6, 2013 7:54 PM > To: John-Luc Bakker > Cc: Christer Holmberg; ecrit@ietf.org > Subject: Re: [Ecrit] RFC 5031 text modification suggestion [was: Draft = new version: draft-holmberg-ecrit-country-emg-urn-01] >=20 >=20 > How do regulators get IP addresses? Or telephone numbers? >=20 > This is not a reduction in sovereignty -- they can freely use = non-standard URIs. It's just that they won't interoperable with the = rest of the world if they choose to their own way instead of doing what = everyone else has agreed to do. >=20 >=20 >=20 > On Wednesday, March 6, 2013, John-Luc Bakker wrote: > Hi, >=20 > This draft excludes the country specific extension as originally = proposed in draft-holmberg-ecrit-country-emg-urn-01. > Without a country specific extension, any countries' regulator would = have to bring a proposal to the IANA to have a URN for their "new and = different" emergency service. >=20 > This may be undesirable from a regulator's perspective, reduce the = country's perception of sovereignty, and hinder the adoption of the = specifications that depend on the RFC. >=20 > While I have no problems with exploring possible modifications to the = policy that governs the registering of emergency URNs, I continue to = support the original proposal to allow for "regulator jurisdiction" = specific URNs. >=20 > Kind regards, >=20 > John-Luc >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org = [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer = Holmberg > Sent: Saturday, March 02, 2013 5:52 AM > To: 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] >=20 >=20 > Hi, >=20 > I've generated a new version (-02) of = draft-holmberg-ecrit-country-emg-urn, which now updates section 4.2 of = RFC 5031. >=20 > As the draft submission window is closed at the moment, I can't submit = it to IETF, but it can be found at: >=20 > = http://users.piuha.net/cholmber/drafts/draft-holmberg-ecrit-country-emg-ur= n-02-noSubmit.txt >=20 > Regards, >=20 > Christer > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > --------------------------------------------------------------------- > 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 your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful. >=20 >=20 > --------------------------------------------------------------------- > 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 your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From wwwrun@rfc-editor.org Thu Mar 7 16:42: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 9CE0121F86B6; Thu, 7 Mar 2013 16:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.84 X-Spam-Level: X-Spam-Status: No, score=-101.84 tagged_above=-999 required=5 tests=[AWL=0.760, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-AvL-z4Um+5; Thu, 7 Mar 2013 16:42:26 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1D19E21F86AF; Thu, 7 Mar 2013 16:42:26 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 12D24B1E002; Thu, 7 Mar 2013 16:28:32 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130308002832.12D24B1E002@rfc-editor.org> Date: Thu, 7 Mar 2013 16:28:32 -0800 (PST) Cc: ecrit@ietf.org, rfc-editor@rfc-editor.org Subject: [Ecrit] BCP 181, RFC 6881 on Best Current Practice for Communications Services in Support of Emergency Calling 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, 08 Mar 2013 00:42:26 -0000 A new Request for Comments is now available in online RFC libraries. BCP 181 RFC 6881 Title: Best Current Practice for Communications Services in Support of Emergency Calling Author: B. Rosen, J. Polk Status: Best Current Practice Stream: IETF Date: March 2013 Mailbox: br@brianrosen.net, jmpolk@cisco.com Pages: 28 Characters: 63007 See Also: BCP 181 I-D Tag: draft-ietf-ecrit-phonebcp-20.txt URL: http://www.rfc-editor.org/rfc/rfc6881.txt The IETF and other standards organizations have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks, and services using IETF protocols should use such standards to make emergency calls. This document is a product of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From hannes.tschofenig@gmx.net Mon Mar 11 04:24: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 4497321F86EC for ; Mon, 11 Mar 2013 04:24:56 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MvgjEYwJBZO for ; Mon, 11 Mar 2013 04:24:55 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3D721F86E1 for ; Mon, 11 Mar 2013 04:24:55 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M0NrX-1V29Wd0szl-00udNF for ; Mon, 11 Mar 2013 12:24:54 +0100 Received: (qmail invoked by alias); 11 Mar 2013 11:24:53 -0000 Received: from dhcp-1077.meeting.ietf.org (EHLO dhcp-1077.meeting.ietf.org) [130.129.16.119] by mail.gmx.net (mp027) with SMTP; 11 Mar 2013 12:24:53 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19kCcklaOJkNTrSRtu3bWFDPP0R2x3eiz+GciHHhu U95PBB2lt5UmUA From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Mar 2013 07:24:50 -0400 Message-Id: <238C720C-0F00-47AF-9344-835AC1C2A0E7@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-unauthenticated-access 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 Mar 2013 11:24:56 -0000 Hi guys,=20 as mentioned in the past already I believe that the WGLC on the = draft-ietf-ecrit-unauthenticated-access draft should be started in order = to complete the work.=20 Ciao Hannes From trac+ecrit@trac.tools.ietf.org Tue Mar 12 12:59: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 608061F0D0D for ; Tue, 12 Mar 2013 12:59:55 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojO9tEfYQSRJ for ; Tue, 12 Mar 2013 12:59:48 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 4A59B21F85B2 for ; Tue, 12 Mar 2013 12:59:43 -0700 (PDT) Received: from localhost ([127.0.0.1]:52579 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UFVMH-0007kM-5v; Tue, 12 Mar 2013 20:59: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: draft-ietf-ecrit-trustworthy-location@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Tue, 12 Mar 2013 19:59:37 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/8#comment:1 Message-ID: <080.bfa668d96b702c5d8f393080fcbd04e2@trac.tools.ietf.org> References: <065.165eff18457d51bb8c98009f8bce2353@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <065.165eff18457d51bb8c98009f8bce2353@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: <20130312195944.4A59B21F85B2@ietfa.amsl.com> Resent-Date: Tue, 12 Mar 2013 12:59:43 -0700 (PDT) Resent-From: trac+ecrit@trac.tools.ietf.org Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #8: 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: Tue, 12 Mar 2013 19:59:55 -0000 #8: Solutions Comment (by bernard_aboba@hotmail.com): Here is the proposed text for the solutions section: 3. Solutions This section presents three mechanisms which can be used to convey location: signed location by value (Section 3.1), location by reference (Section 3.2) and proxy added location (Section 3.3). 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 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. -- -------------------------------------+------------------------------------- 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: 2.0 Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Tue Mar 12 13:02: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 7892111E810A for ; Tue, 12 Mar 2013 13:02:55 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Po1cqVxu6Ll for ; Tue, 12 Mar 2013 13:02:52 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 435C31F0C36 for ; Tue, 12 Mar 2013 13:02:48 -0700 (PDT) Received: from localhost ([127.0.0.1]:52802 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UFVPK-0001gs-Nj; Tue, 12 Mar 2013 21:02:46 +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: Tue, 12 Mar 2013 20:02:46 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/13#comment:2 Message-ID: <080.75801bdf8338d23c332c236f411cd063@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: Tue, 12 Mar 2013 20:02:58 -0000 #13: Location Trust Assessment Comment (by bernard_aboba@hotmail.com): Here is revision to the text (now in its own Section 4): 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 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. Although privacy-preserving procedures may be disabled for emergency 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. Also, the device referred to in the PIDF-LO may not necessarily be the same entity conveying the PIDF-LO to the PSAP. 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. Due to these design choices, it is possible for an attacker to cut and paste a PIDF-LO obtained by a different device or user into a SIP INVITE and send this to the PSAP. While PIDF-LO signing would prevent modification of a PIDF-LO or invention of one out of whole cloth, it would not prevent this cut and paste attack. Neither would implementation of "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)" [RFC4474], allowing the recipient to verify the identity assertion in the From: header. However, while it might not be possible to detect the cut and paste in real-time, examination of the audit logs might provide enough information to enable events to be reconstructed. Real-time validation of the timestamp contained within PIDF-LO objects (reflecting the time at which the location was determined) is also 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. While this document focuses on the discussion of real-time determination of suspicious emergency calls, the use of audit logs may help in enforcing accountability among emergency callers. For example, in the event of a prank call, information relating to the owner of the unlinked pseudonym could be provided to investigators, enabling them to unravel the chain of events that lead to the attack. However, while auditability is an important deterrent, it is likely to be of most benefit in situations where attacks on the emergency services system are likely to be relatively infrequent, since the resources required to pursue an investigation are likely to be considerable. 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. Where attacks are frequent and continuous, automated mechanisms are required. For example, it might be valuable to develop mechanisms to exchange audit trails information in a standardized format between ISPs and PSAPs / VSPs and PSAPs or heuristics to distinguish potentially fraudulent emergency calls from real emergencies. -- -------------------------------------+------------------------------------- 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 Tue Mar 12 13:05: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 46D2421F86AF for ; Tue, 12 Mar 2013 13:05:03 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1L4J7LDPJek for ; Tue, 12 Mar 2013 13:05:01 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9B55A1F0D0B for ; Tue, 12 Mar 2013 13:04:55 -0700 (PDT) Received: from localhost ([127.0.0.1]:53003 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UFVRK-0002sd-QY; Tue, 12 Mar 2013 21:04:50 +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: Tue, 12 Mar 2013 20:04:50 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/14#comment:1 Message-ID: <080.88b7cfad15161a032210342f9747e838@trac.tools.ietf.org> References: <065.a9d5155d47366b7fa2e2b595220d3bd2@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <065.a9d5155d47366b7fa2e2b595220d3bd2@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: <20130312200455.9B55A1F0D0B@ietfa.amsl.com> Resent-Date: Tue, 12 Mar 2013 13:04:55 -0700 (PDT) Resent-From: trac+ecrit@trac.tools.ietf.org Cc: ecrit@ietf.org Subject: Re: [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: Tue, 12 Mar 2013 20:05:04 -0000 #14: Security Considerations Comment (by bernard_aboba@hotmail.com): This issue is now addressed in Section 2. The proposed text is as follows: 2. Threats While previous IETF documents have analyzed aspects of the security of emergency services or threats to geographic location privacy, those documents do not cover the threats arising from unreliable location information. A threat analysis of the emergency services system is provided in "Security Threats and Requirements for Emergency Call Marking and Mapping" [RFC5069]. RFC 5069 describes attacks on the emergency services system, such as attempting to deny system services to all users in a given area, to gain fraudulent use of services and to divert emergency calls to non-emergency sites. [RFC5069] also describes attacks against individuals, including attempts to prevent an individual from receiving aid, or to gain information about an emergency. "Threat Analysis of the Geopriv Protocol" [RFC3694] describes threats against geographic location privacy, including protocol threats, threats resulting from the storage of geographic location data, and threats posed by the abuse of information. This document focuses on threats from attackers providing false location information within emergency calls. Since we do not focus on attackers gaining control of infrastructure elements (e.g., location servers, call route servers) or the emergency services IP network, the threats are derived from the introduction of untrustworthy location information by end hosts. In addition to threats arising from the intentional forging of location information, end hosts may be induced to provide untrustworthy location information. For example, end hosts may obtain location from civilian GPS, which is vulnerable to spoofing [GPSCounter] or from third party Location Service Providers (LSPs) which may be vulnerable to attack or may not warrant the use of their services for emergency purposes. To provide a structured analysis we distinguish between three adversary models: External adversary model: The end host, e.g., an emergency caller whose location is going to be communicated, is honest and the adversary may be located between the end host and the location server or between the end host and the PSAP. None of the emergency service infrastructure elements act maliciously. Malicious infrastructure adversary model: The emergency call routing elements, such as the LIS, the LoST infrastructure, used for mapping locations to PSAP address, or call routing elements, may act maliciously. Malicious end host adversary model: The end host itself acts maliciously, whether the owner is aware of this or whether it is acting as a bot. In this document, we focus only on the malicious end host adversary model. -- -------------------------------------+------------------------------------- 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 martin.thomson@gmail.com Tue Mar 12 13:11: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 DBAA911E80E2 for ; Tue, 12 Mar 2013 13:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rlEMPpakhIR for ; Tue, 12 Mar 2013 13:11:11 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E487C11E8149 for ; Tue, 12 Mar 2013 13:10:52 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id r6so266109wey.5 for ; Tue, 12 Mar 2013 13:10:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=phkpBNgkxx2mt3zNysr1L0Ezwijdqd8cZOcKHA3oLy8=; b=ZsFdOhnzKTb86E/h48KT5jPoZ7sVAnCc4cgP7tkI1tPgzU9gZGE1BVx5o3okVDta/A GElHRL7yszSWV+NhUshlM5SmAL7iAIwCapey13t9zyfk7wcctbyCX+n+QU9WuSZvYuxT K5UF7E0+dgaYwGSkI1ISryWWGSFM0WWr8d9qaNk/OOgn67YYfl6LlDPC0XvWHQv5Hwzb MvJEQbD9cwuTuoh62/QPcUOa7p2rTiwpS2cu3H6zDHgufhjT6nk7IJMqUDnEt06k/GVQ Ijsi+ddRlTLDbG342/UjgOmSlbpfdJxil+bufVR4r4ufVBbYdwg5Qk3t0olsCiJ980MV L0cg== MIME-Version: 1.0 X-Received: by 10.180.185.43 with SMTP id ez11mr22659662wic.28.1363119044463; Tue, 12 Mar 2013 13:10:44 -0700 (PDT) Received: by 10.194.5.135 with HTTP; Tue, 12 Mar 2013 13:10:44 -0700 (PDT) In-Reply-To: <080.bfa668d96b702c5d8f393080fcbd04e2@trac.tools.ietf.org> References: <065.165eff18457d51bb8c98009f8bce2353@trac.tools.ietf.org> <080.bfa668d96b702c5d8f393080fcbd04e2@trac.tools.ietf.org> Date: Tue, 12 Mar 2013 16:10:44 -0400 Message-ID: From: Martin Thomson To: "ecrit@ietf.org Org" Content-Type: multipart/alternative; boundary=001a11c33fce6e93e704d7bfe296 Subject: Re: [Ecrit] [ecrit] #8: Solutions 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, 12 Mar 2013 20:11:12 -0000 --001a11c33fce6e93e704d7bfe296 Content-Type: text/plain; charset=UTF-8 Regarding Section 3.2: Since the intent is to validate the veracity of the location information, authentication of the PSAP is immaterial to the discussion. I fail to see how access control measures applied by the LIS would be applicable. Even if were necessary to authenticate the PSAP, a CA structure could be developed for PSAP authentication in much the same way as for signing. Similar challenges apply, of course. The current text seems to ignore this possibility. On 12 March 2013 15:59, ecrit issue tracker wrote: > #8: Solutions > --001a11c33fce6e93e704d7bfe296 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Regarding Section 3.2:

Since the intent is to= validate the veracity of the location=20 information, authentication of the PSAP is immaterial to the=20 discussion.=C2=A0 I fail to see how access control measures applied by the= =20 LIS would be applicable.

Even if were necessary to authenticate the = PSAP, a CA structure could be developed for PSAP authentication in much the= same way as for signing.=C2=A0 Similar challenges apply, of course.=C2=A0 = The current text seems to ignore this possibility.

On 12 March= 2013 15:59, ecrit issue tracker <trac+ecrit@trac.tools.ietf.= org> wrote:
#8: Solutions
--001a11c33fce6e93e704d7bfe296-- From trac+ecrit@trac.tools.ietf.org Tue Mar 12 13:52: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 188BA11E8121 for ; Tue, 12 Mar 2013 13:52:01 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYPkYUQPxJAQ for ; Tue, 12 Mar 2013 13:52:00 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 369B111E80E3 for ; Tue, 12 Mar 2013 13:51:59 -0700 (PDT) Received: from localhost ([127.0.0.1]:56056 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UFWAu-0002Xc-Kq; Tue, 12 Mar 2013 21:51:56 +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: Tue, 12 Mar 2013 20:51:56 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/8#comment:2 Message-ID: <080.0a4d6d4bdfcf141a1c6f30034c543234@trac.tools.ietf.org> References: <065.165eff18457d51bb8c98009f8bce2353@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <065.165eff18457d51bb8c98009f8bce2353@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: <20130312205200.369B111E80E3@ietfa.amsl.com> Resent-Date: Tue, 12 Mar 2013 13:51:59 -0700 (PDT) Resent-From: trac+ecrit@trac.tools.ietf.org Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #8: 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: Tue, 12 Mar 2013 20:52:01 -0000 #8: Solutions Comment (by bernard_aboba@hotmail.com): [Martin] Regarding Section 3.2: Since the intent is to validate the veracity of the location information, authentication of the PSAP is immaterial to the discussion. I fail to see how access control measures applied by the LIS would be applicable. Even if were necessary to authenticate the PSAP, a CA structure could be developed for PSAP authentication in much the same way as for signing. Similar challenges apply, of course. The current text seems to ignore this possibility. [BA] How about this? Without the introduction of hierarchy, it would be necessary for the PSAP to obtain client certificates or Digest credentials for all the LISes in its coverage area, to enable it to successfully dereference LbyRs. In situations with more than a few LISes per PSAP, this would present operational challenges. A certificate hierarchy providing PSAPs with client certificates chaining to the VESA could be used to enable the LIS to authenticate and authorize PSAPs for dereferencing. Note that unlike PIDF-LO signing (which mitigates against modification of PIDF-LOs), this merely provides the PSAP with access to a (potentially unsigned) PIDF-LO, albeit over a protected TLS channel. Another approach would be for the local LIS to upload location information to a location aggregation point who would in turn manage the relationships with the PSAP. This would shift the management burden from the PSAPs to the location aggregation points. -- -------------------------------------+------------------------------------- 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: 2.0 Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: ecrit From RMarshall@telecomsys.com Tue Mar 12 15:43: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 E0E6011E810D for ; Tue, 12 Mar 2013 15:43:33 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfOcxjtIgRx5 for ; Tue, 12 Mar 2013 15:43:33 -0700 (PDT) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6185811E8104 for ; Tue, 12 Mar 2013 15:43:33 -0700 (PDT) Received: from SEA-EXCAS-2.telecomsys.com (exc2010-local2.telecomsys.com [10.32.12.187]) by sea-mx-02.telecomsys.com (8.14.1/8.14.1) with ESMTP id r2CMhPLo018975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 12 Mar 2013 15:43:25 -0700 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; Tue, 12 Mar 2013 15:43:25 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: WGLC announce - draft-ietf-ecrit-unauthenticated-access Thread-Index: Ac4fcwFJjsaGnpNDS/K3s39bsqXsDw== Date: Tue, 12 Mar 2013 22:43:25 +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_FBD5AAFFD0978846BF6D3FAB4C892ACC2172F4SEAEXMB1telecomsy_" MIME-Version: 1.0 Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: [Ecrit] WGLC announce - draft-ietf-ecrit-unauthenticated-access 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, 12 Mar 2013 22:43:34 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC2172F4SEAEXMB1telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This starts WGLC for draft-ietf-ecrit-unauthenticated-access. The draft can be found at: https://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access Please review the draft and provide comments to the list before COB on Apri= l 3, 2013. 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_FBD5AAFFD0978846BF6D3FAB4C892ACC2172F4SEAEXMB1telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This st= arts WGLC for draft-ietf-ecrit-unauthenticated-access.

&n= bsp;

The dra= ft can be found at:

https://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access=

Please = review the draft and provide comments to the list before COB on April 3, 20= 13.

&n= bsp;

Thanks,=

&n= bsp;

Marc &a= mp; 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_FBD5AAFFD0978846BF6D3FAB4C892ACC2172F4SEAEXMB1telecomsy_-- From internet-drafts@ietf.org Wed Mar 13 11:54: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 019C121F8C1A; Wed, 13 Mar 2013 11:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UI6j+w-Jnt3s; Wed, 13 Mar 2013 11:54:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7313521F8BF2; Wed, 13 Mar 2013 11:54:51 -0700 (PDT) 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.43 Message-ID: <20130313185451.14845.3222.idtracker@ietfa.amsl.com> Date: Wed, 13 Mar 2013 11:54:51 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-trustworthy-location-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: Wed, 13 Mar 2013 18:54:52 -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 : Trustworthy Location Author(s) : Hannes Tschofenig Henning Schulzrinne Bernard Aboba Filename : draft-ietf-ecrit-trustworthy-location-05.txt Pages : 22 Date : 2013-03-13 Abstract: For some location-based applications, such as emergency calling or roadside assistance, the trustworthiness of location information is critically important. This document describes how to convey location in a manner that is inherently secure and reliable. It also provides guidelines for assessing the trustworthiness of location information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-trustworthy-location-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-trustworthy-location-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From brian.rosen@neustar.biz Thu Mar 14 11:15: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 9926311E81C3 for ; Thu, 14 Mar 2013 11:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVRPQ8okAbyt for ; Thu, 14 Mar 2013 11:15:47 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC6511E81C4 for ; Thu, 14 Mar 2013 11:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1363285137; x=1678636642; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=+MOvlaqO+j IRx+cksFE3Zwqq78cpw7CN3XXxGbrRtLA=; b=m7k57dLQLm9+hmvQ3jfcAo5aKZ w1UMm2AZKuhmBelU/W1D1pmo9ifiEku68qPoXmCQ8xQ1QYwENooVVIpcvTAQ== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.20931214; Thu, 14 Mar 2013 14:18:56 -0400 Received: from STNTEXHC11.cis.neustar.com (10.31.58.70) by STNTEXCHHT02.cis.neustar.com (10.31.13.229) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 14 Mar 2013 14:15:44 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.87]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 14:15:39 -0400 From: "Rosen, Brian" To: "ecrit@ietf.org Org" Thread-Topic: Additional Data blocks and device specific type registries Thread-Index: AQHOIN/ulsLRP/QV20e190M5zjgp2A== Date: Thu, 14 Mar 2013 18:15:39 +0000 Message-ID: <480846AD-D6DA-4082-A51A-1A96A3F6AC70@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.133.109] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: fLq8goNLyiQTXHDSs2MBFA== Content-Type: text/plain; charset="us-ascii" Content-ID: <8828903C192AE14196A6A4D3DA7C1DAE@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Ecrit] Additional Data blocks and device specific type registries 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, 14 Mar 2013 18:15:48 -0000 As I reviewed in the meeting, there are two ways to add data to additional-= data: 1. Add a type to the device/service specific data type registry, and put a = URL to it in the DevInfo block 2. Define a new type Turns out there is a problem with the IANA considerations section - the dev= ice/service specific registry wasn't there. I added it, but in doing so, I= ran across a problem: The management policy for the block registry is Expert Review and Specifica= tion required. I think we need that, at minimum, for the device/service sp= ecific type, but I also think we want more review for new blocks that for d= evice/service specific data. So, should I make the blocks registry IETF Review? We could do something more complicated which basically qualifies "Specifica= tion Required" to be some quasi-real SDO doc for the block registry, rather= than, say, some vendor proprietary doc. The latter might be okay for the = device/service specific registry. Brian= From martin.thomson@gmail.com Thu Mar 14 12:51: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 4910A11E8258 for ; Thu, 14 Mar 2013 12:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfLnKMt4pk3F for ; Thu, 14 Mar 2013 12:51:28 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDD211E8257 for ; Thu, 14 Mar 2013 12:51:28 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id e12so2016032wge.34 for ; Thu, 14 Mar 2013 12:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=Mb9rkN5UmUmcMTAir40XC915rqB6I9EKg8cXmtV3Orc=; b=pebpBTPqIUarcT79/OEGd4gfo1/ix48c+Xds9o590Zra2a31pFVc7L0pN5jIZ8Vujj QYQOXv4yKDMFs2GadcnkBdLt1B0ttn3n6pJ6MaFdbWqxw8S6cnXlwiA2N9qiMJViBkq2 SDEVB1VBHCRdolLbTASqx7V7rhmv4OsSdxxgucET5AkeOb0KukMwKGyMwCUE4Qv+gU0U hEWpgpi3Rx0IBFcvEwLaonAa6NfEds93kzYYXdSMxIfjeD4Ql+1Da7YYgCdw16MHvfZ3 4G+6r++f+z4qS7kqt+frPER2u9aPuSifrb+ZF4g9o5UcjDMC8ol1VHK1+ZhnyypctW6X lxRw== MIME-Version: 1.0 X-Received: by 10.194.22.5 with SMTP id z5mr6352578wje.5.1363290687156; Thu, 14 Mar 2013 12:51:27 -0700 (PDT) Received: by 10.194.5.135 with HTTP; Thu, 14 Mar 2013 12:51:27 -0700 (PDT) In-Reply-To: <480846AD-D6DA-4082-A51A-1A96A3F6AC70@neustar.biz> References: <480846AD-D6DA-4082-A51A-1A96A3F6AC70@neustar.biz> Date: Thu, 14 Mar 2013 15:51:27 -0400 Message-ID: From: Martin Thomson To: "Rosen, Brian" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Additional Data blocks and device specific type registries 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, 14 Mar 2013 19:51:30 -0000 Specification required seems adequate. You'd have to convince me that we have either limited space for registrations (we don't) or that there was some risk of harm in private registrations. The risk we run if we do raise the bar on this is that we effectively encourage people to extend existing blocks when a new block is the most appropriate choice. On 14 March 2013 14:15, Rosen, Brian wrote: > As I reviewed in the meeting, there are two ways to add data to additiona= l-data: > 1. Add a type to the device/service specific data type registry, and put = a URL to it in the DevInfo block > 2. Define a new type > > Turns out there is a problem with the IANA considerations section - the d= evice/service specific registry wasn't there. I added it, but in doing so,= I ran across a problem: > The management policy for the block registry is Expert Review and Specifi= cation required. I think we need that, at minimum, for the device/service = specific type, but I also think we want more review for new blocks that for= device/service specific data. > > So, should I make the blocks registry IETF Review? > > We could do something more complicated which basically qualifies "Specifi= cation Required" to be some quasi-real SDO doc for the block registry, rath= er than, say, some vendor proprietary doc. The latter might be okay for th= e device/service specific registry. > > Brian > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From brian.rosen@neustar.biz Thu Mar 14 12:56: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 9EE0D11E8258 for ; Thu, 14 Mar 2013 12:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.322 X-Spam-Level: X-Spam-Status: No, score=-6.322 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7V1j1WS7ExKL for ; Thu, 14 Mar 2013 12:56:49 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id D2A0311E8245 for ; Thu, 14 Mar 2013 12:56:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1363291450; x=1678648674; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=A211N04FCa nhemGJUzNqgCVGLq6kf2pru3TbwTGcons=; b=rekG0dmiCxVk47YTaBeD07az5z LFA8maWAr0kXoKp65wKUJP7PzWsEJAKdMt028NkD/XO0KYfUN3u4iYrKyAdg== Received: from ([10.31.13.228]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.21716808; Thu, 14 Mar 2013 16:04:09 -0400 Received: from STNTEXHC12.cis.neustar.com (10.31.58.71) by STNTEXCHHT01.cis.neustar.com (10.31.13.228) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 14 Mar 2013 15:56:44 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.87]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 15:56:41 -0400 From: "Rosen, Brian" To: Martin Thomson Thread-Topic: [Ecrit] Additional Data blocks and device specific type registries Thread-Index: AQHOIN/ulsLRP/QV20e190M5zjgp2A== Date: Thu, 14 Mar 2013 19:56:40 +0000 Message-ID: <9671BE0A-9E6F-476A-ACEC-A9B626AC3505@neustar.biz> References: <480846AD-D6DA-4082-A51A-1A96A3F6AC70@neustar.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.133.111] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMS-Proccessed: X-EMS-STAMP: KWH1ZRB/Lxa7wNJ7G4DEEw== Cc: "Rosen, Brian" , "ecrit@ietf.org Org" Subject: Re: [Ecrit] Additional Data blocks and device specific type registries 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, 14 Mar 2013 19:56:49 -0000 In the end, if we make one harder than the other, then folks who have weak = reasons will choose the easy one. The "harm" is proliferation of data type= s that PSAPs are asked to contend with. We don't want a whole lot of diffe= rent data choices. That said, it still seems to me that new blocks should have somewhat more s= crutiny than new device/service specific data. Brian On Mar 14, 2013, at 3:51 PM, Martin Thomson wrot= e: > Specification required seems adequate. You'd have to convince me that > we have either limited space for registrations (we don't) or that > there was some risk of harm in private registrations. The risk we run > if we do raise the bar on this is that we effectively encourage people > to extend existing blocks when a new block is the most appropriate > choice. >=20 > On 14 March 2013 14:15, Rosen, Brian wrote: >> As I reviewed in the meeting, there are two ways to add data to addition= al-data: >> 1. Add a type to the device/service specific data type registry, and put= a URL to it in the DevInfo block >> 2. Define a new type >>=20 >> Turns out there is a problem with the IANA considerations section - the = device/service specific registry wasn't there. I added it, but in doing so= , I ran across a problem: >> The management policy for the block registry is Expert Review and Specif= ication required. I think we need that, at minimum, for the device/service= specific type, but I also think we want more review for new blocks that fo= r device/service specific data. >>=20 >> So, should I make the blocks registry IETF Review? >>=20 >> We could do something more complicated which basically qualifies "Specif= ication Required" to be some quasi-real SDO doc for the block registry, rat= her than, say, some vendor proprietary doc. The latter might be okay for t= he device/service specific registry. >>=20 >> Brian >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit From martin.thomson@gmail.com Thu Mar 14 13:06:42 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 CBFEB11E80F2 for ; Thu, 14 Mar 2013 13:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmUVuw5QkCIw for ; Thu, 14 Mar 2013 13:06:42 -0700 (PDT) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ietfa.amsl.com (Postfix) with ESMTP id 1A03B11E80D7 for ; Thu, 14 Mar 2013 13:06:41 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id fn15so2463939wgb.20 for ; Thu, 14 Mar 2013 13:06:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=6nnWeqpagzvhVxwWhKUsh3ePj7vlkrZ02Ea6mLDuxX8=; b=fWPeBF03pd1/WitTghOt5pMdmZHH2LnFZkuQKlAjGBU7gMg3WG/z10s/seGVMlZN/u e/eX/X4OUfxOGhZk5ObubgnL9wklEnmLfUBMUywdcLPCnZaU/si2Bm4GD3oXyf1LTE5P w+XUZ2IUSYW+EJKB5JKWTA6SnKC5qui7chx7x3Cvz/gdk6iETLvr3C/n4NRjTglHRwDH XShQJgc4MaPMkr6s8AnIr195oiNtjCqse/OnuU/X7jkKiB69X2Cne8C/0Ab0MvmIhoEK WoffXMFMLV7fbL1j9Eu27ACmX/Wvkx5Wn2aGrWlBP4AdKnarmyTKOBXr2BAWHtm8IB0T Jf8Q== MIME-Version: 1.0 X-Received: by 10.194.22.5 with SMTP id z5mr6419564wje.5.1363291601327; Thu, 14 Mar 2013 13:06:41 -0700 (PDT) Received: by 10.194.5.135 with HTTP; Thu, 14 Mar 2013 13:06:41 -0700 (PDT) In-Reply-To: <9671BE0A-9E6F-476A-ACEC-A9B626AC3505@neustar.biz> References: <480846AD-D6DA-4082-A51A-1A96A3F6AC70@neustar.biz> <9671BE0A-9E6F-476A-ACEC-A9B626AC3505@neustar.biz> Date: Thu, 14 Mar 2013 16:06:41 -0400 Message-ID: From: Martin Thomson To: "Rosen, Brian" Content-Type: text/plain; charset=UTF-8 Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Additional Data blocks and device specific type registries 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, 14 Mar 2013 20:06:42 -0000 On 14 March 2013 15:56, Rosen, Brian wrote: > In the end, if we make one harder than the other, then folks who have weak reasons will choose the easy one. This is my point exactly. > The "harm" is proliferation of data types that PSAPs are asked to contend with. [...] I don't find this especially convincing. > That said, it still seems to me that new blocks should have somewhat more scrutiny than new device/service specific data. "seems" isn't strong enough for me. From my perspective, a new block can be ignored just as easily as new XML elements. They just have slight different ways of labelling (MIME media type vs. XML QName). I'd like something stronger to go on than "seems to Brian", as much as I respect the ability of your gut to discern the correct technical solution :) From randy@qti.qualcomm.com Fri Mar 15 11:37: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 513C521F8A38 for ; Fri, 15 Mar 2013 11:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.149 X-Spam-Level: X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHkO7p75eSnQ for ; Fri, 15 Mar 2013 11:37:02 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 7713821F8A04 for ; Fri, 15 Mar 2013 11:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1363372622; x=1394908622; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=zJGNYQxxBPNh3V/32jhOOOF5zdTobBh1LYAqIMPDwnY=; b=Ri7qqDz4fOcgfad2ndkKImS+4wB2jddNjgDz9lVHH+Sh+7yaNsfqjed5 otUnQwpHHWb9uZqOPQb4azl7QamQeB1zp9+6WjAE3ekonabmwfb8K5Q0G MdCAaQY9Hf3NYtEZnnS/B8JxOt62V7ZvpEGmkUl5xrzu+XRKNfKTLd0HH 4=; X-IronPort-AV: E=Sophos;i="4.84,853,1355126400"; d="scan'208";a="30082658" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 15 Mar 2013 11:37:02 -0700 X-IronPort-AV: E=Sophos;i="4.84,852,1355126400"; d="scan'208";a="417903502" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Mar 2013 11:37:02 -0700 Received: from dhcp-42ec.meeting.ietf.org (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 15 Mar 2013 11:37:01 -0700 Message-ID: In-Reply-To: <9671BE0A-9E6F-476A-ACEC-A9B626AC3505@neustar.biz> References: <480846AD-D6DA-4082-A51A-1A96A3F6AC70@neustar.biz> <9671BE0A-9E6F-476A-ACEC-A9B626AC3505@neustar.biz> <480846AD-D6DA-4082-A51A-1A96A3F6AC70@neustar.biz> <9671BE0A-9E6F-476A-ACEC-A9B626AC3505@neustar.biz> X-Mailer: Eudora for Mac OS X Date: Fri, 15 Mar 2013 11:36:58 -0700 To: Martin Thomson , "Rosen, Brian" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Additional Data blocks and device specific type registries 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 Mar 2013 18:37:03 -0000 At 3:51 PM -0400 3/14/13, Martin Thomson wrote: > Specification required seems adequate. You'd have to convince me that > we have either limited space for registrations (we don't) or that > there was some risk of harm in private registrations. The risk we run > if we do raise the bar on this is that we effectively encourage people > to extend existing blocks when a new block is the most appropriate > choice. I agree. At 7:56 PM +0000 3/14/13, Brian Rosen wrote: > In the end, if we make one harder than the other, then folks who > have weak reasons will choose the easy one. The "harm" is > proliferation of data types that PSAPs are asked to contend with. > We don't want a whole lot of different data choices. I think a worse risk is mangling or misusing blocks (by shoving data in that doesn't belong). If there are separate blocks, it becomes easier for PSAPs to accept those that are useful and they need to. > That said, it still seems to me that new blocks should have > somewhat more scrutiny than new device/service specific data. The only advantage I can see of this is that it encourages use of the device block, which implicitly forces new data to be by reference, making it easier for a PSAP to not fetch a URL. While that is advantageous, I'm not sure it's compelling enough to bias towards one rather than the other. In general, it seems to me that we've caused ourselves more trouble when we made registration harder than easier. I'd suggest 'specification required' for both, with guidance text for how to choose which way to go. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Wealth is not only money. Wealth can be happiness in your sweetheart or your honey. --(Fortune cookie) From James.Winterbottom@commscope.com Sun Mar 17 20:41:42 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 0227B21F89E1 for ; Sun, 17 Mar 2013 20:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0Sgy32Y0+FE for ; Sun, 17 Mar 2013 20:41:39 -0700 (PDT) Received: from cdcsmgw02.commscope.com (cdcsmgw02.commscope.com [198.135.207.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6C921F89D8 for ; Sun, 17 Mar 2013 20:41:39 -0700 (PDT) X-AuditID: 0a0404e9-b7f996d000000830-8a-51468cf0b53d Received: from CDCE10HC1.commscope.com ( [10.86.28.21]) by cdcsmgw02.commscope.com (Symantec Messaging Gateway) with SMTP id CF.CA.02096.0FC86415; Sun, 17 Mar 2013 22:41:36 -0500 (CDT) 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; Sun, 17 Mar 2013 22:41:36 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Mon, 18 Mar 2013 11:41:29 +0800 From: "Winterbottom, James" To: "ecrit@ietf.org" Date: Mon, 18 Mar 2013 11:41:28 +0800 Thread-Topic: draft-ietf-ecrit-additional-data-07 Thread-Index: Ac4jinj4ZbW0FFV3TRCPUKmZtTsrRg== Message-ID: <5A55A45AE77F5941B18E5457ECAC818801214088303D@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_5A55A45AE77F5941B18E5457ECAC818801214088303DSISPE7MB1co_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKKsWRmVeSWpSXmKPExsXCFSYjqvuhxy3QoO2xjUXjoqesDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKeN/5kK3gTkrFkYaN7A2MDeFdjJwcEgImEo8O/WeDsMUkLtxb D2RzcQgJ7GKUeLSwBcrZwChxauIERghnHaPEkSMfmEBa2ATsJA6vv8EMYosIqEpsOLOSEcRm AbI3750EZgsL6Ei07P7DAlFjKPF0xRtWCFtPou3mETCbVyBIYuPvR2A2I9AZ30+tAZvPLCAu cevJfCaI8wQkluw5zwxhi0q8fPwPql5U4k77ekaI+nyJp993MUHMFJQ4OfMJ2F4hAV2Jpp1f WScwisxCMnYWkpZZSFog4joSC3Z/YoOwtSWWLXzNDGOfOfCYCVl8ASP7Kkbx5JTk4tz0cgMj veT83Nzi5PyCVBBrEyMollhYXu5gPLtB+xCjAAejEg9vJ59roBBrYllxZe4hRkkOJiVR3kPt boFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHgbQoByvCmJlVWpRfkwKQ0ODoHTT+6fYpRiycvP S1WS4O3pBioTLEpNT61Iy8wBJhKYUiYOTpBRPECjykFqeIsLEnOLM9Mh8qcYtTkWXHv0gpGj efnzF4xCYOOkxHlXgJQKgJRmlObBTXvFKA70gjDvRpAsDzAtws15BbSCCWjFvitOICtKEhFS Ug2MdfLLxO1veuoYbktMvxnO9FfixuPsVeEtd265fzu/+vX8ZwW3zaet5J1+ZfHTq7WpQWV6 76/zhG2ueKL/R8A0ozD+yLxp0ou0Pk+qZFG+rHoz+PwGkcSkS24cuh9ST/50X6d1rMefbeEf HxPGsxq9Sz82GtaFpqUxXdqy0m/qqsuMpw4Uc/2PUmIpzkg01GIuKk4EAEYycvVIAwAA Subject: [Ecrit] 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: Mon, 18 Mar 2013 03:41:42 -0000 --_000_5A55A45AE77F5941B18E5457ECAC818801214088303DSISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Authors, I have reviewed this document and have the following comments, some of whic= h I have already posted to the list and have not had a reply to. Comments: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The term "Service Provider" is used extensively throughout this document bu= t the term doesn't seem to be obviously defined in the document, nor is the= re is a reference to an external definition. To add to this, Service Provid= er is a defined type in section 14.1.2, but used more generally throughout = the rest of the document. This needs a clarification. Section 6.2 seems to conflate several different concepts. I think that this= because it bundles access technologies and telephone service type, though = I suspect that it doesn't mean to, but in so doing it left me quite confuse= d and when I tried to describe a DOCSIS, Fibre or DSL service I couldn't. = Here is a proposal to address the current issues I see with this section: 1) Break up this element into two elements, one called accessTechnolog= y and then a second one looking at any higher-level application run over th= e access technology, call it applicationType or something similar. 2) Create a registry for accessTechnology at a minimum it would have w= hat is currently under the "Wireless Telephone System" field and I would ad= d: a. Twisted pair b. Coax c. Fibre 3) The other things listed are high-level services most of which are o= kay except I would change or add the following: a. Drop wireline and call it circuit-switched. This would then allow m= e to have accessTechnology=3DGSM, applicationType=3Dcircuit-switched b. Add Packet-Data As it is currently written this section really only relates to conventional= telephony providers which I didn't think was the only aim of the document. I think it would be worth emphasizing in this section that the nature of th= e physical access technology does not necessarily dictate the mobility of t= he call. In section 6.2, the definition for VoIP needs to be decoupled from the acce= ss technology constraints, these are addressed in section 6.3. Section 6.3, for Nomadic, please can you emphasize that it cannot change it= s point of network attachment. This does not necessarily mean that the devi= ce cannot move. Section 6.2 says "VoIP Telephone Service: A type of service that offers com= munication over internet protocol, such as Fixed, Nomadic, Mobile, Unknown= ". Section 6.3 does not register "Unknown" as an allowable va= lue, yet section 6.4 requires the element to be included in t= he element. I think that it needs to include a valu= e of unknown in the register. Section 8.2. This schema has a sequence with one element in it, and this el= ement is optional. This doesn't make much sense. None of the schemas have extension points. While some of the discourse on t= he list over the last few days might suggest that this was deliberate, the = discussion as I have followed it has been more to do with adding new blocks= than it has been to allowing localized extensions to already defined block= s. NITS =3D=3D=3D=3D=3D Page 5 second paragraph has a PDIF-LO rather than a PIDF-LO Cheers James --_000_5A55A45AE77F5941B18E5457ECAC818801214088303DSISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Authors,=

 

I = have reviewed this document and have the following comments, some of which = I have already posted to the list and have not had a reply to.

 

Comments:<= o:p>

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

The term “Service Pro= vider” is used extensively throughout this document but the term does= n’t seem to be obviously defined in the document, nor is there is a r= eference to an external definition. To add to this, Service Provider is a d= efined type in section 14.1.2, but used more generally throughout the rest = of the document. This needs a clarification.

 

Section 6.2 seems to conflat= e several different concepts. I think that this because it bundles access t= echnologies and telephone service type, though I suspect that it doesn̵= 7;t mean to, but in so doing it left me quite confused and when I tried to = describe a DOCSIS, Fibre or DSL service I couldn’t.  Here is a p= roposal to address the current issues I see with this section:

1)      Break up this element into two elements, one called accessTec= hnology and then a second one looking at any higher-level application run o= ver the access technology, call it applicationType or something similar.

2)<= span style=3D'font:7.0pt "Times New Roman"'>      = Create a registry for accessTechnology at a minimum= it would have what is currently under the “Wireless Telephone System= ” field and I would add:

a.      Twisted pair

= b.      Coax<= /p>

c.   &nb= sp;  Fibre

3)      The other= things listed are high-level services most of which are okay except I woul= d change or add the following:

a.      Drop wireline and call it circuit-switched. This would then allow me to ha= ve accessTechnology=3DGSM, applicationType=3Dcircuit-switched

b.    = ;  Add Packet-Data

As it is currently written this section really only relates to conv= entional telephony providers which I didn’t think was the only aim of= the document.

 

I think it would be worth emphasizing in this section that= the nature of the physical access technology does not necessarily dictate = the mobility of the call.

 

In section 6.2, the definition for VoIP needs t= o be decoupled from the access technology constraints, these are addressed = in section 6.3.

 

Section 6.3, for Nomadic, please can you emphasize that i= t cannot change its point of network attachment. This does not necessarily = mean that the device cannot move.

&= nbsp;

Section 6.2 says “VoIP Telephone = Service: A type of service that offers communication over internet protocol= , such as Fixed, Nomadic,  Mobile, Unknown”. Section 6.3 does no= t register “Unknown” as an allowable <SvcMobility> value,= yet section 6.4 requires the <SvcMobility> element to be included in= the <emergencyCall.SvcInfo> element. I think that it needs to includ= e a value of unknown in the <SvcMobility> register.

 

Section 8.2. Th= is schema has a sequence with one element in it, and this element is option= al. This doesn’t make much sense.

=  

None of the schemas have extensio= n points. While some of the discourse on the list over the last few days mi= ght suggest that this was deliberate, the discussion as I have followed it = has been more to do with adding new blocks than it has been to allowing loc= alized extensions to already defined blocks.

 

NITS

=3D=3D=3D=3D=3D

Page 5 seco= nd paragraph has a PDIF-LO rather than a PIDF-LO

 

 

Cheers

James

= --_000_5A55A45AE77F5941B18E5457ECAC818801214088303DSISPE7MB1co_-- From brian.rosen@neustar.biz Mon Mar 18 05:51: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 73B6321F8CF8 for ; Mon, 18 Mar 2013 05:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wO6CsHrdVzS for ; Mon, 18 Mar 2013 05:51:19 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8D21621F8D1C for ; Mon, 18 Mar 2013 05:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1363611523; x=1678967229; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=cDJk/9+/sR4KfAQRaCu/EtCvfkA6T3BT0qVpL0rvY5M=; b=ha8quLTHfLvq73JTnMPwOtTDXbMFngrOZfFPAA2uK12xWLqGLIAsQIZ/X+A7rP +eH51HDBROcTWFVZya4K+ESQ== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.21840273; Mon, 18 Mar 2013 08:58:42 -0400 Received: from STNTEXCHCASHT04.cis.neustar.com (10.31.15.156) by STNTEXCHHT02.cis.neustar.com (10.31.13.229) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 18 Mar 2013 08:51:15 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.56]) by STNTEXCHCASHT04.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Mon, 18 Mar 2013 08:51:09 -0400 From: "Rosen, Brian" To: "Winterbottom, James" Thread-Topic: [Ecrit] draft-ietf-ecrit-additional-data-07 Thread-Index: AQHOI9dDNRqHBNTkrku/1Eukmxb5JA== Date: Mon, 18 Mar 2013 12:51:09 +0000 Message-ID: <6C05927B-D167-46B8-829F-4FBB8A683544@neustar.biz> References: <5A55A45AE77F5941B18E5457ECAC818801214088303D@SISPE7MB1.commscope.com> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC818801214088303D@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.133.128] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 16KtVkvWdgex0/creamHxw== Content-Type: multipart/alternative; boundary="_000_6C05927BD16746B8829F4FBB8A683544neustarbiz_" MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] 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: Mon, 18 Mar 2013 12:51:20 -0000 --_000_6C05927BD16746B8829F4FBB8A683544neustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for these comments, and they were just in time, as I was about to re= lease a new version addressing your prior concerns. Unless anyone objects,= I'll make these changes. Brian On Mar 17, 2013, at 11:41 PM, "Winterbottom, James" > wrote: Hi Authors, I have reviewed this document and have the following comments, some of whic= h I have already posted to the list and have not had a reply to. Comments: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The term =93Service Provider=94 is used extensively throughout this documen= t but the term doesn=92t seem to be obviously defined in the document, nor = is there is a reference to an external definition. To add to this, Service = Provider is a defined type in section 14.1.2, but used more generally throu= ghout the rest of the document. This needs a clarification. Section 6.2 seems to conflate several different concepts. I think that this= because it bundles access technologies and telephone service type, though = I suspect that it doesn=92t mean to, but in so doing it left me quite confu= sed and when I tried to describe a DOCSIS, Fibre or DSL service I couldn=92= t. Here is a proposal to address the current issues I see with this sectio= n: 1) Break up this element into two elements, one called accessTechnolog= y and then a second one looking at any higher-level application run over th= e access technology, call it applicationType or something similar. 2) Create a registry for accessTechnology at a minimum it would have w= hat is currently under the =93Wireless Telephone System=94 field and I woul= d add: a. Twisted pair b. Coax c. Fibre 3) The other things listed are high-level services most of which are o= kay except I would change or add the following: a. Drop wireline and call it circuit-switched. This would then allow m= e to have accessTechnology=3DGSM, applicationType=3Dcircuit-switched b. Add Packet-Data As it is currently written this section really only relates to conventional= telephony providers which I didn=92t think was the only aim of the documen= t. I think it would be worth emphasizing in this section that the nature of th= e physical access technology does not necessarily dictate the mobility of t= he call. In section 6.2, the definition for VoIP needs to be decoupled from the acce= ss technology constraints, these are addressed in section 6.3. Section 6.3, for Nomadic, please can you emphasize that it cannot change it= s point of network attachment. This does not necessarily mean that the devi= ce cannot move. Section 6.2 says =93VoIP Telephone Service: A type of service that offers c= ommunication over internet protocol, such as Fixed, Nomadic, Mobile, Unkno= wn=94. Section 6.3 does not register =93Unknown=94 as an allowable value, yet section 6.4 requires the element to be inclu= ded in the element. I think that it needs to includ= e a value of unknown in the register. Section 8.2. This schema has a sequence with one element in it, and this el= ement is optional. This doesn=92t make much sense. None of the schemas have extension points. While some of the discourse on t= he list over the last few days might suggest that this was deliberate, the = discussion as I have followed it has been more to do with adding new blocks= than it has been to allowing localized extensions to already defined block= s. NITS =3D=3D=3D=3D=3D Page 5 second paragraph has a PDIF-LO rather than a PIDF-LO Cheers James _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_6C05927BD16746B8829F4FBB8A683544neustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1215661578EC464DAB8A716342B367C7@neustar.biz> Content-Transfer-Encoding: quoted-printable Thanks for these comments, and they were just in time, as I was about to re= lease a new version addressing your prior concerns.  Unless anyone obj= ects, I'll make these changes.  

Brian

On Mar 17, 2013, at 11:41 PM, "Winterbottom, James" <James.Winterbottom@commscop= e.com> wrote:

Hi Authors,
 
I have reviewed this document and have the following comments, some of whic= h I have already posted to the list and have not had a reply to.=
 
Comments:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The term =93Service Provider=94 is used extensively throughout this documen= t but the term doesn=92t seem to be obviously defined in the document, nor = is there is a reference to an external definition. To add to this, Service = Provider is a defined type in section 14.1.2, but used more generally throughout the rest of the document. This = needs a clarification.
 
Section 6.2 seems to conflate several different concepts. I think that this= because it bundles access technologies and telephone service type, though = I suspect that it doesn=92t mean to, but in so doing it left me quite confu= sed and when I tried to describe a DOCSIS, Fibre or DSL service I couldn=92t.  Here is a proposal to add= ress the current issues I see with this section:
1)     =  Break up this element into two elements, one called accessTechnology and then a second one looking at any higher-le= vel application run over the access technology, call it applicationType or = something similar.
2)     =  Create a registry for accessTechnology at a minimum it would have what is currently under the =93Wireless Telepho= ne System=94 field and I would add:
a.     =  Twisted pair
b.     =  Coax
c.     =  Fibre
3)     =  The other things listed are high-level services most of which are okay except I would change or add the following= :
a.     =  Drop wireline and call it circuit-switched. This would then allow me to have accessTechnology=3DGSM, applicationType= =3Dcircuit-switched
b.     =  Add Packet-Data
As it is currently written this section really only relates to conventional= telephony providers which I didn=92t think was the only aim of the documen= t.
 
I think it would be worth emphasizing in this section that the nature of th= e physical access technology does not necessarily dictate the mobility of t= he call.
 
In section 6.2, the definition for VoIP needs to be decoupled from the acce= ss technology constraints, these are addressed in section 6.3.
 
Section 6.3, for Nomadic, please can you emphasize that it cannot change it= s point of network attachment. This does not necessarily mean that the devi= ce cannot move.
 
Section 6.2 says =93VoIP Telephone Service: A type of service that offers c= ommunication over internet protocol, such as Fixed, Nomadic,  Mobile, = Unknown=94. Section 6.3 does not register =93Unknown=94 as an allowable <= ;SvcMobility> value, yet section 6.4 requires the <SvcMobility> element to be included in the <emergencyCall.SvcInf= o> element. I think that it needs to include a value of unknown in the &= lt;SvcMobility> register.
 
Section 8.2. This schema has a sequence with one element in it, and this el= ement is optional. This doesn=92t make much sense.
 
None of the schemas have extension points. While some of the discourse on t= he list over the last few days might suggest that this was deliberate, the = discussion as I have followed it has been more to do with adding new blocks= than it has been to allowing localized extensions to already defined blocks.
 
NITS
=3D=3D=3D=3D=3D
Page 5 second paragraph has a PDIF-LO rather than a PIDF-LO
 
 
Cheers
James
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ec= rit

--_000_6C05927BD16746B8829F4FBB8A683544neustarbiz_-- From James.Winterbottom@commscope.com Mon Mar 18 15:30:07 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 A256F21F8B45 for ; Mon, 18 Mar 2013 15:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duH-eITwXfIr for ; Mon, 18 Mar 2013 15:30:04 -0700 (PDT) Received: from cdcsmgw01.commscope.com (cdcsmgw01.commscope.com [198.135.207.232]) by ietfa.amsl.com (Postfix) with ESMTP id 38DD321F85A0 for ; Mon, 18 Mar 2013 15:30:03 -0700 (PDT) X-AuditID: 0a0404e8-b7f486d00000082e-26-5147956a8dbf Received: from CDCE10HC2.commscope.com ( [10.86.28.22]) by cdcsmgw01.commscope.com (Symantec Messaging Gateway) with SMTP id 8F.1D.02094.A6597415; Mon, 18 Mar 2013 17:30:03 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC2.commscope.com (10.86.28.22) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 18 Mar 2013 17:30:02 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 19 Mar 2013 06:29:59 +0800 From: "Winterbottom, James" To: "Rosen, Brian" Date: Tue, 19 Mar 2013 06:29:57 +0800 Thread-Topic: [Ecrit] draft-ietf-ecrit-additional-data-07 Thread-Index: AQHOI9dDNRqHBNTkrku/1Eukmxb5JJisBxGg Message-ID: <5A55A45AE77F5941B18E5457ECAC8188012140883111@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC818801214088303D@SISPE7MB1.commscope.com> <6C05927B-D167-46B8-829F-4FBB8A683544@neustar.biz> In-Reply-To: <6C05927B-D167-46B8-829F-4FBB8A683544@neustar.biz> 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_5A55A45AE77F5941B18E5457ECAC8188012140883111SISPE7MB1co_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCKsWRmVeSWpSXmKPExsXCFSYjpps91T3Q4M4xVotpJy8zWzQuesrq wOSxZMlPJo8dDc+ZA5iiuGxSUnMyy1KL9O0SuDJ+r2xlL/i+iLFiy7ZW1gbGyRMZuxg5OSQE TCT+3X/NAmGLSVy4t56ti5GLQ0hgF6PEvNtzoJwNjBIfZu1ghXDWM0pMu7OHGaSFTcBO4vD6 G2C2iICORN+022A2s4CqxLnGx2BjWYDsLzMPgMWFBSwkXi65xgRRbylxdfZ9oA0cQLaRRNdX EZAwr0CQxMulvewQu9oZJS5s6mACqeEUsJfY/bcWpIYR6NLvp9YwQawSl7j1ZD4TxAcCEkv2 nGeGsEUlXj7+xwpRLypxp309I0R9vkTn4ceMELsEJU7OfAJ2ppCArkTTzq+sExjFZyEZOwtJ yywkLRBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0Vo3hySnJxbnq5gaFecn5ubnFyfkEq iLWJERSpLCwvdjCe3qB9iFGAg1GJh/dEsHugEGtiWXFl7iFGSQ4mJVHe/5OBQnxJ+SmVGYnF GfFFpTmpxYcYJTiYlUR4g/2BcrwpiZVVqUX5MCkNDg6B00/un2KUYsnLz0tVkuANmwJUJliU mp5akZaZA0xTMKVMHJwgo3iARuWA1PAWFyTmFmemQ+RPMWpzLLj26AUjR/Py5y8YhcDGSYnz JoGUCoCUZpTmwU17xSgO9IIwbyNIlgeYdOHmvAJawQS04sZ+N5AVJYkIKakGxsUCV1+eKBGM PL57vWHzwb8nNgXr6LTvmih7oMg1bqVu8/dujmVH4ruF9l/WVJN+s6Dk/L3jV6KarbodJrz5 URia4Np7s+1LxfKATqN27SUTdVhn7cyW8LFWkuDedp7Vo/rpsfnfLF5+OLHkqLzeM/XFNpMP iH26vbRFVepqtpVFwH6OqXG1ykosxRmJhlrMRcWJAGrFkbp3AwAA Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] 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: Mon, 18 Mar 2013 22:30:07 -0000 --_000_5A55A45AE77F5941B18E5457ECAC8188012140883111SISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brian, Thanks for the fast response. one more quick thing in section 6.4, the schema for the emergencyCall.SvcIn= fo. There is an element in the sequence called but it isn't clear wh= at one would use this for since it isn't defined like the other elements ar= e. Also, increasingly we are seeing single number services, that is my mobile = and home phone can have the same number. If this data is statically maintai= ned against my TN then I might want to have multiple emergencyCall.SvcInfo = blocks. Is this allowed? Cheers James From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Monday, 18 March 2013 11:51 PM To: Winterbottom, James Cc: ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-07 Thanks for these comments, and they were just in time, as I was about to re= lease a new version addressing your prior concerns. Unless anyone objects,= I'll make these changes. Brian On Mar 17, 2013, at 11:41 PM, "Winterbottom, James" > wrote: Hi Authors, I have reviewed this document and have the following comments, some of whic= h I have already posted to the list and have not had a reply to. Comments: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The term "Service Provider" is used extensively throughout this document bu= t the term doesn't seem to be obviously defined in the document, nor is the= re is a reference to an external definition. To add to this, Service Provid= er is a defined type in section 14.1.2, but used more generally throughout = the rest of the document. This needs a clarification. Section 6.2 seems to conflate several different concepts. I think that this= because it bundles access technologies and telephone service type, though = I suspect that it doesn't mean to, but in so doing it left me quite confuse= d and when I tried to describe a DOCSIS, Fibre or DSL service I couldn't. = Here is a proposal to address the current issues I see with this section: 1) Break up this element into two elements, one called accessTechnolog= y and then a second one looking at any higher-level application run over th= e access technology, call it applicationType or something similar. 2) Create a registry for accessTechnology at a minimum it would have w= hat is currently under the "Wireless Telephone System" field and I would ad= d: a. Twisted pair b. Coax c. Fibre 3) The other things listed are high-level services most of which are o= kay except I would change or add the following: a. Drop wireline and call it circuit-switched. This would then allow m= e to have accessTechnology=3DGSM, applicationType=3Dcircuit-switched b. Add Packet-Data As it is currently written this section really only relates to conventional= telephony providers which I didn't think was the only aim of the document. I think it would be worth emphasizing in this section that the nature of th= e physical access technology does not necessarily dictate the mobility of t= he call. In section 6.2, the definition for VoIP needs to be decoupled from the acce= ss technology constraints, these are addressed in section 6.3. Section 6.3, for Nomadic, please can you emphasize that it cannot change it= s point of network attachment. This does not necessarily mean that the devi= ce cannot move. Section 6.2 says "VoIP Telephone Service: A type of service that offers com= munication over internet protocol, such as Fixed, Nomadic, Mobile, Unknown= ". Section 6.3 does not register "Unknown" as an allowable va= lue, yet section 6.4 requires the element to be included in t= he element. I think that it needs to include a valu= e of unknown in the register. Section 8.2. This schema has a sequence with one element in it, and this el= ement is optional. This doesn't make much sense. None of the schemas have extension points. While some of the discourse on t= he list over the last few days might suggest that this was deliberate, the = discussion as I have followed it has been more to do with adding new blocks= than it has been to allowing localized extensions to already defined block= s. NITS =3D=3D=3D=3D=3D Page 5 second paragraph has a PDIF-LO rather than a PIDF-LO Cheers James _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_5A55A45AE77F5941B18E5457ECAC8188012140883111SISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Brian,=

 <= /p>

Thanks for the fast response.

one more quick thing in section 6.4, the= schema for the emergencyCall.SvcInfo. There is an element in the sequence = called <Link> but it isn’t clear what one would use this for si= nce it isn’t defined like the other elements are.

 

Also, increasingly we are seeing single number services, that is= my mobile and home phone can have the same number. If this data is statica= lly maintained against my TN then I might want to have multiple emergencyCa= ll.SvcInfo blocks. Is this allowed?

 

Cheers

James

=

 

From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]
Se= nt: Monday, 18 March 2013 11:51 PM
To: Winterbottom, JamesCc: ecrit@ietf.org
Subject: Re: [Ecrit] draft-ietf-ecrit-= additional-data-07

 

Thanks for these comments, and they= were just in time, as I was about to release a new version addressing your= prior concerns.  Unless anyone objects, I'll make these changes. &nbs= p;

 

Brian

<= o:p> 

On Mar 17, 2013, at 11:4= 1 PM, "Winterbottom, James" <James.Winterbottom@commscope.com> wrote:



Hi Authors,

 =

I have reviewed this document and= have the following comments, some of which I have already posted to the li= st and have not had a reply to.

 

Comments:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

The term R= 20;Service Provider” is used extensively throughout this document but= the term doesn’t seem to be obviously defined in the document, nor i= s there is a reference to an external definition. To add to this, Service P= rovider is a defined type in section 14.1.2, but used more generally throug= hout the rest of the document. This needs a clarification.

 

Section 6.2 seems to conflate several different concepts. I think t= hat this because it bundles access technologies and telephone service type,= though I suspect that it doesn’t mean to, but in so doing it left me= quite confused and when I tried to describe a DOCSIS, Fibre or DSL service= I couldn’t.  Here is a proposal to address the current issues I= see with this section:

1)      Break up this element into two elements, one calle= d accessTechnology and then a second one looking at any higher-level applic= ation run over the access technology, call it applicationType or something = similar.

2)     &nbs= p;Create a registry for accessTechnology at a minimum it would have = what is currently under the “Wireless Telephone System” field a= nd I would add:

a.      Twisted pair

b.      Coax

c.      Fibre

3)      The other things listed are high-le= vel services most of which are okay except I would change or add the follow= ing:

a.      <= /span>Drop wireline and call it circuit-switched. This would then allow me = to have accessTechnology=3DGSM, applicationType=3Dcircuit-switched

b.  =     <= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Add Pack= et-Data

As it is currently wr= itten this section really only relates to conventional telephony providers = which I didn’t think was the only aim of the document.

 

I think it would be worth emphasizing in this section that the na= ture of the physical access technology does not necessarily dictate the mob= ility of the call.

 

In section 6.2, the definition f= or VoIP needs to be decoupled from the access technology constraints, these= are addressed in section 6.3.

 

Section 6.3, for N= omadic, please can you emphasize that it cannot change its point of network= attachment. This does not necessarily mean that the device cannot move.

 

Section 6.2 says “VoIP Telephone Service: A typ= e of service that offers communication over internet protocol, such as Fixe= d, Nomadic,  Mobile, Unknown”. Section 6.3 does not register = 220;Unknown” as an allowable <SvcMobility> value, yet section 6= .4 requires the <SvcMobility> element to be included in the <emerg= encyCall.SvcInfo> element. I think that it needs to include a value of u= nknown in the <SvcMobility> register.

 

= Section= 8.2. This schema has a sequence with one element in it, and this element i= s optional. This doesn’t make much sense.

=

 

Non= e of the schemas have extension points. While some of the discourse on the = list over the last few days might suggest that this was deliberate, the dis= cussion as I have followed it has been more to do with adding new blocks th= an it has been to allowing localized extensions to already defined blocks.<= o:p>

 

<= /div>

NITS

= =3D=3D=3D=3D=3D

Page 5 second= paragraph has a PDIF-LO rather than a PIDF-LO

<= div>

 

&nbs= p;

Cheers

James

_______________________________________________
Ecrit mailing list
<= a href=3D"mailto:Ecrit@ietf.org">Ecrit@ietf.or= g
https://www.ietf.org/mailman/listinfo/ecrit

 

= --_000_5A55A45AE77F5941B18E5457ECAC8188012140883111SISPE7MB1co_-- From christer.holmberg@ericsson.com Tue Mar 19 04:51: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 82D4B21F8920 for ; Tue, 19 Mar 2013 04:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOlV6D0Zn1TQ for ; Tue, 19 Mar 2013 04:51:48 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B8F0521F8622 for ; Tue, 19 Mar 2013 04:51:47 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-ba-51485152492c Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F3.CF.10459.25158415; Tue, 19 Mar 2013 12:51:46 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 12:51:46 +0100 From: Christer Holmberg To: "ecrit@ietf.org" Thread-Topic: Draft new version: draft-holmberg-ecrit-country-emg-urn-02 Thread-Index: Ac4kl4t7Ipdi9+ssQmWcZsIdCoePbw== Date: Tue, 19 Mar 2013 11:51:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B12C63C@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_7594FB04B1934943A5C02806D1A2204B12C63CESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+JvjW5QoEegwa9ryhaNi56yOjB6LFny kymAMYrLJiU1J7MstUjfLoEro+HCMeaCHXIVp7+9Z2xgvCDVxcjJISFgInFpz1V2CFtM4sK9 9WxdjFwcQgKHGCVOnpjFDuEsZpSYs6ODsYuRg4NNwEKi+582SIOIgKrEhjMrwcLCAs4Si6cm QYQ9JE7e/c4GYetJtG2ewQhiswCVH/o1mQXE5hXwlrh/dAeYzQi09/upNUwgNrOAuMStJ/OZ IO4RkFiy5zwzhC0q8fLxP1YIW1Hi6vTlUPX5EvN3tTNDzBSUODnzCcsERqFZSEbNQlI2C0kZ RFxHYsHuT2wQtrbEsoWvmWHsMwceMyGLL2BkX8XInpuYmZNebriJERj0B7f81t3BeOqcyCFG aQ4WJXHeMNcLAUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYp+pWbU6c8/F8+LK4th+7wsxT mkPUeaetffAv5/+xHfo2/gs+P1wcfH7Vn8ilZktWG9yr/3rISEz1H/+ano/HLpr8DC2rci7b suPpMaV4kfzTRyX1HDdMvHD46SP2zOSGvfftS74fuXN8oubum69nSQp69JRf5ND5s3qDbOjr yp8LDSYcCf5yJ02JpTgj0VCLuag4EQAz2MCtSAIAAA== Subject: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-02 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 Mar 2013 11:51:49 -0000 --_000_7594FB04B1934943A5C02806D1A2204B12C63CESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the Orlando decision to move forward with the relax-the-5031-regis= tration-policy alternative for allowing emg URNs for services offered in on= e country only, I've submitted an "official" new version (-02) of draft-hol= mberg-ecrit-country-emg-urn. Aside from some minor changes caused by the ne= w version of xml2rfc, the draft is identical to the pre-02 version I distri= buted before the meeting. As was indicated in the meeting, additional text will still be needed, but = once the Orlando decision is verified on the list I hope we can adopt the d= raft as base for the work. Thanks to everyone who provided comments during the meeting! Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B12C63CESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Based on the Orlando decision to move forward with t= he relax-the-5031-registration-policy alternative for allowing emg URNs for= services offered in one country only, I’ve submitted an “offic= ial” new version (-02) of draft-holmberg-ecrit-country-emg-urn. Aside from some minor changes caused by the new version of xml2rfc, the dr= aft is identical to the pre-02 version I distributed before the meeting.

 

As was indicated in the meeting, additional text wil= l still be needed, but once the Orlando decision is verified on the list I = hope we can adopt the draft as base for the work.

 

Thanks to everyone who provided comments during the = meeting!

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B12C63CESESSMB209ericsso_-- From prvs=87900d2025=jbakker@blackberry.com Tue Mar 19 08:12:17 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 6610E21F8D35 for ; Tue, 19 Mar 2013 08:12:17 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XB83uW3ibk5A for ; Tue, 19 Mar 2013 08:12:15 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 75D7521F8D20 for ; Tue, 19 Mar 2013 08:12:06 -0700 (PDT) X-AuditID: 0a412830-b7ef86d00000339d-2b-5148803e251a Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 08.EF.13213.E3088415; Tue, 19 Mar 2013 10:11:58 -0500 (CDT) 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 Mar 2013 10:11:58 -0500 From: John-Luc Bakker To: Christer Holmberg , "ecrit@ietf.org" Thread-Topic: Draft new version: draft-holmberg-ecrit-country-emg-urn-02 Thread-Index: Ac4kl4t7Ipdi9+ssQmWcZsIdCoePbwAG1qSA Date: Tue, 19 Mar 2013 15:11:57 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA35D24AAE@XMB103ADS.rim.net> References: <7594FB04B1934943A5C02806D1A2204B12C63C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B12C63C@ESESSMB209.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.251] Content-Type: multipart/alternative; boundary="_000_155970D1DA8E174F9E46039E10E2AA35D24AAEXMB103ADSrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBKsWRmVeSWpSXmKPExsXC5ZyvpWvf4BFo8E/V4sLMw4wWjYuesjow efz6epXNY8mSn0wBTFENjDZJiSVlwZnpefp2Nol5efkliSWpCimpxcm2Sj6p6Yk5CgFFmWWJ yZUKLpnFyTmJmbmpRUoKmSm2SiZKCgU5icmpual5JbZKiQUFqXkpSnZcChjABqgsM08hNS85 PyUzL91WyTPYX9fCwtRS11DJTjehkyfj8qytbAUf3St+9W9jbmCcZ9/FyMkhIWAi0f3sLhOE LSZx4d56ti5GLg4hgTYmiVN7/jFCOFsZJQ79/s4MUsUmoCexYvIqRhBbRCBa4ujVbWDdwgLu ElufdbBDxD0kTt79zgZhG0k8PvyeBcRmEVCVON/8CayeV8BNovfqTLA5QgLeEmc2dILVcAr4 SKxYvgisl1FAVmL32etg9cwC4hK3nsyHulRAYsme88wQtqjEy8f/WCFsRYkZe+YD2RxA9bkS u+/UQ6wSlDg58wnLBEaRWUgmzUKomoWkCqJER2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/F KJibUWxgZpicl6xXlJmrl5dasokRlDocNQx2ML5/b3GIUYCDUYmH93y+R6AQa2JZcWXuIUYJ DmYlEd4rOUAh3pTEyqrUovz4otKc1OJDjEHAsJrILMWdnA9Ma3kl8cYGBkRylMR5yzSdAoUE 0oFJLDs1tSC1CGYoEwcnyFIuKZFiYCpKLUosLcmIByXM+GJgypRqYMxVnPmA+e3ivRcnCOuu 6MgNi9CLeZNoZmTy3rl6khDL9hpxvmmrUluaLFlsD+by9M+xFNcLU1jN8mtxlU5cZN9S3pi8 8w5Jbh9bNzpySy9sNGny6toT9Orc6n3LnrWGZzqUOrBl/VBIDFpZyzf5z6XCok+e1gqzTx+7 1Pg6/pJ4XmWAWtcxJZbijERDLeai4kQA1XDi9msDAAA= Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-02 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 Mar 2013 15:12:17 -0000 --_000_155970D1DA8E174F9E46039E10E2AA35D24AAEXMB103ADSrimnet_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Hi Christer, Thanks for this. When a new URN is adopted via expert review, a description of the caller exp= ectation in terms of services rendered (for the new URN) cannot be found in= RFC 5031. For example, for the existing URN urn:service:sos.mountain, the RFC includes= : The 'mountain' service refers to mountain rescue services (i.e., search and rescue activities that occur in a mountainous environment), although the term is sometimes also used to apply to search and rescue in other wilderness environments. Will the caller expectation in terms of services rendered be documented some= where? Apologies if this query was already addressed during the ECRIT session ... Kind regards, JL From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Ch= rister Holmberg Sent: Tuesday, March 19, 2013 6:52 AM To: ecrit@ietf.org Subject: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-02 Hi, Based on the Orlando decision to move forward with the relax-the-5031-regist= ration-policy alternative for allowing emg URNs for services offered in one= country only, I've submitted an "official" new version (-02) of draft-holmb= erg-ecrit-country-emg-urn. Aside from some minor changes caused by the new v= ersion of xml2rfc, the draft is identical to the pre-02 version I distribute= d before the meeting. As was indicated in the meeting, additional text will still be needed, but o= nce the Orlando decision is verified on the list I hope we can adopt the dra= ft as base for the work. Thanks to everyone who provided comments during the meeting! Regards, Christer --------------------------------------------------------------------- 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_155970D1DA8E174F9E46039E10E2AA35D24AAEXMB103ADSrimnet_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Hi Christer,=

 

Thanks for this.

When a new URN is adopt= ed via expert review, a description of the caller expectation in terms of se= rvices rendered (for the new URN) cannot be found in RFC 5031.

 

For example, for the ex= isting URN urn:service:sos.mountain, t= he RFC includes:

 

  =    The 'mountain' service refers to mountain

  =     rescue services (i.e., search and rescue activities that= occur in

  =     a mountainous environment), although the term is sometime= s also

  =     used to apply to search and rescue in other wilderness

  =     environments.

 

Will the caller expecta= tion in terms of services rendered be documented somewhere?

Apologies if this query= was already addressed during the ECRIT session …

 

Kind regards,

 

    = ;           JL<= /span>

 

From: ecrit-bounc= es@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Tuesday, March 19, 2013 6:52 AM
To: ecrit@ietf.org
Subject: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-= urn-02

 

Hi,

 

Based on the Orlando decision to move forward with th= e relax-the-5031-registration-policy alternative for allowing emg URNs for s= ervices offered in one country only, I’ve submitted an “official= ” new version (-02) of draft-holmberg-ecrit-country-emg-urn. Aside from some minor changes caused by the new version of xml2rfc, the dra= ft is identical to the pre-02 version I distributed before the meeting.=

 

As was indicated in the meeting, additional text will= still be needed, but once the Orlando decision is verified on the list I ho= pe we can adopt the draft as base for the work.

 

Thanks to everyone who provided comments during the m= eeting!

 

Regards,

 

Christer

---------------------------------------------------------------------
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_155970D1DA8E174F9E46039E10E2AA35D24AAEXMB103ADSrimnet_-- From pkyzivat@alum.mit.edu Tue Mar 19 08:54: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 86F7321F85ED for ; Tue, 19 Mar 2013 08:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.237 X-Spam-Level: X-Spam-Status: No, score=-0.237 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qp8YN97VUFNT for ; Tue, 19 Mar 2013 08:54:29 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id BBAA821F8B3B for ; Tue, 19 Mar 2013 08:54:28 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta03.westchester.pa.mail.comcast.net with comcast id DPED1l0050cZkys53TuUid; Tue, 19 Mar 2013 15:54:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id DTuT1l01D3ZTu2S3WTuUpu; Tue, 19 Mar 2013 15:54:28 +0000 Message-ID: <51488A33.10405@alum.mit.edu> Date: Tue, 19 Mar 2013 23:54:27 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: ecrit@ietf.org References: <7594FB04B1934943A5C02806D1A2204B12C63C@ESESSMB209.ericsson.se> <155970D1DA8E174F9E46039E10E2AA35D24AAE@XMB103ADS.rim.net> In-Reply-To: <155970D1DA8E174F9E46039E10E2AA35D24AAE@XMB103ADS.rim.net> 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=1363708468; bh=GRpEK5Eegk7ALTrLiDGLuefu0pFVjMEBKJbFSG/R8vY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=URZWs6zaDpKyAfc3Iwrb4jRmxgY0tAqVTcXV+CNlGu5KA9tQxcq0P6eS+UYr6xtAK XlgX2axZ6bAKgZ3yvSa5Xi/V30MwdIw4wbXuvbPdQL96Dv/VTgwrbi0o+va2cpoclI Tdj6wQF1B2dVA54g0GNnD9PVQWetaDs5XzbmBqjojG/9ReLGyKRu4YM49mVFi4b5sa KEFCdhp7PxcB0mOBxIoT5aSvEPDcECaFllFGY4WwRPpi3e8gkYMdS9Q+DpDS70aGuV 2sntNlpm8AUFaf0VuBox8JM3XimIoIWTzlot+l2HooBcqN3jt+nKW+dmlRfx+iUNB9 dUKjPiY0EurYA== Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-02 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 Mar 2013 15:54:30 -0000 This is a good question. It appears that the answer is NO. :-( The current registry only has the service name, a few words of descrption, and a reference. The expert review for new registrations doesn't seem to require a document, so there may not be anything to reference for new registrations. There seem to be a couple of possibilities: Change to require a specification, and provide instructions for IANA to reference it. OR, change the registration template to require a longer description of the service, and change the IANA table to include it. Thanks, Paul On 3/19/13 11:11 PM, John-Luc Bakker wrote: > Hi Christer, > > Thanks for this. > > When a new URN is adopted via expert review, a description of the caller > expectation in terms of services rendered (for the new URN) cannot be > found in RFC 5031. > > For example, for the existing URN urn:service:sos.mountain, the RFC > includes: > > The 'mountain' service refers to mountain > > rescue services (i.e., search and rescue activities that occur in > > a mountainous environment), although the term is sometimes also > > used to apply to search and rescue in other wilderness > > environments. > > Will the caller expectation in terms of services rendered be documented > somewhere? > > Apologies if this query was already addressed during the ECRIT session … > > Kind regards, > > JL > > *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behalf > Of *Christer Holmberg > *Sent:* Tuesday, March 19, 2013 6:52 AM > *To:* ecrit@ietf.org > *Subject:* [Ecrit] Draft new version: > draft-holmberg-ecrit-country-emg-urn-02 > > Hi, > > Based on the Orlando decision to move forward with the > relax-the-5031-registration-policy alternative for allowing emg URNs for > services offered in one country only, I’ve submitted an “official” new > version (-02) of draft-holmberg-ecrit-country-emg-urn. Aside from some > minor changes caused by the new version of xml2rfc, the draft is > identical to the pre-02 version I distributed before the meeting. > > As was indicated in the meeting, additional text will still be needed, > but once the Orlando decision is verified on the list I hope we can > adopt the draft as base for the work. > > Thanks to everyone who provided comments during the meeting! > > Regards, > > Christer > > --------------------------------------------------------------------- > 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 your system. Use, dissemination, distribution, or > reproduction of this transmission by unintended recipients is not > authorized and may be unlawful. > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From ivo.sedlacek@ericsson.com Tue Mar 19 09:02: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 2676721F8D1C for ; Tue, 19 Mar 2013 09:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtYUeBuf800h for ; Tue, 19 Mar 2013 09:02:13 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id DB61621F8EED for ; Tue, 19 Mar 2013 09:02:09 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-46-51488bfdffb2 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 24.6D.19728.DFB88415; Tue, 19 Mar 2013 17:02:05 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.208]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 17:02:04 +0100 From: Ivo Sedlacek To: John-Luc Bakker , Christer Holmberg , "ecrit@ietf.org" Thread-Topic: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-02 Thread-Index: Ac4kl4t7Ipdi9+ssQmWcZsIdCoePbwAG1qSAAAG4UeA= Date: Tue, 19 Mar 2013 16:02:04 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061010A7A26@ESESSMB301.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B12C63C@ESESSMB209.ericsson.se> <155970D1DA8E174F9E46039E10E2AA35D24AAE@XMB103ADS.rim.net> In-Reply-To: <155970D1DA8E174F9E46039E10E2AA35D24AAE@XMB103ADS.rim.net> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B310790061010A7A26ESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvje7fbo9Ag+dfJCwaFz1ltWhYcYLR gcljVsNado8lS34yBTBFcdmkpOZklqUW6dslcGUceHqAueDVdMaKP1/PMDUwvmpj7GLk4JAQ MJFYd7mii5ETyBSTuHBvPVsXIxeHkMAhRoktD5qYIZwljBKzdr1hBaliE9CTmLjlCJgtItDK KDHndjaILSwQKLG9awUbyFARgSCJ+w/UIEqsJP49f8QCEmYRUJWYdk0WJMwr4C3xb/V7Fojx HYwS0x/+BGvlFHCX+HZeCKSGUUBW4uqfXkYQm1lAXOLWk/lMEHcKSCzZc54ZwhaVePn4HyuE rSjR/rQBqj5f4vzcdmaIXYISJ2c+YZnAKDILyahZSMpmISmDiOtJPDs1C8rWlli28DUzhK0r cenhOlZk8QWM7KsY2XMTM3PSy402MQJj5+CW36o7GO+cEznEKM3BoiTOG+56IUBIID2xJDU7 NbUgtSi+qDQntfgQIxMHp1QDo2JHrOnE0uln3HaeYb4p4qJ27ZQbl/v8bwFbGxtlp8VrB0+K 1D0Z3eorv4Ll8ju35W6Ttu1VX78pnL2oLShQerW81/oHm+szHvY8+R8eFr/DPfPxUslio57H 01tmK1tsPXAtm3//SYOf09of/D02ocEyfd5Ej2R+C6agk4K7G3Rqjr1YObfNW4mlOCPRUIu5 qDgRALs1aqprAgAA Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-02 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 Mar 2013 16:02:16 -0000 --_000_39B5E4D390E9BD4890E2B310790061010A7A26ESESSMB301ericsso_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hello, > Will the caller expectation in terms of services rendered be documented s= omewhere? The new policy proposed in draft-holmberg-ecrit-country-emg-urn-02 section = 5.3 states: 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. I.e. in the expert review, the service description and the URN are reviewed= . If approved, the service description and URN are listed in IANA - see htt= p://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-labels.xml#= urn-serviceid-labels-2 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-bounces@ietf.org] On Behalf Of J= ohn-Luc Bakker Sent: 19. b=F8ezna 2013 16:12 To: Christer Holmberg; ecrit@ietf.org Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-ur= n-02 Hi Christer, Thanks for this. When a new URN is adopted via expert review, a description of the caller ex= pectation in terms of services rendered (for the new URN) cannot be found i= n RFC 5031. For example, for the existing URN urn:service:sos.mountain, the RFC include= s: The 'mountain' service refers to mountain rescue services (i.e., search and rescue activities that occur in a mountainous environment), although the term is sometimes also used to apply to search and rescue in other wilderness environments. Will the caller expectation in terms of services rendered be documented som= ewhere? Apologies if this query was already addressed during the ECRIT session ... Kind regards, JL From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Christer Holmberg Sent: Tuesday, March 19, 2013 6:52 AM To: ecrit@ietf.org Subject: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-02 Hi, Based on the Orlando decision to move forward with the relax-the-5031-regis= tration-policy alternative for allowing emg URNs for services offered in on= e country only, I've submitted an "official" new version (-02) of draft-hol= mberg-ecrit-country-emg-urn. Aside from some minor changes caused by the ne= w version of xml2rfc, the draft is identical to the pre-02 version I distri= buted before the meeting. As was indicated in the meeting, additional text will still be needed, but = once the Orlando decision is verified on the list I hope we can adopt the d= raft as base for the work. Thanks to everyone who provided comments during the meeting! Regards, Christer --------------------------------------------------------------------- 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_39B5E4D390E9BD4890E2B310790061010A7A26ESESSMB301ericsso_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hello,

 

> Will the caller expectation in terms o= f services rendered be documented somewhere?

 

The new policy proposed in = draft-holmberg-ecrit-country-emg-urn-02 section 5.3 states:

 

   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 their ab= sence, the IESG.  The

   expert review should only approve services that have emergency

   nature, that are offered in at least one coun= try, 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 'so= s' service is not meant to

   invoke general government, public information= , counseling, or social

   services.

 

I.e. in the expert review, = the service description and the URN are reviewed. If approved, the service = description and URN are listed in IANA - see http://www.iana.org/assignment= s/urn-serviceid-labels/urn-serviceid-labels.xml#urn-serviceid-labels-2=

 

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: ecrit-bo= unces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of John-Luc Bakker
Sent: 19. b=F8ezna 2013 16:12
To: Christer Holmberg; ecrit@ietf.org
Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country= -emg-urn-02

 

Hi Christer,

 

Thanks for this.<= /o:p>

When a new URN is adop= ted via expert review, a description of the caller expectation in terms of = services rendered (for the new URN) cannot be found in RFC 5031.=

 

For example, for the e= xisting URN urn:service:sos.mountain,= the RFC includes:

 

  = ;    The 'mountain' service refers to mountain

  = ;    rescue services (i.e., search and rescue activities tha= t occur in

  = ;    a mountainous environment), although the term is someti= mes also

  = ;    used to apply to search and rescue in other wilderness<= o:p>

  = ;    environments.

 

Will the caller expect= ation in terms of services rendered be documented somewhere?

Apologies if this quer= y was already addressed during the ECRIT session …<= /p>

 

Kind regards,

 

   &nbs= p;           JL

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Tuesday, March 19, 2013 6:52 AM
To: ecrit@ietf.org
Subject: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg= -urn-02

 

Hi,

 

Based on the Orlando decision to move forward with t= he relax-the-5031-registration-policy alternative for allowing emg URNs for= services offered in one country only, I’ve submitted an “offic= ial” new version (-02) of draft-holmberg-ecrit-country-emg-urn. Aside from some minor changes caused by the new version of xml2rfc, the dr= aft is identical to the pre-02 version I distributed before the meeting.

 

As was indicated in the meeting, additional text wil= l still be needed, but once the Orlando decision is verified on the list I = hope we can adopt the draft as base for the work.

 

Thanks to everyone who provided comments during the = meeting!

 

Regards,

 

Christer

------------------------------------= ---------------------------------
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_39B5E4D390E9BD4890E2B310790061010A7A26ESESSMB301ericsso_-- From mlinsner@cisco.com Tue Mar 19 09:33: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 0AC0F21F8F1F for ; Tue, 19 Mar 2013 09:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.203 X-Spam-Level: X-Spam-Status: No, score=-9.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4ADU1eST2gP for ; Tue, 19 Mar 2013 09:33:26 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 58E7321F8EDE for ; Tue, 19 Mar 2013 09:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3050; q=dns/txt; s=iport; t=1363710806; x=1364920406; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=mlSgz7hXrDBGwqAW+/ozJTpANyTLGGsOH/pYiOTtehA=; b=B8USF89oXp1nQSd1XukiIz2xZGyW4tCuPQZ87+ex0oZfHC+BWPCgvm/e HzQn+JsBTqUYMtTRbio2k4UFZq1pFSPe9TWMPyKIUPk/TshaKsUGph78v dSjZbpRimKE5D1PtHA1ssJquatGuGUWcQ0g4YENtiblDn0/uT/mCjI3xN A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FABmTSFGtJV2b/2dsb2JhbABDhQnAEnNnFnSCJAEBAQQMMAEuDgwHCBEDAQJ1BwEBBQMGDgUJiAsMsiqBUo5LjU6BNQsHBoM6A5ZfgR+EXosFgyYggTc X-IronPort-AV: E=Sophos;i="4.84,872,1355097600"; d="scan'208";a="189145068" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 19 Mar 2013 16:33:02 +0000 Received: from [10.116.195.116] (rtp-mlinsner-8713.cisco.com [10.116.195.116]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2JGX0Hd003830; Tue, 19 Mar 2013 16:33:01 GMT User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Tue, 19 Mar 2013 12:32:59 -0400 From: Marc Linsner To: "Rosen, Brian" Message-ID: Thread-Topic: [IANA #658921] General Request for Assignment (urn-serviceid-labels) In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable Cc: "ecrit@ietf.org" Subject: [Ecrit] FW: [IANA #658921] General Request for Assignment (urn-serviceid-labels) 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 Mar 2013 16:33:28 -0000 Brian, Would you please provide a review of this IANA request for registrations. Thanks, Marc & Roger -----Original Message----- From: Amanda Baber via RT Reply-To: Date: Friday, February 15, 2013 6:34 PM Cc: Subject: [IANA #658921] General Request for Assignment (urn-serviceid-labels) Resent-From: Resent-To: , Resent-Date: Fri, 15 Feb 2013 23:22:12 +0000 >Dear Marc and Roger, > >IANA just received a request for two registrations in the 'sos' >Sub-Services registry at >http://www.iana.org/assignments/urn-serviceid-labels, which has the ECRIT >working group listed as its expert reviewer. > >Can you ask the working group to review the request below? If these are >OK, how should we fill out the Description fields in the registry? > >thanks, > >Amanda Baber >IANA Request Specialist >ICANN > >=3D=3D=3D=20 > >Contact Name: >Ivo Sedlacek > >Contact Email: >ivo.sedlacek@ericsson.com > >Type of Assignment: >Assignment of an service URN with the 'sos' service type as specified in >RFC5031, section 4.2. > >The following service URNs are proposed to be registered: >- 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. > >Registry: >Service URN Labels, 'sos' Sub-Services as shown at >http://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-labels. >xml > >Description: >In the Czech republic and Poland, there are two public safety answering >points (PSAP) offering the police related emergency services. The PSAP of >the municipal police and the PSAP of the national police. There is >currently no way how to distinguish whether the user wishes to contact >the PSAP of the municipal police or the PSAP of the national police. > >In Czech, the related regulation is >http://aplikace.mvcr.cz/sbirka-zakonu/ViewFile.aspx?type=3Dc&id=3D5134 pages >9 and 10 section 4.5 which lists the number 156 for "Obecn=ED policie" (=3D >municipal police) and the numbers 158 for "Policie =C8esk=E9 republiky" (=3D >Czech republic police). Both numbers are listed with note 2) which states >"=C8=EDslo je n=E1rodn=EDm =E8=EDslem pro t=EDs=F2ov=E9 vol=E1n=ED" (=3D the number is a national >number for emergency calls). > >In Poland,=20 >http://uke.gov.pl/tablice-numerow-kierowania-alarmowego-nka-9410 lists >the number 986 for "stra=BF miejska" (=3D municipal police) and the number >997 for Policja (=3D police) as "numery alarmowe" (=3D emergency numbers). > >Additional Info: >The registry is defined by RFC5031, section 4.2 From brian.rosen@neustar.biz Tue Mar 19 09:46: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 48A9B21F871C for ; Tue, 19 Mar 2013 09:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.428 X-Spam-Level: X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSVihO5qQJsB for ; Tue, 19 Mar 2013 09:46:26 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 1836C21F86F0 for ; Tue, 19 Mar 2013 09:46:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1363711773; x=1679069481; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=nQr2O2sqi/ qSgpabc/9Ocwz8Lf82FbSym+49mTqMJJ4=; b=MQd5pNpfFQA2//cHeo/3vG8pbC 2lAxbngx5hK3aIUzKv/pMQK2H4a1sSthhCzolLwDxMJP8PBZo+1I6ZDSz7Kg== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.21101551; Tue, 19 Mar 2013 12:49:32 -0400 Received: from STNTEXCHCASHT05.cis.neustar.com (10.31.15.157) by STNTEXCHHT02.cis.neustar.com (10.31.13.229) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 19 Mar 2013 12:46:21 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.56]) by STNTEXCHCASHT05.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Tue, 19 Mar 2013 12:46:17 -0400 From: "Rosen, Brian" To: Marc Linsner Thread-Topic: [IANA #658921] General Request for Assignment (urn-serviceid-labels) Thread-Index: AQHOJL9+9GwFxIdjaEiupL7TQO/fK5itfByA Date: Tue, 19 Mar 2013 16:46:17 +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: [192.168.133.137] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: FcmoyIsTWSwxls7eJ6Umxw== Content-Type: text/plain; charset="iso-8859-2" Content-ID: <474BA25F6AAC3345A1897BAD209811F0@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels) 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 Mar 2013 16:46:27 -0000 Yes In my opinion, urn:service:sos.police.national should be registered, althou= gh I would prefer the term "country" for reasons detailed below. I do not believe urn:service:sos.police.local should be registered, because= the term "local" is ambiguous in many countries and regions. In some area= s, there are multiple levels of "local" that may have separate service URLs= . For example, you could have state, county and municipal police agencies,= any of which could be considered "local". While an expert does not usually supply alternatives, I think the ecrit wor= k group has considered the suggestion to use the "A" levels in PIDF-LO to d= enote the levels of "local". So, for example, urn:service:sos.police.a2 wo= uld be the county police, assuming A1 was state, A2 was county and A3 was c= ity. One could speculate whether urn:service:sos.police.a6 (neighborhood) = was useful for anything, but there are "neighborhood watch" organizations t= hat might qualify, and "vigilante" is probably not a good registration. =20 Using the "A" levels leads you to use "country" as that is the top level na= me for the field in PIDF-LO. "national" is an obvious synonym, and I think= it's okay to use it. However, "local" is ambiguous. Brian=20 On Mar 19, 2013, at 12:32 PM, Marc Linsner wrote: > Brian, >=20 > Would you please provide a review of this IANA request for registrations. >=20 > Thanks, >=20 > Marc & Roger >=20 > -----Original Message----- > From: Amanda Baber via RT > Reply-To: > Date: Friday, February 15, 2013 6:34 PM > Cc: > Subject: [IANA #658921] General Request for Assignment > (urn-serviceid-labels) > Resent-From: > Resent-To: , > Resent-Date: Fri, 15 Feb 2013 23:22:12 +0000 >=20 >> Dear Marc and Roger, >>=20 >> IANA just received a request for two registrations in the 'sos' >> Sub-Services registry at >> http://www.iana.org/assignments/urn-serviceid-labels, which has the ECRI= T >> working group listed as its expert reviewer. >>=20 >> Can you ask the working group to review the request below? If these are >> OK, how should we fill out the Description fields in the registry? >>=20 >> thanks, >>=20 >> Amanda Baber >> IANA Request Specialist >> ICANN >>=20 >> =3D=3D=3D=20 >>=20 >> Contact Name: >> Ivo Sedlacek >>=20 >> Contact Email: >> ivo.sedlacek@ericsson.com >>=20 >> Type of Assignment: >> Assignment of an service URN with the 'sos' service type as specified in >> RFC5031, section 4.2. >>=20 >> The following service URNs are proposed to be registered: >> - urn:service:sos.police.local - The 'police.local' service refers to th= e >> 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 >> Registry: >> Service URN Labels, 'sos' Sub-Services as shown at >> http://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-label= s. >> xml >>=20 >> Description: >> In the Czech republic and Poland, there are two public safety answering >> points (PSAP) offering the police related emergency services. The PSAP o= f >> the municipal police and the PSAP of the national police. There is >> currently no way how to distinguish whether the user wishes to contact >> the PSAP of the municipal police or the PSAP of the national police. >>=20 >> In Czech, the related regulation is >> http://aplikace.mvcr.cz/sbirka-zakonu/ViewFile.aspx?type=3Dc&id=3D5134 p= ages >> 9 and 10 section 4.5 which lists the number 156 for "Obecn=ED policie" (= =3D >> municipal police) and the numbers 158 for "Policie =C8esk=E9 republiky" = (=3D >> Czech republic police). Both numbers are listed with note 2) which state= s >> "=C8=EDslo je n=E1rodn=EDm =E8=EDslem pro t=EDs=F2ov=E9 vol=E1n=ED" (=3D= the number is a national >> number for emergency calls). >>=20 >> In Poland,=20 >> http://uke.gov.pl/tablice-numerow-kierowania-alarmowego-nka-9410 lists >> the number 986 for "stra=BF miejska" (=3D municipal police) and the numb= er >> 997 for Policja (=3D police) as "numery alarmowe" (=3D emergency numbers= ). >>=20 >> Additional Info: >> The registry is defined by RFC5031, section 4.2 >=20 >=20 From martin.thomson@gmail.com Tue Mar 19 09:57: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 BF2CE21F8F69 for ; Tue, 19 Mar 2013 09:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxzXkwL0wOvs for ; Tue, 19 Mar 2013 09:57:56 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 237CA21F8F6F for ; Tue, 19 Mar 2013 09:57:55 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi8so768605wib.7 for ; Tue, 19 Mar 2013 09:57:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=fDbQf0UrypTpLSWInCeWd8dXjvP0F8MdAqrUe++AlyI=; b=t4E+nJxHnhEItoeE0+fABwkDNkklpKRVxBbgYIBq1gliZO/SMM3Ka/7EgYyxhOCpCz Wgn3yp9IHWZUkeVE/O602bLiHxQ0M6C+ukRWbN8JAAQYCRo3qJFsyXST6YIOqW4Jm+B1 aJFpqh1grdB3JwlqwLdSXDD+VEPPf9wEmyxTHMAZoBbeQiUYkS3afqxWTp1vySt5tXSc YU1WBUxF+5w2vNox1y1AcUQAzxo5VnNcOwIlteqdzrj9uDCh2c6g42d9YmvMMUQ9eeI0 Pd6QMsdJrKKP7mFL5pG7/w58GcmgL1hqxDScyh46F8dIky5CXF+/Z5n7x46pa2zZfAnE 5dcA== MIME-Version: 1.0 X-Received: by 10.194.76.37 with SMTP id h5mr4896531wjw.21.1363712275197; Tue, 19 Mar 2013 09:57:55 -0700 (PDT) Received: by 10.194.5.135 with HTTP; Tue, 19 Mar 2013 09:57:55 -0700 (PDT) In-Reply-To: References: Date: Tue, 19 Mar 2013 09:57:55 -0700 Message-ID: From: Martin Thomson To: "Rosen, Brian" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels) 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 Mar 2013 16:57:57 -0000 I agree with Brian, "local" is not just ambiguous, it's redundant. "urn:service:sos.police.local" is semantically equivalent to "urn:service:sos.police". Regarding "national" and "country", there's a subtlety that might be relevant. To my mind, "country" is a location-based designation, whereas "national" implies an ownership-based distinction. This might be a peculiarity of Australian English. To give a concrete example, local councils in Australia are often given money under a "national black-spot programme" to repair problem sections of local roadways - the effect is local (i.e., A3-ish), but the designation is "national" due to the nature of the sponsor. I prefer the location-based label for that reason. On 19 March 2013 09:46, Rosen, Brian wrote: > Yes > > In my opinion, urn:service:sos.police.national should be registered, alth= ough I would prefer the term "country" for reasons detailed below. > > I do not believe urn:service:sos.police.local should be registered, becau= se the term "local" is ambiguous in many countries and regions. In some ar= eas, there are multiple levels of "local" that may have separate service UR= Ls. For example, you could have state, county and municipal police agencie= s, any of which could be considered "local". > > While an expert does not usually supply alternatives, I think the ecrit w= ork group has considered the suggestion to use the "A" levels in PIDF-LO to= denote the levels of "local". So, for example, urn:service:sos.police.a2 = would be the county police, assuming A1 was state, A2 was county and A3 was= city. One could speculate whether urn:service:sos.police.a6 (neighborhood= ) was useful for anything, but there are "neighborhood watch" organizations= that might qualify, and "vigilante" is probably not a good registration. > > Using the "A" levels leads you to use "country" as that is the top level = name for the field in PIDF-LO. "national" is an obvious synonym, and I thi= nk it's okay to use it. > > However, "local" is ambiguous. > > Brian > > On Mar 19, 2013, at 12:32 PM, Marc Linsner > wrote: > >> Brian, >> >> Would you please provide a review of this IANA request for registrations= . >> >> Thanks, >> >> Marc & Roger >> >> -----Original Message----- >> From: Amanda Baber via RT >> Reply-To: >> Date: Friday, February 15, 2013 6:34 PM >> Cc: >> Subject: [IANA #658921] General Request for Assignment >> (urn-serviceid-labels) >> Resent-From: >> Resent-To: , >> Resent-Date: Fri, 15 Feb 2013 23:22:12 +0000 >> >>> Dear Marc and Roger, >>> >>> IANA just received a request for two registrations in the 'sos' >>> Sub-Services registry at >>> http://www.iana.org/assignments/urn-serviceid-labels, which has the ECR= IT >>> working group listed as its expert reviewer. >>> >>> Can you ask the working group to review the request below? If these are >>> OK, how should we fill out the Description fields in the registry? >>> >>> thanks, >>> >>> Amanda Baber >>> IANA Request Specialist >>> ICANN >>> >>> =3D=3D=3D >>> >>> Contact Name: >>> Ivo Sedlacek >>> >>> Contact Email: >>> ivo.sedlacek@ericsson.com >>> >>> Type of Assignment: >>> Assignment of an service URN with the 'sos' service type as specified i= n >>> RFC5031, section 4.2. >>> >>> The following service URNs are proposed to be registered: >>> - urn:service:sos.police.local - The 'police.local' service refers to t= he >>> 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. >>> >>> Registry: >>> Service URN Labels, 'sos' Sub-Services as shown at >>> http://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-labe= ls. >>> xml >>> >>> Description: >>> In the Czech republic and Poland, there are two public safety answering >>> points (PSAP) offering the police related emergency services. The PSAP = of >>> the municipal police and the PSAP of the national police. There is >>> currently no way how to distinguish whether the user wishes to contact >>> the PSAP of the municipal police or the PSAP of the national police. >>> >>> In Czech, the related regulation is >>> http://aplikace.mvcr.cz/sbirka-zakonu/ViewFile.aspx?type=3Dc&id=3D5134 = pages >>> 9 and 10 section 4.5 which lists the number 156 for "Obecn=C3=AD polici= e" (=3D >>> municipal police) and the numbers 158 for "Policie =C4=8Cesk=C3=A9 repu= bliky" (=3D >>> Czech republic police). Both numbers are listed with note 2) which stat= es >>> "=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). >>> >>> In Poland, >>> http://uke.gov.pl/tablice-numerow-kierowania-alarmowego-nka-9410 lists >>> the number 986 for "stra=C5=BC miejska" (=3D municipal police) and the = number >>> 997 for Policja (=3D police) as "numery alarmowe" (=3D emergency number= s). >>> >>> Additional Info: >>> The registry is defined by RFC5031, section 4.2 >> >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From ivo.sedlacek@ericsson.com Tue Mar 19 10:38: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 731C021F862D for ; Tue, 19 Mar 2013 10:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uF-j6aR7uAXm for ; Tue, 19 Mar 2013 10:38:49 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8781021F85D2 for ; Tue, 19 Mar 2013 10:38:48 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-dc-5148a2a74e95 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0F.08.19728.7A2A8415; Tue, 19 Mar 2013 18:38:47 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.208]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 18:38:46 +0100 From: Ivo Sedlacek To: "Rosen, Brian" , Marc Linsner Thread-Topic: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels) Thread-Index: AQHOJMFR8r8GmTg19Uu6YUL2EswLYZitRfyA Date: Tue, 19 Mar 2013 17:38:46 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061010A7AFD@ESESSMB301.ericsson.se> References: 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.16] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvje7yRR6BBkcXqltMO3mZ2aJx0VNW i7OXrzM6MHtM+b2R1WPJkp9MHjsanjMHMEdx2aSk5mSWpRbp2yVwZZx7OIWt4LF+Rc+3I4wN jPvUuxg5OSQETCQ2vd7KCGGLSVy4t56ti5GLQ0jgEKNE46lP7BDOEkaJNw+7mUGq2AT0JCZu OcLaxcjBISIQKDHpfDlImFlAVeJc42MWEFtYIFpi7eRHYENFBGIkZs24wwxhG0m82zidFcRm Aao/c+0bI8gYXgFvibv3JUDCQgIpEjN2/wEr4RSwl2hbcxhsJKOArMTVP72MEKvEJW49mc8E cbOAxJI955khbFGJl4//sULYihI7z7YzQ9TrSTw7NYsFwtaWWLbwNVicV0BQ4uTMJywTGMVm IRk7C0nLLCQts5C0LGBkWcXInpuYmZNebrSJERg1B7f8Vt3BeOecyCFGaQ4WJXHecNcLAUIC 6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYZ7p98Z1077vx7hyVL3qyk/f+XsS7jN17Bm83i+GS nJwHd14nvN/UMd0qo8OyYWnr8eW36zyn8yv/F7kra3/ROcmD752pbUtf6B6HQuljXH0uoecT hN10Tc32Ni5MErxvErTiR+2EDE9D45WcEWf0Py2OXKBdLlym3zPxb6/s5ijt6mLFkmglluKM REMt5qLiRADTNDlgaAIAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels) 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 Mar 2013 17:38:50 -0000 Hello, I am the author of the IANA registration request. I would be happy with "country" instead of "national" in the URN, if that's= the experts' preference. I would also be happy with "A3" instead of "local" in the URN, if that's th= e experts' preference. I.e. - 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. - 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). Do I need to send another IANA registration request or can the IANA existin= g registration request be modified? Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer=20 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of R= osen, Brian Sent: 19. b=F8ezna 2013 17:46 To: Marc Linsner Cc: ecrit@ietf.org Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-ser= viceid-labels) Yes In my opinion, urn:service:sos.police.national should be registered, althou= gh I would prefer the term "country" for reasons detailed below. I do not believe urn:service:sos.police.local should be registered, because= the term "local" is ambiguous in many countries and regions. In some area= s, there are multiple levels of "local" that may have separate service URLs= . For example, you could have state, county and municipal police agencies,= any of which could be considered "local". While an expert does not usually supply alternatives, I think the ecrit wor= k group has considered the suggestion to use the "A" levels in PIDF-LO to d= enote the levels of "local". So, for example, urn:service:sos.police.a2 wo= uld be the county police, assuming A1 was state, A2 was county and A3 was c= ity. One could speculate whether urn:service:sos.police.a6 (neighborhood) = was useful for anything, but there are "neighborhood watch" organizations t= hat might qualify, and "vigilante" is probably not a good registration. =20 Using the "A" levels leads you to use "country" as that is the top level na= me for the field in PIDF-LO. "national" is an obvious synonym, and I think= it's okay to use it. However, "local" is ambiguous. Brian=20 On Mar 19, 2013, at 12:32 PM, Marc Linsner wrote: > Brian, >=20 > Would you please provide a review of this IANA request for registrations. >=20 > Thanks, >=20 > Marc & Roger >=20 > -----Original Message----- > From: Amanda Baber via RT > Reply-To: > Date: Friday, February 15, 2013 6:34 PM > Cc: > Subject: [IANA #658921] General Request for Assignment > (urn-serviceid-labels) > Resent-From: > Resent-To: , > Resent-Date: Fri, 15 Feb 2013 23:22:12 +0000 >=20 >> Dear Marc and Roger, >>=20 >> IANA just received a request for two registrations in the 'sos' >> Sub-Services registry at >> http://www.iana.org/assignments/urn-serviceid-labels, which has the=20 >> ECRIT working group listed as its expert reviewer. >>=20 >> Can you ask the working group to review the request below? If these=20 >> are OK, how should we fill out the Description fields in the registry? >>=20 >> thanks, >>=20 >> Amanda Baber >> IANA Request Specialist >> ICANN >>=20 >> =3D=3D=3D >>=20 >> Contact Name: >> Ivo Sedlacek >>=20 >> Contact Email: >> ivo.sedlacek@ericsson.com >>=20 >> Type of Assignment: >> Assignment of an service URN with the 'sos' service type as specified=20 >> in RFC5031, section 4.2. >>=20 >> The following service URNs are proposed to be registered: >> - urn:service:sos.police.local - The 'police.local' service refers to=20 >> the emergency service offered by the police department or other law=20 >> enforcement authorities of the local or municipal authorities. >> - urn:service:sos.police.national - The 'police.national' service=20 >> refers to the emergency service offered by the police department or=20 >> other law enforcement authorities of the national government. >>=20 >> Registry: >> Service URN Labels, 'sos' Sub-Services as shown at=20 >> http://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-label= s. >> xml >>=20 >> Description: >> In the Czech republic and Poland, there are two public safety=20 >> answering points (PSAP) offering the police related emergency=20 >> services. The PSAP of the municipal police and the PSAP of the=20 >> national police. There is currently no way how to distinguish whether=20 >> the user wishes to contact the PSAP of the municipal police or the PSAP = of the national police. >>=20 >> In Czech, the related regulation is >> http://aplikace.mvcr.cz/sbirka-zakonu/ViewFile.aspx?type=3Dc&id=3D5134=20 >> pages >> 9 and 10 section 4.5 which lists the number 156 for "Obecn=ED policie"=20 >> (=3D municipal police) and the numbers 158 for "Policie =C8esk=E9=20 >> republiky" (=3D Czech republic police). Both numbers are listed with=20 >> note 2) which states "=C8=EDslo je n=E1rodn=EDm =E8=EDslem pro t=EDs=F2o= v=E9 vol=E1n=ED" (=3D=20 >> the number is a national number for emergency calls). >>=20 >> In Poland, >> http://uke.gov.pl/tablice-numerow-kierowania-alarmowego-nka-9410=20 >> lists the number 986 for "stra=BF miejska" (=3D municipal police) and th= e=20 >> number >> 997 for Policja (=3D police) as "numery alarmowe" (=3D emergency numbers= ). >>=20 >> Additional Info: >> The registry is defined by RFC5031, section 4.2 >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From jmpolk@cisco.com Tue Mar 19 11:16: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 822EB21F8DB4 for ; Tue, 19 Mar 2013 11:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.203 X-Spam-Level: X-Spam-Status: No, score=-109.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfjLJf+b6Sb2 for ; Tue, 19 Mar 2013 11:16:49 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id CC92121F8D67 for ; Tue, 19 Mar 2013 11:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5641; q=dns/txt; s=iport; t=1363717008; x=1364926608; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version:content-transfer-encoding; bh=2vW5yGmPkIoEAj1FHPfBDTE4OOpiYjk6DEXV51NsxuY=; b=hYKWhOrr2CS1H9UYvMKa4umVm0ZbJlsHRn9YU5fy3TYLcZgwC8qj5D4P ULMS3fi7gecsWe3su8BT5ie6AWyVICDeJdt4srGZovI51ejyfuLJJ5neo AzGApvNkIjX7CKVk9h14iJyC89beNDvMSQz9ysptUsLa3hZsZp1kGFsjh I=; X-IronPort-AV: E=Sophos;i="4.84,873,1355097600"; d="scan'208";a="189189161" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 19 Mar 2013 18:16:48 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8718.cisco.com [10.99.80.25]) (authenticated bits=0) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2JIGlE2002418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Mar 2013 18:16:48 GMT Message-Id: <201303191816.r2JIGlE2002418@rcdn-core-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 19 Mar 2013 13:16:24 -0500 To: "Rosen, Brian" , Marc Linsner From: James Polk In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-User: jmpolk Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels) 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 Mar 2013 18:16:51 -0000 Brian (and all) Riddle me this "local" is ambiguous in your opinion and "national" isn't? Take in the US for instance, would "national" be synonymous with "federal"? Or more specifically, who would urn:service:sos.police.national be= contacting? - the US Marshall service? - the FBI? - ATF/DEA? - the US Army? - the US Navy? - the US Marines? - or the US DoD hotline for them to decide which=20 service to send out (kinda like a PSAP) - some other national organization (e.g., military police, NCIS, etc) In my view, national =3D federal, but it might not be in everyone's view. James At 11:46 AM 3/19/2013, Rosen, Brian wrote: >Yes > >In my opinion, urn:service:sos.police.national=20 >should be registered, although I would prefer=20 >the term "country" for reasons detailed below. > >I do not believe urn:service:sos.police.local=20 >should be registered, because the term "local"=20 >is ambiguous in many countries and regions. In=20 >some areas, there are multiple levels of "local"=20 >that may have separate service URLs. For=20 >example, you could have state, county and=20 >municipal police agencies, any of which could be considered "local". > >While an expert does not usually supply=20 >alternatives, I think the ecrit work group has=20 >considered the suggestion to use the "A" levels=20 >in PIDF-LO to denote the levels of "local". So,=20 >for example, urn:service:sos.police.a2 would be=20 >the county police, assuming A1 was state, A2 was=20 >county and A3 was city. One could speculate=20 >whether urn:service:sos.police.a6 (neighborhood)=20 >was useful for anything, but there are=20 >"neighborhood watch" organizations that might=20 >qualify, and "vigilante" is probably not a good registration. > >Using the "A" levels leads you to use "country"=20 >as that is the top level name for the field in=20 >PIDF-LO. "national" is an obvious synonym, and I think it's okay to use= it. > >However, "local" is ambiguous. > >Brian > >On Mar 19, 2013, at 12:32 PM, Marc Linsner > wrote: > > > Brian, > > > > Would you please provide a review of this IANA request for= registrations. > > > > Thanks, > > > > Marc & Roger > > > > -----Original Message----- > > From: Amanda Baber via RT > > Reply-To: > > Date: Friday, February 15, 2013 6:34 PM > > Cc: > > Subject: [IANA #658921] General Request for Assignment > > (urn-serviceid-labels) > > Resent-From: > > Resent-To: , > > Resent-Date: Fri, 15 Feb 2013 23:22:12 +0000 > > > >> Dear Marc and Roger, > >> > >> IANA just received a request for two registrations in the 'sos' > >> Sub-Services registry at > >> http://www.iana.org/assignments/urn-serviceid-labels, which has the= ECRIT > >> working group listed as its expert reviewer. > >> > >> Can you ask the working group to review the request below? If these are > >> OK, how should we fill out the Description fields in the registry? > >> > >> thanks, > >> > >> Amanda Baber > >> IANA Request Specialist > >> ICANN > >> > >> =3D=3D=3D > >> > >> Contact Name: > >> Ivo Sedlacek > >> > >> Contact Email: > >> ivo.sedlacek@ericsson.com > >> > >> Type of Assignment: > >> Assignment of an service URN with the 'sos' service type as specified= in > >> RFC5031, section 4.2. > >> > >> The following service URNs are proposed to be registered: > >> - 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. > >> > >> Registry: > >> Service URN Labels, 'sos' Sub-Services as shown at > >>= http://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-labels. > >> xml > >> > >> Description: > >> In the Czech republic and Poland, there are two public safety answering > >> points (PSAP) offering the police related emergency services. The PSAP= of > >> the municipal police and the PSAP of the national police. There is > >> currently no way how to distinguish whether the user wishes to contact > >> the PSAP of the municipal police or the PSAP of the national police. > >> > >> In Czech, the related regulation is > >> http://aplikace.mvcr.cz/sbirka-zakonu/ViewFile.aspx?type=3Dc&id=3D5134= pages > >> 9 and 10 section 4.5 which lists the number 156 for "Obecn=ED policie"= (=3D > >> municipal police) and the numbers 158 for "Policie =C8esk=E9 republiky"= (=3D > >> Czech republic police). Both numbers are listed with note 2) which= states > >> "=C8=EDslo je n=E1rodn=EDm =E8=EDslem pro t=EDs=F2ov=E9 vol=E1n=ED" (= =3D the number is a national > >> number for emergency calls). > >> > >> In Poland, > >> http://uke.gov.pl/tablice-numerow-kierowania-alarmowego-nka-9410 lists > >> the number 986 for "stra=BF miejska" (=3D municipal police) and the= number > >> 997 for Policja (=3D police) as "numery alarmowe" (=3D emergency= numbers). > >> > >> Additional Info: > >> The registry is defined by RFC5031, section 4.2 > > > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From brian.rosen@neustar.biz Tue Mar 19 11:23:00 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 9B71F21F8EEA for ; Tue, 19 Mar 2013 11:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.457 X-Spam-Level: X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0NHMdSpkQSw for ; Tue, 19 Mar 2013 11:22:58 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACA521F8E10 for ; Tue, 19 Mar 2013 11:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1363717271; x=1679072782; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=/w3Hi+OZ+s 83/OmXCcCIXCrPYG837dSmHPwO5AHpV88=; b=FZnkFL/h8Rd4uBRdV68GPnaHqx hjuZYmWCdZHwW4XUKZt9UubIDB9HzygRbGEvYpiw4zTgNVHKUeL4bVqOq1Ww== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.17588527; Tue, 19 Mar 2013 14:21:09 -0400 Received: from STNTEXHC12.cis.neustar.com (10.31.58.71) by STNTEXCHHT03.cis.neustar.com (10.31.13.242) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 19 Mar 2013 14:22:54 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.56]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Tue, 19 Mar 2013 14:22:51 -0400 From: "Rosen, Brian" To: James Polk Thread-Topic: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels) Thread-Index: AQHOJL9+9GwFxIdjaEiupL7TQO/fKw== Date: Tue, 19 Mar 2013 18:22:50 +0000 Message-ID: References: <201303191816.r2JIGlE2002418@rcdn-core-5.cisco.com> In-Reply-To: <201303191816.r2JIGlE2002418@rcdn-core-5.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.133.137] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: F/+ifi8JmfGzbL4gKZvMIw== Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1E4BDDF4ED0A5F4684BFF10623BD589C@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels) 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 Mar 2013 18:23:00 -0000 It's the FBI, not DoD. The US Marshall service is indeed a special case, a= nd there could be similar organizations elsewhere. Other examples abound - there are traffic police in some areas. There is t= he notion of some "County Sheriff" who is not a regular police force, but h= as specialized duties such as court summons service and escorting prisoners= . =20 But nearly every country has some sort of a national police force with broa= der powers. In the U.S., that is the FBI. =20 Brian On Mar 19, 2013, at 2:16 PM, James Polk wrote: > Brian (and all) >=20 > Riddle me this >=20 > "local" is ambiguous in your opinion and "national" isn't? >=20 > Take in the US for instance, would "national" be synonymous with "federal= "? >=20 > Or more specifically, who would urn:service:sos.police.national be contac= ting? >=20 > - the US Marshall service? > - the FBI? > - ATF/DEA? > - the US Army? > - the US Navy? > - the US Marines? > - or the US DoD hotline for them to decide which service to send out (kin= da like a PSAP) > - some other national organization (e.g., military police, NCIS, etc) >=20 > In my view, national =3D federal, but it might not be in everyone's view. >=20 > James >=20 > At 11:46 AM 3/19/2013, Rosen, Brian wrote: >> Yes >>=20 >> In my opinion, urn:service:sos.police.national should be registered, alt= hough I would prefer the term "country" for reasons detailed below. >>=20 >> I do not believe urn:service:sos.police.local should be registered, beca= use the term "local" is ambiguous in many countries and regions. In some a= reas, there are multiple levels of "local" that may have separate service U= RLs. For example, you could have state, county and municipal police agenci= es, any of which could be considered "local". >>=20 >> While an expert does not usually supply alternatives, I think the ecrit = work group has considered the suggestion to use the "A" levels in PIDF-LO t= o denote the levels of "local". So, for example, urn:service:sos.police.a2= would be the county police, assuming A1 was state, A2 was county and A3 wa= s city. One could speculate whether urn:service:sos.police.a6 (neighborhoo= d) was useful for anything, but there are "neighborhood watch" organization= s that might qualify, and "vigilante" is probably not a good registration. >>=20 >> Using the "A" levels leads you to use "country" as that is the top level= name for the field in PIDF-LO. "national" is an obvious synonym, and I th= ink it's okay to use it. >>=20 >> However, "local" is ambiguous. >>=20 >> Brian >>=20 >> On Mar 19, 2013, at 12:32 PM, Marc Linsner >> wrote: >>=20 >> > Brian, >> > >> > Would you please provide a review of this IANA request for registratio= ns. >> > >> > Thanks, >> > >> > Marc & Roger >> > >> > -----Original Message----- >> > From: Amanda Baber via RT >> > Reply-To: >> > Date: Friday, February 15, 2013 6:34 PM >> > Cc: >> > Subject: [IANA #658921] General Request for Assignment >> > (urn-serviceid-labels) >> > Resent-From: >> > Resent-To: , >> > Resent-Date: Fri, 15 Feb 2013 23:22:12 +0000 >> > >> >> Dear Marc and Roger, >> >> >> >> IANA just received a request for two registrations in the 'sos' >> >> Sub-Services registry at >> >> http://www.iana.org/assignments/urn-serviceid-labels, which has the E= CRIT >> >> working group listed as its expert reviewer. >> >> >> >> Can you ask the working group to review the request below? If these a= re >> >> OK, how should we fill out the Description fields in the registry? >> >> >> >> thanks, >> >> >> >> Amanda Baber >> >> IANA Request Specialist >> >> ICANN >> >> >> >> =3D=3D=3D >> >> >> >> Contact Name: >> >> Ivo Sedlacek >> >> >> >> Contact Email: >> >> ivo.sedlacek@ericsson.com >> >> >> >> Type of Assignment: >> >> Assignment of an service URN with the 'sos' service type as specified= in >> >> RFC5031, section 4.2. >> >> >> >> The following service URNs are proposed to be registered: >> >> - 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 ref= ers >> >> to the emergency service offered by the police department or other la= w >> >> enforcement authorities of the national government. >> >> >> >> Registry: >> >> Service URN Labels, 'sos' Sub-Services as shown at >> >> http://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-la= bels. >> >> xml >> >> >> >> Description: >> >> In the Czech republic and Poland, there are two public safety answeri= ng >> >> points (PSAP) offering the police related emergency services. The PSA= P of >> >> the municipal police and the PSAP of the national police. There is >> >> currently no way how to distinguish whether the user wishes to contac= t >> >> the PSAP of the municipal police or the PSAP of the national police. >> >> >> >> In Czech, the related regulation is >> >> http://aplikace.mvcr.cz/sbirka-zakonu/ViewFile.aspx?type=3Dc&id=3D513= 4 pages >> >> 9 and 10 section 4.5 which lists the number 156 for "Obecn=ED policie= " (=3D >> >> municipal police) and the numbers 158 for "Policie =C8esk=E9 republik= y" (=3D >> >> Czech republic police). Both numbers are listed with note 2) which st= ates >> >> "=C8=EDslo je n=E1rodn=EDm =E8=EDslem pro t=EDs=F2ov=E9 vol=E1n=ED" (= =3D the number is a national >> >> number for emergency calls). >> >> >> >> In Poland, >> >> http://uke.gov.pl/tablice-numerow-kierowania-alarmowego-nka-9410 list= s >> >> the number 986 for "stra=BF miejska" (=3D municipal police) and the n= umber >> >> 997 for Policja (=3D police) as "numery alarmowe" (=3D emergency numb= ers). >> >> >> >> Additional Info: >> >> The registry is defined by RFC5031, section 4.2 >> > >> > >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From keith.drage@alcatel-lucent.com Tue Mar 19 12:27: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 8C51721F8FE3 for ; Tue, 19 Mar 2013 12:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+CKO8jUjRYs for ; Tue, 19 Mar 2013 12:27:24 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4345521F8FDD for ; Tue, 19 Mar 2013 12:27:23 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r2JJRMG2013939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 Mar 2013 14:27:22 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r2JJRLDs017856 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Mar 2013 15:27:22 -0400 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 19 Mar 2013 15:27:21 -0400 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 19 Mar 2013 20:27:18 +0100 From: "DRAGE, Keith (Keith)" To: Martin Thomson , "Rosen, Brian" Thread-Topic: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels) Thread-Index: AQHOJMMH2o3AEBawjEWvWcnSLNjkW5itZMDQ Date: Tue, 19 Mar 2013 19:27:17 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B01831C@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels) 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 Mar 2013 19:27:25 -0000 Martin Thomson wrote: > I agree with Brian, "local" is not just ambiguous, it's redundant. > "urn:service:sos.police.local" is semantically equivalent to > "urn:service:sos.police". > I disagree with the last part of this. It is only semantically equivalent i= f the PSAP assigned to handle .local calls is the same as the one assigned = to handle .police. It could equally be that .police and .national are hande= d by the same PSAP, or there could be three sets of PSAPs. So it depends on= how the PSAPs are arranged and supported in any particular administration. I'd also stress that we are setting this up to cover real need examples. Th= erefore if a country doesn't currently have a PSAP handling of emergency ca= lls at these levels, it should advertise .police and handle the subtypes as= .police. I personally would like these subtypes to be reasonably meaningful, i.e. En= glish words rather than codes. Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Martin Thomson > Sent: 19 March 2013 16:58 > To: Rosen, Brian > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn- > serviceid-labels) >=20 > I agree with Brian, "local" is not just ambiguous, it's redundant. > "urn:service:sos.police.local" is semantically equivalent to > "urn:service:sos.police". >=20 > Regarding "national" and "country", there's a subtlety that might be > relevant. To my mind, "country" is a location-based designation, > whereas "national" implies an ownership-based distinction. This might > be a peculiarity of Australian English. To give a concrete example, > local councils in Australia are often given money under a "national > black-spot programme" to repair problem sections of local roadways - > the effect is local (i.e., A3-ish), but the designation is "national" > due to the nature of the sponsor. I prefer the location-based label > for that reason. >=20 > On 19 March 2013 09:46, Rosen, Brian wrote: > > Yes > > > > In my opinion, urn:service:sos.police.national should be registered, > although I would prefer the term "country" for reasons detailed below. > > > > I do not believe urn:service:sos.police.local should be registered, > because the term "local" is ambiguous in many countries and regions. In > some areas, there are multiple levels of "local" that may have separate > service URLs. For example, you could have state, county and municipal > police agencies, any of which could be considered "local". > > > > While an expert does not usually supply alternatives, I think the ecrit > work group has considered the suggestion to use the "A" levels in PIDF-LO > to denote the levels of "local". So, for example, > urn:service:sos.police.a2 would be the county police, assuming A1 was > state, A2 was county and A3 was city. One could speculate whether > urn:service:sos.police.a6 (neighborhood) was useful for anything, but > there are "neighborhood watch" organizations that might qualify, and > "vigilante" is probably not a good registration. > > > > Using the "A" levels leads you to use "country" as that is the top leve= l > name for the field in PIDF-LO. "national" is an obvious synonym, and I > think it's okay to use it. > > > > However, "local" is ambiguous. > > > > Brian > > > > On Mar 19, 2013, at 12:32 PM, Marc Linsner > > wrote: > > > >> Brian, > >> > >> Would you please provide a review of this IANA request for > registrations. > >> > >> Thanks, > >> > >> Marc & Roger > >> > >> -----Original Message----- > >> From: Amanda Baber via RT > >> Reply-To: > >> Date: Friday, February 15, 2013 6:34 PM > >> Cc: > >> Subject: [IANA #658921] General Request for Assignment > >> (urn-serviceid-labels) > >> Resent-From: > >> Resent-To: , > >> Resent-Date: Fri, 15 Feb 2013 23:22:12 +0000 > >> > >>> Dear Marc and Roger, > >>> > >>> IANA just received a request for two registrations in the 'sos' > >>> Sub-Services registry at > >>> http://www.iana.org/assignments/urn-serviceid-labels, which has the > ECRIT > >>> working group listed as its expert reviewer. > >>> > >>> Can you ask the working group to review the request below? If these > are > >>> OK, how should we fill out the Description fields in the registry? > >>> > >>> thanks, > >>> > >>> Amanda Baber > >>> IANA Request Specialist > >>> ICANN > >>> > >>> =3D=3D=3D > >>> > >>> Contact Name: > >>> Ivo Sedlacek > >>> > >>> Contact Email: > >>> ivo.sedlacek@ericsson.com > >>> > >>> Type of Assignment: > >>> Assignment of an service URN with the 'sos' service type as specified > in > >>> RFC5031, section 4.2. > >>> > >>> The following service URNs are proposed to be registered: > >>> - 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 la= w > >>> enforcement authorities of the national government. > >>> > >>> Registry: > >>> Service URN Labels, 'sos' Sub-Services as shown at > >>> http://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid- > labels. > >>> xml > >>> > >>> Description: > >>> In the Czech republic and Poland, there are two public safety > answering > >>> points (PSAP) offering the police related emergency services. The PSA= P > of > >>> the municipal police and the PSAP of the national police. There is > >>> currently no way how to distinguish whether the user wishes to contac= t > >>> the PSAP of the municipal police or the PSAP of the national police. > >>> > >>> In Czech, the related regulation is > >>> http://aplikace.mvcr.cz/sbirka-zakonu/ViewFile.aspx?type=3Dc&id=3D513= 4 > pages > >>> 9 and 10 section 4.5 which lists the number 156 for "Obecn=ED policie= " > (=3D > >>> municipal police) and the numbers 158 for "Policie =C8esk=E9 republik= y" (=3D > >>> Czech republic police). Both numbers are listed with note 2) which > states > >>> "=C8=EDslo je n=E1rodn=EDm =E8=EDslem pro t=EDs=F2ov=E9 vol=E1n=ED" (= =3D the number is a > national > >>> number for emergency calls). > >>> > >>> In Poland, > >>> http://uke.gov.pl/tablice-numerow-kierowania-alarmowego-nka-9410 list= s > >>> the number 986 for "stra=BF miejska" (=3D municipal police) and the n= umber > >>> 997 for Policja (=3D police) as "numery alarmowe" (=3D emergency numb= ers). > >>> > >>> Additional Info: > >>> The registry is defined by RFC5031, section 4.2 > >> > >> > > > > _______________________________________________ > > 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 Tue Mar 19 12:56: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 5872121F8AB7 for ; Tue, 19 Mar 2013 12:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQjjpdBMnG7v for ; Tue, 19 Mar 2013 12:56:02 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 79B1B21F863C for ; Tue, 19 Mar 2013 12:56:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1363722843; x=1679080148; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=YAQ7fp9Uv2 DstcYvJI9TLr4/UAYnApg8oqw6llEjU40=; b=S6B4Oiaboa0dQEB59HevBruEQN SPZm/5tj06nlOaihtcoGJoLJ+oWSeXZnWCZJAl+rZDocnnPYQ/2WYfyFdRcA== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.17592826; Tue, 19 Mar 2013 15:54:02 -0400 Received: from STNTEXHC12.cis.neustar.com (10.31.58.71) by STNTEXCHHT03.cis.neustar.com (10.31.13.242) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 19 Mar 2013 15:55:46 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.56]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Tue, 19 Mar 2013 15:55:46 -0400 From: "Rosen, Brian" To: "DRAGE, Keith (Keith)" Thread-Topic: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels) Thread-Index: AQHOJNu+Xde3Zc6iFka7qbmi79bxgw== Date: Tue, 19 Mar 2013 19:55:45 +0000 Message-ID: <959CCDB7-89A9-4CC8-8C95-7CAC38B39747@neustar.biz> References: <949EF20990823C4C85C18D59AA11AD8B01831C@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B01831C@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.133.137] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: XiytTwbH+YnbZL34O0GOmA== Content-Type: text/plain; charset="windows-1250" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels) 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 Mar 2013 19:56:03 -0000 On Mar 19, 2013, at 3:27 PM, "DRAGE, Keith (Keith)" wrote: > I personally would like these subtypes to be reasonably meaningful, i.e. = English words rather than codes. >=20 > Keith >=20 The reason I didn't suggest words rather than the "A" codes is the same rea= son PIDF has A codes and not words: there are many not-quite-interchangeab= le words that are used in constructing addresses, or naming police agencies= . Take A1. Is it state, province, prefecture, =85.? Whatever word you choos= e is a poor choice in one country or another. =20 Brian From martin.thomson@gmail.com Tue Mar 19 13:03: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 EA70B21F8CC8 for ; Tue, 19 Mar 2013 13:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1hHvr1vEPi2 for ; Tue, 19 Mar 2013 13:03:14 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6A121F8C48 for ; Tue, 19 Mar 2013 13:03:14 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id ez12so981935wid.12 for ; Tue, 19 Mar 2013 13:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JlUWI1hJ0m7rCoW8di7AWr0I/+aQTo8WkNTUzx/kqzw=; b=c3w0WdpeUHz43+korbIFtzkBz9CvXQjNROBkCiDN1WyyXxs9Le9ZH8/paE/RhBEJvP zmrZ6tyIDSMjgkxJtKnRL3O2nXgWmbtvCGSzRqkEgCijGTyVuX1Rih0dyEtgG9Tmmffu T2wbOQt374rcg+eoqZoIW6S+VH9qyRr/RRFmncAUa2r1ZJJui8MBBoNMXBvkc+G/Wl+D 8VFVVWbvatWqVMiPS6Ba5qp4WJ1vHWtnk6mXNIRR9r6bXsTcdd7u8tK9UX4SFUuUQugn Z9mNLSjCe3oNQTFMt3SZc/CIh3yI1awQJSiy3A9O+Bjv+y48yOppGqZgwoE/oETYs58e /1Rw== MIME-Version: 1.0 X-Received: by 10.180.77.9 with SMTP id o9mr7578738wiw.16.1363723391012; Tue, 19 Mar 2013 13:03:11 -0700 (PDT) Received: by 10.194.5.135 with HTTP; Tue, 19 Mar 2013 13:03:10 -0700 (PDT) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B01831C@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B01831C@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Tue, 19 Mar 2013 13:03:10 -0700 Message-ID: From: Martin Thomson To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=UTF-8 Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels) 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 Mar 2013 20:03:15 -0000 On 19 March 2013 12:27, DRAGE, Keith (Keith) wrote: > Martin Thomson wrote: > >> I agree with Brian, "local" is not just ambiguous, it's redundant. >> "urn:service:sos.police.local" is semantically equivalent to >> "urn:service:sos.police". >> > > I disagree with the last part of this. I think that you missed my point. By nature, all urn:service:sos sub-services are local. That's why LoST exists. Adding ".local" is redundant. From internet-drafts@ietf.org Tue Mar 19 13:22: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 BAC5521F8FA1; Tue, 19 Mar 2013 13:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.402 X-Spam-Level: X-Spam-Status: No, score=-102.402 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFDHANT6hpsO; Tue, 19 Mar 2013 13:22:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D8521F8F7A; Tue, 19 Mar 2013 13:22:28 -0700 (PDT) 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.43 Message-ID: <20130319202228.21040.47220.idtracker@ietfa.amsl.com> Date: Tue, 19 Mar 2013 13:22:28 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-psap-callback-09.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 Mar 2013 20:22:28 -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-09.txt Pages : 19 Date : 2013-03-19 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-psap-callback-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hannes.tschofenig@gmx.net Tue Mar 19 13:23: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 4689921F8782 for ; Tue, 19 Mar 2013 13:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrFuIzRkjyhO for ; Tue, 19 Mar 2013 13:23:53 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4209721F8613 for ; Tue, 19 Mar 2013 13:23:50 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.29]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M68YO-1UcCaG1OV0-00yB4S for ; Tue, 19 Mar 2013 21:23:46 +0100 Received: (qmail invoked by alias); 19 Mar 2013 20:23:46 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.100]) [88.115.219.140] by mail.gmx.net (mp029) with SMTP; 19 Mar 2013 21:23:46 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19c1AYM2bZc4AFaoSnpzyNGON0Ih2KQnyqq+DRS1f Pq0ncBWYITt6Gb From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Mar 2013 22:23:44 +0200 Message-Id: <65D8BD17-ECC9-4FDD-9720-B5FD97AE6A2A@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 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 Mar 2013 20:23:54 -0000 I just posted an updated version of the PSAP callback draft. In the new = version I have addressed the review comments from Roger.=20 Thank you Roger for doing your shepherd review.=20 Ciao Hannes From prvs=2790d27ad3=jbakker@blackberry.com Tue Mar 19 13:33: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 8011C21F8EF2 for ; Tue, 19 Mar 2013 13:33:27 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKMHSEaG1hLn for ; Tue, 19 Mar 2013 13:33:23 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 470FB21F8E16 for ; Tue, 19 Mar 2013 13:33:23 -0700 (PDT) X-AuditID: 0a412830-b7ef86d00000339d-7c-5148cb862d94 Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 46.EB.13213.78BC8415; Tue, 19 Mar 2013 15:33:11 -0500 (CDT) 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 Mar 2013 15:33:10 -0500 From: John-Luc Bakker To: Ivo Sedlacek , Christer Holmberg , "ecrit@ietf.org" Thread-Topic: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-02 Thread-Index: AQHOJLsckTJrzwF7wEuJRVz7mxhPIpitdisQ Date: Tue, 19 Mar 2013 20:33:09 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA35D253A6@XMB103ADS.rim.net> References: <7594FB04B1934943A5C02806D1A2204B12C63C@ESESSMB209.ericsson.se> <155970D1DA8E174F9E46039E10E2AA35D24AAE@XMB103ADS.rim.net> <39B5E4D390E9BD4890E2B310790061010A7A26@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B310790061010A7A26@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.251] Content-Type: multipart/alternative; boundary="_000_155970D1DA8E174F9E46039E10E2AA35D253A6XMB103ADSrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEKsWRmVeSWpSXmKPExsXC5Zyvpdt+2iPQ4MMleYsLMw8zWjQuespq 0btyHqsDs8evr1fZPJYs+ckUwBTVwGiTlFhSFpyZnqdvZ5OYl5dfkliSqpCSWpxsq+STmp6Y oxBQlFmWmFyp4JJZnJyTmJmbWqSkkJliq2SipFCQk5icmpuaV2KrlFhQkJqXomTHpYABbIDK MvMUUvOS81My89JtlTyD/XUtLEwtdQ2V7HQTOnkyzi2rKFh1krHi7eULzA2M7zcxdjFyckgI mEicPrWQDcIWk7hwbz2QzcUhJNDGJPF4xXR2CGcro8SvA19ZQarYBPQkVkxexQiSEBFoZZT4 svAy2ChhgUCJ7V0rgNo5gBJBEvcfqIGERQSMJCZ/n8EOYrMIqEos234BrJxXwE3i0KK3UAtO MUpsaXzADJLgFPCRuPxzN5jNKCArsfvsdSYQm1lAXOLWk/lMEKcKSCzZc54ZwhaVePn4HyuE rSgxY898Voj6XIlPP5YxQywTlDg58wnLBEaRWUhGzUJSNgtJGURcT+LZqVlQtrbEsoWvmSFs XYlLD9exIosvYGRfxSiYm1FsYGaYnJesV5SZq5eXWrKJEZROHDUMdjC+f29xiFGAg1GJh3ff CY9AIdbEsuLK3EOMEhzMSiK8R44AhXhTEiurUovy44tKc1KLDzEGAYNrIrMUd3I+MNXllcQb GxgQyVES5y3TdAoUEkgHJrPs1NSC1CKYoUwcnCBLuaREioEpKbUosbQkIx6UOOOLgalTqoFR xbPmW5nRYzU+reeLeo2bTSQPWO0OFmjp1q8+aujec02p4Nz+iFN8PeLyb9jUXNp6vY4eb07t rFvmUFr+f5lk+bRjxxpE9BzKjt+ueLDDNspHhiX2WqXweYlfUS2mi0MippmcDGd5suhfPnvj srdM20vSsxc91N+iwhy32FaHnavyzgvGGUosxRmJhlrMRcWJAG2Rn511AwAA Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-02 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 Mar 2013 20:33:27 -0000 --_000_155970D1DA8E174F9E46039E10E2AA35D253A6XMB103ADSrimnet_ Content-Type: text/plain; charset="iso-8859-2" content-transfer-encoding: quoted-printable Hi Ivo, Thanks for the quick response. The IANA web page has for "urn:service:sos.mountain" the following descripti= on "Mountain rescue" and a link to the RFC. The RFC then has the following d= escription of the caller expectation in terms of services rendered: The 'mountain' service refers to mountain rescue services (i.e., search and rescue activities that occur in a mountainous environment), although the term is sometimes also used to apply to search and rescue in other wilderness environments. In my opinion, according to the RFC, "urn:service:sos.mountain" could also b= e applied to emergencies in caves/sink holes (i.e. no need for a mountainous= terrain), although such use would not be immediately apparent from the desc= ription on the IANA web page that has the registry for Service URN Labels. Perhaps the issue is that the IANA web page that has the registry for Servic= e URN Labels misses some information that is found in the RFC. Regards, JL From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] Sent: Tuesday, March 19, 2013 11:02 AM To: John-Luc Bakker; Christer Holmberg; ecrit@ietf.org Subject: RE: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn= -02 Hello, > Will the caller expectation in terms of services rendered be documented so= mewhere? The new policy proposed in draft-holmberg-ecrit-country-emg-urn-02 section 5= .3 states: 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. I.e. in the expert review, the service description and the URN are reviewed.= If approved, the service description and URN are listed in IANA - see http:= //www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-labels.xml#urn= -serviceid-labels-2 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: ecrit-bounces@ietf.org [mailto:ecrit-bo= unces@ietf.org] On Behalf Of John-Luc Bakker Sent: 19. b=F8ezna 2013 16:12 To: Christer Holmberg; ecrit@ietf.org Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn= -02 Hi Christer, Thanks for this. When a new URN is adopted via expert review, a description of the caller exp= ectation in terms of services rendered (for the new URN) cannot be found in= RFC 5031. For example, for the existing URN urn:service:sos.mountain, the RFC includes= : The 'mountain' service refers to mountain rescue services (i.e., search and rescue activities that occur in a mountainous environment), although the term is sometimes also used to apply to search and rescue in other wilderness environments. Will the caller expectation in terms of services rendered be documented some= where? Apologies if this query was already addressed during the ECRIT session ... Kind regards, JL From: ecrit-bounces@ietf.org [mailto:ecrit-bo= unces@ietf.org] On Behalf Of Christer Holmberg Sent: Tuesday, March 19, 2013 6:52 AM To: ecrit@ietf.org Subject: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-02 Hi, Based on the Orlando decision to move forward with the relax-the-5031-regist= ration-policy alternative for allowing emg URNs for services offered in one= country only, I've submitted an "official" new version (-02) of draft-holmb= erg-ecrit-country-emg-urn. Aside from some minor changes caused by the new v= ersion of xml2rfc, the draft is identical to the pre-02 version I distribute= d before the meeting. As was indicated in the meeting, additional text will still be needed, but o= nce the Orlando decision is verified on the list I hope we can adopt the dra= ft as base for the work. Thanks to everyone who provided comments during the meeting! Regards, Christer --------------------------------------------------------------------- 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_155970D1DA8E174F9E46039E10E2AA35D253A6XMB103ADSrimnet_ Content-Type: text/html; charset="iso-8859-2" content-transfer-encoding: quoted-printable

Hi Ivo,

 

Thanks for the quick re= sponse.

The IANA web page has f= or “urn:service:sos.mountain” the following description “Mountain rescue” and a link to the RFC. The RFC then has the follo= wing description of the caller expectatio= n in terms of services rendered:

 

  =    The 'mountain' service refers to mountain

  =     rescue services (i.e., search and rescue activities that= occur in

  =     a mountainous environment), although the term is sometime= s also

  =     used to apply to search and rescue in other wilderness

  =     environments.

 

In my opinion, accordin= g to the RFC, “urn:service:sos.mountain” could also be applied to emergencies in caves/sink holes (i.e. no need for a mountainous terrain), although such= use would not be immediately apparent from the description on the IANA web= page that has the registry for = Service URN Labels.

 

Perhaps the issue is th= at the IANA web page that has the registry for = Service URN Labels misses some informat= ion that is found in the RFC.

 

Regards,

 

    = ;           JL<= /span>

 

From: Ivo Sedlace= k [mailto:ivo.sedlacek@ericsson.com]
Sent: Tuesday, March 19, 2013 11:02 AM
To: John-Luc Bakker; Christer Holmberg; ecrit@ietf.org
Subject: RE: [Ecrit] Draft new version: draft-holmberg-ecrit-country-= emg-urn-02

 

Hello,

 

> Will the caller expectation in terms of= services rendered be documented somewhere?

 

The new policy proposed in dr= aft-holmberg-ecrit-country-emg-urn-02 section 5.3 states:<= /p>

 

   The 'sos' service type describes emergency serv= ices requiring an

   immediate response, typically offered by variou= s 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 abse= nce, the IESG.  The

   expert review should only approve services that have emergency

   nature, that are offered in at least one countr= y, that do not match

   description of any existing service URN with th= e '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.

 

I.e. in the expert review, th= e service description and the URN are reviewed. If approved, the service des= cription and URN are listed in IANA - see http://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-labels.xm= l#urn-serviceid-labels-2

 

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: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of John-Luc Bakker
Sent: 19. b=F8ezna 2013 16:12
To: Christer Holmberg; ecrit@ietf.o= rg
Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-= emg-urn-02

 

Hi Christer,=

 

Thanks for this.

When a new URN is adopt= ed via expert review, a description of the caller expectation in terms of se= rvices rendered (for the new URN) cannot be found in RFC 5031.

 

For example, for the ex= isting URN urn:service:sos.mountain, t= he RFC includes:

 

  =    The 'mountain' service refers to mountain

  =     rescue services (i.e., search and rescue activities that= occur in

  =     a mountainous environment), although the term is sometime= s also

  =     used to apply to search and rescue in other wilderness

  =     environments.

 

Will the caller expecta= tion in terms of services rendered be documented somewhere?

Apologies if this query= was already addressed during the ECRIT session …

 

Kind regards,

 

    = ;           JL<= /span>

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Tuesday, March 19, 2013 6:52 AM
To: ecrit@ietf.org
Subject: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-= urn-02

 

Hi,

 

Based on the Orlando decision to move forward with th= e relax-the-5031-registration-policy alternative for allowing emg URNs for s= ervices offered in one country only, I’ve submitted an “official= ” new version (-02) of draft-holmberg-ecrit-country-emg-urn. Aside from some minor changes caused by the new version of xml2rfc, the dra= ft is identical to the pre-02 version I distributed before the meeting.=

 

As was indicated in the meeting, additional text will= still be needed, but once the Orlando decision is verified on the list I ho= pe we can adopt the draft as base for the work.

 

Thanks to everyone who provided comments during the m= eeting!

 

Regards,

 

Christer

--------------------------------------= -------------------------------
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_155970D1DA8E174F9E46039E10E2AA35D253A6XMB103ADSrimnet_-- From brian.rosen@neustar.biz Tue Mar 19 13:41: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 1475021F8EE1 for ; Tue, 19 Mar 2013 13:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPrN+LH3mTqj for ; Tue, 19 Mar 2013 13:41:34 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 332DE21F8B45 for ; Tue, 19 Mar 2013 13:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1363725881; x=1679078482; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=Un2mjG06rfeawcm/PMOQYcSA6iXwAdW81GaPqRmFavQ=; b=bYKHh0CafKlr9nesG1Aq3pwZPHcCisPpQvtv+10c+sHd8yGXxZRDwP8aK15lfb 1lVnawSTt7rcdI7JtSinLs1g== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.21114001; Tue, 19 Mar 2013 16:44:40 -0400 Received: from STNTEXCHCASHT05.cis.neustar.com (10.31.15.157) by STNTEXCHHT02.cis.neustar.com (10.31.13.229) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 19 Mar 2013 16:41:29 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.56]) by STNTEXCHCASHT05.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Tue, 19 Mar 2013 16:41:25 -0400 From: "Rosen, Brian" To: John-Luc Bakker Thread-Topic: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-02 Thread-Index: AQHOJOIf8bNTe0Ilr0aqHMx18kDz/A== Date: Tue, 19 Mar 2013 20:41:24 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B12C63C@ESESSMB209.ericsson.se> <155970D1DA8E174F9E46039E10E2AA35D24AAE@XMB103ADS.rim.net> <39B5E4D390E9BD4890E2B310790061010A7A26@ESESSMB301.ericsson.se> <155970D1DA8E174F9E46039E10E2AA35D253A6@XMB103ADS.rim.net> In-Reply-To: <155970D1DA8E174F9E46039E10E2AA35D253A6@XMB103ADS.rim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.133.137] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: yGJypqtzgeUqebsY8B9HVg== Content-Type: multipart/alternative; boundary="_000_DE0E4923A3534596ADDEC151EDD0E595neustarbiz_" MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-02 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 Mar 2013 20:41:36 -0000 --_000_DE0E4923A3534596ADDEC151EDD0E595neustarbiz_ Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable I think we have a problem here. We don't require "specification" and we do= n't have adequate descriptions in the registry. I am loath to require specification for this registry. So, I suggest we ex= pand "description" to a larger piece of text, and supply advice to the expe= rt to evaluate the adequacy of the explanation. We could copy text out of = the RFC to start this process. Brian On Mar 19, 2013, at 4:33 PM, John-Luc Bakker > wrote: Hi Ivo, Thanks for the quick response. The IANA web page has for =93urn:service:sos.mountain=94 the following desc= ription =93Mountain rescue=94 and a link to the RFC. The RFC then has the f= ollowing description of the caller expectation in terms of services rendere= d: The 'mountain' service refers to mountain rescue services (i.e., search and rescue activities that occur in a mountainous environment), although the term is sometimes also used to apply to search and rescue in other wilderness environments. In my opinion, according to the RFC, =93urn:service:sos.mountain=94 could a= lso be applied to emergencies in caves/sink holes (i.e. no need for a mount= ainous terrain), although such use would not be immediately apparent from t= he description on the IANA web page that has the registry for Service URN L= abels. Perhaps the issue is that the IANA web page that has the registry for Servi= ce URN Labels misses some information that is found in the RFC. Regards, JL From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] Sent: Tuesday, March 19, 2013 11:02 AM To: John-Luc Bakker; Christer Holmberg; ecrit@ietf.org Subject: RE: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-ur= n-02 Hello, > Will the caller expectation in terms of services rendered be documented s= omewhere? The new policy proposed in draft-holmberg-ecrit-country-emg-urn-02 section = 5.3 states: 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. I.e. in the expert review, the service description and the URN are reviewed= . If approved, the service description and URN are listed in IANA - see htt= p://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-labels.xml#= urn-serviceid-labels-2 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 John-Luc Bakker Sent: 19. b=F8ezna 2013 16:12 To: Christer Holmberg; ecrit@ietf.org Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-ur= n-02 Hi Christer, Thanks for this. When a new URN is adopted via expert review, a description of the caller ex= pectation in terms of services rendered (for the new URN) cannot be found i= n RFC 5031. For example, for the existing URN urn:service:sos.mountain, the RFC include= s: The 'mountain' service refers to mountain rescue services (i.e., search and rescue activities that occur in a mountainous environment), although the term is sometimes also used to apply to search and rescue in other wilderness environments. Will the caller expectation in terms of services rendered be documented som= ewhere? Apologies if this query was already addressed during the ECRIT session =85 Kind regards, JL From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Christer Holmberg Sent: Tuesday, March 19, 2013 6:52 AM To: ecrit@ietf.org Subject: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-02 Hi, Based on the Orlando decision to move forward with the relax-the-5031-regis= tration-policy alternative for allowing emg URNs for services offered in on= e country only, I=92ve submitted an =93official=94 new version (-02) of dra= ft-holmberg-ecrit-country-emg-urn. Aside from some minor changes caused by = the new version of xml2rfc, the draft is identical to the pre-02 version I = distributed before the meeting. As was indicated in the meeting, additional text will still be needed, but = once the Orlando decision is verified on the list I hope we can adopt the d= raft as base for the work. Thanks to everyone who provided comments during the meeting! Regards, Christer --------------------------------------------------------------------- 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. --------------------------------------------------------------------- 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. _______________= ________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_DE0E4923A3534596ADDEC151EDD0E595neustarbiz_ Content-Type: text/html; charset="windows-1250" Content-ID: Content-Transfer-Encoding: quoted-printable I think we have a problem here.  We don't require "specification&= quot; and we don't have adequate descriptions in the registry.

I am loath to require specification for this registry.  So, I sug= gest we expand "description" to a larger piece of text, and suppl= y advice to the expert to evaluate the adequacy of the explanation.  W= e could copy text out of the RFC to start this process.

Brian

On Mar 19, 2013, at 4:33 PM, John-Luc Bakker <jbakker@blackberry.com> wrote:

Hi Ivo,
 
Thanks for the quick response.
The IANA web page has for =93= =94 the following desc= ription =93Mountain rescue=94 and a link to t= he RFC. The RFC then has the following descripti= on of the caller expectation in terms of services rendered:<= /span>
 
&= nbsp;     The 'mountain' service refers to mountain
&= nbsp;     rescue services (i.e., search and rescue acti= vities that occur in
&= nbsp;     a mountainous environment), although the term= is sometimes also
&= nbsp;     used to apply to search and rescue in other w= ilderness
&= nbsp;     environments.
 
In my opinion, according to the R= FC, =93urn:service:sos.mountain=94 could also be applied to emergencies in caves/sink holes (i.e. no need for a mountainous terrain), although suc= h use would not be immediately apparent from the description on the IANA we= b page that has the registry for = ;Service URN Labels.
 
Perhaps the issue is that the IAN= A web page that has the registry for&= nbsp;Service= URN Labels misses some information that is found in the RFC.
 
Regards,
 
     &nb= sp;         JL
 
From:=  Ivo Sedlacek [mailto:= ivo.sedlacek@ericsson.com] 
Sent: Tuesday, Mar= ch 19, 2013 11:02 AM
To: John-Luc Bakke= r; Christer Holmberg; ecrit@ietf.org
Subject: RE: [Ecri= t] Draft new version: draft-holmberg-ecrit-country-emg-urn-02
 
Hello,
 
> Will the caller expectation in= terms of services rendered be documented somewhere?=
 
The new policy proposed in draft-holmberg-ecrit-country-emg= -urn-02 section 5.3 states:
 
   = 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<= o:p>
   = 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&nbs= p;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.
 
I.e. in the expert review, the service description and the = URN are reviewed. If approved, the service description and URN are listed i= n IANA - see http://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-lab= els.xml#urn-serviceid-labels-2
 
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 John-Luc B= akker
Sent: 19. b=F8ezna= 2013 16:12
To: Christer Holmb= erg; ecrit@i= etf.org
Subject: Re: [Ecri= t] Draft new version: draft-holmberg-ecrit-country-emg-urn-02
 
Hi Christer,
 
Thanks for this.
When a new URN is adopted via exp= ert review, a description of the caller expectation in terms of services re= ndered (for the new URN) cannot be found in RFC 5031.
 
For example, for the existing URN=  urn:service:sos.mo= untain, the RFC includes:
 
&= nbsp;     The 'mountain' service refers to mountain
&= nbsp;     rescue services (i.e., search and rescue acti= vities that occur in
&= nbsp;     a mountainous environment), although the term= is sometimes also
&= nbsp;     used to apply to search and rescue in other w= ilderness
&= nbsp;     environments.
 
Will the caller expectation in te= rms of services rendered be documented somewhere?
Apologies if this query was alrea= dy addressed during the ECRIT session =85
 
Kind regards,
 
     &nb= sp;         JL
 
From:=  = ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer H= olmberg
Sent: Tuesday, Mar= ch 19, 2013 6:52 AM
To: e= crit@ietf.org
Subject: [Ecrit] D= raft new version: draft-holmberg-ecrit-country-emg-urn-02=
 
Hi,
 
Based on the Orlando decision to move forward with the relax-the-5031-regis= tration-policy alternative for allowing emg URNs for services offered in on= e country only, I=92ve submitted an =93official=94 new version (-02) of dra= ft-holmberg-ecrit-country-emg-urn. Aside from some minor changes caused by the new version of xml2rfc, the draft is= identical to the pre-02 version I distributed before the meeting.
 
As was indicated in the meeting, additional text will still be needed, but = once the Orlando decision is verified on the list I hope we can adopt the d= raft as base for the work.
 
Thanks to everyone who provided comments during the meeting!
 
Regards,
 
Christer
--= ------------------------------------------------------------------- 
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.=
--------------------------------------------------------------------- 
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. __________= _____________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ec= rit

--_000_DE0E4923A3534596ADDEC151EDD0E595neustarbiz_-- From keith.drage@alcatel-lucent.com Tue Mar 19 18:49: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 1DC2121F8782 for ; Tue, 19 Mar 2013 18:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ac3wNKvgGxvD for ; Tue, 19 Mar 2013 18:49:07 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECDC21F86DE for ; Tue, 19 Mar 2013 18:49:07 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r2K1n5vX015045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 Mar 2013 20:49:05 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r2K1n5MS025721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Mar 2013 21:49:05 -0400 Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 19 Mar 2013 21:49:05 -0400 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 20 Mar 2013 02:49:03 +0100 From: "DRAGE, Keith (Keith)" To: Martin Thomson Thread-Topic: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels) Thread-Index: AQHOJN0HiPQAg8Uiuk+EGiwTaCC+Ppitz4/g Date: Wed, 20 Mar 2013 01:49:02 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0184C8@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B01831C@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels) 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 Mar 2013 01:49:08 -0000 These are two different concepts. In the URN, this is about distinguishing between two (or more) different ty= pes of police force, i.e. municipal police versus FBI, or whatever. Whatever the value of the URN you still want the PSAP that serves your area= , be that the municipal police or the FBI. Keith > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: 19 March 2013 20:03 > To: DRAGE, Keith (Keith) > Cc: Rosen, Brian; ecrit@ietf.org > Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn- > serviceid-labels) >=20 > On 19 March 2013 12:27, DRAGE, Keith (Keith) > wrote: > > Martin Thomson wrote: > > > >> I agree with Brian, "local" is not just ambiguous, it's redundant. > >> "urn:service:sos.police.local" is semantically equivalent to > >> "urn:service:sos.police". > >> > > > > I disagree with the last part of this. >=20 > I think that you missed my point. By nature, all urn:service:sos > sub-services are local. That's why LoST exists. Adding ".local" is > redundant. From dan@mongrain.org Tue Mar 19 19:12: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 A44F921F8E23 for ; Tue, 19 Mar 2013 19:12:08 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7GSfRp4gNRn for ; Tue, 19 Mar 2013 19:12:07 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 8030921F8D3C for ; Tue, 19 Mar 2013 19:12:00 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id c12so1514192ieb.6 for ; Tue, 19 Mar 2013 19:12:00 -0700 (PDT) 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:content-type:x-gm-message-state; bh=dWP0pgu852lIwi0ZV8x+GkvFaYye8fAz2CUFADKi+5c=; b=lzx3xq25S6gk3QvIl+C/Esidf6+UhPoSkXaUgThHINYxQqJ6WPQO0/5V/uHOYTrDWc njKVIcJ6EBvMwVPqZUDknfRg9Qc6EY3h6/htDiydQrLM3YuyfF3lDHSkDobe3cKvfhhr G8qMzo+F1/5pGGuWro9DTkniFX0bflTOz9p/1vkkFUHwMwsf0OEyFbj30nKL911n+IbP HpbBQA9KHqqZWml2prV6BWjV6q8n2RfHJDSGBfK4xMWqAF8wx2N6Dv3ZGVqIo56t8W+X Nsemiw3MYT44oul/bGG9WXZrnLBTaSvJMDaTSYG+LRx0Av9PO59OjKjykBjEr9syvSgv sGqg== MIME-Version: 1.0 X-Received: by 10.50.37.236 with SMTP id b12mr384865igk.42.1363745519934; Tue, 19 Mar 2013 19:11:59 -0700 (PDT) Received: by 10.50.193.133 with HTTP; Tue, 19 Mar 2013 19:11:59 -0700 (PDT) X-Originating-IP: [96.23.59.4] In-Reply-To: <39B5E4D390E9BD4890E2B310790061010A7AFD@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B310790061010A7AFD@ESESSMB301.ericsson.se> Date: Tue, 19 Mar 2013 22:11:59 -0400 Message-ID: From: Dan Mongrain To: "ecrit@ietf.org" Content-Type: multipart/alternative; boundary=f46d044788d947bbf804d851bf40 X-Gm-Message-State: ALoCoQnrq7MCWE1gx6AC98XrcY5nWlwVmq90EDOJL5W+AbFDfBx8P2fB42BxJH/AIMz2hCjIuphC Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels) 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 Mar 2013 02:12:08 -0000 --f46d044788d947bbf804d851bf40 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable I am currently writing a draft that will specify jurisdictional scope for a Service URN. I hope to have it completed and published early next week. As I have suggested previously it documents the addition of a PIDF-LO civic tag at the end of a Service URN to specify a specific jurisdiction in the case multiple jurisdictions offer the service. I think that by proceeding this way, it alleviates the need to register multiple combinations of Service URNs and jurisdictional scopes. We can still register the generic Service URNs (sos.police.traffic, sos.fire.highrise, etc.) and in locations where the service is offered by multiple jurisdictions then one can add the jurisdictional scope at the end of the Service URN. Dan On Tue, Mar 19, 2013 at 1:38 PM, Ivo Sedlacek wr= ote: > Hello, > > I am the author of the IANA registration request. > > I would be happy with "country" instead of "national" in the URN, if > that's the experts' preference. > I would also be happy with "A3" instead of "local" in the URN, if that's > the experts' preference. > > I.e. > - urn:service:sos.police.country - The 'police.national' service refers t= o > the emergency service offered by the police department or other law > enforcement authorities of the government of a country. > - 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). > > Do I need to send another IANA registration request or can the IANA > existing registration request be modified? > > 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 > Rosen, Brian > Sent: 19. b=F8ezna 2013 17:46 > To: Marc Linsner > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment > (urn-serviceid-labels) > > Yes > > In my opinion, urn:service:sos.police.national should be registered, > although I would prefer the term "country" for reasons detailed below. > > I do not believe urn:service:sos.police.local should be registered, > because the term "local" is ambiguous in many countries and regions. In > some areas, there are multiple levels of "local" that may have separate > service URLs. For example, you could have state, county and municipal > police agencies, any of which could be considered "local". > > While an expert does not usually supply alternatives, I think the ecrit > work group has considered the suggestion to use the "A" levels in PIDF-LO > to denote the levels of "local". So, for example, > urn:service:sos.police.a2 would be the county police, assuming A1 was > state, A2 was county and A3 was city. One could speculate whether > urn:service:sos.police.a6 (neighborhood) was useful for anything, but the= re > are "neighborhood watch" organizations that might qualify, and "vigilante= " > is probably not a good registration. > > Using the "A" levels leads you to use "country" as that is the top level > name for the field in PIDF-LO. "national" is an obvious synonym, and I > think it's okay to use it. > > However, "local" is ambiguous. > > Brian > > On Mar 19, 2013, at 12:32 PM, Marc Linsner > wrote: > > > Brian, > > > > Would you please provide a review of this IANA request for registration= s. > > > > Thanks, > > > > Marc & Roger > > > > -----Original Message----- > > From: Amanda Baber via RT > > Reply-To: > > Date: Friday, February 15, 2013 6:34 PM > > Cc: > > Subject: [IANA #658921] General Request for Assignment > > (urn-serviceid-labels) > > Resent-From: > > Resent-To: , > > Resent-Date: Fri, 15 Feb 2013 23:22:12 +0000 > > > >> Dear Marc and Roger, > >> > >> IANA just received a request for two registrations in the 'sos' > >> Sub-Services registry at > >> http://www.iana.org/assignments/urn-serviceid-labels, which has the > >> ECRIT working group listed as its expert reviewer. > >> > >> Can you ask the working group to review the request below? If these > >> are OK, how should we fill out the Description fields in the registry? > >> > >> thanks, > >> > >> Amanda Baber > >> IANA Request Specialist > >> ICANN > >> > >> =3D=3D=3D > >> > >> Contact Name: > >> Ivo Sedlacek > >> > >> Contact Email: > >> ivo.sedlacek@ericsson.com > >> > >> Type of Assignment: > >> Assignment of an service URN with the 'sos' service type as specified > >> in RFC5031, section 4.2. > >> > >> The following service URNs are proposed to be registered: > >> - 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. > >> > >> Registry: > >> Service URN Labels, 'sos' Sub-Services as shown at > >> > http://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-labels= . > >> xml > >> > >> Description: > >> In the Czech republic and Poland, there are two public safety > >> answering points (PSAP) offering the police related emergency > >> services. The PSAP of the municipal police and the PSAP of the > >> national police. There is currently no way how to distinguish whether > >> the user wishes to contact the PSAP of the municipal police or the PSA= P > of the national police. > >> > >> In Czech, the related regulation is > >> http://aplikace.mvcr.cz/sbirka-zakonu/ViewFile.aspx?type=3Dc&id=3D5134 > >> pages > >> 9 and 10 section 4.5 which lists the number 156 for "Obecn=ED policie" > >> (=3D municipal police) and the numbers 158 for "Policie =C8esk=E9 > >> republiky" (=3D Czech republic police). Both numbers are listed with > >> note 2) which states "=C8=EDslo je n=E1rodn=EDm =E8=EDslem pro t=EDs= =F2ov=E9 vol=E1n=ED" (=3D > >> the number is a national number for emergency calls). > >> > >> In Poland, > >> http://uke.gov.pl/tablice-numerow-kierowania-alarmowego-nka-9410 > >> lists the number 986 for "stra=BF miejska" (=3D municipal police) and = the > >> number > >> 997 for Policja (=3D police) as "numery alarmowe" (=3D emergency numbe= rs). > >> > >> Additional Info: > >> The registry is defined by RFC5031, section 4.2 > > > > > > _______________________________________________ > 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 > --f46d044788d947bbf804d851bf40 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable I am currently writing a draft that will specify jurisdictional scope for a= Service URN.=A0 I hope to have it completed and published early next week.= =A0 As I have suggested previously it documents the addition of a PIDF-LO c= ivic tag at the end of a Service URN to specify a specific jurisdiction in = the case multiple jurisdictions offer the service.=A0 I think that by proce= eding this way, it alleviates the need to register multiple combinations of= Service URNs and jurisdictional scopes.=A0 We can still register the gener= ic Service URNs (sos.police.traffic, sos.fire.highrise, etc.) and in locati= ons where the service is offered by multiple jurisdictions then one can add= the jurisdictional scope at the end of the Service URN.

Dan

On Tue, Mar 19, 2013 at 1:38 PM, = Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Hello,

I am the author of the IANA registration request.

I would be happy with "country" instead of "national" i= n the URN, if that's the experts' preference.
I would also be happy with "A3" instead of "local" in t= he URN, if that's the experts' preference.

I.e.
- 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.
- urn:service:sos.police.A3 - The 'police.local' service refers to = the emergency service offered by the police department or other law enforce= ment authorities of the authorities of a city, township, shi (JP).

Do I need to send another IANA registration request or can the IANA existin= g registration request be modified?

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 Rosen, Brian
Sent: 19. b=F8ezna 2013 17:46
To: Marc Linsner
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-ser= viceid-labels)

Yes

In my opinion, urn:service:sos.police.national should be registered, althou= gh I would prefer the term "country" for reasons detailed below.<= br>
I do not believe urn:service:sos.police.local should be registered, because= the term "local" is ambiguous in many countries and regions. =A0= In some areas, there are multiple levels of "local" that may have= separate service URLs. =A0For example, you could have state, county and mu= nicipal police agencies, any of which could be considered "local"= .

While an expert does not usually supply alternatives, I think the ecrit wor= k group has considered the suggestion to use the "A" levels in PI= DF-LO to denote the levels of "local". =A0So, for example, urn:se= rvice:sos.police.a2 would be the county police, assuming A1 was state, A2 w= as county and A3 was city. =A0One could speculate whether urn:service:sos.p= olice.a6 (neighborhood) was useful for anything, but there are "neighb= orhood watch" organizations that might qualify, and "vigilante&qu= ot; is probably not a good registration.

Using the "A" levels leads you to use "country" as that= is the top level name for the field in PIDF-LO. =A0"national" is= an obvious synonym, and I think it's okay to use it.

However, "local" is ambiguous.

Brian

On Mar 19, 2013, at 12:32 PM, Marc Linsner <mlinsner@cisco.com>
=A0wrote:

> Brian,
>
> Would you please provide a review of this IANA request for registratio= ns.
>
> Thanks,
>
> Marc & Roger
>
> -----Original Message-----
> From: Amanda Baber via RT <iana-prot-param-comment@iana.org>
> Reply-To: <iana= -prot-param-comment@iana.org>
> Date: Friday, February 15, 2013 6:34 PM
> Cc: <ecrit-chairs@to= ols.ietf.org>
> Subject: [IANA #658921] General Request for Assignment
> (urn-serviceid-labels)
> Resent-From: <wg= -alias-bounces@tools.ietf.org>
> Resent-To: <rmarshall@t= elecomsys.com>, <marc.l= insner@cisco.com>
> Resent-Date: Fri, 15 Feb 2013 23:22:12 +0000
>
>> Dear Marc and Roger,
>>
>> IANA just received a request for two registrations in the 'sos= '
>> Sub-Services registry at
>> http://www.iana.org/assignments/urn-serviceid-labels, = which has the
>> ECRIT working group listed as its expert reviewer.
>>
>> Can you ask the working group to review the request below? If thes= e
>> are OK, how should we fill out the Description fields in the regis= try?
>>
>> thanks,
>>
>> Amanda Baber
>> IANA Request Specialist
>> ICANN
>>
>> =3D=3D=3D
>>
>> Contact Name:
>> Ivo Sedlacek
>>
>> Contact Email:
>> ivo.sedlacek@ericsson= .com
>>
>> Type of Assignment:
>> Assignment of an service URN with the 'sos' service type a= s specified
>> in RFC5031, section 4.2.
>>
>> The following service URNs are proposed to be registered:
>> - urn:service:sos.police.local - The 'police.local' servic= e refers 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 the police department o= r
>> other law enforcement authorities of the national government.
>>
>> Registry:
>> Service URN Labels, 'sos' Sub-Services as shown at
>> http://www.iana.org/assignments/urn-s= erviceid-labels/urn-serviceid-labels.
>> xml
>>
>> Description:
>> In the Czech republic and Poland, there are two public safety
>> answering points (PSAP) offering the police related emergency
>> services. The PSAP of the municipal police and the PSAP of the
>> national police. There is currently no way how to distinguish whet= her
>> the user wishes to contact the PSAP of the municipal police or the= PSAP of the national police.
>>
>> In Czech, the related regulation is
>> http://aplikace.mvcr.cz/sbirka-zakon= u/ViewFile.aspx?type=3Dc&id=3D5134
>> pages
>> 9 and 10 section 4.5 which lists the number 156 for "Obecn=ED= policie"
>> (=3D municipal police) and the numbers 158 for "Policie =C8es= k=E9
>> republiky" (=3D Czech republic police). Both numbers are list= ed with
>> note 2) which states "=C8=EDslo je n=E1rodn=EDm =E8=EDslem pr= o t=EDs=F2ov=E9 vol=E1n=ED" (=3D
>> the number is a national number for emergency calls).
>>
>> In Poland,
>> http://uke.gov.pl/tablice-numerow-kierowania-a= larmowego-nka-9410
>> lists the number 986 for "stra=BF miejska" (=3D municipa= l police) and the
>> number
>> 997 for Policja (=3D police) as "numery alarmowe" (=3D e= mergency numbers).
>>
>> Additional Info:
>> The registry is defined by RFC5031, section 4.2
>
>

_______________________________________________
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

--f46d044788d947bbf804d851bf40-- From James.Winterbottom@commscope.com Tue Mar 19 19:28: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 71F0121F8D19 for ; Tue, 19 Mar 2013 19:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyPqYLkPMWGU for ; Tue, 19 Mar 2013 19:28:36 -0700 (PDT) Received: from cdcsmgw01.commscope.com (cdcsmgw01.commscope.com [198.135.207.232]) by ietfa.amsl.com (Postfix) with ESMTP id 642A021F8C9E for ; Tue, 19 Mar 2013 19:28:35 -0700 (PDT) X-AuditID: 0a0404e8-b7f486d00000082e-a0-51491ed1a982 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Messaging Gateway) with SMTP id 40.8A.02094.1DE19415; Tue, 19 Mar 2013 21:28:33 -0500 (CDT) 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 Mar 2013 21:28:32 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 20 Mar 2013 10:28:30 +0800 From: "Winterbottom, James" To: Dan Mongrain , "ecrit@ietf.org" Date: Wed, 20 Mar 2013 10:28:28 +0800 Thread-Topic: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels) Thread-Index: Ac4lEFfjfUb84qjHQKm/DfQrODad4wAATydw Message-ID: <5A55A45AE77F5941B18E5457ECAC8188012140883295@SISPE7MB1.commscope.com> References: <39B5E4D390E9BD4890E2B310790061010A7AFD@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_5A55A45AE77F5941B18E5457ECAC8188012140883295SISPE7MB1co_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGKsWRmVeSWpSXmKPExsXCFSaSrntRzjPQYMIrI4v7c1pYLBoXPWV1 YPJYsuQnk8eLbQoBTFFcNimpOZllqUX6dglcGSdn+xVc2M5YMXPpW5YGxl3zGbsYOTkkBEwk rsxexAJhi0lcuLeerYuRi0NIYDejxLyfvxghnA2MEnOX/mKGcNYzSize8IAJpIVNwE7i8Pob zCC2iICbxMXNjWBxFgFVia83+9hAbGGBaIn/13YCreAAqomRWDHXHKLcSKLhZANYK69AkMTM lvlgVwgJvGWUmPpcEcTmFAiUaJr7B+xSRqDrvp9aAzaeWUBc4taT+UwQVwtILNlznhnCFpV4 +fgfK0S9qMSd9vWMEPX5EvuedbFC7BKUODnzCdQuXYmmnV9ZJzCKzUIydhaSlllIWiDiehLP Ts2CsrUlli18zQxh60pceriOFVl8ASP7Kkbx5JTk4tz0cgNDveT83Nzi5PyCVBBrEyMoGllY XuxgPL1B+xCjAAejEg/vi9kegUKsiWXFlbmHGCU5mJREeT9LeAYK8SXlp1RmJBZnxBeV5qQW H2KU4GBWEuH9cg2onDclsbIqtSgfJqXBwSFw+sn9U4xSLHn5ealKErzawIQiJFiUmp5akZaZ A0xFMKVMHJwgo3iARomA1PAWFyTmFmemQ+RPMWpzzHj96AUjR/Py5y8YhcDGSYnzfpUFKhUA Kc0ozYOb9opRHOgFYV5RkEE8wMQKN+cV0AomoBU39ruBrChJREhJNTBqb/nrG85ucuYQ07qM 782rYyb53IhiLbhiUTvh8X/vvbse+skZ2boXHcs7emBv2ixZjcWmv8SMGII9XpzdUmKaLb7d 1XHyJuaSeCeurAtfljKFlCYz3/OdINz1hisucOaE2mlfn21+5bv8ekjv4iOBCU6vphZYPf45 Y0X6xLl8TLz7Ks5Nf39ciaU4I9FQi7moOBEASlZL32kDAAA= Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels) 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 Mar 2013 02:28:41 -0000 --_000_5A55A45AE77F5941B18E5457ECAC8188012140883295SISPE7MB1co_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable This question isn't specific to Dan, but more to the wider ECRIT community = on ever decreasing service URNs. For NENA i3 today, if I provide a LIS I must validate all civic locations a= gainst an LVF. This essentially issues a LoST findService request against t= he civic location with the specific service URN I am interested in, which a= t present is just urn:service:sos. When requesting a location from a LIS, there is no way to say that I want a= location for a specific service type. Sooooo I want to make 100% sure that= everybody is aware and in agreement that if a civic location is validated = against urn:service:sos that it has to be valid for any subordinate service= identified in this service urn tree. Cheers James From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of D= an Mongrain Sent: Wednesday, 20 March 2013 1:12 PM To: ecrit@ietf.org Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-ser= viceid-labels) I am currently writing a draft that will specify jurisdictional scope for a= Service URN. I hope to have it completed and published early next week. = As I have suggested previously it documents the addition of a PIDF-LO civic= tag at the end of a Service URN to specify a specific jurisdiction in the = case multiple jurisdictions offer the service. I think that by proceeding = this way, it alleviates the need to register multiple combinations of Servi= ce URNs and jurisdictional scopes. We can still register the generic Servi= ce URNs (sos.police.traffic, sos.fire.highrise, etc.) and in locations wher= e the service is offered by multiple jurisdictions then one can add the jur= isdictional scope at the end of the Service URN. Dan On Tue, Mar 19, 2013 at 1:38 PM, Ivo Sedlacek > wrote: Hello, I am the author of the IANA registration request. I would be happy with "country" instead of "national" in the URN, if that's= the experts' preference. I would also be happy with "A3" instead of "local" in the URN, if that's th= e experts' preference. I.e. - 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. - 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). Do I need to send another IANA registration request or can the IANA existin= g registration request be modified? 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-b= ounces@ietf.org] On Behalf Of Rosen, Brian Sent: 19. b=F8ezna 2013 17:46 To: Marc Linsner Cc: ecrit@ietf.org Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-ser= viceid-labels) Yes In my opinion, urn:service:sos.police.national should be registered, althou= gh I would prefer the term "country" for reasons detailed below. I do not believe urn:service:sos.police.local should be registered, because= the term "local" is ambiguous in many countries and regions. In some area= s, there are multiple levels of "local" that may have separate service URLs= . For example, you could have state, county and municipal police agencies,= any of which could be considered "local". While an expert does not usually supply alternatives, I think the ecrit wor= k group has considered the suggestion to use the "A" levels in PIDF-LO to d= enote the levels of "local". So, for example, urn:service:sos.police.a2 wo= uld be the county police, assuming A1 was state, A2 was county and A3 was c= ity. One could speculate whether urn:service:sos.police.a6 (neighborhood) = was useful for anything, but there are "neighborhood watch" organizations t= hat might qualify, and "vigilante" is probably not a good registration. Using the "A" levels leads you to use "country" as that is the top level na= me for the field in PIDF-LO. "national" is an obvious synonym, and I think= it's okay to use it. However, "local" is ambiguous. Brian On Mar 19, 2013, at 12:32 PM, Marc Linsner > wrote: > Brian, > > Would you please provide a review of this IANA request for registrations. > > Thanks, > > Marc & Roger > > -----Original Message----- > From: Amanda Baber via RT > > Reply-To: > > Date: Friday, February 15, 2013 6:34 PM > Cc: > > Subject: [IANA #658921] General Request for Assignment > (urn-serviceid-labels) > Resent-From: > > Resent-To: >, <= marc.linsner@cisco.com> > Resent-Date: Fri, 15 Feb 2013 23:22:12 +0000 > >> Dear Marc and Roger, >> >> IANA just received a request for two registrations in the 'sos' >> Sub-Services registry at >> http://www.iana.org/assignments/urn-serviceid-labels, which has the >> ECRIT working group listed as its expert reviewer. >> >> Can you ask the working group to review the request below? If these >> are OK, how should we fill out the Description fields in the registry? >> >> thanks, >> >> Amanda Baber >> IANA Request Specialist >> ICANN >> >> =3D=3D=3D >> >> Contact Name: >> Ivo Sedlacek >> >> Contact Email: >> ivo.sedlacek@ericsson.com >> >> Type of Assignment: >> Assignment of an service URN with the 'sos' service type as specified >> in RFC5031, section 4.2. >> >> The following service URNs are proposed to be registered: >> - 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. >> >> Registry: >> Service URN Labels, 'sos' Sub-Services as shown at >> http://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-label= s. >> xml >> >> Description: >> In the Czech republic and Poland, there are two public safety >> answering points (PSAP) offering the police related emergency >> services. The PSAP of the municipal police and the PSAP of the >> national police. There is currently no way how to distinguish whether >> the user wishes to contact the PSAP of the municipal police or the PSAP = of the national police. >> >> In Czech, the related regulation is >> http://aplikace.mvcr.cz/sbirka-zakonu/ViewFile.aspx?type=3Dc&id=3D5134 >> pages >> 9 and 10 section 4.5 which lists the number 156 for "Obecn=ED policie" >> (=3D municipal police) and the numbers 158 for "Policie =C8esk=E9 >> republiky" (=3D Czech republic police). Both numbers are listed with >> note 2) which states "=C8=EDslo je n=E1rodn=EDm =E8=EDslem pro t=EDs=F2o= v=E9 vol=E1n=ED" (=3D >> the number is a national number for emergency calls). >> >> In Poland, >> http://uke.gov.pl/tablice-numerow-kierowania-alarmowego-nka-9410 >> lists the number 986 for "stra=BF miejska" (=3D municipal police) and th= e >> number >> 997 for Policja (=3D police) as "numery alarmowe" (=3D emergency numbers= ). >> >> Additional Info: >> The registry is defined by RFC5031, section 4.2 > > _______________________________________________ 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_5A55A45AE77F5941B18E5457ECAC8188012140883295SISPE7MB1co_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

This ques= tion isn’t specific to Dan, but more to the wider ECRIT community on = ever decreasing service URNs.

 

For NENA i3 tod= ay, if I provide a LIS I must validate all civic locations against an LVF. = This essentially issues a LoST findService request against the civic locati= on with the specific service URN I am interested in, which at present is ju= st urn:service:sos.

 

When requesting a locat= ion from a LIS, there is no way to say that I want a location for a specifi= c service type. Sooooo I want to make 100% sure that everybody is aware and= in agreement that if a civic location is validated against urn:service:sos= that it has to be valid for any subordinate service identified in this ser= vice urn tree.

 =

Cheers

James

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

 

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@= ietf.org] On Behalf Of Dan Mongrain
Sent: Wednesday, 20 Ma= rch 2013 1:12 PM
To: ecrit@ietf.org
Subject: Re: [Ecrit= ] [IANA #658921] General Request for Assignment (urn-serviceid-labels)=

 

I am currently writing a draft = that will specify jurisdictional scope for a Service URN.  I hope to h= ave it completed and published early next week.  As I have suggested p= reviously it documents the addition of a PIDF-LO civic tag at the end of a = Service URN to specify a specific jurisdiction in the case multiple jurisdi= ctions offer the service.  I think that by proceeding this way, it all= eviates the need to register multiple combinations of Service URNs and juri= sdictional scopes.  We can still register the generic Service URNs (so= s.police.traffic, sos.fire.highrise, etc.) and in locations where the servi= ce is offered by multiple jurisdictions then one can add the jurisdictional= scope at the end of the Service URN.

Dan

On Tue, Mar 19, 2013 at 1:38 PM, Ivo Sedlacek <ivo.sedlacek@ericsson.c= om> wrote:

Hello,

I am the= author of the IANA registration request.

I would be happy with &quo= t;country" instead of "national" in the URN, if that's the e= xperts' preference.
I would also be happy with "A3" instead of= "local" in the URN, if that's the experts' preference.

I.= e.
- 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.
- urn:service:sos= .police.A3 - The 'police.local' service refers to the emergency service off= ered by the police department or other law enforcement authorities of the a= uthorities of a city, township, shi (JP).

Do I need to send another = IANA registration request or can the IANA existing registration request be = modified?

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 Messa= ge-----
From: ecrit-bounces@ie= tf.org [mailto:ecrit-bounces@= ietf.org] On Behalf Of Rosen, Brian
Sent: 19. b=F8ezna 2013 17:46To: Marc Linsner
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (u= rn-serviceid-labels)

Yes

In my opinion, urn:service:sos.polic= e.national should be registered, although I would prefer the term "cou= ntry" for reasons detailed below.

I do not believe urn:service:= sos.police.local should be registered, because the term "local" i= s ambiguous in many countries and regions.  In some areas, there are m= ultiple levels of "local" that may have separate service URLs. &n= bsp;For example, you could have state, county and municipal police agencies= , any of which could be considered "local".

While an exper= t does not usually supply alternatives, I think the ecrit work group has co= nsidered the suggestion to use the "A" levels in PIDF-LO to denot= e the levels of "local".  So, for example, urn:service:sos.p= olice.a2 would be the county police, assuming A1 was state, A2 was county a= nd A3 was city.  One could speculate whether urn:service:sos.police.a6= (neighborhood) was useful for anything, but there are "neighborhood w= atch" organizations that might qualify, and "vigilante" is p= robably not a good registration.

Using the "A" levels lead= s you to use "country" as that is the top level name for the fiel= d in PIDF-LO.  "national" is an obvious synonym, and I think= it's okay to use it.

However, "local" is ambiguous.
Brian

On Mar 19, 2013, at 12:32 PM, Marc Linsner <mlinsner@cisco.com>
 wrote:

= > Brian,
>
> Would you please provide a review of this IANA = request for registrations.
>
> Thanks,
>
> Marc &am= p; Roger
>
> -----Original Message-----
> From: Amanda Ba= ber via RT <iana-pro= t-param-comment@iana.org>
> Reply-To: <iana-prot-param-comment@iana.org>> Date: Friday, February 15, 2013 6:34 PM
> Cc: <ecrit-chairs@tools.ietf.org>
&g= t; Subject: [IANA #658921] General Request for Assignment
> (urn-serv= iceid-labels)
> Resent-From: <wg-alias-bounces@tools.ietf.org>
> Resent-To: &= lt;rmarshall@telecomsys.com= >, <marc.linsner@cisco.com<= /a>>
> Resent-Date: Fri, 15 Feb 2013 23:22:12 +0000
>
>= ;> Dear Marc and Roger,
>>
>> IANA just received a req= uest for two registrations in the 'sos'
>> Sub-Services registry a= t
>> http://www.iana.org/assignments/urn-serviceid-labels<= /a>, which has the
>> ECRIT working group listed as its expert rev= iewer.
>>
>> Can you ask the working group to review the = request below? If these
>> are OK, how should we fill out the Desc= ription fields in the registry?
>>
>> thanks,
>>=
>> Amanda Baber
>> IANA Request Specialist
>> I= CANN
>>
>> =3D=3D=3D
>>
>> Contact Name= :
>> Ivo Sedlacek
>>
>> Contact Email:
>&g= t; ivo.sedlacek@ericsson.com
>>
>> Type of Assignment:
>> Assignment of an= service URN with the 'sos' service type as specified
>> in RFC503= 1, section 4.2.
>>
>> The following service URNs are prop= osed to be registered:
>> - urn:service:sos.police.local - The 'po= lice.local' service refers to
>> the emergency service offered by = the police department or other law
>> enforcement authorities of t= he local or municipal authorities.
>> - urn:service:sos.police.nat= ional - The 'police.national' service
>> refers to the emergency s= ervice offered by the police department or
>> other law enforcemen= t authorities of the national government.
>>
>> Registry:=
>> Service URN Labels, 'sos' Sub-Services as shown at
>>= http://www.iana.org/assignments/urn-serviceid= -labels/urn-serviceid-labels.
>> xml
>>
>> D= escription:
>> In the Czech republic and Poland, there are two pub= lic safety
>> answering points (PSAP) offering the police related = emergency
>> services. The PSAP of the municipal police and the PS= AP of the
>> national police. There is currently no way how to dis= tinguish whether
>> the user wishes to contact the PSAP of the mun= icipal police or the PSAP of the national police.
>>
>> I= n Czech, the related regulation is
>> http://aplikace.mvcr.cz/sbirka-zakonu/ViewFile.aspx?type=3Dc&id=3D513= 4
>> pages
>> 9 and 10 section 4.5 which lists the nu= mber 156 for "Obecn=ED policie"
>> (=3D municipal police= ) and the numbers 158 for "Policie =C8esk=E9
>> republiky&quo= t; (=3D Czech republic police). Both numbers are listed with
>> no= te 2) which states "=C8=EDslo je n=E1rodn=EDm =E8=EDslem pro t=EDs=F2o= v=E9 vol=E1n=ED" (=3D
>> the number is a national number for = emergency calls).
>>
>> In Poland,
>> http://uke.gov.pl/tablice-numerow-kierowania-alarmowego-nka-941= 0
>> lists the number 986 for "stra=BF miejska" (=3D= municipal police) and the
>> number
>> 997 for Policja (= =3D police) as "numery alarmowe" (=3D emergency numbers).
>= >
>> Additional Info:
>> The registry is defined by RF= C5031, section 4.2
>
>

_________________________________= ______________
Ecrit mailing list
E= crit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
____= ___________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailm= an/listinfo/ecrit

 <= /o:p>

= --_000_5A55A45AE77F5941B18E5457ECAC8188012140883295SISPE7MB1co_-- From James.Winterbottom@commscope.com Tue Mar 19 20:43: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 C621721F8F28 for ; Tue, 19 Mar 2013 20:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Kf99zoSmfxi for ; Tue, 19 Mar 2013 20:43:30 -0700 (PDT) Received: from cdcsmgw02.commscope.com (cdcsmgw02.commscope.com [198.135.207.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFEE21F8CEF for ; Tue, 19 Mar 2013 20:43:30 -0700 (PDT) X-AuditID: 0a0404e9-b7f996d000000830-fe-5149305f97bc Received: from CDCE10HC1.commscope.com ( [10.86.28.21]) by cdcsmgw02.commscope.com (Symantec Messaging Gateway) with SMTP id 18.C7.02096.F5039415; Tue, 19 Mar 2013 22:43:27 -0500 (CDT) 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 Mar 2013 22:43:27 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 20 Mar 2013 11:43:24 +0800 From: "Winterbottom, James" To: "ecrit@ietf.org" Date: Wed, 20 Mar 2013 11:43:23 +0800 Thread-Topic: Additional Data -07 Thread-Index: Ac4lHRKZXzsTcTjhT22kXBt5KTmklQ== Message-ID: <5A55A45AE77F5941B18E5457ECAC81880121408832BB@SISPE7MB1.commscope.com> 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+NgFprOKsWRmVeSWpSXmKPExsXCFSYjqhtv4BlosOWGsUXjoqesDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKmDX1HkvBa5mK/Rd/MDUwvhPvYuTkkBAwkVjR2coOYYtJXLi3 nq2LkYtDSGAXo8SV74fYIZwNjBKb7kyEctYzSjTfvMUM0sImYCdxeP0NMFtEQFViw5mVjCA2 C5D9ddUrVhBbWEBW4nLHdTaIGiWJhvU/WSBsPYk//WuZQGxegSCJh1NmgPUyAp3x/dQasDiz gLjErSfzmSDOE5BYsuc8M4QtKvHy8T9WiHpRiTvt6xkh6nUkFuz+xAZha0ssW/iaGWK+oMTJ mU/A9goJ6Eo07fzKOoFRdBaSFbOQtM9C0j4LSfsCRpZVjOLJKcnFuenlBkZ6yfm5ucXJ+QWp INYmRlBssLC83MF4doP2IUYBDkYlHt4Xsz0ChVgTy4orcw8xSnIwKYnyqmh5BgrxJeWnVGYk FmfEF5XmpBYfYpTgYFYS4f1yDaicNyWxsiq1KB8mpcHBIXD6yf1TjFIsefl5qUoSvOL6QCME i1LTUyvSMnOAiQGmlImDE2QUD9CoTj2gGt7igsTc4sx0iPwpRlWO5uXPXzAKgQ2SEud9DVIk AFKUUZoHN+cVozjQ8cK8h0CyPMDUBjfhFdBwJqDhN/a7gQwvSURISTUwqh7X+v9KQu3plKw1 ea+lTc54/+/hCCrqD9UMsYwxTt4jPOGik0jnhjWpV6ROGvgbKmtP0jnYqeD4Y5YAq0Hd6Z9J z3rqX8zfV6dV9fz/o6YsgYTXE5/Nbnn05nm/hbH7Q/n4/QX2aWqTddRFjSZtnPEnIGSd04ZZ 7w/yXMyyW1T59Mf0BYy/lViKMxINtZiLihMBZEXgfCoDAAA= Subject: [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: Wed, 20 Mar 2013 03:43:30 -0000 Hi Authors, It is quite possible that I am misunderstanding things here and how the new= Provided-By schema defined in section 14.3.1 is intended to be used, so le= t me present my use case. The Location interworking Function (LIF) in NENA i3 essentially needs to be= able to serve up existing ALI records but broken up into locations and add= itional data. The additional data that needs to be provided maps into sever= al of the additional data XML containers defined in this document. What I need to be able to do is to return: 1) A single structure with multiple URIs each URI to a different container = type. 2) A single XML container with the actual XML structures I want. What is provided doesn't seem to let me do that easily, and certainly isn't= obvious. I would like to propose the following schema as a replacement for what is c= urrently in the document. =09 =09 =09 =09 This schema lets you send a single reference, or multiple references, as we= ll as a single XML container with all the relevant blocks and provides exte= nsions points. I think that this still meets the original intent. Cheers James =20 From rlb@ipv.sx Tue Mar 19 21:29: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 3A59221F8CC8 for ; Tue, 19 Mar 2013 21:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.424 X-Spam-Level: X-Spam-Status: No, score=0.424 tagged_above=-999 required=5 tests=[AWL=-0.933, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ik2f+KCyKAga for ; Tue, 19 Mar 2013 21:29:28 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 95A1721F8CEF for ; Tue, 19 Mar 2013 21:29:28 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id dn14so1224547obc.32 for ; Tue, 19 Mar 2013 21:29:28 -0700 (PDT) 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=9y+Jvj9FFDJVZj0BKq+1u+OLyq2GC0BE3GQAsIP0H/Q=; b=HG16m9VffRhJbO8jIhp/ThCpq5mv/Xqw+xf1LQKMNhizgpSTq8PQP2XjOTzTUacgea yVroDcOJuvyzTpdojY9maWJBl1LFBXhn94X2/T+LoWKCX8HewVntH6v8E6eFW/8F2RZ/ sigymeIhd01BuTqElgZBoDo21biuahLxVoa+0KnS0GE+8q3H4w5VX8gy40RkZ5Q2GWgT d4sMPn5ZR5zX0vLbNpuRMnflVXe2+JCG8X5LHLCFAA83aG2crChFWjBYyCqAdJ5vFIiU bYdAB1na9ktBYg86mc18ruB4npnC6AUnpmGt31hs0a4Adbqx4Eyn4Gj14Gwj4VuX9iWU Xkew== MIME-Version: 1.0 X-Received: by 10.60.9.1 with SMTP id v1mr3069626oea.130.1363753768047; Tue, 19 Mar 2013 21:29:28 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Tue, 19 Mar 2013 21:29:27 -0700 (PDT) X-Originating-IP: [108.18.40.68] In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B12C63C@ESESSMB209.ericsson.se> <155970D1DA8E174F9E46039E10E2AA35D24AAE@XMB103ADS.rim.net> <39B5E4D390E9BD4890E2B310790061010A7A26@ESESSMB301.ericsson.se> <155970D1DA8E174F9E46039E10E2AA35D253A6@XMB103ADS.rim.net> Date: Wed, 20 Mar 2013 00:29:27 -0400 Message-ID: From: Richard Barnes To: "Rosen, Brian" Content-Type: multipart/alternative; boundary=e89a8fb20318e82b8a04d853aadf X-Gm-Message-State: ALoCoQn1gYISaNVuCIK1H+wk1zxQIpAvWtgWc7gljQrKQEJNCZMAEMgJbTapzaDqKQqd4Qu96W3q Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-02 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 Mar 2013 04:29:32 -0000 --e89a8fb20318e82b8a04d853aadf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 Part of the point of these identifiers is that they don't have detailed specifications. That way "urn:sos:ambulance" can cover both the Kentucky and Brussels ambulance services even if the Kentucky service is a volunteer service that only works Tuesdays and the Brussels service offers you a complimentary waffle en route to the hospital. In less frivolous words, minor service differences shouldn't require separate identifiers. On Tue, Mar 19, 2013 at 4:41 PM, Rosen, Brian wrot= e: > I think we have a problem here. We don't require "specification" and we > don't have adequate descriptions in the registry. > > I am loath to require specification for this registry. So, I suggest we > expand "description" to a larger piece of text, and supply advice to the > expert to evaluate the adequacy of the explanation. We could copy text o= ut > of the RFC to start this process. > > Brian > > On Mar 19, 2013, at 4:33 PM, John-Luc Bakker > wrote: > > Hi Ivo,**** > > Thanks for the quick response.**** > The IANA web page has for =E2=80=9Curn:service:sos.mountain=E2=80=9D the= following * > description* =E2=80=9CMountain rescue=E2=80=9D and a link to the RFC. The= RFC then has > the following *description of the caller expectation in terms of services > rendered*:**** > > The 'mountain' service refers to mountain**** > rescue services (i.e., search and rescue activities that occur in*= * > ** > a mountainous environment), although the term is sometimes also***= * > used to apply to search and rescue in other wilderness**** > environments.**** > > In my opinion, according to the RFC, =E2=80=9Curn:service:sos.mountain= =E2=80=9D could > also be applied to emergencies in caves/sink holes (i.e. no need for a > mountainous terrain), although such use would not be immediately apparent > from the description on the IANA web page that has the registry for Servi= ce > URN Labels.**** > > Perhaps the issue is that the IANA web page that has the registry for Se= rvice > URN Labels misses some information that is found in the RFC.**** > > Regards,**** > > JL**** > > *From:* Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] > *Sent:* Tuesday, March 19, 2013 11:02 AM > *To:* John-Luc Bakker; Christer Holmberg; ecrit@ietf.org > *Subject:* RE: [Ecrit] Draft new version: > draft-holmberg-ecrit-country-emg-urn-02**** > ** ** > Hello,**** > > > Will the caller expectation in terms of services rendered be > documented somewhere?**** > > The new policy proposed in draft-holmberg-ecrit-country-emg-urn-02 > section 5.3 states:**** > > 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.**** > > I.e. in the expert review, the service description and the URN are > reviewed. If approved, the service description and URN are listed in IANA= - > see > http://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-labels= .xml#urn-serviceid-labels-2 > **** > > 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 *John-Luc Bakker > *Sent:* 19. b=C5=99ezna 2013 16:12 > *To:* Christer Holmberg; ecrit@ietf.org > *Subject:* Re: [Ecrit] Draft new version: > draft-holmberg-ecrit-country-emg-urn-02**** > ** ** > Hi Christer,**** > > Thanks for this.**** > When a new URN is adopted via expert review, a description of the caller > expectation in terms of services rendered (for the new URN) cannot be fou= nd > in RFC 5031.**** > > For example, for the existing URN urn:service:sos.mountain, the RFC > includes:**** > > The 'mountain' service refers to mountain**** > rescue services (i.e., search and rescue activities that occur in*= * > ** > a mountainous environment), although the term is sometimes also***= * > used to apply to search and rescue in other wilderness**** > environments.**** > > Will the caller expectation in terms of services rendered be documented > somewhere?**** > Apologies if this query was already addressed during the ECRIT session = =E2=80=A6* > *** > > Kind regards,**** > > JL**** > > *From:* ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org > ] *On Behalf Of *Christer Holmberg > *Sent:* Tuesday, March 19, 2013 6:52 AM > *To:* ecrit@ietf.org > *Subject:* [Ecrit] Draft new version: > draft-holmberg-ecrit-country-emg-urn-02**** > ** ** > Hi,**** > > Based on the Orlando decision to move forward with the > relax-the-5031-registration-policy alternative for allowing emg URNs for > services offered in one country only, I=E2=80=99ve submitted an =E2=80=9C= official=E2=80=9D new > version (-02) of draft-holmberg-ecrit-country-emg-urn. Aside from some > minor changes caused by the new version of xml2rfc, the draft is identica= l > to the pre-02 version I distributed before the meeting.**** > ** ** > As was indicated in the meeting, additional text will still be needed, > but once the Orlando decision is verified on the list I hope we can adopt > the draft as base for the work.**** > ** ** > Thanks to everyone who provided comments during the meeting!**** > ** ** > Regards,**** > ** ** > Christer**** > --------------------------------------------------------------------- > 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 unlawf= ul. > **** > --------------------------------------------------------------------- > 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. _______________________________________________ > > 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 > > --e89a8fb20318e82b8a04d853aadf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1

Part of the point of these identifiers is that they d= on't have detailed specifications. =C2=A0That way "urn:sos:ambulan= ce" can cover both the Kentucky and Brussels ambulance services even i= f the Kentucky service is a volunteer service that only works Tuesdays and = the Brussels service offers you a complimentary waffle en route to the hosp= ital. =C2=A0In less frivolous words, minor service differences shouldn'= t require separate identifiers.



On Tue, M= ar 19, 2013 at 4:41 PM, Rosen, Brian <Brian.Rosen@neustar.biz>= ; wrote:
I think we have a problem here. =C2=A0We don't require "specificat= ion" and we don't have adequate descriptions in the registry.

I am loath to require specification for this registry. =C2=A0So, I sug= gest we expand "description" to a larger piece of text, and suppl= y advice to the expert to evaluate the adequacy of the explanation. =C2=A0W= e could copy text out of the RFC to start this process.

Brian

On Mar 19, 2013, at 4:33 PM, John-Luc Bakker <jbakker@blackberry.com> wrote= :

Hi Ivo,
=C2=A0
Thanks for the quick response.<= u>
The IANA web page has for =E2=80=9Curn:service:sos.mountain= =E2=80=9D the following=C2=A0description=C2=A0=E2=80=9CMountain rescue=E2=80=9D and a link to = the RFC. The RFC then has the following=C2=A0description of the caller expectation in term= s of services rendered:
=C2=A0
=C2=A0
In my opinion, according to the RFC, = =E2=80=9Curn:service:sos.mountain=E2=80=9D could also be applied to emergencies in caves/sink holes (i.e. no need for a mountainous terrain), although suc= h use would not be immediately apparent from the description on the IANA we= b page that has the registry for=C2=A0Service URN Labels.
=C2=A0
Perhaps the issue is that the IANA web= page that has the registry for=C2=A0Service URN Labels=C2=A0misses some information that is found in the RFC.
=C2=A0
Regards,
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 JL
=C2=A0
From:=C2= =A0Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com]=C2= =A0
Sent:=C2=A0Tuesday, March 19, 2013 11:02 AM
To:=C2=A0John-Luc Bakker; Christer Holmberg;=C2= =A0ecrit@ietf.org
Subject:=C2=A0RE: [Ecrit] Draft new version: draft-holm= berg-ecrit-country-emg-urn-02
=C2=A0
Hello,
=C2=A0
>=C2=A0Wi= ll the caller expectation in terms of services rendered be documented somew= here?
=C2=A0
The new policy proposed in draft-holmberg-ecrit-country-emg-urn-02 se= ction 5.3 states:
=C2=A0
=C2=A0=C2= =A0 The 'sos' service type describes emergency services requiring a= n
=C2=A0=C2= =A0 immediate response, typically offered by various branches of the=
=C2=A0=C2= =A0 government or other public institutions.=C2=A0 Additional sub-services = can
=C2=A0=C2= =A0 be added after expert review.=C2=A0 The expert is designated by the ECR= IT
=C2=A0=C2= =A0 working group, its successor, or, in their absence, the IESG.=C2=A0 The=
=C2=A0=C2= =A0 expert review should only approve=C2=A0services=C2=A0that have emergency
=C2=A0=C2= =A0 nature, that are offered in at least one country, that do not match<= /u>
=C2=A0=C2= =A0 description of any existing service URN with the 'sos' service = type,
=C2=A0=C2= =A0 and where=C2=A0the service description=C2=A0<= /span>and=C2=A0the URN=C2=A0are defined as broadly
=C2=A0=C2= =A0 as possible to encourage reuse.=C2=A0 The 'sos' service is not = meant to
=C2=A0=C2= =A0 invoke general government, public information, counseling, or social=
=C2=A0=C2= =A0 services.
=C2=A0
I.e. in the expert review, the service description and the URN are re= viewed. If approved, the service description and URN are listed in IANA - s= ee=C2=A0http://www.iana.org/assi= gnments/urn-serviceid-labels/urn-serviceid-labels.xml#urn-serviceid-labels-= 2
=C2=A0
Kind regards
=C2=A0
Ivo Sedlacek
=C2=A0
=C2=A0
This Communication is Confidential. We only send and receive email on t= he basis of the terms set out at=C2=A0www= .ericsson.com/email_disclaimer
From:=C2= =A0ecrit-bounces@ietf.org=C2=A0[mailto:ecrit-bounces@ietf.= org]=C2=A0On Behalf Of=C2=A0John-Luc Bakker
Sent:=C2=A019. b=C5=99ezna 2013 16:12
To:=C2=A0Christer Holmberg;=C2=A0ecrit@ietf.org
Subject:=C2=A0Re: [Ecrit] Draft new version: draft-holm= berg-ecrit-country-emg-urn-02
=C2=A0
Hi Christer,
=C2=A0
Thanks for this.<= /div>
When a new URN is adopted via expert r= eview, a description of the caller expectation in terms of services rendere= d (for the new URN) cannot be found in RFC 5031.
=C2=A0
For example, for the existing URN=C2=A0urn:service:sos.mountain, the RFC includes:
=C2=A0
=C2=A0
Will the caller expectation in terms o= f services rendered be documented somewhere?
Apologies if this query was already ad= dressed during the ECRIT session =E2=80=A6
=C2=A0
Kind regards,
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 JL
=C2=A0
From:=C2= =A0ecrit-bounces@ietf.org=C2=A0[mailto:ecrit-bounces@ietf.= org]=C2=A0On Behalf Of=C2=A0Christer Holmberg
Sent:=C2=A0Tuesday, March 19, 2013 6:52 AM
To:=C2=A0ecrit@ietf.org Subject:=C2=A0[Ecrit] Draft new version: draft-holmberg= -ecrit-country-emg-urn-02
=C2=A0
Hi,
=C2=A0
Based on the Orlando decision to move forward with the relax-the-5031-regis= tration-policy alternative for allowing emg URNs for services offered in on= e country only, I=E2=80=99ve submitted an =E2=80=9Cofficial=E2=80=9D new ve= rsion (-02) of draft-holmberg-ecrit-country-emg-urn. Aside from some minor changes caused by the new version of xml2rfc, the draft is= identical to the pre-02 version I distributed before the meeting.
=C2=A0
As was indicated in the meeting, additional text will still be needed, but = once the Orlando decision is verified on the list I hope we can adopt the d= raft as base for the work.
=C2=A0
Thanks to everyone who provided comments during the meeting!<= /div>
=C2=A0
Regards,
=C2=A0
Christer
= ---------------------------------------------------------------------= =C2=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 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.<= /u>
---------------------------------------------------------------------= =C2=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 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. __________= _____________________________________

Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailma= n/listinfo/ecrit


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


--e89a8fb20318e82b8a04d853aadf-- From James.Winterbottom@commscope.com Tue Mar 19 21:41: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 98AAB21F8EF2 for ; Tue, 19 Mar 2013 21:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nko72jqhfOwJ for ; Tue, 19 Mar 2013 21:41:46 -0700 (PDT) Received: from cdcsmgw01.commscope.com (cdcsmgw01.commscope.com [198.135.207.232]) by ietfa.amsl.com (Postfix) with ESMTP id B40AD21F8EF1 for ; Tue, 19 Mar 2013 21:41:46 -0700 (PDT) X-AuditID: 0a0404e8-b7f486d00000082e-da-51493e0a83c8 Received: from CDCE10HC1.commscope.com ( [10.86.28.21]) by cdcsmgw01.commscope.com (Symantec Messaging Gateway) with SMTP id 85.8C.02094.A0E39415; Tue, 19 Mar 2013 23:41:46 -0500 (CDT) 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 Mar 2013 23:41:45 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 20 Mar 2013 12:41:42 +0800 From: "Winterbottom, James" To: "ecrit@ietf.org" Date: Wed, 20 Mar 2013 12:41:41 +0800 Thread-Topic: [Ecrit] Additional Data -07 Thread-Index: Ac4lHRKZXzsTcTjhT22kXBt5KTmklQAB9Ysw Message-ID: <5A55A45AE77F5941B18E5457ECAC81880121408832CC@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC81880121408832BB@SISPE7MB1.commscope.com> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880121408832BB@SISPE7MB1.commscope.com> 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+NgFlrPKsWRmVeSWpSXmKPExsXCFSYjqstl5xlo0HNPwKJx0VNWB0aPJUt+ MgUwRnHZpKTmZJalFunbJXBlTLh+j7mgT7Hi7aSHTA2Mh6W7GDk5JARMJCbv3M4GYYtJXLi3 Hsjm4hAS2MUo8XrKEyYIZwOjxJrWB+wQzjpGiV33voO1sAnYSRxef4MZxBYRUJXYcGYlI4jN AmQ/mfWSBcQWFtCQOP92EyNEjabEnpXLmSBsI4lzG/aCzeEVCJLY+nM7WFwIyJ7/Yz9YL6dA sMS1ixC9jEDnfT+1BqyGWUBc4taT+UwQZwtILNlznhnCFpV4+fgfK0S9qMSd9vWMEPU6Egt2 f2KDsLUlli18zQyxV1Di5MwnLBB7dSWadn5lncAoPgvJillI2mchaZ+FpH0BI8sqRvHklOTi 3PRyA0O95Pzc3OLk/IJUEGsTIyiWWFhe7GA8vUH7EKMAB6MSD++L2R6BQqyJZcWVuYcYJTmY lER5t1l4BgrxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4f1yDaicNyWxsiq1KB8mpcHBIXD6yf1T jFIsefl5qUoSvBU2QCMEi1LTUyvSMnOAiQSmlImDE2QUD9CoxSA1vMUFibnFmekQ+VOMqhzN y5+/YBQCGyQlzjsHpEgApCijNA9uzitGcaDjhXmXgGR5gKkQbsIroOFMQMNv7HcDGV6SiJCS amBMPnHm3ERR/kTT9bqTpgmqhH7Iuffm5fV0zgOzsmR+uAscn7vtS9JThtvrGhKPeHpMtQ4I Loz7uiR3+e/LNy8yT/DvvM3gX/Q0ekVX9KlTZivZ9nL2lnzxnPlM5sQf5dAbtftuHFw3Ocap 5mVN2WGuB3yBkr83yn0VrV946qOr6tSTb/xWtiu+VmIpzkg01GIuKk4EAM8tm8BCAwAA Subject: Re: [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: Wed, 20 Mar 2013 04:41:48 -0000 The example in section 4.3 is inconsistent with the schema for emergencyCal= l.ProviderInfo defined in section 5.10. The schema requires a DataProviderS= tring element. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of W= interbottom, James Sent: Wednesday, 20 March 2013 2:43 PM To: ecrit@ietf.org Subject: [Ecrit] Additional Data -07 Hi Authors, It is quite possible that I am misunderstanding things here and how the new= Provided-By schema defined in section 14.3.1 is intended to be used, so le= t me present my use case. The Location interworking Function (LIF) in NENA i3 essentially needs to be= able to serve up existing ALI records but broken up into locations and add= itional data. The additional data that needs to be provided maps into sever= al of the additional data XML containers defined in this document. What I need to be able to do is to return: 1) A single structure with multiple URIs each URI to a different container = type. 2) A single XML container with the actual XML structures I want. What is provided doesn't seem to let me do that easily, and certainly isn't= obvious. I would like to propose the following schema as a replacement for what is c= urrently in the document. =09 =09 =09 =09 This schema lets you send a single reference, or multiple references, as we= ll as a single XML container with all the relevant blocks and provides exte= nsions points. I think that this still meets the original intent. Cheers James =20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From James.Winterbottom@commscope.com Tue Mar 19 22:15: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 757F921F8D46 for ; Tue, 19 Mar 2013 22:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwOB32M8JWXU for ; Tue, 19 Mar 2013 22:15:55 -0700 (PDT) Received: from cdcsmgw02.commscope.com (cdcsmgw02.commscope.com [198.135.207.233]) by ietfa.amsl.com (Postfix) with ESMTP id 2917521F8D3C for ; Tue, 19 Mar 2013 22:15:54 -0700 (PDT) X-AuditID: 0a0404e9-b7f996d000000830-27-5149460a2c69 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw02.commscope.com (Symantec Messaging Gateway) with SMTP id E4.09.02096.A0649415; Wed, 20 Mar 2013 00:15:54 -0500 (CDT) 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; Wed, 20 Mar 2013 00:15:54 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 20 Mar 2013 13:15:24 +0800 From: "Winterbottom, James" To: "ecrit@ietf.org" Date: Wed, 20 Mar 2013 13:15:23 +0800 Thread-Topic: Additional Data -07 Thread-Index: Ac4lKexilpcq63Y2T5Kszo0eY/xbuA== Message-ID: <5A55A45AE77F5941B18E5457ECAC81880121408832D4@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_5A55A45AE77F5941B18E5457ECAC81880121408832D4SISPE7MB1co_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPKsWRmVeSWpSXmKPExsXCFSaSpsvl5hlo0D5JwqJx0VNWB0aPJUt+ MgUwRnHZpKTmZJalFunbJXBlvJlwh61gh2jF3j1HWRsYm4W7GDk5JARMJCZ3/meDsMUkLtxb D2RzcQgJ7GaU+P32JzuEs4FR4vCMg8wQzjpGiVU377CDtLAJ2EkcXn+DGcQWEVCV2HBmJSOI zQJkf1v4AaxGWEBGYv3uP2wQNYoS5/5fYoSw9SSeTnzPBGLzCgRJrHt9nAXEZgQ64/upNWBx ZgFxiVtP5jNBnCcgsWTPeWYIW1Ti5eN/rBD1ohJ32tczQtTnS9y8tokVYqagxMmZT8BmCgno SjTt/Mo6gVFkFpKxs5C0zELSAhHXkViw+xMbhK0tsWzha2YY+8yBx0zI4gsY2VcxiienJBfn ppcbGOkl5+fmFifnF6SCWJsYQbHEwvJyB+PZDdqHGAU4GJV4eF/M9ggUYk0sK67MPcQoycGk JMr70sEzUIgvKT+lMiOxOCO+qDQntfgQowQHs5II75drQOW8KYmVValF+TApDQ4OgdNP7p9i lGLJy89LVZLg/eACNEKwKDU9tSItMweYSGBKmTg4QUbxAI26DlLDW1yQmFucmQ6RP8WoytG8 /PkLRiGwQVLivPtBigRAijJK8+DmvGIUBzpemPcuSJYHmArhJrwCGs4ENPzGfjeQ4SWJCCmp Bsb53hv+8S0Rkj98mFHKe0tHYu2VtpQy1pnSlbWilycpTv01q/LJErWyygUleauWl+dX6fXe mhN7cO18uZarpyc+e/FFVcZrTcgbrrS6t+Zqr0ImPQh7vub5l1i/tS8Pxcv3V0jvcRR53HFu TUl/vk2Z3b5z0gvvzNU/ydxx0aHxmcW6izcy2D2VWIozEg21mIuKEwEBm+JtQgMAAA== Subject: [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: Wed, 20 Mar 2013 05:15:56 -0000 --_000_5A55A45AE77F5941B18E5457ECAC81880121408832D4SISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry about the continual flood. Last one for today I promise. Section 6.3 says that a registry will be created for the toke= ns. I couldn't see a request for this registry in the IANA section. Cheers James --_000_5A55A45AE77F5941B18E5457ECAC81880121408832D4SISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry about the = continual flood. Last one for today I promise.

 

Section 6.3 says that a re= gistry will be created for the <SvcMobility> tokens. I couldn’t= see a request for this registry in the IANA section.

 

Cheers

James

 =

= --_000_5A55A45AE77F5941B18E5457ECAC81880121408832D4SISPE7MB1co_-- From ivo.sedlacek@ericsson.com Tue Mar 19 23:15: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 0EA7521F8F41 for ; Tue, 19 Mar 2013 23:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koF3lA1X4bDF for ; Tue, 19 Mar 2013 23:15:47 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 60FDB21F8BB3 for ; Tue, 19 Mar 2013 23:15:46 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-1e-5149540ba754 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 88.1E.10459.B0459415; Wed, 20 Mar 2013 07:15:39 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.208]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0318.004; Wed, 20 Mar 2013 07:15:38 +0100 From: Ivo Sedlacek To: Martin Thomson , "DRAGE, Keith (Keith)" Thread-Topic: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels) Thread-Index: AQHOJNzNAxHHV043zUCcny63YnH6O5iuF9Yw Date: Wed, 20 Mar 2013 06:15:38 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061010A7DB1@ESESSMB301.ericsson.se> References: <949EF20990823C4C85C18D59AA11AD8B01831C@FR712WXCHMBA11.zeu.alcatel-lucent.com> 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.149] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+JvjS53iGegwdWnIhbTTl5mtmhc9JTV 4mnjWUaLa2f+MTqweLQ+28vqsXPWXXaPJUt+MnnsaHjOHMASxWWTkpqTWZZapG+XwJXx9uE7 xoLtPBUnl4g0MM7n6mLk5JAQMJHYOu8PI4QtJnHh3nq2LkYuDiGBQ4wSGz/1MUI4SxglDh3Y CFbFJqAnMXHLEVYQW0QgQ2J39yVmEJtZIFBiwYJnYHFhgWiJ/9d2snQxcgDVxEismGsOYRpJ vL7vBVLBIqAq8e1cCzuIzSvgLXHw2m6oVYeZJI5u+we2ihNo5Ndbh8GKGAVkJa7+6WWEWCUu cevJfCaIowUkluw5zwxhi0q8fPyPFcJWklh7eDsLRL2exLNTs6BsbYllC18zQywWlDg58wnL BEaxWUjGzkLSMgtJyywkLQsYWVYxsucmZuaklxtuYgRG0sEtv3V3MJ46J3KIUZqDRUmcN8z1 QoCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRtc01t32ovsKlwkY7HSaYlp5KKb3j7TJNEM5 41XF53dYVa7V+uJi+6NWuXmV6TRxobK196cyJH26fGNj4C0XIe+VcVx37e4/qjr6YIWN9Qxv 39rViXu+N93Jvsm9mG972sLX37cUrpkUuLRQj4Xb5HeFqdkHGx22fDuJJXu/nz4p/OR24cwT 1UosxRmJhlrMRcWJADia4c1yAgAA Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels) 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 Mar 2013 06:15:48 -0000 Hello, we need to distinguish: - the emergency service of the municipal police (e.g. to be used to report = a pickpocket) - the emergency service of the national police (e.g. to be used to report a= murder). In a given location, the user can call any of them and get different servic= e. That's why different emergency URNs are needed. I have no strong view whether ".local" or other suffix (e.g. ".A3") is to i= dentify the emergency service of the municipal police. Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer=20 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of M= artin Thomson Sent: 19. b=F8ezna 2013 21:03 To: DRAGE, Keith (Keith) Cc: Rosen, Brian; ecrit@ietf.org Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-ser= viceid-labels) On 19 March 2013 12:27, DRAGE, Keith (Keith) wrote: > Martin Thomson wrote: > >> I agree with Brian, "local" is not just ambiguous, it's redundant. >> "urn:service:sos.police.local" is semantically equivalent to=20 >> "urn:service:sos.police". >> > > I disagree with the last part of this. I think that you missed my point. By nature, all urn:service:sos sub-servi= ces are local. That's why LoST exists. Adding ".local" is redundant. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Wed Mar 20 07:09: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 CF55621F84C8 for ; Wed, 20 Mar 2013 07:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.281 X-Spam-Level: X-Spam-Status: No, score=-101.281 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUe059nH6Mfh for ; Wed, 20 Mar 2013 07:09:04 -0700 (PDT) Received: from mm2.idig.net (raphotoclub.ca [70.33.247.99]) by ietfa.amsl.com (Postfix) with ESMTP id D397F21F8554 for ; Wed, 20 Mar 2013 07:09:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=HwUSefs9QToqwm8Y5hTfGn2s3xqrLjjRN8DBueOHI9U=; b=iGwe89zBOR4RQmrtN8mUQmYXG0Ph65YOgbhGOaYbU5S5BmXZG2ydqRUJPnshbPPEAv0aQlIOol0PNBcITY9ObazIcy7O41bHK63h55smndNQDpDDWlKm8iO1xKzVaKdQJNUl7VLw+98EEz9u8ExqXPlkIOmQ726ppnWxvY+bYZM=; Received: from neustargw.va.neustar.com ([209.173.53.233]:45926 helo=[192.168.133.138]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UIJhN-0001jQ-Ry; Wed, 20 Mar 2013 10:09:02 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Rosen In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880121408832BB@SISPE7MB1.commscope.com> Date: Wed, 20 Mar 2013 10:09:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5A55A45AE77F5941B18E5457ECAC81880121408832BB@SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Mailer: Apple Mail (2.1503) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mm2.idig.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net Cc: "ecrit@ietf.org" Subject: Re: [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: Wed, 20 Mar 2013 14:09:05 -0000 I think you misunderstand the mechanism, although what we provide isn't = EXACTLY what you asked for. You can 1) provide a single structure with multiple URIs, each URI to a = different container type. This would look like =85 2) provide a single XML container with the actual XML structure you = want. This would look like Example SP 11234 =85 Business =85 On Mar 19, 2013, at 11:43 PM, "Winterbottom, James" = wrote: > Hi Authors, >=20 > It is quite possible that I am misunderstanding things here and how = the new Provided-By schema defined in section 14.3.1 is intended to be = used, so let me present my use case. >=20 > The Location interworking Function (LIF) in NENA i3 essentially needs = to be able to serve up existing ALI records but broken up into locations = and additional data. The additional data that needs to be provided maps = into several of the additional data XML containers defined in this = document. >=20 > What I need to be able to do is to return: > 1) A single structure with multiple URIs each URI to a different = container type. > 2) A single XML container with the actual XML structures I want. >=20 > What is provided doesn't seem to let me do that easily, and certainly = isn't obvious. >=20 > I would like to propose the following schema as a replacement for what = is currently in the document. >=20 > > = targetNamespace=3D"urn:ietf:params:xml:ns:pidf:geopriv10:emergencyCallData= " > xmlns:xs=3D"http://www.w3.org/2001/XMLSchema" > xmlns:ad=3D"urn:ietf:params:xml:ns:pidf:geopriv10:emergencyCallData" > xmlns:xml=3D"http://www.w3.org/XML/1998/namespace" > xmlns:pi=3D"urn:ietf:params:xml:ns:emergencyCall.ProviderInfo" > xmlns:svc=3D"urn:ietf:params:xml:ns:emergencyCall.SvcInfo" > xmlns:dev=3D"urn:ietf:params:xml:ns:emergencyCall.DevInfo" > xmlns:sub=3D"urn:ietf:params:xml:ns:emergencyCall.SubInfo" > xmlns:com=3D"urn:ietf:params:xml:ns:emergencyCall.Comment" > elementFormDefault=3D"qualified" attributeFormDefault=3D"unqualified"> > =09 > > =09 > > > > > > > > > > > > > =09 > > =09 > > > > minOccurs=3D"0" maxOccurs=3D"1"/> > minOccurs=3D"0" maxOccurs=3D"1"/> > minOccurs=3D"0" maxOccurs=3D"1"/> > minOccurs=3D"0" maxOccurs=3D"1"/> > minOccurs=3D"0" maxOccurs=3D"1"/> > > > > > >=20 >=20 > This schema lets you send a single reference, or multiple references, = as well as a single XML container with all the relevant blocks and = provides extensions points. I think that this still meets the original = intent. >=20 > Cheers > James >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From rlb@ipv.sx Wed Mar 20 07:42: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 C8E6221F8FAF for ; Wed, 20 Mar 2013 07:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.539, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WK0b9LZFRo4b for ; Wed, 20 Mar 2013 07:42:16 -0700 (PDT) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id 32F9821F8F8A for ; Wed, 20 Mar 2013 07:42:16 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id h2so1829472oag.24 for ; Wed, 20 Mar 2013 07:42:15 -0700 (PDT) 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=Jy1/AZ1iYmUsv8KfjILMb9k0v3nhyq/MZLmRvz8HL4A=; b=fmwk92abjDgg0N+1kIAIxtGOwY149pY8Kg/4ZFzIsumQ2PmIVYIkNIYT/M462ETeLk q87g6r796pmxdDsSRWe/sesBOuV+NKQ/Fk6Evvx2ZtTZYilQ9Gf2D/WiMtpjYlwH6aQ8 63t7UeAcoV0eRqDAE4S9lIewuIu6CNJPPQd3TRGn0imB1LBwvhHm71QNF3fKsnXDRGtq vhkOApBfxk5m7xRMaqbiH0MDrSYRr+SHTLSwIA2fdxcZoBAv+qixmyVM8zAWFxlqK17H qv5pKPJf25aMShStzhrs80HGxLOf3BfGG1VlXhyVoaxwQd7o/biDqIjb+2BhKhSYg2gQ yzHA== MIME-Version: 1.0 X-Received: by 10.182.217.10 with SMTP id ou10mr4224358obc.30.1363790535612; Wed, 20 Mar 2013 07:42:15 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Wed, 20 Mar 2013 07:42:15 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: <39B5E4D390E9BD4890E2B310790061010A7DB1@ESESSMB301.ericsson.se> References: <949EF20990823C4C85C18D59AA11AD8B01831C@FR712WXCHMBA11.zeu.alcatel-lucent.com> <39B5E4D390E9BD4890E2B310790061010A7DB1@ESESSMB301.ericsson.se> Date: Wed, 20 Mar 2013 10:42:15 -0400 Message-ID: From: Richard Barnes To: Ivo Sedlacek Content-Type: multipart/alternative; boundary=f46d0444709d6cc09f04d85c3af2 X-Gm-Message-State: ALoCoQnFfK0/WY98cqJ0n0TSiTSPULUpi2gDOqsU2c7KsGMKEZ0V/Pl7OqvGoKKdALq8H7Z1N0EL Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels) 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 Mar 2013 14:42:18 -0000 --f46d0444709d6cc09f04d85c3af2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ivo, How is the first of those two different from "urn:service:sos.police" ? That is, do you envision a case where "sos.police", "sos.police.national", and "sos.police.local" all refer to different entities? --Richard On Wed, Mar 20, 2013 at 2:15 AM, Ivo Sedlacek wr= ote: > Hello, > > we need to distinguish: > - the emergency service of the municipal police (e.g. to be used to repor= t > a pickpocket) > - the emergency service of the national police (e.g. to be used to report > a murder). > > In a given location, the user can call any of them and get different > service. That's why different emergency URNs are needed. > > I have no strong view whether ".local" or other suffix (e.g. ".A3") is to > identify the emergency service of the municipal police. > > 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 > Martin Thomson > Sent: 19. b=C5=99ezna 2013 21:03 > To: DRAGE, Keith (Keith) > Cc: Rosen, Brian; ecrit@ietf.org > Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment > (urn-serviceid-labels) > > On 19 March 2013 12:27, DRAGE, Keith (Keith) < > keith.drage@alcatel-lucent.com> wrote: > > Martin Thomson wrote: > > > >> I agree with Brian, "local" is not just ambiguous, it's redundant. > >> "urn:service:sos.police.local" is semantically equivalent to > >> "urn:service:sos.police". > >> > > > > I disagree with the last part of this. > > I think that you missed my point. By nature, all urn:service:sos > sub-services are local. That's why LoST exists. Adding ".local" is > redundant. > _______________________________________________ > 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 > --f46d0444709d6cc09f04d85c3af2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ivo,

How is the first of those two different from "= urn:service:sos.police" ? =C2=A0That is, do you envision a case where = "sos.police", "sos.police.national", and "sos.poli= ce.local" all refer to different entities?

--Richard



On Wed, Mar 20, 2013 at 2:15 AM, Ivo Sedlacek <iv= o.sedlacek@ericsson.com> wrote:
Hello,

we need to distinguish:
- the emergency service of the municipal police (e.g. to be used to report = a pickpocket)
- the emergency service of the national police (e.g. to be used to report a= murder).

In a given location, the user can call any of them and get different servic= e. That's why different emergency URNs are needed.

I have no strong view whether ".local" or other suffix (e.g. &quo= t;.A3") is to identify the emergency service of the municipal police.<= br>

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 Martin Thomson
Sent: 19. b=C5=99ezna 2013 21:03
To: DRAGE, Keith (Keith)
Cc: Rosen, Brian; ecrit@ietf.org
Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-ser= viceid-labels)

On 19 March 2013 12:27, DRAGE= , Keith (Keith) <keith= .drage@alcatel-lucent.com> wrote:
> Martin Thomson wrote:
>
>> I agree with Brian, "local" is not just ambiguous, it= 9;s redundant.
>> "urn:service:sos.police.local" is semantically equivalen= t to
>> "urn:service:sos.police".
>>
>
> I disagree with the last part of this.

I think that you missed my point. =C2=A0By nature, all urn:service:sos sub-= services are local. =C2=A0That's why LoST exists. =C2=A0Adding ".l= ocal" is redundant.
_______________________________________________
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

--f46d0444709d6cc09f04d85c3af2-- From ivo.sedlacek@ericsson.com Wed Mar 20 08:32: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 0ADD911E80B8 for ; Wed, 20 Mar 2013 08:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62A8wbMl0Ibc for ; Wed, 20 Mar 2013 08:32:24 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4F811E80A4 for ; Wed, 20 Mar 2013 08:32:23 -0700 (PDT) X-AuditID: c1b4fb30-b7f0d6d000007e61-02-5149d681ef30 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 46.8B.32353.186D9415; Wed, 20 Mar 2013 16:32:18 +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; Wed, 20 Mar 2013 16:32:17 +0100 From: Ivo Sedlacek To: Richard Barnes Thread-Topic: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels) Thread-Index: AQHOJXkhza7aK8/vJE6vacAHT4S6uZiurzaA Date: Wed, 20 Mar 2013 15:32:16 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061010A849E@ESESSMB301.ericsson.se> References: <949EF20990823C4C85C18D59AA11AD8B01831C@FR712WXCHMBA11.zeu.alcatel-lucent.com> <39B5E4D390E9BD4890E2B310790061010A7DB1@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.18] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B310790061010A849EESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGfG3RrfpmmegwdolPBbTTl5mtmhc9JTV 4mnjWUaLa2f+MVpM7bN1YPVofbaX1WPnrLvsHkuW/GTymLxxFovHjobnzAGsUVw2Kak5mWWp Rfp2CVwZTce72Qp+dTJWzDs0lamBcUEbYxcjJ4eEgInE5Na/ULaYxIV769m6GLk4hAQOMUr0 T2lignCWMEp8n/iFGaSKTUBPYuKWI6wgtoiAvMTp6w9YQYqYBbYzSvz7/4EJJCEsEC2xdvIj RoiiGIlZM+4ANXMA2UYSay/bg5gsAqoSZx8mgFTwCnhL9F9Zwwyx6wyzxObP/ewgCU6BQIml zQ9YQGxGAVmJq396wUYyC4hL3HoynwniagGJJXvOM0PYohIvH/9jhbAVJT6+2gdVny/RdHM+ K8QyQYmTM5+wTGAUnYVk1CwkZbOQlM0COpVZQFNi/S59iBJFiSndD9khbA2J1jlz2ZHFFzCy r2Jkz03MzEkvN9/ECIzIg1t+G+xg3HRf7BCjNAeLkjhvuOuFACGB9MSS1OzU1ILUovii0pzU 4kOMTBycUg2MBqb/52yb37hB8KHSlx+HvmvdfrNQXszA/4U02x+/ow+e6ByJfHu/kz9s7a3d Ks2lOzpUalx8dvPJbz09c/Jjl8C+DGXx3u65e3vtOTwa6tU+nvo/Myd7WaPgxieL5oroe+zJ 9vix/4Fw/Wu2YvHfDwvK5v2Z+TTfuelRfgG/tVocS5q556kpSizFGYmGWsxFxYkA8+TClZYC AAA= Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels) 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 Mar 2013 15:32:29 -0000 --_000_39B5E4D390E9BD4890E2B310790061010A849EESESSMB301ericsso_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCj4gSG93IGlzIHRoZSBmaXJzdCBvZiB0aG9zZSB0d28gZGlmZmVyZW50IGZyb20g InVybjpzZXJ2aWNlOnNvcy5wb2xpY2UiID8gIFRoYXQgaXMsIGRvIHlvdSBlbnZpc2lvbiBhIGNh c2Ugd2hlcmUgInNvcy5wb2xpY2UiLCAic29zLnBvbGljZS5uYXRpb25hbCIsIGFuZCAic29zLnBv bGljZS5sb2NhbCIgYWxsIHJlZmVyIHRvIGRpZmZlcmVudCBlbnRpdGllcz8NCg0KInNvcy5wb2xp Y2UubG9jYWwiIChtdW5pY2lwYWwgcG9saWNlKSB3aWxsIHJlZmVyIHRvIHRoZSBQU0FQIG9mIHRo ZSBtdW5pY2lwYWwgcG9saWNlLg0KInNvcy5wb2xpY2UubmF0aW9uYWwiIChuYXRpb25hbCBwb2xp Y2UpIHdpbGwgcmVmZXIgdG8gdGhlIFBTQVAgb2YgdGhlIG5hdGlvbmFsIHBvbGljZS4NCkluIHRo ZSBDemVjaCByZXB1YmxpYywgYSByZXF1ZXN0IGZvciAic29zLnBvbGljZSIgd2lsbCBsaWtlbHkg YmUgcm91dGVkIHRvIHRoZSBQU0FQIG9mIHRoZSBuYXRpb25hbCBwb2xpY2UuIElmIGEgbWFqb3Ig Y3JpbWUgaXMgdG8gYmUgcmVwb3J0ZWQsIHRoZSBtdW5pY2lwYWwgcG9saWNlIHdpbGwgbmVlZCB0 byBoYW5kIGl0IG92ZXIgdG8gdGhlIG5hdGlvbmFsIHBvbGljZSBhbnl3YXkuIEkgZG8gbm90IGtu b3cgcmVxdWlyZW1lbnRzIGluIG90aGVyIGNvdW50cmllcy4NCg0KS2luZCByZWdhcmRzDQoNCkl2 byBTZWRsYWNlaw0KDQpUaGlzIENvbW11bmljYXRpb24gaXMgQ29uZmlkZW50aWFsLiBXZSBvbmx5 IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0 IGF0IHd3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lcjxodHRwOi8vd3d3LmVyaWNzc29u LmNvbS9lbWFpbF9kaXNjbGFpbWVyPg0KRnJvbTogUmljaGFyZCBCYXJuZXMgW21haWx0bzpybGJA aXB2LnN4XQ0KU2VudDogMjAuIGLFmWV6bmEgMjAxMyAxNTo0Mg0KVG86IEl2byBTZWRsYWNlaw0K Q2M6IE1hcnRpbiBUaG9tc29uOyBEUkFHRSwgS2VpdGggKEtlaXRoKTsgUm9zZW4sIEJyaWFuOyBl Y3JpdEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtFY3JpdF0gW0lBTkEgIzY1ODkyMV0gR2VuZXJh bCBSZXF1ZXN0IGZvciBBc3NpZ25tZW50ICh1cm4tc2VydmljZWlkLWxhYmVscykNCg0KSXZvLA0K DQpIb3cgaXMgdGhlIGZpcnN0IG9mIHRob3NlIHR3byBkaWZmZXJlbnQgZnJvbSAidXJuOnNlcnZp Y2U6c29zLnBvbGljZSIgPyAgVGhhdCBpcywgZG8geW91IGVudmlzaW9uIGEgY2FzZSB3aGVyZSAi c29zLnBvbGljZSIsICJzb3MucG9saWNlLm5hdGlvbmFsIiwgYW5kICJzb3MucG9saWNlLmxvY2Fs IiBhbGwgcmVmZXIgdG8gZGlmZmVyZW50IGVudGl0aWVzPw0KDQotLVJpY2hhcmQNCg0KDQpPbiBX ZWQsIE1hciAyMCwgMjAxMyBhdCAyOjE1IEFNLCBJdm8gU2VkbGFjZWsgPGl2by5zZWRsYWNla0Bl cmljc3Nvbi5jb208bWFpbHRvOml2by5zZWRsYWNla0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhl bGxvLA0KDQp3ZSBuZWVkIHRvIGRpc3Rpbmd1aXNoOg0KLSB0aGUgZW1lcmdlbmN5IHNlcnZpY2Ug b2YgdGhlIG11bmljaXBhbCBwb2xpY2UgKGUuZy4gdG8gYmUgdXNlZCB0byByZXBvcnQgYSBwaWNr cG9ja2V0KQ0KLSB0aGUgZW1lcmdlbmN5IHNlcnZpY2Ugb2YgdGhlIG5hdGlvbmFsIHBvbGljZSAo ZS5nLiB0byBiZSB1c2VkIHRvIHJlcG9ydCBhIG11cmRlcikuDQoNCkluIGEgZ2l2ZW4gbG9jYXRp b24sIHRoZSB1c2VyIGNhbiBjYWxsIGFueSBvZiB0aGVtIGFuZCBnZXQgZGlmZmVyZW50IHNlcnZp Y2UuIFRoYXQncyB3aHkgZGlmZmVyZW50IGVtZXJnZW5jeSBVUk5zIGFyZSBuZWVkZWQuDQoNCkkg aGF2ZSBubyBzdHJvbmcgdmlldyB3aGV0aGVyICIubG9jYWwiIG9yIG90aGVyIHN1ZmZpeCAoZS5n LiAiLkEzIikgaXMgdG8gaWRlbnRpZnkgdGhlIGVtZXJnZW5jeSBzZXJ2aWNlIG9mIHRoZSBtdW5p Y2lwYWwgcG9saWNlLg0KDQpLaW5kIHJlZ2FyZHMNCg0KSXZvIFNlZGxhY2VrDQoNClRoaXMgQ29t bXVuaWNhdGlvbiBpcyBDb25maWRlbnRpYWwuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFp bCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQgd3d3LmVyaWNzc29uLmNvbS9l bWFpbF9kaXNjbGFpbWVyPGh0dHA6Ly93d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXI+ DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZWNyaXQtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzplY3JpdC1ib3VuY2VzQGll dGYub3JnPG1haWx0bzplY3JpdC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIE1hcnRp biBUaG9tc29uDQpTZW50OiAxOS4gYsWZZXpuYSAyMDEzIDIxOjAzDQpUbzogRFJBR0UsIEtlaXRo IChLZWl0aCkNCkNjOiBSb3NlbiwgQnJpYW47IGVjcml0QGlldGYub3JnPG1haWx0bzplY3JpdEBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRWNyaXRdIFtJQU5BICM2NTg5MjFdIEdlbmVyYWwgUmVx dWVzdCBmb3IgQXNzaWdubWVudCAodXJuLXNlcnZpY2VpZC1sYWJlbHMpDQpPbiAxOSBNYXJjaCAy MDEzIDEyOjI3LCBEUkFHRSwgS2VpdGggKEtlaXRoKSA8a2VpdGguZHJhZ2VAYWxjYXRlbC1sdWNl bnQuY29tPG1haWx0bzprZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb20+PiB3cm90ZToNCj4g TWFydGluIFRob21zb24gd3JvdGU6DQo+DQo+PiBJIGFncmVlIHdpdGggQnJpYW4sICJsb2NhbCIg aXMgbm90IGp1c3QgYW1iaWd1b3VzLCBpdCdzIHJlZHVuZGFudC4NCj4+ICJ1cm46c2VydmljZTpz b3MucG9saWNlLmxvY2FsIiBpcyBzZW1hbnRpY2FsbHkgZXF1aXZhbGVudCB0bw0KPj4gInVybjpz ZXJ2aWNlOnNvcy5wb2xpY2UiLg0KPj4NCj4NCj4gSSBkaXNhZ3JlZSB3aXRoIHRoZSBsYXN0IHBh cnQgb2YgdGhpcy4NCg0KSSB0aGluayB0aGF0IHlvdSBtaXNzZWQgbXkgcG9pbnQuICBCeSBuYXR1 cmUsIGFsbCB1cm46c2VydmljZTpzb3Mgc3ViLXNlcnZpY2VzIGFyZSBsb2NhbC4gIFRoYXQncyB3 aHkgTG9TVCBleGlzdHMuICBBZGRpbmcgIi5sb2NhbCIgaXMgcmVkdW5kYW50Lg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkVjcml0IG1haWxpbmcgbGlz dA0KRWNyaXRAaWV0Zi5vcmc8bWFpbHRvOkVjcml0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkVjcml0IG1haWxpbmcgbGlzdA0KRWNyaXRAaWV0Zi5vcmc8 bWFpbHRvOkVjcml0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9lY3JpdA0KDQo= --_000_39B5E4D390E9BD4890E2B310790061010A849EESESSMB301ericsso_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojQzA1MDREOw0KCWZvbnQtd2VpZ2h0 Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+SGVsbG8s PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiND MDUwNEQiPiZndDsNCjwvc3Bhbj5Ib3cgaXMgdGhlIGZpcnN0IG9mIHRob3NlIHR3byBkaWZmZXJl bnQgZnJvbSAmcXVvdDt1cm46c2VydmljZTpzb3MucG9saWNlJnF1b3Q7ID8gJm5ic3A7VGhhdCBp cywgZG8geW91IGVudmlzaW9uIGEgY2FzZSB3aGVyZSAmcXVvdDtzb3MucG9saWNlJnF1b3Q7LCAm cXVvdDtzb3MucG9saWNlLm5hdGlvbmFsJnF1b3Q7LCBhbmQgJnF1b3Q7c29zLnBvbGljZS5sb2Nh bCZxdW90OyBhbGwgcmVmZXIgdG8gZGlmZmVyZW50IGVudGl0aWVzPzxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPiZxdW90O3Nvcy5wb2xpY2UubG9jYWwmcXVv dDsgKG11bmljaXBhbCBwb2xpY2UpIHdpbGwgcmVmZXIgdG8gdGhlIFBTQVAgb2YgdGhlIG11bmlj aXBhbCBwb2xpY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj4mcXVvdDtzb3MucG9saWNl Lm5hdGlvbmFsJnF1b3Q7IChuYXRpb25hbCBwb2xpY2UpIHdpbGwgcmVmZXIgdG8gdGhlIFBTQVAg b2YgdGhlIG5hdGlvbmFsIHBvbGljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNDMDUwNEQiPkluIHRo ZSBDemVjaCByZXB1YmxpYywgYSByZXF1ZXN0IGZvciAmcXVvdDtzb3MucG9saWNlJnF1b3Q7IHdp bGwgbGlrZWx5IGJlIHJvdXRlZCB0byB0aGUgUFNBUCBvZiB0aGUgbmF0aW9uYWwgcG9saWNlLiBJ ZiBhIG1ham9yIGNyaW1lIGlzIHRvIGJlIHJlcG9ydGVkLCB0aGUgbXVuaWNpcGFsDQogcG9saWNl IHdpbGwgbmVlZCB0byBoYW5kIGl0IG92ZXIgdG8gdGhlIG5hdGlvbmFsIHBvbGljZSBhbnl3YXku IEkgZG8gbm90IGtub3cgcmVxdWlyZW1lbnRzIGluIG90aGVyIGNvdW50cmllcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiNDMDUwNEQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+S2lu ZCByZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQzA1MDREIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiNDMDUwNEQiPkl2byBTZWRsYWNlazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0MwNTA0RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzMzMzMiPlRoaXMgQ29tbXVuaWNhdGlvbiBpcyBD b25maWRlbnRpYWwuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMg b2YgdGhlIHRlcm1zIHNldCBvdXQgYXQNCjxhIGhyZWY9Imh0dHA6Ly93d3cuZXJpY3Nzb24uY29t L2VtYWlsX2Rpc2NsYWltZXIiIHRpdGxlPSJodHRwOi8vd3d3LmVyaWNzc29uLmNvbS9lbWFpbF9k aXNjbGFpbWVyIj4NCnd3dy5lcmljc3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lcjwvYT4gPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IFJpY2hhcmQgQmFybmVzIFttYWlsdG86cmxiQGlwdi5zeF0NCjxicj4NCjxiPlNlbnQ6PC9iPiAy MC4gYsWZZXpuYSAyMDEzIDE1OjQyPGJyPg0KPGI+VG86PC9iPiBJdm8gU2VkbGFjZWs8YnI+DQo8 Yj5DYzo8L2I+IE1hcnRpbiBUaG9tc29uOyBEUkFHRSwgS2VpdGggKEtlaXRoKTsgUm9zZW4sIEJy aWFuOyBlY3JpdEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0Vjcml0XSBbSUFO QSAjNjU4OTIxXSBHZW5lcmFsIFJlcXVlc3QgZm9yIEFzc2lnbm1lbnQgKHVybi1zZXJ2aWNlaWQt bGFiZWxzKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXZvLDxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93IGlzIHRoZSBmaXJzdCBvZiB0aG9z ZSB0d28gZGlmZmVyZW50IGZyb20gJnF1b3Q7dXJuOnNlcnZpY2U6c29zLnBvbGljZSZxdW90OyA/ ICZuYnNwO1RoYXQgaXMsIGRvIHlvdSBlbnZpc2lvbiBhIGNhc2Ugd2hlcmUgJnF1b3Q7c29zLnBv bGljZSZxdW90OywgJnF1b3Q7c29zLnBvbGljZS5uYXRpb25hbCZxdW90OywgYW5kICZxdW90O3Nv cy5wb2xpY2UubG9jYWwmcXVvdDsgYWxsIHJlZmVyIHRvIGRpZmZlcmVudCBlbnRpdGllcz88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS1SaWNo YXJkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBNYXIgMjAsIDIwMTMgYXQgMjoxNSBBTSwg SXZvIFNlZGxhY2VrICZsdDs8YSBocmVmPSJtYWlsdG86aXZvLnNlZGxhY2VrQGVyaWNzc29uLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPml2by5zZWRsYWNla0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxvLDxicj4NCjxicj4N CndlIG5lZWQgdG8gZGlzdGluZ3Vpc2g6PGJyPg0KLSB0aGUgZW1lcmdlbmN5IHNlcnZpY2Ugb2Yg dGhlIG11bmljaXBhbCBwb2xpY2UgKGUuZy4gdG8gYmUgdXNlZCB0byByZXBvcnQgYSBwaWNrcG9j a2V0KTxicj4NCi0gdGhlIGVtZXJnZW5jeSBzZXJ2aWNlIG9mIHRoZSBuYXRpb25hbCBwb2xpY2Ug KGUuZy4gdG8gYmUgdXNlZCB0byByZXBvcnQgYSBtdXJkZXIpLjxicj4NCjxicj4NCkluIGEgZ2l2 ZW4gbG9jYXRpb24sIHRoZSB1c2VyIGNhbiBjYWxsIGFueSBvZiB0aGVtIGFuZCBnZXQgZGlmZmVy ZW50IHNlcnZpY2UuIFRoYXQncyB3aHkgZGlmZmVyZW50IGVtZXJnZW5jeSBVUk5zIGFyZSBuZWVk ZWQuPGJyPg0KPGJyPg0KSSBoYXZlIG5vIHN0cm9uZyB2aWV3IHdoZXRoZXIgJnF1b3Q7LmxvY2Fs JnF1b3Q7IG9yIG90aGVyIHN1ZmZpeCAoZS5nLiAmcXVvdDsuQTMmcXVvdDspIGlzIHRvIGlkZW50 aWZ5IHRoZSBlbWVyZ2VuY3kgc2VydmljZSBvZiB0aGUgbXVuaWNpcGFsIHBvbGljZS48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxicj4NCktpbmQgcmVnYXJkczxicj4NCjxicj4NCkl2byBTZWRsYWNlazxicj4N Cjxicj4NClRoaXMgQ29tbXVuaWNhdGlvbiBpcyBDb25maWRlbnRpYWwuIFdlIG9ubHkgc2VuZCBh bmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQNCjxh IGhyZWY9Imh0dHA6Ly93d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXIiIHRhcmdldD0i X2JsYW5rIj53d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2NsYWltZXI8L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxicj4NCkZyb206IDxhIGhyZWY9Im1haWx0bzplY3JpdC1ib3VuY2VzQGlldGYu b3JnIj5lY3JpdC1ib3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpl Y3JpdC1ib3VuY2VzQGlldGYub3JnIj5lY3JpdC1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVo YWxmIE9mIE1hcnRpbiBUaG9tc29uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5TZW50OiAxOS4gYsWZZXpuYSAyMDEzIDIxOjAzPGJyPg0KVG86IERS QUdFLCBLZWl0aCAoS2VpdGgpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkNjOiBSb3NlbiwgQnJp YW47IDxhIGhyZWY9Im1haWx0bzplY3JpdEBpZXRmLm9yZyI+DQplY3JpdEBpZXRmLm9yZzwvYT48 YnI+DQpTdWJqZWN0OiBSZTogW0Vjcml0XSBbSUFOQSAjNjU4OTIxXSBHZW5lcmFsIFJlcXVlc3Qg Zm9yIEFzc2lnbm1lbnQgKHVybi1zZXJ2aWNlaWQtbGFiZWxzKTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDE5IE1hcmNoIDIwMTMg MTI6MjcsIERSQUdFLCBLZWl0aCAoS2VpdGgpICZsdDs8YSBocmVmPSJtYWlsdG86a2VpdGguZHJh Z2VAYWxjYXRlbC1sdWNlbnQuY29tIj5rZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb208L2E+ Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IE1hcnRpbiBUaG9tc29uIHdyb3RlOjxicj4NCiZndDs8YnI+ DQomZ3Q7Jmd0OyBJIGFncmVlIHdpdGggQnJpYW4sICZxdW90O2xvY2FsJnF1b3Q7IGlzIG5vdCBq dXN0IGFtYmlndW91cywgaXQncyByZWR1bmRhbnQuPGJyPg0KJmd0OyZndDsgJnF1b3Q7dXJuOnNl cnZpY2U6c29zLnBvbGljZS5sb2NhbCZxdW90OyBpcyBzZW1hbnRpY2FsbHkgZXF1aXZhbGVudCB0 bzxicj4NCiZndDsmZ3Q7ICZxdW90O3VybjpzZXJ2aWNlOnNvcy5wb2xpY2UmcXVvdDsuPGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGRpc2FncmVlIHdpdGggdGhlIGxhc3QgcGFy dCBvZiB0aGlzLjxicj4NCjxicj4NCkkgdGhpbmsgdGhhdCB5b3UgbWlzc2VkIG15IHBvaW50LiAm bmJzcDtCeSBuYXR1cmUsIGFsbCB1cm46c2VydmljZTpzb3Mgc3ViLXNlcnZpY2VzIGFyZSBsb2Nh bC4gJm5ic3A7VGhhdCdzIHdoeSBMb1NUIGV4aXN0cy4gJm5ic3A7QWRkaW5nICZxdW90Oy5sb2Nh bCZxdW90OyBpcyByZWR1bmRhbnQuPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpFY3JpdCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86RWNyaXRAaWV0Zi5vcmciPkVjcml0QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0PC9hPjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KRWNyaXQg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkVjcml0QGlldGYub3JnIj5FY3JpdEBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2Vjcml0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9lY3JpdDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_39B5E4D390E9BD4890E2B310790061010A849EESESSMB301ericsso_-- From James.Winterbottom@commscope.com Wed Mar 20 15:22: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 CF7B921F8D98 for ; Wed, 20 Mar 2013 15:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z04moe52kWDW for ; Wed, 20 Mar 2013 15:22:38 -0700 (PDT) Received: from cdcsmgw01.commscope.com (cdcsmgw01.commscope.com [198.135.207.232]) by ietfa.amsl.com (Postfix) with ESMTP id EEB0E21F8D3A for ; Wed, 20 Mar 2013 15:22:37 -0700 (PDT) X-AuditID: 0a0404e8-b7f486d00000082e-b5-514a36ac81e9 Received: from CDCE10HC2.commscope.com ( [10.86.28.22]) by cdcsmgw01.commscope.com (Symantec Messaging Gateway) with SMTP id 0E.DF.02094.CA63A415; Wed, 20 Mar 2013 17:22:36 -0500 (CDT) 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; Wed, 20 Mar 2013 17:22:36 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Thu, 21 Mar 2013 06:22:33 +0800 From: "Winterbottom, James" To: Brian Rosen Date: Thu, 21 Mar 2013 06:22:31 +0800 Thread-Topic: [Ecrit] Additional Data -07 Thread-Index: Ac4ldHuRjpjJqZ2hQNSj3du9wSmcbAAOuqAA Message-ID: <5A55A45AE77F5941B18E5457ECAC8188012140883374@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC81880121408832BB@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGKsWRmVeSWpSXmKPExsXCFSYjprvGzCvQ4FiPucXT+9PYLBoXPWV1 YPK4/+0vu8eSJT+ZApiiuGxSUnMyy1KL9O0SuDImbZ3EWnDLrGLDy3ssDYwdul2MnBwSAiYS L//tZ4GwxSQu3FvP1sXIxSEksItRYtbGXkYIZwOjRP+Fq6wQzjpGiY1/lrCDtLAJ2EkcXn+D GcQWEVCW2HmrEyzOLKAqca7xMdhYFiC7b8I9VhBbWEBD4vzbTYwQ9ZoSe1YuZ4KwjSSa1vwC 6+UVCJI40DwBanMXo8SXyQfBmjkFnCRW/m5iA7EZgW79fmoNE8QycYlbT+YzQfwgILFkz3lm CFtU4uXjf6wQ9aISd9rXM0LU60gs2P2JDcLWlli28DUzxGJBiZMzn4AdLSSgK9G08yvrBGAo IFkxC0n7LCTts5C0L2BkWcUonpySXJybXm5gqJecn5tbnJxfkApibWIERR4Ly4sdjKc3aB9i FOBgVOLh5XjiGSjEmlhWXJl7iFGSg0lJlNdL3ytQiC8pP6UyI7E4I76oNCe1+BCjBAezkgjv MiWgHG9KYmVValE+TEqDg0Pg9JP7pxilWPLy81KVJHjNTIHKBItS01Mr0jJzgGkHppSJgxNk FA/QKGmQGt7igsTc4sx0iPwpRlWO5uXPXzAKgQ2SEudtAikSACnKKM2Dm/OKURzoeGFeV5As DzBxwk14BTScCWj4jf1uIMNLEhFSUg2M3AIcswSNfXM0F703sNzjcGOvxYwvHuKqnspPoy4s sdhrFCb2vXnyhXX7LErvdS8+1h2/Z57I526dX3dtX65awXRHVmJz0F8vsXf/j0vNU9q1gVW4 v6hi39K38/3vvd66KOHwTf3DtTuWT0nlSlxqm6P57m1z3cGvwjs/n21+3KC/duax9arsX5RY ijMSDbWYi4oTAWcl1UlZAwAA Cc: "ecrit@ietf.org" Subject: Re: [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: Wed, 20 Mar 2013 22:22:49 -0000 Hi Brian, I can see that this can be used to provide what will meet my needs, but it = becomes a bit clunky in the URI case where a single source might provide mu= ltiple blocks and you need all (or more than one block) to get the informat= ion you need. In this case the client needs to fetch multiple data sets and= then glue them together. I think a useful addition to the document would be to allow the fetching of= all the additional data blocks that an node has in one fetch. I can think = of several ways that this could be done: 1) Allow a general purpose; purpose=3D"emergencyCallData" and this would sa= y to the receiving end that a GET to this URI will give you all I have. 2) Allow a compound purpose so that you can specify which blocks the URI ca= n return (I don't like this because it requires specific parsing of the pur= pose field). 3) Change the semantics of the GET to any of define URI blocks so that the = server is allowed to return whatever blocks it has providing that it return= s at least the block type that the URI was for. For example, if I used the = list of URI you provided below, a GET to https:addlData,example.com/ref1 wo= uld allow the server to return; emergencyCallData.ProviderInfo, emergencyCa= llData.SvcInfo, and any other blocks it has. I know that this is an optimization, but as specified a PSAP in i3 will nee= d to make 3 additional data queries to the LIF to get what it needs. Cheers James =20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Thursday, 21 March 2013 1:09 AM To: Winterbottom, James Cc: ecrit@ietf.org Subject: Re: [Ecrit] Additional Data -07 I think you misunderstand the mechanism, although what we provide isn't EXA= CTLY what you asked for. You can 1) provide a single structure with multiple URIs, each URI to a different c= ontainer type. This would look like ... 2) provide a single XML container with the actual XML structure you want. = This would look like Example SP 11234 ... Business ... On Mar 19, 2013, at 11:43 PM, "Winterbottom, James" wrote: > Hi Authors, >=20 > It is quite possible that I am misunderstanding things here and how the n= ew Provided-By schema defined in section 14.3.1 is intended to be used, so = let me present my use case. >=20 > The Location interworking Function (LIF) in NENA i3 essentially needs to = be able to serve up existing ALI records but broken up into locations and a= dditional data. The additional data that needs to be provided maps into sev= eral of the additional data XML containers defined in this document. >=20 > What I need to be able to do is to return: > 1) A single structure with multiple URIs each URI to a different containe= r type. > 2) A single XML container with the actual XML structures I want. >=20 > What is provided doesn't seem to let me do that easily, and certainly isn= 't obvious. >=20 > I would like to propose the following schema as a replacement for what is= currently in the document. >=20 > > targetNamespace=3D"urn:ietf:params:xml:ns:pidf:geopriv10:emergencyCallDa= ta" > xmlns:xs=3D"http://www.w3.org/2001/XMLSchema" > xmlns:ad=3D"urn:ietf:params:xml:ns:pidf:geopriv10:emergencyCallData" > xmlns:xml=3D"http://www.w3.org/XML/1998/namespace" > xmlns:pi=3D"urn:ietf:params:xml:ns:emergencyCall.ProviderInfo" > xmlns:svc=3D"urn:ietf:params:xml:ns:emergencyCall.SvcInfo" > xmlns:dev=3D"urn:ietf:params:xml:ns:emergencyCall.DevInfo" > xmlns:sub=3D"urn:ietf:params:xml:ns:emergencyCall.SubInfo" > xmlns:com=3D"urn:ietf:params:xml:ns:emergencyCall.Comment" > elementFormDefault=3D"qualified" attributeFormDefault=3D"unqualified"> > =09 > > =09 > > > > > > > > > > > > > =09 > > =09 > > > > minOccurs=3D"0" maxOccurs=3D"1"/> > minOccurs=3D"0" maxOccurs=3D"1"/> > minOccurs=3D"0" maxOccurs=3D"1"/> > minOccurs=3D"0" maxOccurs=3D"1"/> > minOccurs=3D"0" maxOccurs=3D"1"/> > > > > > >=20 >=20 > This schema lets you send a single reference, or multiple references, as = well as a single XML container with all the relevant blocks and provides ex= tensions points. I think that this still meets the original intent. >=20 > Cheers > James >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From keith.drage@alcatel-lucent.com Fri Mar 22 03:20: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 C145C21F90CC for ; Fri, 22 Mar 2013 03:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiuyX3HmySqd for ; Fri, 22 Mar 2013 03:20:53 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8820921F90BA for ; Fri, 22 Mar 2013 03:20:53 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r2MAKna6003084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Mar 2013 05:20:49 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r2MAKmgn010894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Mar 2013 06:20:48 -0400 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 22 Mar 2013 06:20:48 -0400 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 22 Mar 2013 11:20:40 +0100 From: "DRAGE, Keith (Keith)" To: Ivo Sedlacek , Richard Barnes Thread-Topic: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels) Thread-Index: AQHOJXkliPQAg8Uiuk+EGiwTaCC+PpiupH0AgALZDbA= Date: Fri, 22 Mar 2013 10:20:39 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0193EE@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B01831C@FR712WXCHMBA11.zeu.alcatel-lucent.com> <39B5E4D390E9BD4890E2B310790061010A7DB1@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B310790061010A849E@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B310790061010A849E@ESESSMB301.ericsson.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B0193EEFR712WXCHMBA11zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-serviceid-labels) 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 Mar 2013 10:20:54 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B0193EEFR712WXCHMBA11zeu_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable I believe all the specifications require is that sos.police is handled appr= opriately if sos.police.national and sos.police.local exist and that depend= s on national regulation. It would be perfectly legitimate that sos.police = is handled by a third set of PSAPs, but the likely scenario is that they ar= e handled either by PSAPs relating to sos.police.national, or by PSAPS rela= ting to sos.police.local. The point is that depending on the nature of the national police force vers= us munical police force in any given country, either could apply, and I sus= pect we could identify European examples that support both. Keith ________________________________ From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] Sent: 20 March 2013 15:32 To: Richard Barnes Cc: Martin Thomson; DRAGE, Keith (Keith); Rosen, Brian; ecrit@ietf.org Subject: RE: [Ecrit] [IANA #658921] General Request for Assignment (urn-ser= viceid-labels) Hello, > How is the first of those two different from "urn:service:sos.police" ? = That is, do you envision a case where "sos.police", "sos.police.national", = and "sos.police.local" all refer to different entities? "sos.police.local" (municipal police) will refer to the PSAP of the municip= al police. "sos.police.national" (national police) will refer to the PSAP of the natio= nal police. In the Czech republic, a request for "sos.police" will likely be routed to = the PSAP of the national police. If a major crime is to be reported, the mu= nicipal police will need to hand it over to the national police anyway. I d= o not know requirements in other 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: Richard Barnes [mailto:rlb@ipv.sx] Sent: 20. b=F8ezna 2013 15:42 To: Ivo Sedlacek Cc: Martin Thomson; DRAGE, Keith (Keith); Rosen, Brian; ecrit@ietf.org Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-ser= viceid-labels) Ivo, How is the first of those two different from "urn:service:sos.police" ? Th= at is, do you envision a case where "sos.police", "sos.police.national", an= d "sos.police.local" all refer to different entities? --Richard On Wed, Mar 20, 2013 at 2:15 AM, Ivo Sedlacek > wrote: Hello, we need to distinguish: - the emergency service of the municipal police (e.g. to be used to report = a pickpocket) - the emergency service of the national police (e.g. to be used to report a= murder). In a given location, the user can call any of them and get different servic= e. That's why different emergency URNs are needed. I have no strong view whether ".local" or other suffix (e.g. ".A3") is to i= dentify the emergency service of the municipal police. 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-b= ounces@ietf.org] On Behalf Of Martin Thomson Sent: 19. b=F8ezna 2013 21:03 To: DRAGE, Keith (Keith) Cc: Rosen, Brian; ecrit@ietf.org Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-ser= viceid-labels) On 19 March 2013 12:27, DRAGE, Keith (Keith) > wrote: > Martin Thomson wrote: > >> I agree with Brian, "local" is not just ambiguous, it's redundant. >> "urn:service:sos.police.local" is semantically equivalent to >> "urn:service:sos.police". >> > > I disagree with the last part of this. I think that you missed my point. By nature, all urn:service:sos sub-servi= ces are local. That's why LoST exists. Adding ".local" is redundant. _______________________________________________ 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_949EF20990823C4C85C18D59AA11AD8B0193EEFR712WXCHMBA11zeu_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable <= o:SmartTagType namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" = name=3D"date" />

I believe all the specifications requi= re is that sos.police is handled appropriately if sos.police.national and s= os.police.local exist and that depends on national regulation. It would be perfectly legitimate = that sos.police is handled by a third set of PSAPs, but the likely scenario= is that they are handled either by PSAPs relating to sos.police.national, = or by PSAPS relating to sos.police.local.

 

The point is that depending on the nat= ure of the national police force versus munical police force in any given c= ountry, either could apply, and I suspect we could identify European examples that support both= .

 

Keith

 

From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com]
Sent: 20 March 2013 15:32 To: Richard Barnes
Cc: Martin Thomson; DRAGE, K= eith (Keith); Rosen, Brian; ecrit@ietf.org
Subject: RE: [Ecrit] [IANA #= 658921] General Request for Assignment (urn-serviceid-labels)=

 

Hello,

 

> How is the first of those two different = from "urn:service:sos.police" ?  That is, do you envision a = case where "sos.police", "sos.police.national", and &qu= ot;sos.police.local" all refer to different entities?

 

"sos.police.local" (municipal police) will refer to the PSAP o= f the municipal police.

"sos.police.national" (national police) will refer to the PSAP= of the national police.

In the Czech republic, a request for "sos.police" will like= ly be routed to the PSAP of the national police. If a major crime is to be = reported, the municipal police will need to hand it over to the national police anyway. I do not know requirements in other= countries.

 

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: Richard Barnes [mailto:rlb@ipv.sx]
Sent: 20. b=F8ezna 2013 15:4= 2
To: Ivo Sedlacek
Cc: Martin Thomson; DRAGE, K= eith (Keith); Rosen, Brian; ecrit@ietf.org
Subject: Re: [Ecrit] [IANA #= 658921] General Request for Assignment (urn-serviceid-labels)

 

Ivo,

 

How is the first of those two differe= nt from "urn:service:sos.police" ?  That is, do you envision= a case where "sos.police", "sos.police.national", and = "sos.police.local" all refer to different entities?

 

--Richard

 

&= nbsp;

On Wed, Mar= 20, 2013 at 2:15 AM, Ivo Sedl= acek <ivo= .sedlacek@ericsson.com> wrote:

Hello,

we need to distinguish:
- the emergency service of the municipal police (e.g. to be used to report = a pickpocket)
- the emergency service of the national police (e.g. to be used to report a= murder).

In a given location, the user can call any of them and get different servic= e. That's why different emergency URNs are needed.

I have no strong view whether ".local" or other suffix (e.g. &quo= t;.A3") is to identify the emergency service of the municipal police.<= o:p>


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

Sent: 19. b=F8ezna 2013 21:03
To: DRAGE, Keith (Keith)

Cc: Ro= sen, Brian; ecrit@ietf.org
Subject: Re: [Ecrit] [IANA #658921] General Request for Assignment (urn-ser= viceid-labels)

On 19 March 2013 12:27, DRAGE, Keith = (Keith) <keith.drage@a= lcatel-lucent.com> wrote:
> Martin Thomson wrote:
>
>> I agree with Brian, "local" is not just ambiguous, it's = redundant.
>> "urn:service:sos.police.local" is semantically equivalen= t to
>> "urn:service:sos.police".
>>
>
> I disagree with the last part of this.

I think that you missed my point.  By nature, all urn:service:sos sub-= services are local.  That's why LoST exists.  Adding ".local= " is redundant.
_______________________________________________
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

 

--_000_949EF20990823C4C85C18D59AA11AD8B0193EEFR712WXCHMBA11zeu_-- From RMarshall@telecomsys.com Fri Mar 22 15: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 03E6521F9454 for ; Fri, 22 Mar 2013 15:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.998 X-Spam-Level: X-Spam-Status: No, score=-103.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClFKiDVI+RMG for ; Fri, 22 Mar 2013 15:45:19 -0700 (PDT) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) by ietfa.amsl.com (Postfix) with ESMTP id 47C9E21F9451 for ; Fri, 22 Mar 2013 15:45:19 -0700 (PDT) Received: from SEA-EXCAS-2.telecomsys.com (exc2010-local2.telecomsys.com [10.32.12.187]) by sea-mx-02.telecomsys.com (8.14.1/8.14.1) with ESMTP id r2MMjCHt005903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 22 Mar 2013 15:45:13 -0700 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.178]) by SEA-EXCAS-2.telecomsys.com ([10.32.12.187]) with mapi id 14.01.0355.002; Fri, 22 Mar 2013 15:45:12 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: IETF86: Minutes for Ecrit, 03/13/2013 Thread-Index: Ac4nTukMYxlSoYNRRaS58RAGew+JXQ== Date: Fri, 22 Mar 2013 22:45:11 +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_FBD5AAFFD0978846BF6D3FAB4C892ACC23135FSEAEXMB1telecomsy_" MIME-Version: 1.0 Subject: [Ecrit] IETF86: Minutes for Ecrit, 03/13/2013 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 Mar 2013 22:45:32 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC23135FSEAEXMB1telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Minutes w/summary, ECRIT WG Meeting, IETF86 Orlando, 03/13/2013, 13:00-15:00 If you have any additions or modifications to these minutes, please let Roger & Marc know via email. These minutes will be updated to the IETF86 meeting materials page. Thank you goes to Jean Mahoney for note-taking, and, thanks also to Robert Sparks for serving as RAI AD these past years. Chairs: Roger Marshall, rmarshall@telecomsys.com Marc Linsner, mlinsner@cisco.com Summary 1. Revisions shown to former milestone dates will be posted to the list, th= en submitted, based on comments received in the working group meeting. It was agreed that the current date for rough-location should be pushed out a year. 2. Christer agreed to fix the nits to draft-ietf-ecrit-psap-callback-08, th= en chairs will submit to IESG for processing. 3. Richard provided status on the rough-location, stating that it's progress is dependent on a liaison response for direction. 4. Brian agreed to additional-data next action discussing new block or URI = on the wg email list. 5. For data-only draft, when a CAP message is by reference or value, Brian agreed to rework the draft to make it like the additional-data draft, using a Call-Info header with a URL that can be a cid. 6. Ecall draft, it was proposed that document be made separate drafts, so that service URNs just need expert review. Brian would be agreeable subject to wg consensus (tested on the list). 7. The discussion around trustworthy-location was that some parts needed to be lifted out and put into other drafts, then ask for an intense review once Bernard submits version -05. 8. Draft rph-reg-policy suggests changes that avoid adding a new top level requires standard track, but would make it by expert review. Adam Roach stated that the RPH Registry Management Policy draft be raised in sipcore. 9. For draft-holmberg-ecrit-country-emg-urn, the proposal to handle this with expert review was proffered, and the wg chairs asked for a show of interest in this work? <12 hands up>, with , which showed a decent amount of interest. Actual drafts discussed: Additional Data related to an Emergency Call draft-ietf-ecrit-additional-data Data-Only Emergency Alerts using the SIP draft-ietf-ecrit-data-only-ea Internet Protocol-based In-Vehicle Emergency Call draft-rosen-ecrit-ecall Trustworthy Location Information draft-ietf-ecrit-trustworthy-location RPH Registry Management Policy to IETF Review draft-rosen-rph-reg-policy-00.txt/ URN For Country Specific Emergency Services draft-holmberg-ecrit-country-emg-urn/ ----------------------------------------------------------------------- Agenda Bashing, Draft Status Update (10 min) Presentation: http://www.ietf.org/proceedings/86/slides/slides-86-ecrit-5.p= ptx Presenters: Marc Linsner, Roger Marshall Note taker: Jean Mahoney Jabber scribe: Hannes Tschofenig Jabber log: http://www.ietf.org/jabber/logs/ecrit/2013-03-13.html The ECRIT working group presented the outgoing RAI area director Robert Spa= rks a bottle of tequila as a token of their appreciation. On behalf of the GEOPRIV working group, which didn't meet, Richard Barnes p= resented Robert with geographically-specific chocolates and a chocolate bar= with privacy rules and which, according to its label, may cause an emergen= cy if consumed. ACTION: Robert Sparks to report on how he gets the tequila home. Note well presented. The agenda has been modified - the presentation "Extensions to the Emergenc= y Services Architecture for dealing with Unauthenticated and Unauthorized D= evices (15 min)" was canceled. Document status presented: draft-ietf-ecrit-psap-callback-08* would be good to correct nits first, the= n send to IESG Milestones presented: Have been updated but not submitted. Hannes Tschofenig - what's the status of the Imprecise Location draft? Richard Barnes - Liaison to see if pending NC direction. Hannes - the March milestones need to be updated. I also requested a WGLC o= n [?], maybe in July. ACTION: provide feedback on the mailing list before the update is submitted. ----------------------------------------------------------------------- Additional Data related to an Emergency Call (10 min) http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ Presentation: http://www.ietf.org/proceedings/86/slides/slides-86-ecrit-1.p= ptx Presenter: Brian Rosen Intention: Discuss if ready for WGLC Sllide 3 - Open Items: Brian - We need some text on when it is appropriate to use either a new blo= ck or URI and type with registry in device block when handling device-speci= fic data. The answer has to do with the following issues: - things that are widely applicable and large structure - need separate bl= ock with more IETF review - URI - first come first served What kind of review should it get? It's allowable to send a block by value but not a device block with url, yo= u can't send that by value. What about A huge thing sent by value? - I worr= y about that. It should be covered in the considerations section. Any reactions? Randall Gellens - There can be side effects from sending large data by valu= e, but for device, you can only send by value. Hannes - You don't want to be restrictive on the process of adding new bloc= ks. You can shoot yourself in the foot. Brian - It's expert review - not RFC. Hannes - that's not that restrictive. Martin Thomson - it's not a restrictive space. Brian - Right. We think we're done. Get it out before the intermediary [?] = (interim? but Marc indicated later in the meeting that there wasn't an inte= rim). Marc - Anyone willing to review it? We'll take it to the list. ACTION: Discuss when it is appropriate to use either a new block or URI and= type with registry in device block when handling device-specific data on t= he mailing list. ----------------------------------------------------------------------- Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the S= ession Initiation Protocol (10 min) http://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ Presentation: http://www.ietf.org/proceedings/86/slides/slides-86-ecrit-2.p= ptx Presenter: Brian Rosen Intention: Discuss latest changes Slides presented. James Polk - On slide 3, do you mean any SIP request? Including CANCEL? Brian - it's not a request, it's a transaction. CANCEL is a bad example. Ce= rtainly UPDATE. Bernard Aboba - you could include a URL. Fetch an updated version if you wa= nted to. Brian - sure. Now I need to define a mime type or a new header. Now it's a = just a [...] Martin - I was going to suggest using Call-Info. Where to get the sub and t= he authorization? Send a message saying I'm here [...]. I think it's a fin= e idea. Brian - I should put the mechanism with the original INVITE. It will be eas= y. I can define [...] In the Call-Info, for further info, subscribe here - = URL and call info. Randall - what about the mechanism in additional-data [...] Brian - I'm going to reuse that. Roger - Summarize what Randall said. Brian - Send a CAP message by reference or value. Like the additional-data = draft - A Call-Info header with a URL that can be a CID. I will rework the = draft to that. Randall - you just need a definition of the MIME type and [...] Brian - make the CAP message a block of additional data. Great idea. ----------------------------------------------------------------------- Internet Protocol-based In-Vehicle Emergency Call (20 min) http://datatracker.ietf.org/doc/draft-rosen-ecrit-ecall/ Presentation: http://www.ietf.org/proceedings/86/slides/slides-86-ecrit-6.p= pt Presenter: Hannes Tschofenig Intention: Discuss whether candidate for WG adoption Slides presented. Marc, as indvidual - How does this draft contrast with the data-only draft? Hannes - It complements data-only. There are some additional structures. Th= e eCall spec talks about 2 data elements - a minimal set (covered in the ex= ample on slide 4). The other is more extensive and lines up with additional= -data and data-only. The data-only plays a role when there's no media. Brian - additional-data provides a mechanism for carrying sensor-related da= ta. We have extensions for carrying data. data-only provides CAP - alert re= lated - which says, "you need to pay attention because". I don't know how t= his adds. We have a place to put the data and a place to put the alert. Wha= t isn't covered? Hannes - This defines 2 service URNs for eCall. It provides description of = how it relates to eCall. How to use this work for their purpose. Randall - With every situation for eCall, the voice channel is the paramoun= t importance. Hannes - The draft doesn't reference the data-only draft because I had the = same impression. eCall doesn't spec how to [?]. Henning - In the United States, there are researchers that collect data tha= t include deceleration, airbags inflated, tension on seatbelt. Doesn't seem= to fit into a CAP model. Hannes - it fits into Additional Data. Henning Schulzrinne - we should talk with those folks. How to make it fit = in. They are using VOIP for emergency calls. 2nd - there's a blurring betwe= en true emergency calls - sending an ambulance for instance - and when you = want to do more prevention. Reporting that the ABS/stability systems go on = - can indicate black ice. Or fog lights go on - fog - the information could= go to highway patrol. Possibly a different service URN. It's safety relate= d. They can get warnings out. Need to send salt out. Act as data fusion cen= ter. Can be automated. This is stretching the 911 model. Can think about th= is. Hannes - We can describe that in doc as use cases. And double check with ad= ditional-data to see if we have schemas in place. But it's a different leve= l of detail. Henning Schulzrinne - try to get people to think ahead. Randall, to Henning - have those people get in touch with authors, review, = sign up on mail list. You raise the safety related issues. There's overlap = for reuse. The use cases should be in a new doc. I want this doc to be emer= gency calling. ACTION: Henning to contact the US researchers he mentioned to ask them to r= eview the document and to sign up for the ECRIT mailing list. Brian - I'm an author but I haven't been involved in the last 2 versions. F= irst point - the doc needs to be clearer on its intended purposes. It doesn= 't explain why you are defining new URNs. It's because they are routed diff= erently. Second point - why is it standards track? Because it's defining se= rvice URNs. Otherwise it's an informational document. Keith Drage - eCall is an emergency call. We have different architectures f= or delivering calls. Don't want non-emergency sent to the PSAP. Randall - that's why it should be in its own document. RFC - say URNs need = expert review, not standards track. Hannes - Is there interest in the working group? Brian - I would like to speak in favor as an author. It's a reference to us= e IETF mechanisms to do what they want to do. It's valuable. Marc - Then I heard Henning say we need to add others. Henning - I don't want to hold up anything for something speculative. Ensur= e that the doc is self-contained for all pieces for telematics for emergenc= y calling. I don't know if it's been considered by eCall. Separately - we n= eed to talk about the other component - a separate schema and URI. Hannes - I reference Additional Data. It would be good [?]. There's a limit= on the data they send for eCall. Marc - what do we think? Randall - we might want a separate doc so that service URNs just need exper= t review. Brian - do IETF consensus for it. I'd be happy to do that doc. Marc, as chair - how many people read the draft and are interested? Marc - We will take it to the list. ACTION: Discuss adopting the draft as a working group item on the mailing l= ist. Randall - [?] Brian - I request a call for a hum to downgrade the registry. Keith - we're going to talk about this later. Brian - I can wait. ----------------------------------------------------------------------- Extensions to the Emergency Services Architecture for dealing with Unauthen= ticated and Unauthorized Devices (15 min) http://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access/ Presenter: Hannes Tschofenig Intention: Discuss latest changes CANCELED. ----------------------------------------------------------------------- Trustworthy Location Information (15 min) http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/ Presenter: Bernard Aboba Intention: Discuss latest changes Slide 3 - Issue 4: Untrusted Location and Provider Intent. Martin Thomson - I worry when people look at how location info was received= to determine if it's trustworthy. The real info used to determine if it's = good is: when it was the info generated? What's the uncertainty? What's the= location? There are other things used to determine trust. The latter half = of the paragraph is important. Bernard - If it came from a LIS, ok. But if it came from some weird place, = what do I say in the pdif-lo? I want to tell the PSAP enough info to make a= judgment. Brian - It's on the right track. The basic info is: how you measured it, ho= w accurate it is, what the location is. Bernard - if not authoritative and measured a year ago. Brian - the timestamp of the measurement and the timestamp of when it was s= ent [?] Henning - It's difficult to know if the accuracy was determined in a global= way. For instance, GPS has this sort of accuracy. Or for that specific mea= surement. Wifi gives you this. In certain cases, it's more or less accurate= . But you tell me about the particular measurement. Primary and secondary -= aggregators - have munged up data magically, adding trust info. The smartp= hone vendors do this, and don't say how they do it. Just knowing source - l= ike the company and if they do a good job of preventing spoofing - it gives= you a sense. Bernard - We're not capturing that. we'll expand section 4. Martin - every location provided provides uncertainty on it. There are some= cells where locations are within 10 meters. With GPS, you can determine un= certainty and can report that. You need to make it explicit that you report= the measurement's uncertainty, not the technology's. The location info is = not technology specific - there's a lot of combination of data. Bernard - good point. "wifi location" term is meaningless. Henning - it's not a technology - saying which vendor which provided it is = shorthand for what data is blended. FCC no longer makes some of these disti= nctions. Slide 4 - Issue 9: Definition of Trustworthy Russ Housley - I worry that the term "Secure" is more vague than "trustwort= hy". You are trying to say with authentication, integrity or both. But not = confidentiality. Bernard - We're not talking about privacy here. Russ - Define the security services - authentication, integrity or both. Henning - our model is different than a traditional security system. Our mo= del is more statistical, a risk assessment model. As a PSAP, I care about t= he following: out of a million locations, how many are wrong? How many are = maliciously modified? How many of these issues can I detect reasonably? If = you can detect it. Except for large scale man-in-the-middle attacks, this i= s generally determined one by one. This is risk assessment. If your adversa= ry can compromise GPS satellites - then your data can't be trustworthy. Bernard - How about the end - "securely obtained from a trusted source"? Richard - It needs to say what we are and aren't doing. Would like to guara= ntee the position of the call. Henning - There are levels of trust - origin assertion that you verified. I= f you were to ask a PSAP director to define trustworthy, he would care abou= t correctness, not that there's an adversary. A wifi access point has been = moved to a new Starbuck's branch, for instance. That's far removed from the= trustworthy computing model. They are concerned more with incompetence tha= n malice. Richard - Say in doc that we're reducing the problem from the security prob= lem to the positioning problem. Henning - it's a framing informational doc. Need to start at a high goal - = what is trustworthy. I need to have confidence in data in provided, that so= meone is responsible for improving the data (the locations of people callin= g from a certain mall always show that they're over there), and that muckin= g with data is difficult. PSAPs conflate all of those. The solutions are di= fferent. Martin - it's hard work. The biggest part is managing where the location in= fo comes from and patching it when it changes. It's complicated and expensi= ve. Slide 6 - Issue 8 Solutions Martin - I've commented on section 3.2 on the list. What a list provider wo= uld do, but not what we want to do in this situation. You're talking about = authorization from the LIS end of things. Bernard - We have an operational concern - how does the PSAP do this? But c= ircumstance [?] location hiding. Martin - Move it to a doc on location hiding, it doesn't belong here. Bernard - is it worth talking about access control at all? Martin - no, it can be cut. Brian - I'm not sure I agree on this. I care about the solution. Sending it= by reference to some server, and we know who we're talking about. The choi= ce of credentials becomes a problem. The PSAP can't maintain credentials fo= r everything. Then the PSAP has to provide credentials to you. Can't ignore= this. Bernard - if using TLS [?] Brian - It needs text on where credentials come from. Section 3.3 (proxy ad= ded location) needs more work. If the access network ... and doesn't trust = ... and it adds a proxy. The proxy adds location. Because it's more trustwo= rthy, I don't need the other. The intermediary doesn't have the trust. Coul= d expand the text. Bernard - Please provide text. Martin - Add the text and the PSAP credentials to the rough-loc draft. It's= confusing in this doc. Slide 10 - Next steps Bernard - Would like an intense review to get into -06 Marc - when you submit -05, we'll ask for reviewers. ----------------------------------------------------------------------- Resource Priority Header (RPH) Registry Management Policy to IETF Review (5 min) http://datatracker.ietf.org/doc/draft-rosen-rph-reg-policy-00.txt/ Presentation: http://www.ietf.org/proceedings/86/slides/slides-86-ecrit-3.p= ptx Presenter: Brian Rosen Intention: Discussion Brian - This is IESG approved, but 4412 requires standards track to define = a new RPH namespace. I wrote this draft to downgrade the IANA policy to mak= e it consensus rather than standards track. Adam Roach - Please comment on sipcore list. Marc, as chair - quickly. Brian - sos only requires expert review. Adding a new top level requires st= andard track, this is a proposal to change that. Adding [?] expert review, = Hannes' doc can be informational. There are no changes to the registry poli= cy. Richard - please summarize [?] Marc - I'll have to find it. Let Christer go on with his presentation. ----------------------------------------------------------------------- URN For Country Specific Emergency Services (20 min) http://datatracker.ietf.org/doc/draft-holmberg-ecrit-country-emg-urn/ Presentation: http://www.ietf.org/proceedings/86/slides/slides-86-ecrit-0.p= pt Presenter: Christer Holmberg Intention: New draft presentation Slide 4 - alternative 1 Brian - we've recreated X- or P headers. Christer - We've been told to do this on the list. Slide 6 - alternative 3 Keith - I don't think this solves the problem of "we may never have to move= it". You have one country that wants it. Or three countries that want it, = but they don't exist. For example, road side assistance. You may need to co= ver 2 or more values. The first person in says - I have service offered by = the police. The second one - same service, same semantics, but not offered = by police. You are still going to have this problem. Brian - I don't know how to engineer around it. We want review, not first-c= ome-first-served. I support this proposal. Will there be a document that do= es just this? Christer - it updates 5031. BIran - want to downgrade in the same doc. Henning - There is not a demonstrated need at the moment. Brian - I don't want this to be held up because it's only defining service = URN. Henning - Don't want to argue about regional. For example, lower 48, not of= fered in Alaska. Only reason to do sub-services - don't get lower level. St= ill have a problem with an organizational hierarchy that changes over time = - think of the Department of Homeland Security. Advice to experts to consid= er - is it inherently a police function? Not enforcement of law. Could add = that advice. It may not be a big enough problem to create another label. Th= ere's no way to go up, no generic emergency service on top of it. Christer - to clarify - there may be a reason why due to hierarchy but the = semantics are the same and should also allow to register. Henning - that outcome is undesirable and should be avoidable. Brian - send text Henning - we don't want to imply [?] The notion of one country is somewhat = meaningless. Christer - and send xml version of 3631[?] Andrew Allen - who can apply? You have to check that they are a relevant au= thority. Christer - it's good to have guidance, but we can't say who can and can't a= pply. Brian - good idea, send text. The experts can consider who's asking. Keith - I sent to the list 2-3 weeks ago. In regard who is asked to reply. = the top level. If you don't apply if you can't offer. If you need to move s= ubtypes. For example sos.police.xyz and the police go away. The admin wants= the URNs, not the deployers, they are not involved in IETF. That's why we = need expert review. Richard - moving subtypes from one super-type to the other is not a big dea= l, just define the new one. I don't think "who's asking" is a problem. Chec= k out the wikipedia article on what emergency services are. We can just go = ahead and register these. Brian - this document doesn't do - adding sub-sub-service. There are differ= ent hierarchies of policy. Do you want a separate doc? Christer - I think we need a separate decision. Brian - I'm raising the issue. People recognize that this is a problem. Sta= te and local policy need different URNs. It doesn't have to be this doc. = I recommend that it is in this doc. Keith - To do that - just write a letter to IANA. Brian - only add sub-services after sos. I have an already registered servi= ce. sos.police -> sos.police.nnn If IANA doesn't have a problem. Keith - we want the same policy to apply to sub-sub-types. Marc, as chair - your coauthor sent request to IANA. Christer - I was informed just before the meeting. That isn't really about = this document. Marc - we'll handle this with expert review. How many people interested in = this work? <12 hands up> Marc - Any opposition? 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_FBD5AAFFD0978846BF6D3FAB4C892ACC23135FSEAEXMB1telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Minutes w/summary, ECRIT WG Meeting, IETF86 Orlando,= 03/13/2013, 13:00-15:00

 

If you have any additions or modifications to these = minutes, please let

Roger & Marc know via email.  These minutes= will be updated to the IETF86

meeting materials page.

 

Thank you goes to Jean Mahoney for note-taking, and,= thanks also to Robert

Sparks for serving as RAI AD these past years.<= /o:p>

 

Chairs:

Roger Marshall, rmarshall@telecomsys.com

Marc Linsner, = mlinsner@cisco.com

 

Summary

 

1. Revisions shown to former milestone dates will be= posted to the list, then

submitted, based on comments received in the working= group meeting. It was

agreed that the current date for rough-location shou= ld be pushed out a year.

 

2. Christer agreed to fix the nits to draft-ietf-ecr= it-psap-callback-08, then

chairs will submit to IESG for processing.

 

3. Richard provided status on the rough-location, st= ating that it's progress

is dependent on a liaison response for direction.

 

4. Brian agreed to additional-data next action discu= ssing new block or URI on

the wg email list.

 

5. For data-only draft, when a CAP message is by ref= erence or value, Brian

agreed to rework the draft to make it like the addit= ional-data draft, using

a Call-Info header with a URL that can be a cid.

 

6. Ecall draft, it was proposed that document be mad= e separate drafts, so

that service URNs just need expert review.  Bri= an would be agreeable subject

to wg consensus (tested on the list).

 

7. The discussion around trustworthy-location was th= at some parts needed to

be lifted out and put into other drafts, then ask fo= r an intense review once

Bernard submits version -05.

 

8. Draft rph-reg-policy suggests changes that avoid = adding a new top level

requires standard track, but would make it by expert= review. Adam Roach

stated that the RPH Registry Management Policy draft= be raised in sipcore.

 

9. For draft-holmberg-ecrit-country-emg-urn, the pro= posal to handle

this with expert review was proffered, and the wg ch= airs asked for a show of

interest in this work? <12 hands up>, with <= ;no opposition>, which showed a

decent amount of interest.

 

 

 

Actual drafts discussed:

 

Additional Data related to an Emergency Call

draft-ietf-ecrit-additional-data

 

Data-Only Emergency Alerts using the SIP<= /p>

draft-ietf-ecrit-data-only-ea

 

Internet Protocol-based In-Vehicle Emergency Call

draft-rosen-ecrit-ecall

 

Trustworthy Location Information

draft-ietf-ecrit-trustworthy-location

 

RPH Registry Management Policy to IETF Review

draft-rosen-rph-reg-policy-00.txt/

 

URN For Country Specific Emergency Services

draft-holmberg-ecrit-country-emg-urn/

 

 

 

----------------------------------------------------= -------------------

Agenda Bashing, Draft Status Update (10 min)

Presentation: http://www.ietf.org/proceedings/86/sli= des/slides-86-ecrit-5.pptx

Presenters: Marc Linsner, Roger Marshall<= /p>

 

Note taker: Jean Mahoney

Jabber scribe: Hannes Tschofenig

Jabber log: http://www.ietf.org/jabber/logs/ecrit/20= 13-03-13.html

 

The ECRIT working group presented the outgoing RAI a= rea director Robert Sparks a bottle of tequila as a token of their apprecia= tion.

 

On behalf of the GEOPRIV working group, which didn't= meet, Richard Barnes presented Robert with geographically-specific chocola= tes and a chocolate bar with privacy rules and which, according to its labe= l, may cause an emergency if consumed.

 

ACTION: Robert Sparks to report on how he gets the t= equila home.

 

Note well presented.

 

The agenda has been modified - the presentation &quo= t;Extensions to the Emergency Services Architecture for dealing with Unauth= enticated and Unauthorized Devices (15 min)" was canceled.

 

Document status presented:

 

draft-ietf-ecrit-psap-callback-08* would be good to = correct nits first, then send to IESG

 

Milestones presented:

 

Have been updated but not submitted.

 

Hannes Tschofenig - what's the status of the Impreci= se Location draft?

 

Richard Barnes - Liaison to see if pending NC direct= ion.

 

Hannes - the March milestones need to be updated. I = also requested a WGLC on [?], maybe in July.

 

ACTION: provide feedback on the mailing list before = the update is submitted.

 

----------------------------------------------------= -------------------

Additional Data related to an Emergency Call  (= 10 min)

http://datatracker.ietf.org/doc/draft-ietf-ecrit-add= itional-data/

Presentation: http://www.ietf.org/proceedings/86/sli= des/slides-86-ecrit-1.pptx

Presenter: Brian Rosen

Intention: Discuss if ready for WGLC

 

Sllide 3 - Open Items:

 

Brian - We need some text on when it is appropriate = to use either a new block or URI and type with registry in device block whe= n handling device-specific data.

 

The answer has to do with the following issues:=

- things that are widely applicable and large struct= ure - need separate  block with more IETF review

- URI - first come first served

 

What kind of review should it get?

 

It's allowable to send a block by value but not a de= vice block with url, you can't send that by value. What about A huge thing = sent by value? - I worry about that. It should be covered in the considerat= ions section.

 

Any reactions?

 

Randall Gellens - There can be side effects from sen= ding large data by value, but for device, you can only send by value.

 

Hannes - You don't want to be restrictive on the pro= cess of adding new blocks. You can shoot yourself in the foot.

 

Brian - It's expert review - not RFC.

 

Hannes - that's not that restrictive.

 

Martin Thomson - it's not a restrictive space. =

 

Brian - Right. We think we're done. Get it out befor= e the intermediary [?] (interim? but Marc indicated later in the meeting th= at there wasn't an interim).

 

Marc - Anyone willing to review it? <no response&= gt; We'll take it to the list.

 

ACTION: Discuss when it is appropriate to use either= a new block or URI and type with registry in device block when handling de= vice-specific data on the mailing list. 

 

----------------------------------------------------= -------------------

Common Alerting Protocol (CAP) based Data-Only Emerg= ency Alerts using the Session Initiation Protocol (10 min)

http://datatracker.ietf.org/doc/draft-ietf-ecrit-dat= a-only-ea/

Presentation: http://www.ietf.org/proceedings/86/sli= des/slides-86-ecrit-2.pptx

Presenter: Brian Rosen

Intention: Discuss latest changes

 

Slides presented.

 

James Polk - On slide 3, do you mean any SIP request= ? Including CANCEL?

 

Brian - it's not a request, it's a transaction. CANC= EL is a bad example. Certainly UPDATE.

 

Bernard Aboba - you could include a URL. Fetch an up= dated version if you wanted to.

 

Brian - sure. Now I need to define a mime type or a = new header. Now it's a just a [...]

 

Martin - I was going to suggest using Call-Info. Whe= re to get the sub and the authorization?  Send a message saying I'm he= re [...]. I think it's a fine idea.  

 

Brian - I should put the mechanism with the original= INVITE. It will be easy. I can define […] In the Call-Info, for furt= her info, subscribe here - URL and call info.

 

Randall - what about the mechanism in additional-dat= a […]

 

Brian - I'm going to reuse that.

 

Roger - Summarize what Randall said.

 

Brian - Send a CAP message by reference or value. Li= ke the additional-data draft - A Call-Info header with a URL that can be a = CID. I will rework the draft to that.

 

Randall - you just need a definition of the MIME typ= e and […]

 

Brian - make the CAP message a block of additional d= ata. Great idea.

 

----------------------------------------------------= -------------------

Internet Protocol-based In-Vehicle Emergency Call (2= 0 min)

http://datatracker.ietf.org/doc/draft-rosen-ecrit-ec= all/

Presentation: http://www.ietf.org/proceedings/86/sli= des/slides-86-ecrit-6.ppt

Presenter: Hannes Tschofenig

Intention: Discuss whether candidate for WG adoption=

 

Slides presented.

 

Marc, as indvidual - How does this draft contrast wi= th the data-only draft?

 

Hannes - It complements data-only. There are some ad= ditional structures. The eCall spec talks about 2 data elements - a minimal= set (covered in the example on slide 4). The other is more extensive and l= ines up with additional-data and data-only. The data-only plays a role when there's no media.

 

Brian - additional-data provides a mechanism for car= rying sensor-related data. We have extensions for carrying data. data-only = provides CAP - alert related - which says, "you need to pay attention = because". I don't know how this adds. We have a place to put the data and a place to put the alert. What isn't cove= red?

 

Hannes - This defines 2 service URNs for eCall. It p= rovides description of how it relates to eCall. How to use this work for th= eir purpose.

 

Randall - With every situation for eCall, the voice = channel is the paramount importance.

 

Hannes - The draft doesn't reference the data-only d= raft because I had the same impression. eCall doesn't spec how to [?].=

 

Henning - In the United States, there are researcher= s that collect data that include deceleration, airbags inflated, tension on= seatbelt. Doesn't seem to fit into a CAP model.

 

Hannes - it fits into Additional Data.

 

Henning Schulzrinne  - we should talk with thos= e folks. How to make it fit in. They are using VOIP for emergency calls. 2n= d - there's a blurring between true emergency calls - sending an ambulance = for instance - and when you want to do more prevention. Reporting that the ABS/stability systems go on - can indi= cate black ice. Or fog lights go on - fog - the information could go to hig= hway patrol. Possibly a different service URN. It's safety related. They ca= n get warnings out. Need to send salt out. Act as data fusion center. Can be automated. This is stretching = the 911 model. Can think about this.

 

Hannes - We can describe that in doc as use cases. A= nd double check with additional-data to see if we have schemas in place. Bu= t it's a different level of detail.

 

Henning Schulzrinne - try to get people to think ahe= ad.

 

Randall, to Henning - have those people get in touch= with authors, review, sign up on mail list. You raise the safety related i= ssues. There's overlap for reuse. The use cases should be in a new doc. I w= ant this doc to be emergency calling.

 

ACTION: Henning to contact the US researchers he men= tioned to ask them to review the document and to sign up for the ECRIT mail= ing list.

 

Brian - I'm an author but I haven't been involved in= the last 2 versions. First point - the doc needs to be clearer on its inte= nded purposes. It doesn't explain why you are defining new URNs. It's becau= se they are routed differently. Second point - why is it standards track? Because it’s defining service URN= s. Otherwise it's an informational document.

 

Keith Drage - eCall is an emergency call. We have di= fferent architectures for delivering calls. Don't want non-emergency sent t= o the PSAP.

 

Randall - that's why it should be in its own documen= t. RFC - say URNs need expert review, not standards track.

 

Hannes - Is there interest in the working group?

 

Brian - I would like to speak in favor as an author.= It's a reference to use IETF mechanisms to do what they want to do. It's v= aluable.

 

Marc - Then I heard Henning say we need to add other= s.

 

Henning - I don't want to hold up anything for somet= hing speculative. Ensure that the doc is self-contained for all pieces for = telematics for emergency calling. I don't know if it's been considered by e= Call. Separately - we need to talk about the other component - a separate schema and URI.

 

Hannes - I reference Additional Data. It would be go= od [?]. There's a limit on the data they send for eCall.

 

Marc - what do we think?

 

Randall - we might want a separate doc so that servi= ce URNs just need expert review. 

 

Brian - do IETF consensus for it. I’d be happy= to do that doc.

 

Marc, as chair - how many people read the draft and = are interested?

 

<some folks raised hands>

 

Marc - We will take it to the list.

 

ACTION: Discuss adopting the draft as a working grou= p item on the mailing list.

 

Randall - [?]

 

Brian - I request a call for a hum to downgrade the = registry.

 

Keith - we're going to talk about this later.

 

Brian - I can wait.

 

 

----------------------------------------------------= -------------------

Extensions to the Emergency Services Architecture fo= r dealing with Unauthenticated and Unauthorized Devices (15 min)

http://datatracker.ietf.org/doc/draft-ietf-ecrit-una= uthenticated-access/

Presenter: Hannes Tschofenig

Intention: Discuss latest changes

 

CANCELED.

 

 

----------------------------------------------------= -------------------

Trustworthy Location Information (15 min)=

http://datatracker.ietf.org/doc/draft-ietf-ecrit-tru= stworthy-location/

Presenter: Bernard Aboba

Intention: Discuss latest changes

 

Slide 3 - Issue 4: Untrusted Location and Provider I= ntent.

 

Martin Thomson - I worry when people look at how loc= ation info was received to determine if it’s trustworthy. The real in= fo used to determine if it’s good is: when it was the info generated?= What's the uncertainty? What’s the location? There are other things used to determine trust. The latter half of the par= agraph is important.

 

Bernard - If it came from a LIS, ok. But if it came = from some weird place, what do I say in the pdif-lo? I want to tell the PSA= P enough info to make a judgment.

 

Brian - It's on the right track. The basic info is: = how you measured it, how accurate it is, what the location is. 

 

Bernard - if not authoritative and measured a year a= go.

 

Brian - the timestamp of the measurement and the tim= estamp of when it was sent [?]

 

Henning - It's difficult to know if the accuracy was= determined in a global way. For instance, GPS has this sort of accuracy. O= r for that specific measurement. Wifi gives you this. In certain cases, it'= s more or less accurate. But you tell me about the particular measurement. Primary and secondary - aggregators -= have munged up data magically, adding trust info. The smartphone vendors d= o this, and don't say how they do it. Just knowing source - like the compan= y and if they do a good job of preventing spoofing - it gives you a sense.

 

Bernard - We're not capturing that. we'll expand sec= tion 4.

 

Martin - every location provided provides uncertaint= y on it. There are some cells where locations are within 10 meters. With GP= S, you can determine uncertainty and can report that. You need to make it e= xplicit that you report the measurement's uncertainty, not the technology's. The location info is not technology spe= cific - there's a lot of combination of data.

 

Bernard - good point. "wifi location" term= is meaningless.

 

Henning - it's not a technology - saying which vendo= r which provided it is shorthand for what data is blended. FCC no longer ma= kes some of these distinctions.

 

 

Slide 4 - Issue 9: Definition of Trustworthy

 

Russ Housley - I worry that the term "Secure&qu= ot; is more vague than "trustworthy". You are trying to say with = authentication, integrity or both. But not confidentiality.

 

Bernard - We're not talking about privacy here.

 

Russ - Define the security services - authentication= , integrity or both.

 

Henning - our model is different than a traditional = security system. Our model is more statistical, a risk assessment model. As= a PSAP, I care about the following: out of a million locations, how many a= re wrong? How many are maliciously modified? How many of these issues can I detect reasonably? If you can det= ect it. Except for large scale man-in-the-middle attacks, this is generally= determined one by one. This is risk assessment. If your adversary can comp= romise GPS satellites - then your data can't be trustworthy.

 

Bernard - How about the end - "securely obtaine= d from a trusted source"?

 

Richard - It needs to say what we are and aren't doi= ng. Would like to guarantee the position of the call.

 

Henning - There are levels of trust - origin asserti= on that you verified. If you were to ask a PSAP director to define trustwor= thy, he would care about correctness, not that there's an adversary. A wifi= access point has been moved to a new Starbuck's branch, for instance. That's far removed from the trustwort= hy computing model. They are concerned more with incompetence than malice.

 

Richard - Say in doc that we're reducing the problem= from the security problem to the positioning problem.

 

Henning - it's a framing informational doc. Need to = start at a high goal - what is trustworthy. I need to have confidence in da= ta in provided, that someone is responsible for improving the data (the loc= ations of people calling from a certain mall always show that they're over there), and that mucking with data is d= ifficult. PSAPs conflate all of those. The solutions are different.

 

Martin - it's hard work. The biggest part is managin= g where the location info comes from and patching it when it changes. It's = complicated and expensive.

 

Slide 6 - Issue 8 Solutions

 

Martin - I've commented on section 3.2 on the list. = What a list provider would do, but not what we want to do in this situation= . You're talking about authorization from the LIS end of things.

 

Bernard - We have an operational concern - how does = the PSAP do this? But circumstance [?] location hiding.

 

Martin - Move it to a doc on location hiding, it doe= sn't belong here.

 

Bernard - is it worth talking about access control a= t all?

 

Martin - no, it can be cut.

 

Brian - I'm not sure I agree on this. I care about t= he solution. Sending it by reference to some server, and we know who we're = talking about. The choice of credentials becomes a problem. The PSAP can't = maintain credentials for everything. Then the PSAP has to provide credentials to you. Can't ignore this.

 

Bernard - if using TLS [?]

 

Brian - It needs text on where credentials come from= . Section 3.3 (proxy added location) needs more work. If the access network= … and doesn't trust … and it adds a proxy. The proxy adds loca= tion. Because it's more trustworthy, I don't need the other. The intermediary doesn't have the trust. Could expand the text.=

 

Bernard - Please provide text.

 

Martin - Add the text and the PSAP credentials to th= e rough-loc draft. It's confusing in this doc.

 

Slide 10 - Next steps

 

Bernard - Would like an intense review to get into -= 06

 

Marc - when you submit -05, we'll ask for reviewers.=

 

 

----------------------------------------------------= -------------------

Resource Priority Header (RPH) Registry Management P= olicy

to IETF Review (5 min)

http://datatracker.ietf.org/doc/draft-rosen-rph-reg-= policy-00.txt/

Presentation: http://www.ietf.org/proceedings/86/sli= des/slides-86-ecrit-3.pptx

Presenter: Brian Rosen

Intention: Discussion

 

Brian - This is IESG approved, but 4412 requires sta= ndards track to define a new RPH namespace. I wrote this draft to downgrade= the IANA policy to make it consensus rather than standards track.

 

Adam Roach - Please comment on sipcore list.

 

Marc, as chair - quickly.

 

Brian - sos only requires expert review. Adding a ne= w top level requires standard track, this is a proposal to change that. Add= ing [?] expert review, Hannes' doc can be informational. There are no chang= es to the registry policy.

 

Richard - please summarize [?]

 

Marc - I'll have to find it. Let Christer go on with= his presentation. 

 

 

 

 

----------------------------------------------------= -------------------

URN For Country Specific Emergency Services (20 min)=

http://datatracker.ietf.org/doc/draft-holmberg-ecrit= -country-emg-urn/

Presentation: http://www.ietf.org/proceedings/86/sli= des/slides-86-ecrit-0.ppt

Presenter: Christer Holmberg

Intention: New draft presentation

 

 

Slide 4 - alternative 1

 

Brian - we've recreated X- or P headers. =

 

Christer - We've been told to do this on the list. <= o:p>

 

 

Slide 6 - alternative 3

 

Keith - I don't think this solves the problem of &qu= ot;we may never have to move it". You have one country that wants it. = Or three countries that want it, but they don't exist. For example, road si= de assistance. You may need to cover 2 or more values. The first person in says - I have service offered by the police. T= he second one - same service, same semantics, but not offered by police. Yo= u are still going to have this problem.

 

Brian - I don't know how to engineer around it. We w= ant review, not first-come-first-served. I support this proposal. Will ther= e be a document that does just this?

 

Christer - it updates 5031.

 

BIran - want to downgrade in the same doc.

 

Henning - There is not a demonstrated need at the mo= ment.

 

Brian - I don't want this to be held up because it's= only defining service URN.

 

Henning - Don't want to argue about regional. For ex= ample, lower 48, not offered in Alaska. Only reason to do sub-services - do= n't get lower level. Still have a problem with an organizational hierarchy = that changes over time - think of the Department of Homeland Security. Advice to experts to consider - is it= inherently a police function? Not enforcement of law. Could add that advic= e. It may not be a big enough problem to create another label. There's no w= ay to go up, no generic emergency service on top of it.

 

Christer - to clarify - there may be a reason why du= e to hierarchy but the semantics are the same and should also allow to regi= ster.

 

Henning - that outcome is undesirable and should be = avoidable.

 

Brian - send text

 

Henning - we don't want to imply [?] The notion of o= ne country is somewhat meaningless.

 

Christer - and send xml version of 3631[?]

 

Andrew Allen - who can apply? You have to check that= they are a relevant authority.

 

Christer - it's good to have guidance, but we can't = say who can and can't apply.

 

Brian - good idea, send text. The experts can consid= er who's asking.

 

Keith - I sent to the list 2-3 weeks ago. In regard = who is asked to reply. the top level. If you don't apply if you can't offer= . If you need to move subtypes. For example sos.police.xyz and the police g= o away. The admin wants the URNs, not the deployers, they are not involved in IETF. That's why we need exper= t review.

 

Richard - moving subtypes from one super-type to the= other is not a big deal, just define the new one. I don't think "who'= s asking" is a problem. Check out the wikipedia article on what emerge= ncy services are. We can just go ahead and register these.

 

Brian - this document doesn't do - adding sub-sub-se= rvice. There are different hierarchies of policy. Do you want a separate do= c?

 

Christer - I think we need a separate decision.=

 

Brian - I'm raising the issue. People recognize that= this is a problem. State and local policy need different URNs.  It do= esn't have to be this doc.  I recommend that it is in this doc.

 

Keith - To do that - just write a letter to IANA.&nb= sp;

 

Brian - only add sub-services after sos. I have an a= lready registered service. sos.police -> sos.police.nnn If IANA doesn't = have a problem.

 

Keith - we want the same policy to apply to sub-sub-= types.

 

Marc, as chair - your coauthor sent request to IANA.=

 

Christer - I was informed just before the meeting. T= hat isn't really about this document.

 

Marc - we'll handle this with expert review. How man= y people interested in this work? <12 hands up>

 

Marc - Any opposition? <none>

 

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_FBD5AAFFD0978846BF6D3FAB4C892ACC23135FSEAEXMB1telecomsy_-- From RMarshall@telecomsys.com Fri Mar 22 16:02: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 3BD4421F8E63 for ; Fri, 22 Mar 2013 16:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.298 X-Spam-Level: X-Spam-Status: No, score=-103.298 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8Q8NKcL6kQP for ; Fri, 22 Mar 2013 16:02:18 -0700 (PDT) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4E921F8D8B for ; Fri, 22 Mar 2013 16:02:18 -0700 (PDT) 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 r2MN296V031080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 22 Mar 2013 16:02:09 -0700 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.178]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Fri, 22 Mar 2013 16:02:09 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: draft-holmberg-ecrit-country-emg-urn - ready to be WG draft? Thread-Index: Ac4nUUc9Pn9t8t+zTf6VhqEr+na1Bw== Date: Fri, 22 Mar 2013 23:02:08 +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_FBD5AAFFD0978846BF6D3FAB4C892ACC23137BSEAEXMB1telecomsy_" MIME-Version: 1.0 Subject: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG 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: Fri, 22 Mar 2013 23:02:19 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC23137BSEAEXMB1telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Given the discussion at IETF86 around service URNs, as described in Christe= r's draft, draft-holmberg-ecrit-country-emg-urn, and based on the goodly level of interest as shown in the room and as captured in the minutes, [taken from posted ecrit minutes], "the wg chairs asked for a show of interest in this = work? <12 hands up>, with ". Please weigh in on the question posed now to the list. Should draft-holmberg-ecrit-country-emg-urn be accepted as a ECRIT work gro= up item? Roger & Marc 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_FBD5AAFFD0978846BF6D3FAB4C892ACC23137BSEAEXMB1telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Given the discussion at IETF86 around service URNs, = as described in Christer’s

draft, draft-holmberg-ecrit-country-emg-urn, and bas= ed on the goodly level

of interest as shown in the room and as captured in = the minutes, [taken from

posted ecrit minutes], “the wg chairs asked fo= r a show of interest in this work?

<12 hands up>, with <no opposition>̶= 1;.

 

Please weigh in on the question posed now to the lis= t.

 

Should draft-holmberg-ecrit-country-emg-urn be accep= ted as a ECRIT work group item?

 

 

Roger & Marc

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_FBD5AAFFD0978846BF6D3FAB4C892ACC23137BSEAEXMB1telecomsy_-- From christer.holmberg@ericsson.com Sat Mar 23 02:18: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 0312F21F88EA for ; Sat, 23 Mar 2013 02:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EO-t5F9YTos for ; Sat, 23 Mar 2013 02:18:14 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C2EB021F88B9 for ; Sat, 23 Mar 2013 02:18:13 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-58-514d7353954c Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id EA.BB.10459.3537D415; Sat, 23 Mar 2013 10:18:11 +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; Sat, 23 Mar 2013 10:18:11 +0100 From: Christer Holmberg To: Roger Marshall , "ecrit@ietf.org" Thread-Topic: draft-holmberg-ecrit-country-emg-urn - ready to be WG draft? Thread-Index: Ac4nUUc9Pn9t8t+zTf6VhqEr+na1BwAVf9VD Date: Sat, 23 Mar 2013 09:18:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B13233A@ESESSMB209.ericsson.se> References: 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.18] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+JvjW5wsW+gwaln8haNi56yWhy+upTJ gcljyZKfTB4btp5iDmCK4rJJSc3JLEst0rdL4MqYc/8sY8Evropfp5ewNjC2cXYxcnJICJhI TOidzQhhi0lcuLeerYuRi0NI4BCjxKyl91kgnMWMEns3X2HvYuTgYBOwkOj+pw1iiggESZy7 aQPSKyzgKfHn8xRWEFtEwEuit/MvI4RtJDFr5yx2EJtFQFXi/JTHLCA2r4C3xP5318HiQgJ+ En1nHjKD2JwC/hLTFswDizMC3fP91BomEJtZQFzi1pP5TBB3Ckgs2XOeGcIWlXj5+B8rhK0o 8fHVPkaIegOJ9+fmM0PY2hLLFr5mhtgrKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiZM9N zMxJLzfcxAiMhINbfuvuYDx1TuQQozQHi5I4b5jrhQAhgfTEktTs1NSC1KL4otKc1OJDjEwc nFINjLbF8nUb9JJvWDGL2X/2qdzf3PIg7GuQVCTvM/9rfQlRDM/2z3X1SVGME9p09WSP7OSD W9wCjx46frQtT+i749ZXDiHxO36zialO+HMqTjy9a8OphoyXRVX3z5ulO+p2FqRej19xkmfK Npf3+i8v7jlfdoj5al+dG8uZR7sseC8FL9eT4qk1VmIpzkg01GIuKk4EAOCRlitSAgAA Subject: Re: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG 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: Sat, 23 Mar 2013 09:18:15 -0000 I obviously support this :) Regards, Christer ________________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] on behalf of Roger Ma= rshall [RMarshall@telecomsys.com] Sent: Saturday, 23 March 2013 1:02 AM To: ecrit@ietf.org Subject: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG draf= t? Given the discussion at IETF86 around service URNs, as described in Christe= r=92s draft, draft-holmberg-ecrit-country-emg-urn, and based on the goodly level of interest as shown in the room and as captured in the minutes, [taken fro= m posted ecrit minutes], =93the wg chairs asked for a show of interest in thi= s work? <12 hands up>, with =94. Please weigh in on the question posed now to the list. Should draft-holmberg-ecrit-country-emg-urn be accepted as a ECRIT work gro= up item? Roger & Marc 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. From christer.holmberg@ericsson.com Sat Mar 23 02:19: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 8CCAB21F88EA for ; Sat, 23 Mar 2013 02:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.949 X-Spam-Level: X-Spam-Status: No, score=-6.949 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UW-sclycE87d for ; Sat, 23 Mar 2013 02:19:43 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A71B621F88B9 for ; Sat, 23 Mar 2013 02:19:42 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-bb-514d73ade6af Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0D.F1.19728.DA37D415; Sat, 23 Mar 2013 10:19:41 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0318.004; Sat, 23 Mar 2013 10:19:41 +0100 From: Christer Holmberg To: Roger Marshall , "ecrit@ietf.org" Thread-Topic: IETF86: Minutes for Ecrit, 03/13/2013 Thread-Index: Ac4nTukMYxlSoYNRRaS58RAGew+JXQAWHs/D Date: Sat, 23 Mar 2013 09:19:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B132359@ESESSMB209.ericsson.se> References: 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.18] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvje7aYt9Ag3VXjC0aFz1ltTh8dSmT A5PHkiU/mTw2bD3FHMAUxWWTkpqTWZZapG+XwJVx5sBz1oIzBxkrJh+QaWBsmMPYxcjJISFg IrH+0xI2CFtM4sK99UA2F4eQwCFGieZNbWBFQgKLGSU2nlTpYuTgYBOwkOj+pw1iiggESZy7 aQNSISxgJPHp0E82iLCxxPoniSBhEaDwmdNvmUFsFgFVic9rz4Bt4hXwlriz5DsrxHA/iSMX f7OD2JwC/hIzr00Gq2cEuub7qTVMIDazgLjErSfzmSCuFJBYsuc8M4QtKvHy8T9WCFtR4uOr fYwQ9QYS78/NZ4awtSWWLXzNDLFXUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFyJ6bmJmT Xm60iREYBwe3/FbdwXjnnMghRmkOFiVx3nDXCwFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUa GINkFVOZ/5rd0Lgqt+TKnhcdF27yznIO4Ey5/e1utM+EyIXy949d///t74Xcp5vcb0+77qJ+ Y3+49/8fNnslGpW/5lw8MqXA4qhM+xMTwa1pUZPOeD8rchfZnbDT5k2yN18bB/9WhgcZmhP2 PLxx+0DKhNm9fHafd2t2vdi8dtnkiPWfrt0ufrhXiaU4I9FQi7moOBEA/PI1rFECAAA= Subject: Re: [Ecrit] IETF86: Minutes for Ecrit, 03/13/2013 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: Sat, 23 Mar 2013 09:19:45 -0000 Hi, A minor correction to bullet 2): Hannes will fix the nits to draft-ietf-ecr= it-psap-callback. Regards, Christer ________________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] on behalf of Roger Ma= rshall [RMarshall@telecomsys.com] Sent: Saturday, 23 March 2013 12:45 AM To: ecrit@ietf.org Subject: [Ecrit] IETF86: Minutes for Ecrit, 03/13/2013 Minutes w/summary, ECRIT WG Meeting, IETF86 Orlando, 03/13/2013, 13:00-15:0= 0 If you have any additions or modifications to these minutes, please let Roger & Marc know via email. These minutes will be updated to the IETF86 meeting materials page. Thank you goes to Jean Mahoney for note-taking, and, thanks also to Robert Sparks for serving as RAI AD these past years. Chairs: Roger Marshall, rmarshall@telecomsys.com Marc Linsner, mlinsner@cisco.com Summary 1. Revisions shown to former milestone dates will be posted to the list, th= en submitted, based on comments received in the working group meeting. It was agreed that the current date for rough-location should be pushed out a year= . 2. Christer agreed to fix the nits to draft-ietf-ecrit-psap-callback-08, th= en chairs will submit to IESG for processing. 3. Richard provided status on the rough-location, stating that it's progres= s is dependent on a liaison response for direction. 4. Brian agreed to additional-data next action discussing new block or URI = on the wg email list. 5. For data-only draft, when a CAP message is by reference or value, Brian agreed to rework the draft to make it like the additional-data draft, using a Call-Info header with a URL that can be a cid. 6. Ecall draft, it was proposed that document be made separate drafts, so that service URNs just need expert review. Brian would be agreeable subjec= t to wg consensus (tested on the list). 7. The discussion around trustworthy-location was that some parts needed to be lifted out and put into other drafts, then ask for an intense review onc= e Bernard submits version -05. 8. Draft rph-reg-policy suggests changes that avoid adding a new top level requires standard track, but would make it by expert review. Adam Roach stated that the RPH Registry Management Policy draft be raised in sipcore. 9. For draft-holmberg-ecrit-country-emg-urn, the proposal to handle this with expert review was proffered, and the wg chairs asked for a show o= f interest in this work? <12 hands up>, with , which showed a decent amount of interest. Actual drafts discussed: Additional Data related to an Emergency Call draft-ietf-ecrit-additional-data Data-Only Emergency Alerts using the SIP draft-ietf-ecrit-data-only-ea Internet Protocol-based In-Vehicle Emergency Call draft-rosen-ecrit-ecall Trustworthy Location Information draft-ietf-ecrit-trustworthy-location RPH Registry Management Policy to IETF Review draft-rosen-rph-reg-policy-00.txt/ URN For Country Specific Emergency Services draft-holmberg-ecrit-country-emg-urn/ ----------------------------------------------------------------------- Agenda Bashing, Draft Status Update (10 min) Presentation: http://www.ietf.org/proceedings/86/slides/slides-86-ecrit-5.p= ptx Presenters: Marc Linsner, Roger Marshall Note taker: Jean Mahoney Jabber scribe: Hannes Tschofenig Jabber log: http://www.ietf.org/jabber/logs/ecrit/2013-03-13.html The ECRIT working group presented the outgoing RAI area director Robert Spa= rks a bottle of tequila as a token of their appreciation. On behalf of the GEOPRIV working group, which didn't meet, Richard Barnes p= resented Robert with geographically-specific chocolates and a chocolate bar= with privacy rules and which, according to its label, may cause an emergen= cy if consumed. ACTION: Robert Sparks to report on how he gets the tequila home. Note well presented. The agenda has been modified - the presentation "Extensions to the Emergenc= y Services Architecture for dealing with Unauthenticated and Unauthorized D= evices (15 min)" was canceled. Document status presented: draft-ietf-ecrit-psap-callback-08* would be good to correct nits first, the= n send to IESG Milestones presented: Have been updated but not submitted. Hannes Tschofenig - what's the status of the Imprecise Location draft? Richard Barnes - Liaison to see if pending NC direction. Hannes - the March milestones need to be updated. I also requested a WGLC o= n [?], maybe in July. ACTION: provide feedback on the mailing list before the update is submitted= . ----------------------------------------------------------------------- Additional Data related to an Emergency Call (10 min) http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ Presentation: http://www.ietf.org/proceedings/86/slides/slides-86-ecrit-1.p= ptx Presenter: Brian Rosen Intention: Discuss if ready for WGLC Sllide 3 - Open Items: Brian - We need some text on when it is appropriate to use either a new blo= ck or URI and type with registry in device block when handling device-speci= fic data. The answer has to do with the following issues: - things that are widely applicable and large structure - need separate bl= ock with more IETF review - URI - first come first served What kind of review should it get? It's allowable to send a block by value but not a device block with url, yo= u can't send that by value. What about A huge thing sent by value? - I worr= y about that. It should be covered in the considerations section. Any reactions? Randall Gellens - There can be side effects from sending large data by valu= e, but for device, you can only send by value. Hannes - You don't want to be restrictive on the process of adding new bloc= ks. You can shoot yourself in the foot. Brian - It's expert review - not RFC. Hannes - that's not that restrictive. Martin Thomson - it's not a restrictive space. Brian - Right. We think we're done. Get it out before the intermediary [?] = (interim? but Marc indicated later in the meeting that there wasn't an inte= rim). Marc - Anyone willing to review it? We'll take it to the list= . ACTION: Discuss when it is appropriate to use either a new block or URI and= type with registry in device block when handling device-specific data on t= he mailing list. ----------------------------------------------------------------------- Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the S= ession Initiation Protocol (10 min) http://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ Presentation: http://www.ietf.org/proceedings/86/slides/slides-86-ecrit-2.p= ptx Presenter: Brian Rosen Intention: Discuss latest changes Slides presented. James Polk - On slide 3, do you mean any SIP request? Including CANCEL? Brian - it's not a request, it's a transaction. CANCEL is a bad example. Ce= rtainly UPDATE. Bernard Aboba - you could include a URL. Fetch an updated version if you wa= nted to. Brian - sure. Now I need to define a mime type or a new header. Now it's a = just a [...] Martin - I was going to suggest using Call-Info. Where to get the sub and t= he authorization? Send a message saying I'm here [...]. I think it's a fin= e idea. Brian - I should put the mechanism with the original INVITE. It will be eas= y. I can define [=85] In the Call-Info, for further info, subscribe here - = URL and call info. Randall - what about the mechanism in additional-data [=85] Brian - I'm going to reuse that. Roger - Summarize what Randall said. Brian - Send a CAP message by reference or value. Like the additional-data = draft - A Call-Info header with a URL that can be a CID. I will rework the = draft to that. Randall - you just need a definition of the MIME type and [=85] Brian - make the CAP message a block of additional data. Great idea. ----------------------------------------------------------------------- Internet Protocol-based In-Vehicle Emergency Call (20 min) http://datatracker.ietf.org/doc/draft-rosen-ecrit-ecall/ Presentation: http://www.ietf.org/proceedings/86/slides/slides-86-ecrit-6.p= pt Presenter: Hannes Tschofenig Intention: Discuss whether candidate for WG adoption Slides presented. Marc, as indvidual - How does this draft contrast with the data-only draft? Hannes - It complements data-only. There are some additional structures. Th= e eCall spec talks about 2 data elements - a minimal set (covered in the ex= ample on slide 4). The other is more extensive and lines up with additional= -data and data-only. The data-only plays a role when there's no media. Brian - additional-data provides a mechanism for carrying sensor-related da= ta. We have extensions for carrying data. data-only provides CAP - alert re= lated - which says, "you need to pay attention because". I don't know how t= his adds. We have a place to put the data and a place to put the alert. Wha= t isn't covered? Hannes - This defines 2 service URNs for eCall. It provides description of = how it relates to eCall. How to use this work for their purpose. Randall - With every situation for eCall, the voice channel is the paramoun= t importance. Hannes - The draft doesn't reference the data-only draft because I had the = same impression. eCall doesn't spec how to [?]. Henning - In the United States, there are researchers that collect data tha= t include deceleration, airbags inflated, tension on seatbelt. Doesn't seem= to fit into a CAP model. Hannes - it fits into Additional Data. Henning Schulzrinne - we should talk with those folks. How to make it fit = in. They are using VOIP for emergency calls. 2nd - there's a blurring betwe= en true emergency calls - sending an ambulance for instance - and when you = want to do more prevention. Reporting that the ABS/stability systems go on = - can indicate black ice. Or fog lights go on - fog - the information could= go to highway patrol. Possibly a different service URN. It's safety relate= d. They can get warnings out. Need to send salt out. Act as data fusion cen= ter. Can be automated. This is stretching the 911 model. Can think about th= is. Hannes - We can describe that in doc as use cases. And double check with ad= ditional-data to see if we have schemas in place. But it's a different leve= l of detail. Henning Schulzrinne - try to get people to think ahead. Randall, to Henning - have those people get in touch with authors, review, = sign up on mail list. You raise the safety related issues. There's overlap = for reuse. The use cases should be in a new doc. I want this doc to be emer= gency calling. ACTION: Henning to contact the US researchers he mentioned to ask them to r= eview the document and to sign up for the ECRIT mailing list. Brian - I'm an author but I haven't been involved in the last 2 versions. F= irst point - the doc needs to be clearer on its intended purposes. It doesn= 't explain why you are defining new URNs. It's because they are routed diff= erently. Second point - why is it standards track? Because it=92s defining = service URNs. Otherwise it's an informational document. Keith Drage - eCall is an emergency call. We have different architectures f= or delivering calls. Don't want non-emergency sent to the PSAP. Randall - that's why it should be in its own document. RFC - say URNs need = expert review, not standards track. Hannes - Is there interest in the working group? Brian - I would like to speak in favor as an author. It's a reference to us= e IETF mechanisms to do what they want to do. It's valuable. Marc - Then I heard Henning say we need to add others. Henning - I don't want to hold up anything for something speculative. Ensur= e that the doc is self-contained for all pieces for telematics for emergenc= y calling. I don't know if it's been considered by eCall. Separately - we n= eed to talk about the other component - a separate schema and URI. Hannes - I reference Additional Data. It would be good [?]. There's a limit= on the data they send for eCall. Marc - what do we think? Randall - we might want a separate doc so that service URNs just need exper= t review. Brian - do IETF consensus for it. I=92d be happy to do that doc. Marc, as chair - how many people read the draft and are interested? Marc - We will take it to the list. ACTION: Discuss adopting the draft as a working group item on the mailing l= ist. Randall - [?] Brian - I request a call for a hum to downgrade the registry. Keith - we're going to talk about this later. Brian - I can wait. ----------------------------------------------------------------------- Extensions to the Emergency Services Architecture for dealing with Unauthen= ticated and Unauthorized Devices (15 min) http://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access/ Presenter: Hannes Tschofenig Intention: Discuss latest changes CANCELED. ----------------------------------------------------------------------- Trustworthy Location Information (15 min) http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/ Presenter: Bernard Aboba Intention: Discuss latest changes Slide 3 - Issue 4: Untrusted Location and Provider Intent. Martin Thomson - I worry when people look at how location info was received= to determine if it=92s trustworthy. The real info used to determine if it= =92s good is: when it was the info generated? What's the uncertainty? What= =92s the location? There are other things used to determine trust. The latt= er half of the paragraph is important. Bernard - If it came from a LIS, ok. But if it came from some weird place, = what do I say in the pdif-lo? I want to tell the PSAP enough info to make a= judgment. Brian - It's on the right track. The basic info is: how you measured it, ho= w accurate it is, what the location is. Bernard - if not authoritative and measured a year ago. Brian - the timestamp of the measurement and the timestamp of when it was s= ent [?] Henning - It's difficult to know if the accuracy was determined in a global= way. For instance, GPS has this sort of accuracy. Or for that specific mea= surement. Wifi gives you this. In certain cases, it's more or less accurate= . But you tell me about the particular measurement. Primary and secondary -= aggregators - have munged up data magically, adding trust info. The smartp= hone vendors do this, and don't say how they do it. Just knowing source - l= ike the company and if they do a good job of preventing spoofing - it gives= you a sense. Bernard - We're not capturing that. we'll expand section 4. Martin - every location provided provides uncertainty on it. There are some= cells where locations are within 10 meters. With GPS, you can determine un= certainty and can report that. You need to make it explicit that you report= the measurement's uncertainty, not the technology's. The location info is = not technology specific - there's a lot of combination of data. Bernard - good point. "wifi location" term is meaningless. Henning - it's not a technology - saying which vendor which provided it is = shorthand for what data is blended. FCC no longer makes some of these disti= nctions. Slide 4 - Issue 9: Definition of Trustworthy Russ Housley - I worry that the term "Secure" is more vague than "trustwort= hy". You are trying to say with authentication, integrity or both. But not = confidentiality. Bernard - We're not talking about privacy here. Russ - Define the security services - authentication, integrity or both. Henning - our model is different than a traditional security system. Our mo= del is more statistical, a risk assessment model. As a PSAP, I care about t= he following: out of a million locations, how many are wrong? How many are = maliciously modified? How many of these issues can I detect reasonably? If = you can detect it. Except for large scale man-in-the-middle attacks, this i= s generally determined one by one. This is risk assessment. If your adversa= ry can compromise GPS satellites - then your data can't be trustworthy. Bernard - How about the end - "securely obtained from a trusted source"? Richard - It needs to say what we are and aren't doing. Would like to guara= ntee the position of the call. Henning - There are levels of trust - origin assertion that you verified. I= f you were to ask a PSAP director to define trustworthy, he would care abou= t correctness, not that there's an adversary. A wifi access point has been = moved to a new Starbuck's branch, for instance. That's far removed from the= trustworthy computing model. They are concerned more with incompetence tha= n malice. Richard - Say in doc that we're reducing the problem from the security prob= lem to the positioning problem. Henning - it's a framing informational doc. Need to start at a high goal - = what is trustworthy. I need to have confidence in data in provided, that so= meone is responsible for improving the data (the locations of people callin= g from a certain mall always show that they're over there), and that muckin= g with data is difficult. PSAPs conflate all of those. The solutions are di= fferent. Martin - it's hard work. The biggest part is managing where the location in= fo comes from and patching it when it changes. It's complicated and expensi= ve. Slide 6 - Issue 8 Solutions Martin - I've commented on section 3.2 on the list. What a list provider wo= uld do, but not what we want to do in this situation. You're talking about = authorization from the LIS end of things. Bernard - We have an operational concern - how does the PSAP do this? But c= ircumstance [?] location hiding. Martin - Move it to a doc on location hiding, it doesn't belong here. Bernard - is it worth talking about access control at all? Martin - no, it can be cut. Brian - I'm not sure I agree on this. I care about the solution. Sending it= by reference to some server, and we know who we're talking about. The choi= ce of credentials becomes a problem. The PSAP can't maintain credentials fo= r everything. Then the PSAP has to provide credentials to you. Can't ignore= this. Bernard - if using TLS [?] Brian - It needs text on where credentials come from. Section 3.3 (proxy ad= ded location) needs more work. If the access network =85 and doesn't trust = =85 and it adds a proxy. The proxy adds location. Because it's more trustwo= rthy, I don't need the other. The intermediary doesn't have the trust. Coul= d expand the text. Bernard - Please provide text. Martin - Add the text and the PSAP credentials to the rough-loc draft. It's= confusing in this doc. Slide 10 - Next steps Bernard - Would like an intense review to get into -06 Marc - when you submit -05, we'll ask for reviewers. ----------------------------------------------------------------------- Resource Priority Header (RPH) Registry Management Policy to IETF Review (5 min) http://datatracker.ietf.org/doc/draft-rosen-rph-reg-policy-00.txt/ Presentation: http://www.ietf.org/proceedings/86/slides/slides-86-ecrit-3.p= ptx Presenter: Brian Rosen Intention: Discussion Brian - This is IESG approved, but 4412 requires standards track to define = a new RPH namespace. I wrote this draft to downgrade the IANA policy to mak= e it consensus rather than standards track. Adam Roach - Please comment on sipcore list. Marc, as chair - quickly. Brian - sos only requires expert review. Adding a new top level requires st= andard track, this is a proposal to change that. Adding [?] expert review, = Hannes' doc can be informational. There are no changes to the registry poli= cy. Richard - please summarize [?] Marc - I'll have to find it. Let Christer go on with his presentation. ----------------------------------------------------------------------- URN For Country Specific Emergency Services (20 min) http://datatracker.ietf.org/doc/draft-holmberg-ecrit-country-emg-urn/ Presentation: http://www.ietf.org/proceedings/86/slides/slides-86-ecrit-0.p= pt Presenter: Christer Holmberg Intention: New draft presentation Slide 4 - alternative 1 Brian - we've recreated X- or P headers. Christer - We've been told to do this on the list. Slide 6 - alternative 3 Keith - I don't think this solves the problem of "we may never have to move= it". You have one country that wants it. Or three countries that want it, = but they don't exist. For example, road side assistance. You may need to co= ver 2 or more values. The first person in says - I have service offered by = the police. The second one - same service, same semantics, but not offered = by police. You are still going to have this problem. Brian - I don't know how to engineer around it. We want review, not first-c= ome-first-served. I support this proposal. Will there be a document that do= es just this? Christer - it updates 5031. BIran - want to downgrade in the same doc. Henning - There is not a demonstrated need at the moment. Brian - I don't want this to be held up because it's only defining service = URN. Henning - Don't want to argue about regional. For example, lower 48, not of= fered in Alaska. Only reason to do sub-services - don't get lower level. St= ill have a problem with an organizational hierarchy that changes over time = - think of the Department of Homeland Security. Advice to experts to consid= er - is it inherently a police function? Not enforcement of law. Could add = that advice. It may not be a big enough problem to create another label. Th= ere's no way to go up, no generic emergency service on top of it. Christer - to clarify - there may be a reason why due to hierarchy but the = semantics are the same and should also allow to register. Henning - that outcome is undesirable and should be avoidable. Brian - send text Henning - we don't want to imply [?] The notion of one country is somewhat = meaningless. Christer - and send xml version of 3631[?] Andrew Allen - who can apply? You have to check that they are a relevant au= thority. Christer - it's good to have guidance, but we can't say who can and can't a= pply. Brian - good idea, send text. The experts can consider who's asking. Keith - I sent to the list 2-3 weeks ago. In regard who is asked to reply. = the top level. If you don't apply if you can't offer. If you need to move s= ubtypes. For example sos.police.xyz and the police go away. The admin wants= the URNs, not the deployers, they are not involved in IETF. That's why we = need expert review. Richard - moving subtypes from one super-type to the other is not a big dea= l, just define the new one. I don't think "who's asking" is a problem. Chec= k out the wikipedia article on what emergency services are. We can just go = ahead and register these. Brian - this document doesn't do - adding sub-sub-service. There are differ= ent hierarchies of policy. Do you want a separate doc? Christer - I think we need a separate decision. Brian - I'm raising the issue. People recognize that this is a problem. Sta= te and local policy need different URNs. It doesn't have to be this doc. = I recommend that it is in this doc. Keith - To do that - just write a letter to IANA. Brian - only add sub-services after sos. I have an already registered servi= ce. sos.police -> sos.police.nnn If IANA doesn't have a problem. Keith - we want the same policy to apply to sub-sub-types. Marc, as chair - your coauthor sent request to IANA. Christer - I was informed just before the meeting. That isn't really about = this document. Marc - we'll handle this with expert review. How many people interested in = this work? <12 hands up> Marc - Any opposition? 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. From md3135@att.com Sat Mar 23 11:35: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 1EA3421F8B37 for ; Sat, 23 Mar 2013 11:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62PuXp6Q6yAm for ; Sat, 23 Mar 2013 11:35:40 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id C1E8B21F8B1E for ; Sat, 23 Mar 2013 11:35:39 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id bf5fd415.50ece940.128970.00-597.339205.nbfkord-smmo05.seg.att.com (envelope-from ); Sat, 23 Mar 2013 18:35:39 +0000 (UTC) X-MXL-Hash: 514df5fb28547046-588f9b7d3bf7a50d59372bce8b9c6341d3826492 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 9f5fd415.0.128962.00-454.339174.nbfkord-smmo05.seg.att.com (envelope-from ); Sat, 23 Mar 2013 18:35:38 +0000 (UTC) X-MXL-Hash: 514df5fa3ba1294b-3a459462d5bfa34acc96daa4d4d2bc660bea2106 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r2NIZaPg002931; Sat, 23 Mar 2013 14:35:36 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r2NIZSW1002880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Mar 2013 14:35:30 -0400 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Sat, 23 Mar 2013 18:35:14 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0342.003; Sat, 23 Mar 2013 14:35:14 -0400 From: "DOLLY, MARTIN C" To: Christer Holmberg , Roger Marshall , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG draft? Thread-Index: Ac4nUUc9Pn9t8t+zTf6VhqEr+na1BwAVf9VDABNwkBA= Date: Sat, 23 Mar 2013 18:35:13 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B13233A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B13233A@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.16.253] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=Nr1mhbhJ c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=Uxu2Wy0ugi4A:10 a=nVNOJAGcQ4UA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=KDNF9pAz0v0A:10 a=48vgC7mUAAAA:8 a=BQ6xbDwIAAAA:8] X-AnalysisOut: [ a=nbo0uU1Bn4X5r50wB3kA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=JvXaaV0oIFoA:10 a=Dc-7JBwO5S12tP4E:21 a=BiLhRhvwKehY] X-AnalysisOut: [lftu:21] Subject: Re: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG 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: Sat, 23 Mar 2013 18:35:41 -0000 It should be accepted as a ECRIT WG item=20 Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of C= hrister Holmberg Sent: Saturday, March 23, 2013 5:18 AM To: Roger Marshall; ecrit@ietf.org Subject: Re: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG = draft? I obviously support this :) Regards, Christer ________________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] on behalf of Roger Ma= rshall [RMarshall@telecomsys.com] Sent: Saturday, 23 March 2013 1:02 AM To: ecrit@ietf.org Subject: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG draf= t? Given the discussion at IETF86 around service URNs, as described in Christe= r's draft, draft-holmberg-ecrit-country-emg-urn, and based on the goodly level of interest as shown in the room and as captured in the minutes, [taken fro= m posted ecrit minutes], "the wg chairs asked for a show of interest in this = work? <12 hands up>, with ". Please weigh in on the question posed now to the list. Should draft-holmberg-ecrit-country-emg-urn be accepted as a ECRIT work gro= up item? Roger & Marc 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. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From jgunn6@csc.com Sat Mar 23 12:03: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 D310F21F8D19; Sat, 23 Mar 2013 12:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPbdVVzO9Ui8; Sat, 23 Mar 2013 12:03:51 -0700 (PDT) Received: from mail86.messagelabs.com (mail86.messagelabs.com [216.82.242.179]) by ietfa.amsl.com (Postfix) with ESMTP id B67CB21F8D23; Sat, 23 Mar 2013 12:03:49 -0700 (PDT) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-9.tower-86.messagelabs.com!1364065428!37922899!1 X-Originating-IP: [20.137.2.87] X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18592 invoked from network); 23 Mar 2013 19:03:48 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-9.tower-86.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Mar 2013 19:03:48 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (8.13.8/8.13.8) with ESMTP id r2NJ25Of018673; Sat, 23 Mar 2013 15:02:05 -0400 In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B13233A@ESESSMB209.ericsson.se> To: "DOLLY, MARTIN C" MIME-Version: 1.0 X-KeepSent: A9547529:33C86F45-85257B37:0068AB63; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Sat, 23 Mar 2013 15:03:45 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 03/23/2013 02:58:19 PM, Serialize complete at 03/23/2013 02:58:19 PM Content-Type: multipart/alternative; boundary="=_alternative 0068B75985257B37_=" Cc: ecrit-bounces@ietf.org, "ecrit@ietf.org" Subject: Re: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG 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: Sat, 23 Mar 2013 19:03:52 -0000 This is a multipart message in MIME format. --=_alternative 0068B75985257B37_= Content-Type: text/plain; charset="US-ASCII" I agree Janet Gunn This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. From: "DOLLY, MARTIN C" To: Christer Holmberg , Roger Marshall , "ecrit@ietf.org" Date: 03/23/2013 02:35 PM Subject: Re: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG draft? Sent by: ecrit-bounces@ietf.org It should be accepted as a ECRIT WG item Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Saturday, March 23, 2013 5:18 AM To: Roger Marshall; ecrit@ietf.org Subject: Re: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG draft? I obviously support this :) Regards, Christer ________________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] on behalf of Roger Marshall [RMarshall@telecomsys.com] Sent: Saturday, 23 March 2013 1:02 AM To: ecrit@ietf.org Subject: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG draft? Given the discussion at IETF86 around service URNs, as described in Christer's draft, draft-holmberg-ecrit-country-emg-urn, and based on the goodly level of interest as shown in the room and as captured in the minutes, [taken from posted ecrit minutes], "the wg chairs asked for a show of interest in this work? <12 hands up>, with ". Please weigh in on the question posed now to the list. Should draft-holmberg-ecrit-country-emg-urn be accepted as a ECRIT work group item? Roger & Marc CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network. _______________________________________________ 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 --=_alternative 0068B75985257B37_= Content-Type: text/html; charset="US-ASCII" I agree

Janet Gunn

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.



From:        "DOLLY, MARTIN C" <md3135@att.com>
To:        Christer Holmberg <christer.holmberg@ericsson.com>, Roger Marshall <RMarshall@telecomsys.com>, "ecrit@ietf.org" <ecrit@ietf.org>
Date:        03/23/2013 02:35 PM
Subject:        Re: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be        WG        draft?
Sent by:        ecrit-bounces@ietf.org



It should be accepted as a ECRIT WG item

Cheers,

Martin

-----Original Message-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Saturday, March 23, 2013 5:18 AM
To: Roger Marshall; ecrit@ietf.org
Subject: Re: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG draft?


I obviously support this :)

Regards,

Christer
________________________________________
From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] on behalf of Roger Marshall [RMarshall@telecomsys.com]
Sent: Saturday, 23 March 2013 1:02 AM
To: ecrit@ietf.org
Subject: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG draft?

Given the discussion at IETF86 around service URNs, as described in Christer's
draft, draft-holmberg-ecrit-country-emg-urn, and based on the goodly level
of interest as shown in the room and as captured in the minutes, [taken from
posted ecrit minutes], "the wg chairs asked for a show of interest in this work?
<12 hands up>, with <no opposition>".

Please weigh in on the question posed now to the list.

Should draft-holmberg-ecrit-country-emg-urn be accepted as a ECRIT work group item?


Roger & Marc

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.

_______________________________________________
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
--=_alternative 0068B75985257B37_=-- From prvs=7794bd1c15=aallen@blackberry.com Sat Mar 23 15:16: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 35E0721F8BE4 for ; Sat, 23 Mar 2013 15:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.706 X-Spam-Level: X-Spam-Status: No, score=-4.706 tagged_above=-999 required=5 tests=[AWL=0.497, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6n6aT8jzMsZ for ; Sat, 23 Mar 2013 15:16:27 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5F45721F8BCD for ; Sat, 23 Mar 2013 15:16:26 -0700 (PDT) X-AuditID: 0a41282f-b7fa06d000002431-43-514e29a9c84c Received: from XCT101ADS.rim.net (xct101ads.rim.net [10.67.111.42]) by mhs060cnc.rim.net (SBG) with SMTP id 49.91.09265.9A92E415; Sat, 23 Mar 2013 17:16:10 -0500 (CDT) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.02.0328.009; Sat, 23 Mar 2013 17:16:09 -0500 From: Andrew Allen To: "md3135@att.com" , "christer.holmberg@ericsson.com" , "RMarshall@telecomsys.com" , "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG draft? Thread-Index: AQHOJ/U8fxlNFmm5Okyzjv1us253Upiz2B4x Date: Sat, 23 Mar 2013 22:16:08 +0000 Message-ID: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.253] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDKsWRmVeSWpSXmKPExsXC5ZyvpbtK0y/QYM4bNosLMw8zWjQuespq cejBU3aLw1eXMjmweLzsn8Po8evrVTaPJUt+Mnls2HqKOYAlqoHRJimxpCw4Mz1P384mMS8v vySxJFUhJbU42VbJJzU9MUchoCizLDG5UsElszg5JzEzN7VISSEzxVbJREmhICcxOTU3Na/E VimxoCA1L0XJjksBA9gAlWXmKaTmJeenZOal2yp5BvvrWliYWuoaKtnpJnTyZFy7+5W54J5Q Re+z08wNjHf4uxg5OSQETCSubXjLAmGLSVy4t56ti5GDQ0hgJaPEVKAwF5C5mVHi/PTzrCA1 bAJaEvsPT2cCSYgIHGOUeNPxgQ0kISwQLNHS2g9miwiESOy6OJ0ZwjaS6Gm5wAIylEVAVeLo 43iQMK+Ah0TrjEdg5ZwCURKzb74EK2cUkJXYffY6E4jNLCAucevJfCaI2wQkluw5zwxhi0q8 fPyPFcJWlPi79zsrRL2exI2pU9ggbG2JZQtfM0PsEpQ4OfMJywRGkVlIxs5C0jILScssJC0L GFlWMQrmZhQbmBkk5yXrFWXm6uWllmxiBCUHRw39HYxv31scYhTgYFTi4c1V9QsUYk0sK67M PcQowcGsJMIrxwUU4k1JrKxKLcqPLyrNSS0+xOgKDIiJzFLcyfnAxJVXEm9sYICboyTO+2ux T6CQQDowxWSnphakFsHMYeLgBNnDJSVSDEwUqUWJpSUZ8aB0Fl8MTGhSDYxHz4ftvuqvPKuX g/fO5r7+FcxTtu/RuLdYPinw+SbH/4pT2Mtil19SfeIUtGGrVsxqRYO++L7INfv9Nngfb/B6 du8+l87H3m/VepOKKurqLZYKxz383ywz0/av5VoJK+f/oRtK7l9h3/wqrfIpb2yoWgbX6gl6 puuMosN5Zj1akcwmE6qTsUCJpTgj0VCLuag4EQDgf3WbTwMAAA== Subject: Re: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG 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: Sat, 23 Mar 2013 22:16:28 -0000 +1 I agree ----- Original Message ----- From: DOLLY, MARTIN C [mailto:md3135@att.com] Sent: Saturday, March 23, 2013 01:35 PM Central Standard Time=0A= To: Christer Holmberg ; Roger Marshall ; ecrit@ietf.org Subject: Re: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG d= raft? It should be accepted as a ECRIT WG item Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Ch= rister Holmberg Sent: Saturday, March 23, 2013 5:18 AM To: Roger Marshall; ecrit@ietf.org Subject: Re: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG d= raft? I obviously support this :) Regards, Christer ________________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] on behalf of Roger Mar= shall [RMarshall@telecomsys.com] Sent: Saturday, 23 March 2013 1:02 AM To: ecrit@ietf.org Subject: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG draft= ? Given the discussion at IETF86 around service URNs, as described in Christer= 's draft, draft-holmberg-ecrit-country-emg-urn, and based on the goodly level of interest as shown in the room and as captured in the minutes, [taken from posted ecrit minutes], "the wg chairs asked for a show of interest in this w= ork? <12 hands up>, with ". Please weigh in on the question posed now to the list. Should draft-holmberg-ecrit-country-emg-urn be accepted as a ECRIT work grou= p item? Roger & Marc CONFIDENTIALITY NOTICE: The information contained in this message may be pri= vileged and/or confidential. If you are not the intended recipient, or respo= nsible for delivering this message to the intended recipient, any review, fo= rwarding, dissemination, distribution or copying of this communication or an= y attachment(s) is strictly prohibited. If you have received this message in= error, please notify the sender immediately, and delete it and all attachme= nts from your computer and network. _______________________________________________ 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 --------------------------------------------------------------------- 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. From prvs=7795f7a316=jbakker@blackberry.com Sat Mar 23 18:40: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 5FEB021F8CA5 for ; Sat, 23 Mar 2013 18:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTmqgyHGZuba for ; Sat, 23 Mar 2013 18:40:04 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED5D21F8CA7 for ; Sat, 23 Mar 2013 18:40:04 -0700 (PDT) X-AuditID: 0a41282f-b7fa06d000002431-b3-514e596cafbe Received: from XCT102ADS.rim.net (xct102ads.rim.net [10.67.111.43]) by mhs060cnc.rim.net (SBG) with SMTP id E1.62.09265.D695E415; Sat, 23 Mar 2013 20:39:57 -0500 (CDT) Received: from XMB103ADS.rim.net ([fe80::e54b:97d9:3777:f8dc]) by XCT102ADS.rim.net ([fe80::4806:2e1d:2b7c:cfdf%22]) with mapi id 14.02.0328.009; Sat, 23 Mar 2013 20:39:56 -0500 From: John-Luc Bakker To: "ecrit@ietf.org" Thread-Topic: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG draft? Thread-Index: AQHOJ6dgGlrURtKRikuOc+cIlZvEhpi0EFHg Date: Sun, 24 Mar 2013 01:39:55 +0000 Message-ID: <155970D1DA8E174F9E46039E10E2AA35D33564@XMB103ADS.rim.net> References: <7594FB04B1934943A5C02806D1A2204B13233A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B13233A@ESESSMB209.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.253] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDKsWRmVeSWpSXmKPExsXC5ZyvrZsb6RdocHQTl0XjoqesDoweS5b8 ZApgjGpgtElKLCkLzkzP07ezSczLyy9JLElVSEktTrZV8klNT8xRCCjKLEtMrlRwySxOzknM zE0tUlLITLFVMlFSKMhJTE7NTc0rsVVKLChIzUtRsuNSwAA2QGWZeQqpecn5KZl56bZKnsH+ uhYWppa6hkp2ugmdPBkTFl1kL3gtUPH47XzmBsbfvF2MnBwSAiYSZ9f/Y4GwxSQu3FvP1sXI xSEksJJRYsquPUwgCSGBrYwSj+4pg9hsAnoSKyavYgSxRQRUJTacWQlmCwsES/zuOs8CEQ+R 6Fj7BarGSOLzindgNgtQfdOig2A2r4CbxOal+xghlk1glPi/tR+smVPAR+Ly6ptgNqOArMTu s9fBjmAWEJe49WQ+E8SlAhJL9pxnhrBFJV4+/scKYStK/N37nRWiXkdiwe5PbBC2tsSyha+Z IRYLSpyc+YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsYBXMzig3MDJLzkvWKMnP18lJLNjGCot9R Q38H49v3FocYBTgYlXh4n4T5BQqxJpYVV+YeYpTgYFYS4ZXjAgrxpiRWVqUW5ccXleakFh9i dAUGy0RmKe7kfGBiyiuJNzYwwM1REuf9tdgnUEggHZh+slNTC1KLYOYwcXCC7OGSEikGJpHU osTSkox4UKqLLwYmO6kGRlUDfrW55ssO75jtu0N2nZ1ezAytM7/uaM58LPb0xPeo+6v8fPYI /0qIb/n6e9Kz4I9/Tn0Mu2K/PsnI4sheDRFPExX3J6aqDxwrzxe81/HuWM8pwWBoVzH/mchk 5UzxY1vaFoTd0mmyKDn6POjc1zdXpX5sdeGqOX5J7v3i7xn+ibELzwvsEVRiKc5INNRiLipO BAARtheBPwMAAA== Subject: Re: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG 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: Sun, 24 Mar 2013 01:40:05 -0000 I support the work with the following note. I agree with relaxing the rules, however in addition it would still be usefu= l to create a new subtree within which regulators can define emergency servi= ce URNs. Emergency service URNs, for which no consensus exists (yet), can be= located within this subtree. Regards, JL -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Ch= rister Holmberg Sent: Saturday, March 23, 2013 4:18 AM To: Roger Marshall; ecrit@ietf.org Subject: Re: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG d= raft? I obviously support this :) Regards, Christer ________________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] on behalf of Roger Mar= shall [RMarshall@telecomsys.com] Sent: Saturday, 23 March 2013 1:02 AM To: ecrit@ietf.org Subject: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG draft= ? Given the discussion at IETF86 around service URNs, as described in Christer= 's draft, draft-holmberg-ecrit-country-emg-urn, and based on the goodly leve= l of interest as shown in the room and as captured in the minutes, [taken fr= om posted ecrit minutes], "the wg chairs asked for a show of interest in thi= s work? <12 hands up>, with ". Please weigh in on the question posed now to the list. Should draft-holmberg-ecrit-country-emg-urn be accepted as a ECRIT work grou= p item? Roger & Marc CONFIDENTIALITY NOTICE: The information contained in this message may be pri= vileged and/or confidential. If you are not the intended recipient, or respo= nsible for delivering this message to the intended recipient, any review, fo= rwarding, dissemination, distribution or copying of this communication or an= y attachment(s) is strictly prohibited. If you have received this message in= error, please notify the sender immediately, and delete it and all attachme= nts from your computer and network. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --------------------------------------------------------------------- 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. From laura.liess.dt@googlemail.com Sun Mar 24 01:36: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 6559521F8AD8 for ; Sun, 24 Mar 2013 01:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9eHxaJyjfwN for ; Sun, 24 Mar 2013 01:36:05 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 10D6621F89FB for ; Sun, 24 Mar 2013 01:36:04 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id fo12so9690713lab.0 for ; Sun, 24 Mar 2013 01:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=uNtNrSP32Cq4scDKXs5mZamIvYtJ7vhaTiQ+QtZN0EQ=; b=ApiPGbz0z5eSBY1tpfmWYzEKKqC29quWRhoUvxThpFzfDt1JfEChjgqmVbbzVa1+8e dMaA/9bAGY9ORrbU+pOiY4mWJO9rv50lPQceu+8QWREpEjZ8wLYD6XeOP6UlnLz8MGPN X4Z/uktkKTIE6OJIaMSKyERY8+BNxWKk73ryfoXSEj+cXGIy4g9uB9CDugtN2hMxl4WF DJ1Bop73rgYnEFvU2AG3gYSq4spi+/FWKmaW8WKARWJ9u1baLTQZ/ML/D7JkC7983Av/ GurgZ1QgVWPr2FIQh8ipgWveV3sVYGKdL93jN/RwddqeT1dzQuKJ0TQ3el8P24Ezqb/D AgVw== MIME-Version: 1.0 X-Received: by 10.112.23.136 with SMTP id m8mr3976367lbf.53.1364114163875; Sun, 24 Mar 2013 01:36:03 -0700 (PDT) Received: by 10.114.95.99 with HTTP; Sun, 24 Mar 2013 01:36:03 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B13233A@ESESSMB209.ericsson.se> Date: Sun, 24 Mar 2013 09:36:03 +0100 Message-ID: From: Laura Liess To: Christer Holmberg , Roger Marshall , "ecrit@ietf.org" Content-Type: multipart/alternative; boundary=e0cb4efe304a2bcab104d8a79464 Subject: Re: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG 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: Sun, 24 Mar 2013 08:36:06 -0000 --e0cb4efe304a2bcab104d8a79464 Content-Type: text/plain; charset=ISO-8859-1 Yes, I support the draft to be accepted as a WG item. Laura > ________________________________________ > From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] on behalf of Roger > Marshall [RMarshall@telecomsys.com] > Sent: Saturday, 23 March 2013 1:02 AM > To: ecrit@ietf.org > Subject: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG > draft? > > Given the discussion at IETF86 around service URNs, as described in > Christer's > draft, draft-holmberg-ecrit-country-emg-urn, and based on the goodly level > of interest as shown in the room and as captured in the minutes, [taken > from > posted ecrit minutes], "the wg chairs asked for a show of interest in this > work? > <12 hands up>, with ". > > Please weigh in on the question posed now to the list. > > Should draft-holmberg-ecrit-country-emg-urn be accepted as a ECRIT work > group item? > > > Roger & Marc > > CONFIDENTIALITY NOTICE: The information contained in this message may be > privileged and/or confidential. If you are not the intended recipient, or > responsible for delivering this message to the intended recipient, any > review, forwarding, dissemination, distribution or copying of this > communication or any attachment(s) is strictly prohibited. If you have > received this message in error, please notify the sender immediately, and > delete it and all attachments from your computer and network. > > _______________________________________________ > 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 > --e0cb4efe304a2bcab104d8a79464 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, I support the draft to be accepted as a WG item.

Laura
________________________________________
From: ecrit-bounces@ietf.org = [ecrit-bounces@ietf.org] on b= ehalf of Roger Marshall [RMarsh= all@telecomsys.com]
Sent: Saturday, 23 March 2013 1:02 AM
To: ecrit@ietf.org
Subject: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG draf= t?

Given the discussion at IETF86 around service URNs, as described in Christe= r's
draft, draft-holmberg-ecrit-country-emg-urn, and based on the goodly level<= br> of interest as shown in the room and as captured in the minutes, [taken fro= m
posted ecrit minutes], "the wg chairs asked for a show of interest in = this work?
<12 hands up>, with <no opposition>".

Please weigh in on the question posed now to the list.

Should draft-holmberg-ecrit-country-emg-urn be accepted as a ECRIT work gro= up item?


Roger & Marc

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.

_______________________________________________
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

--e0cb4efe304a2bcab104d8a79464-- From James.Winterbottom@commscope.com Sun Mar 24 14:06:00 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 9156221F8DD9 for ; Sun, 24 Mar 2013 14:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDUJQYQCd7t8 for ; Sun, 24 Mar 2013 14:05:59 -0700 (PDT) Received: from cdcsmgw02.commscope.com (cdcsmgw02.commscope.com [198.135.207.233]) by ietfa.amsl.com (Postfix) with ESMTP id 32DC821F8CA4 for ; Sun, 24 Mar 2013 14:05:58 -0700 (PDT) X-AuditID: 0a0404e9-b7f996d000000830-01-514f6ab6d275 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Messaging Gateway) with SMTP id 53.89.02096.6BA6F415; Sun, 24 Mar 2013 16:05:58 -0500 (CDT) 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; Sun, 24 Mar 2013 16:05:57 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 25 Mar 2013 05:05:55 +0800 From: "Winterbottom, James" To: Roger Marshall , "ecrit@ietf.org" Date: Mon, 25 Mar 2013 05:05:51 +0800 Thread-Topic: draft-holmberg-ecrit-country-emg-urn - ready to be WG draft? Thread-Index: Ac4nUUc9Pn9t8t+zTf6VhqEr+na1BwBgg9rw Message-ID: <5A55A45AE77F5941B18E5457ECAC818801214088357E@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_5A55A45AE77F5941B18E5457ECAC818801214088357ESISPE7MB1co_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDKsWRmVeSWpSXmKPExsXCFSaSrrstyz/QoKVD3KJx0VNWi8NXlzI5 MHksWfKTyWPD1lPMAUxRXDYpqTmZZalF+nYJXBnPL/SxFjw3qFjcXtnA+ESri5GTQ0LAROLr 2RYWCFtM4sK99WxdjFwcQgK7GSXedj0BSwgJbGCUePZXGSKxnlGi78BGsASbgJ3E4fU3mLsY OThEBIIkzt20AQmzCKhKvPv/kRHEFhbwlPjzeQoriC0i4CXR2/mXEcI2kvjxfClYnBeo9fPH 6VC7/CT6zjxkBrE5Bfwlpi2Yxw5iMwId9/3UGiYQm1lAXOLWk/lMEEcLSCzZc54ZwhaVePn4 HytEvajEnfb1jCCnMQvkS0z9Kw+xSlDi5EyYt3QlmnZ+ZZ3AKDYLydRZCB2zkHRAlOhILNj9 iQ3C1pZYtvA1M4x95sBjJmTxBYzsqxjFk1OSi3PTyw2M9JLzc3OLk/MLUkGsTYygKGRhebmD 8ewG7UOMAhyMSjy8D1T9AoVYE8uKK3MPMUpyMCmJ8hZm+AcK8SXlp1RmJBZnxBeV5qQWH2KU 4GBWEuFd5geU401JrKxKLcqHSWlwcAicfnL/FKMUS15+XqqSBO/cJKAywaLU9NSKtMwcYAqC KWXi4AQZxQM0yi4TZFRxQWJucWY6RP4UoypH+8/vrxiFwAZJifMGgRQJgBRllObBzXnFKA50 vDDvRZAsDzCJwk14BTScCWi4e68PyPCSRISUVANjCsf8Lwt9un/fkjrMc2PSDj3VSPX1a0J/ hivwb4uZ3DTPZfq0+mecErJlZyUevORKXLHMenVetINZ0/Ffp35lHTDcsvmp4K6UlHnJ2vmL f/bp/W5dEtV3Xd3LeX731NlOJudeet1QjD51nO/e1NK6fe5Xp9Yc9RGxinl1MTq3bpX9huc8 s80alFiKMxINtZiLihMBdbGoDl8DAAA= Subject: Re: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG 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: Sun, 24 Mar 2013 21:06:00 -0000 --_000_5A55A45AE77F5941B18E5457ECAC818801214088357ESISPE7MB1co_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like to see this become a WG item please. From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of R= oger Marshall Sent: Saturday, 23 March 2013 10:02 AM To: ecrit@ietf.org Subject: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG draf= t? Given the discussion at IETF86 around service URNs, as described in Christe= r's draft, draft-holmberg-ecrit-country-emg-urn, and based on the goodly level of interest as shown in the room and as captured in the minutes, [taken fro= m posted ecrit minutes], "the wg chairs asked for a show of interest in this = work? <12 hands up>, with ". Please weigh in on the question posed now to the list. Should draft-holmberg-ecrit-country-emg-urn be accepted as a ECRIT work gro= up item? Roger & Marc 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_5A55A45AE77F5941B18E5457ECAC818801214088357ESISPE7MB1co_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would like to see this become a WG item please.<= /span>

 

 = ;

From: ecrit-bounces@ietf= .org [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall
= Sent: Saturday, 23 March 2013 10:02 AM
To: ecrit@ietf.org<= br>Subject: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to = be WG draft?

&nb= sp;

Given the discussion at IETF86 around ser= vice URNs, as described in Christer’s

draft, draft-holmberg-ecrit-country-emg-urn, and based on the goodly l= evel

of interest as shown in the room a= nd as captured in the minutes, [taken from

posted ecrit minutes], “the wg chairs asked for a show of interest= in this work?

<12 hands up>, with= <no opposition>”.

&nbs= p;

Please weigh in on the question posed now = to the list.

 

Should draft-holmberg-ecrit-country-emg-urn be accepted as a= ECRIT work group item?

 

 

Roger &= amp; Marc

CONFIDENTIALITY NOTICE: The information contained in this = message may be privileged and/or confidential. If you are not the intended = recipient, or responsible for delivering this message to the intended recip= ient, any review, forwarding, dissemination, distribution or copying of thi= s communication or any attachment(s) is strictly prohibited. If you have re= ceived this message in error, please notify the sender immediately, and del= ete it and all attachments from your computer and network.

= --_000_5A55A45AE77F5941B18E5457ECAC818801214088357ESISPE7MB1co_-- From gunnar.hellstrom@omnitor.se Sun Mar 24 23:08: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 77BB121F883A for ; Sun, 24 Mar 2013 23:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JfP-hVDQhSQ for ; Sun, 24 Mar 2013 23:08:04 -0700 (PDT) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id D557E21F8814 for ; Sun, 24 Mar 2013 23:08:03 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP for ; Mon, 25 Mar 2013 07:07:53 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-02-01.atm.binero.net (Postfix) with ESMTPA id 05A233A11A for ; Mon, 25 Mar 2013 07:07:53 +0100 (CET) Message-ID: <514FE9BB.5030603@omnitor.se> Date: Mon, 25 Mar 2013 07:07:55 +0100 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: ecrit@ietf.org References: <7594FB04B1934943A5C02806D1A2204B13233A@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080608020200090908060003" Subject: Re: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG 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: Mon, 25 Mar 2013 06:08:08 -0000 This is a multi-part message in MIME format. --------------080608020200090908060003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I support. /Gunnar ------------------------------------------------------------------------ On 2013-03-23 19:35, DOLLY, MARTIN C wrote: > It should be accepted as a ECRIT WG item > > Cheers, > > Martin > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Saturday, March 23, 2013 5:18 AM > To: Roger Marshall; ecrit@ietf.org > Subject: Re: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG draft? > > > I obviously support this :) > > Regards, > > Christer > ________________________________________ > From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] on behalf of Roger Marshall [RMarshall@telecomsys.com] > Sent: Saturday, 23 March 2013 1:02 AM > To: ecrit@ietf.org > Subject: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG draft? > > Given the discussion at IETF86 around service URNs, as described in Christer's > draft, draft-holmberg-ecrit-country-emg-urn, and based on the goodly level > of interest as shown in the room and as captured in the minutes, [taken from > posted ecrit minutes], "the wg chairs asked for a show of interest in this work? > <12 hands up>, with ". > > Please weigh in on the question posed now to the list. > > Should draft-holmberg-ecrit-country-emg-urn be accepted as a ECRIT work group item? > > > Roger & Marc > > CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network. > > _______________________________________________ > 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 --------------080608020200090908060003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I support.

/Gunnar
On 2013-03-23 19:35, DOLLY, MARTIN C wrote:
It should be accepted as a ECRIT WG item 

Cheers,

Martin

-----Original Message-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Saturday, March 23, 2013 5:18 AM
To: Roger Marshall; ecrit@ietf.org
Subject: Re: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG draft?


I obviously support this :)

Regards,

Christer
________________________________________
From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] on behalf of Roger Marshall [RMarshall@telecomsys.com]
Sent: Saturday, 23 March 2013 1:02 AM
To: ecrit@ietf.org
Subject: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG draft?

Given the discussion at IETF86 around service URNs, as described in Christer's
draft, draft-holmberg-ecrit-country-emg-urn, and based on the goodly level
of interest as shown in the room and as captured in the minutes, [taken from
posted ecrit minutes], "the wg chairs asked for a show of interest in this work?
<12 hands up>, with <no opposition>".

Please weigh in on the question posed now to the list.

Should draft-holmberg-ecrit-country-emg-urn be accepted as a ECRIT work group item?


Roger & Marc

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.

_______________________________________________
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

--------------080608020200090908060003-- From gunnar.hellstrom@omnitor.se Sun Mar 24 23:16: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 50F5321F8E67 for ; Sun, 24 Mar 2013 23:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[AWL=-0.300, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1PyCQsv3CZm for ; Sun, 24 Mar 2013 23:16:16 -0700 (PDT) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id F2A2221F8E27 for ; Sun, 24 Mar 2013 23:16:14 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP for ; Mon, 25 Mar 2013 07:16:03 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-05-01.atm.binero.net (Postfix) with ESMTPA id 986A43A162 for ; Mon, 25 Mar 2013 07:16:02 +0100 (CET) Message-ID: <514FEBA4.2030306@omnitor.se> Date: Mon, 25 Mar 2013 07:16:04 +0100 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: ecrit@ietf.org References: <7594FB04B1934943A5C02806D1A2204B12C63C@ESESSMB209.ericsson.se> <155970D1DA8E174F9E46039E10E2AA35D24AAE@XMB103ADS.rim.net> <39B5E4D390E9BD4890E2B310790061010A7A26@ESESSMB301.ericsson.se> <155970D1DA8E174F9E46039E10E2AA35D253A6@XMB103ADS.rim.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090806020708050005060204" Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-02 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 Mar 2013 06:16:19 -0000 This is a multi-part message in MIME format. --------------090806020708050005060204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit A minor correction proposal to the draft: In last line of section 5.1: "6.3" should be "5.3". Gunnar On 2013-03-20 05:29, Richard Barnes wrote: > +1 > > Part of the point of these identifiers is that they don't have > detailed specifications. That way "urn:sos:ambulance" can cover both > the Kentucky and Brussels ambulance services even if the Kentucky > service is a volunteer service that only works Tuesdays and the > Brussels service offers you a complimentary waffle en route to the > hospital. In less frivolous words, minor service differences > shouldn't require separate identifiers. > > > > On Tue, Mar 19, 2013 at 4:41 PM, Rosen, Brian > wrote: > > I think we have a problem here. We don't require "specification" > and we don't have adequate descriptions in the registry. > > I am loath to require specification for this registry. So, I > suggest we expand "description" to a larger piece of text, and > supply advice to the expert to evaluate the adequacy of the > explanation. We could copy text out of the RFC to start this process. > > Brian > > On Mar 19, 2013, at 4:33 PM, John-Luc Bakker > > wrote: > >> Hi Ivo, >> Thanks for the quick response. >> The IANA web page has for "urn:service:sos.mountain" the >> following_description_"Mountain rescue" and a link to the RFC. >> The RFC then has the following_description of the caller >> expectation in terms of services rendered_: >> The 'mountain' service refers to mountain >> rescue services (i.e., search and rescue activities that >> occur in >> a mountainous environment), although the term is sometimes also >> used to apply to search and rescue in other wilderness >> environments. >> In my opinion, according to the RFC, "urn:service:sos.mountain" >> could also be applied to emergencies in caves/sink holes (i.e. no >> need for a mountainous terrain), although such use would not be >> immediately apparent from the description on the IANA web page >> that has the registry forService URN Labels. >> Perhaps the issue is that the IANA web page that has the registry >> forService URN Labelsmisses some information that is found in the >> RFC. >> Regards, >> JL >> *From:*Ivo Sedlacek [mailto:ivo.sedlacek@ >> ericsson.com ] >> *Sent:*Tuesday, March 19, 2013 11:02 AM >> *To:*John-Luc Bakker; Christer Holmberg;ecrit@ietf.org >> >> *Subject:*RE: [Ecrit] Draft new version: >> draft-holmberg-ecrit-country-emg-urn-02 >> Hello, >> >Will the caller expectation in terms of services rendered be >> documented somewhere? >> The new policy proposed in >> draft-holmberg-ecrit-country-emg-urn-02 section 5.3 states: >> 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. >> I.e. in the expert review, the service description and the URN >> are reviewed. If approved, the service description and URN are >> listed in IANA - >> seehttp://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-labels.xml#urn-serviceid-labels-2 >> 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 >> >> *From:*ecrit-bounces@ietf.org >> [mailto:ecrit-bounces@ietf.org]*On >> Behalf Of*John-Luc Bakker >> *Sent:*19. br(ezna 2013 16:12 >> *To:*Christer Holmberg;ecrit@ietf.org >> *Subject:*Re: [Ecrit] Draft new version: >> draft-holmberg-ecrit-country-emg-urn-02 >> Hi Christer, >> Thanks for this. >> When a new URN is adopted via expert review, a description of the >> caller expectation in terms of services rendered (for the new >> URN) cannot be found in RFC 5031. >> For example, for the existing URNurn:service:sos.mountain, the >> RFC includes: >> The 'mountain' service refers to mountain >> rescue services (i.e., search and rescue activities that >> occur in >> a mountainous environment), although the term is sometimes also >> used to apply to search and rescue in other wilderness >> environments. >> Will the caller expectation in terms of services rendered be >> documented somewhere? >> Apologies if this query was already addressed during the ECRIT >> session ... >> Kind regards, >> JL >> *From:*ecrit-bounces@ietf.org >> [mailto:ecrit-bounces@ietf.org]*On >> Behalf Of*Christer Holmberg >> *Sent:*Tuesday, March 19, 2013 6:52 AM >> *To:*ecrit@ietf.org >> *Subject:*[Ecrit] Draft new version: >> draft-holmberg-ecrit-country-emg-urn-02 >> Hi, >> Based on the Orlando decision to move forward with the >> relax-the-5031-registration-policy alternative for allowing emg >> URNs for services offered in one country only, I've submitted an >> "official" new version (-02) of >> draft-holmberg-ecrit-country-emg-urn. Aside from some minor >> changes caused by the new version of xml2rfc, the draft is >> identical to the pre-02 version I distributed before the meeting. >> As was indicated in the meeting, additional text will still be >> needed, but once the Orlando decision is verified on the list I >> hope we can adopt the draft as base for the work. >> Thanks to everyone who provided comments during the meeting! >> Regards, >> Christer >> --------------------------------------------------------------------- >> 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 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 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 your system. Use, dissemination, distribution, >> or reproduction of this transmission by unintended recipients is >> not authorized and may be unlawful. >> _______________________________________________ >> >> 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 --------------090806020708050005060204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
A minor correction proposal to the draft:
In last line of section 5.1:  "6.3" should be "5.3".

Gunnar


On 2013-03-20 05:29, Richard Barnes wrote:
+1

Part of the point of these identifiers is that they don't have detailed specifications.  That way "urn:sos:ambulance" can cover both the Kentucky and Brussels ambulance services even if the Kentucky service is a volunteer service that only works Tuesdays and the Brussels service offers you a complimentary waffle en route to the hospital.  In less frivolous words, minor service differences shouldn't require separate identifiers.



On Tue, Mar 19, 2013 at 4:41 PM, Rosen, Brian <Brian.Rosen@neustar.biz> wrote:
I think we have a problem here.  We don't require "specification" and we don't have adequate descriptions in the registry.

I am loath to require specification for this registry.  So, I suggest we expand "description" to a larger piece of text, and supply advice to the expert to evaluate the adequacy of the explanation.  We could copy text out of the RFC to start this process.

Brian

On Mar 19, 2013, at 4:33 PM, John-Luc Bakker <jbakker@blackberry.com> wrote:

Hi Ivo,
 
Thanks for the quick response.
The IANA web page has for “urn:service:sos.mountain” the following description “Mountain rescue” and a link to the RFC. The RFC then has the following description of the caller expectation in terms of services rendered:
 
      The 'mountain' service refers to mountain
      rescue services (i.e., search and rescue activities that occur in
      a mountainous environment), although the term is sometimes also
      used to apply to search and rescue in other wilderness
      environments.
 
In my opinion, according to the RFC, “urn:service:sos.mountain” could also be applied to emergencies in caves/sink holes (i.e. no need for a mountainous terrain), although such use would not be immediately apparent from the description on the IANA web page that has the registry for Service URN Labels.
 
Perhaps the issue is that the IANA web page that has the registry for Service URN Labels misses some information that is found in the RFC.
 
Regards,
 
               JL
 
From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] 
Sent: Tuesday, March 19, 2013 11:02 AM
To: John-Luc Bakker; Christer Holmberg; ecrit@ietf.org
Subject: RE: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-02
 
Hello,
 
> Will the caller expectation in terms of services rendered be documented somewhere?
 
The new policy proposed in draft-holmberg-ecrit-country-emg-urn-02 section 5.3 states:
 
   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.
 
I.e. in the expert review, the service description and the URN are reviewed. If approved, the service description and URN are listed in IANA - see http://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-labels.xml#urn-serviceid-labels-2
 
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 John-Luc Bakker
Sent: 19. března 2013 16:12
To: Christer Holmberg; ecrit@ietf.org
Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-02
 
Hi Christer,
 
Thanks for this.
When a new URN is adopted via expert review, a description of the caller expectation in terms of services rendered (for the new URN) cannot be found in RFC 5031.
 
For example, for the existing URN urn:service:sos.mountain, the RFC includes:
 
      The 'mountain' service refers to mountain
      rescue services (i.e., search and rescue activities that occur in
      a mountainous environment), although the term is sometimes also
      used to apply to search and rescue in other wilderness
      environments.
 
Will the caller expectation in terms of services rendered be documented somewhere?
Apologies if this query was already addressed during the ECRIT session …
 
Kind regards,
 
               JL
 
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Tuesday, March 19, 2013 6:52 AM
To: ecrit@ietf.org
Subject: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-02
 
Hi,
 
Based on the Orlando decision to move forward with the relax-the-5031-registration-policy alternative for allowing emg URNs for services offered in one country only, I’ve submitted an “official” new version (-02) of draft-holmberg-ecrit-country-emg-urn. Aside from some minor changes caused by the new version of xml2rfc, the draft is identical to the pre-02 version I distributed before the meeting.
 
As was indicated in the meeting, additional text will still be needed, but once the Orlando decision is verified on the list I hope we can adopt the draft as base for the work.
 
Thanks to everyone who provided comments during the meeting!
 
Regards,
 
Christer
--------------------------------------------------------------------- 
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 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 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 your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. _______________________________________________

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

--------------090806020708050005060204-- From christer.holmberg@ericsson.com Mon Mar 25 01:59: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 7503E1F0C74 for ; Mon, 25 Mar 2013 01:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.389 X-Spam-Level: X-Spam-Status: No, score=-4.389 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W75pkYoi2-Xb for ; Mon, 25 Mar 2013 01:58:56 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id AB39221F8EA8 for ; Mon, 25 Mar 2013 01:58:55 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-42-515011ce6916 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D0.9A.10459.EC110515; Mon, 25 Mar 2013 09:58:54 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0318.004; Mon, 25 Mar 2013 09:58:53 +0100 From: Christer Holmberg To: Gunnar Hellstrom , "ecrit@ietf.org" Thread-Topic: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-02 Thread-Index: AQHOJLsZXaipe/QTS0avXZI/qULsmJitZ7WAgAACTwCAAILFgIAH+XIAgAA+F/A= Date: Mon, 25 Mar 2013 08:58:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B13314D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B12C63C@ESESSMB209.ericsson.se> <155970D1DA8E174F9E46039E10E2AA35D24AAE@XMB103ADS.rim.net> <39B5E4D390E9BD4890E2B310790061010A7A26@ESESSMB301.ericsson.se> <155970D1DA8E174F9E46039E10E2AA35D253A6@XMB103ADS.rim.net> <514FEBA4.2030306@omnitor.se> In-Reply-To: <514FEBA4.2030306@omnitor.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_7594FB04B1934943A5C02806D1A2204B13314DESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyM+Jvje45wYBAg8e31C0aFz1ltdjx/gyL A5PHkiU/mTwmLv7EHMAUxWWTkpqTWZZapG+XwJWx4fh19oJrP5gq5q0zaGC8dpmpi5GTQ0LA RGL+nR5WCFtM4sK99WxdjFwcQgKHGCUOP//ADOEsZpRo2vUUyOHgYBOwkOj+pw3SICIQLrHu 8XWwQcICgRLbu1awgZSICARJ3H+gBlHiJ7Fx/1aw+SwCqhL/rk9mBLF5Bbwllq1oZIQazyyx smEuO0iCU0BLonXKA7CZjEAHfT+1BsxmFhCXuPVkPtTRAhJL9pxnhrBFJV4+/gf1gKLE1enL oerzJY5eWs0MsUxQ4uTMJywTGEVmIRk1C0nZLCRlEHE9iWenZkHZ2hLLFr5mhrB1JS49XMeK LL6AkX0VI3tuYmZOernhJkZg9Bzc8lt3B+OpcyKHGKU5WJTEecNcLwQICaQnlqRmp6YWpBbF F5XmpBYfYmTi4JRqYDTwVu55fTFPLHn6QZ8n3Ezil/8/PZnwykNkx2s35nl6c/97hB3iyfqq fLD6SJfk9DuONhJ/Czu2c2urzHy0PImNt8Ihk4V1l+tMc8PJcnaLbC6W6l9sPe5szMylE/Kv wGeD8/aQbwdSj55bsd1UI/DjREn1polJt9MWrv6lbDf1WsN++9MsPEosxRmJhlrMRcWJAEjE bsFsAgAA Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-02 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 Mar 2013 08:59:01 -0000 --_000_7594FB04B1934943A5C02806D1A2204B13314DESESSMB209ericsso_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi Gunnar, I will fix the bug in the next version of the draft. Thanks! :) Regards, Christer From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of G= unnar Hellstrom Sent: 25. maaliskuuta 2013 8:16 To: ecrit@ietf.org Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-ur= n-02 A minor correction proposal to the draft: In last line of section 5.1: "6.3" should be "5.3". Gunnar On 2013-03-20 05:29, Richard Barnes wrote: +1 Part of the point of these identifiers is that they don't have detailed spe= cifications. That way "urn:sos:ambulance" can cover both the Kentucky and = Brussels ambulance services even if the Kentucky service is a volunteer ser= vice that only works Tuesdays and the Brussels service offers you a complim= entary waffle en route to the hospital. In less frivolous words, minor ser= vice differences shouldn't require separate identifiers. On Tue, Mar 19, 2013 at 4:41 PM, Rosen, Brian > wrote: I think we have a problem here. We don't require "specification" and we do= n't have adequate descriptions in the registry. I am loath to require specification for this registry. So, I suggest we ex= pand "description" to a larger piece of text, and supply advice to the expe= rt to evaluate the adequacy of the explanation. We could copy text out of = the RFC to start this process. Brian On Mar 19, 2013, at 4:33 PM, John-Luc Bakker > wrote: Hi Ivo, Thanks for the quick response. The IANA web page has for "urn:service:sos.mountain" the following descript= ion "Mountain rescue" and a link to the RFC. The RFC then has the following= description of the caller expectation in terms of services rendered: The 'mountain' service refers to mountain rescue services (i.e., search and rescue activities that occur in a mountainous environment), although the term is sometimes also used to apply to search and rescue in other wilderness environments. In my opinion, according to the RFC, "urn:service:sos.mountain" could also = be applied to emergencies in caves/sink holes (i.e. no need for a mountaino= us terrain), although such use would not be immediately apparent from the d= escription on the IANA web page that has the registry for Service URN Label= s. Perhaps the issue is that the IANA web page that has the registry for Servi= ce URN Labels misses some information that is found in the RFC. Regards, JL From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com<= http://ericsson.com>] Sent: Tuesday, March 19, 2013 11:02 AM To: John-Luc Bakker; Christer Holmberg; ecrit@ietf.org Subject: RE: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-ur= n-02 Hello, > Will the caller expectation in terms of services rendered be documented s= omewhere? The new policy proposed in draft-holmberg-ecrit-country-emg-urn-02 section = 5.3 states: 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. I.e. in the expert review, the service description and the URN are reviewed= . If approved, the service description and URN are listed in IANA - see htt= p://www.iana.org/assignments/urn-serviceid-labels/urn-serviceid-labels.xml#= urn-serviceid-labels-2 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 John-Luc Bakker Sent: 19. b=F8ezna 2013 16:12 To: Christer Holmberg; ecrit@ietf.org Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-ur= n-02 Hi Christer, Thanks for this. When a new URN is adopted via expert review, a description of the caller ex= pectation in terms of services rendered (for the new URN) cannot be found i= n RFC 5031. For example, for the existing URN urn:service:sos.mountain, the RFC include= s: The 'mountain' service refers to mountain rescue services (i.e., search and rescue activities that occur in a mountainous environment), although the term is sometimes also used to apply to search and rescue in other wilderness environments. Will the caller expectation in terms of services rendered be documented som= ewhere? Apologies if this query was already addressed during the ECRIT session ... Kind regards, JL From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Christer Holmberg Sent: Tuesday, March 19, 2013 6:52 AM To: ecrit@ietf.org Subject: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-02 Hi, Based on the Orlando decision to move forward with the relax-the-5031-regis= tration-policy alternative for allowing emg URNs for services offered in on= e country only, I've submitted an "official" new version (-02) of draft-hol= mberg-ecrit-country-emg-urn. Aside from some minor changes caused by the ne= w version of xml2rfc, the draft is identical to the pre-02 version I distri= buted before the meeting. As was indicated in the meeting, additional text will still be needed, but = once the Orlando decision is verified on the list I hope we can adopt the d= raft as base for the work. Thanks to everyone who provided comments during the meeting! Regards, Christer --------------------------------------------------------------------- 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. --------------------------------------------------------------------- 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. _______________= ________________________________ 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_7594FB04B1934943A5C02806D1A2204B13314DESESSMB209ericsso_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hi Gunnar,

 <= /p>

I will fix the bug in the= next version of the draft. Thanks! J

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf= .org] On Behalf Of Gunnar Hellstrom
Sent: 25. maaliskuuta 2013 8:16
To: ecrit@ietf.org
Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country= -emg-urn-02

 

A minor correction proposal to the draft:
In last line of section 5.1:  "6.3" should be "5.3"= ;.

Gunnar


On 2013-03-20 05:29, Richard Barnes wrote:

+1

 

Part of the point of these identifiers is that they = don't have detailed specifications.  That way "urn:sos:ambulance&= quot; can cover both the Kentucky and Brussels ambulance services even if t= he Kentucky service is a volunteer service that only works Tuesdays and the Brussels service offers you a complimentary waffle = en route to the hospital.  In less frivolous words, minor service diff= erences shouldn't require separate identifiers.

 

 

 

On Tue, Mar 19, 2013 at 4:41 PM, Rosen, Brian <Brian.Rosen@neus= tar.biz> wrote:

I think we have a problem here.  We don't requi= re "specification" and we don't have adequate descriptions in the= registry.

 

I am loath to require specification for this registr= y.  So, I suggest we expand "description" to a larger piece = of text, and supply advice to the expert to evaluate the adequacy of the ex= planation.  We could copy text out of the RFC to start this process.

 

Brian

 

On Mar 19, 2013, at 4:33 PM, John-Luc Bakker <jbakker@blackberry= .com> wrote:

 

Hi Ivo,

 

Thanks for the quick resp= onse.

The IANA web page has for= “urn:service:sos.mountain” the following description “Mounta= in rescue” and a link to the RFC. T= he RFC then has the following description of the caller expectation in terms of services rendered:

 

      The 'mountain' = service refers to mountain

      rescue services= (i.e., search and rescue activities that occur in=

      a mountainous e= nvironment), although the term is sometimes also

      used to apply t= o search and rescue in other wilderness

      environments.

 

In my opinion, according = to the RFC, “urn:service:sos.mountain” could also be applied to emergencies in caves/sink holes (i.e. no need for= a mountainous terrain), although such use would not be immediately apparen= t from the description on the IANA web page that has the registry for = Service URN Labels.

 

Perhaps the issue is that= the IANA web page that has the registry for Service= URN Labels misses some information that is found in the RFC.<= /span>

 

Regards,

 

    &= nbsp;          JL

 

From: Ivo= Sedlacek [mailto:ivo.se= dlacek@ericsson.com] 
Sent: Tuesday, March 19, 2013 11:02 AM
To: John-Luc Bakker; Christer Holmberg; ecrit@ietf.o= rg
Subject: RE: [Ecrit] Draft new version: draft-holmberg-ecrit-co= untry-emg-urn-02

 

Hello,<= o:p>

 <= o:p>

> Will the caller expectation in terms of services rendered = be documented somewhere?

 <= o:p>

The new policy proposed in = draft-holmberg-ecrit-country-emg-urn-02 section 5.3 states:

 <= o:p>

   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 their ab= sence, the IESG.  The

   expert review should only approve ser= vices that have emergency

   nature, that are offered in at least one coun= try, 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 'so= s' service is not meant to

   invoke general government, public information= , counseling, or social

   services.

 <= o:p>

I.e. in the expert review, = the service description and the URN are reviewed. If approved, the service = description and URN are listed in IANA - see http://www.iana= .org/assignments/urn-serviceid-labels/urn-serviceid-labels.xml#urn-servicei= d-labels-2

 <= o:p>

Kind regards

 <= o:p>

Ivo Sedlacek

 <= o:p>

 <= o:p>

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: ecrit-bounces@ietf.org [mailto:ecr= it-bounces@ietf.org] On Behalf Of John-Luc Bakker
Sent: 19. b=F8ezna 2013 16:12
To: Christer Holmberg; ecrit@ietf.org
Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-co= untry-emg-urn-02

 

Hi Christer,

 

Thanks for this.

When a new URN is adopted= via expert review, a description of the caller expectation in terms of ser= vices rendered (for the new URN) cannot be found in RFC 5031.

 

For example, for the exis= ting URN urn:service:sos.mountain, the RFC includes:

 

      The 'mountain' = service refers to mountain

      rescue services= (i.e., search and rescue activities that occur in=

      a mountainous e= nvironment), although the term is sometimes also

      used to apply t= o search and rescue in other wilderness

      environments.

 

Will the caller expectati= on in terms of services rendered be documented somewhere?

Apologies if this query w= as already addressed during the ECRIT session …

 

Kind regards,

 

    &= nbsp;          JL

 

From: ecrit-bounces@ietf.org [mailto:ecr= it-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Tuesday, March 19, 2013 6:52 AM
To: ecrit@ietf.org
Subject: [Ecrit] Draft new version: draft-holmberg-ecrit-countr= y-emg-urn-02

 

Hi,

 <= o:p>

Based on the Orlando decision to move f= orward with the relax-the-5031-registration-policy alternative for allowing= emg URNs for services offered in one country only, I’ve submitted an “official” new version (-02) of draft-holmberg-ec= rit-country-emg-urn. Aside from some minor changes caused by the new versio= n of xml2rfc, the draft is identical to the pre-02 version I distributed be= fore the meeting.

 

As was indicated in the meeting, additi= onal text will still be needed, but once the Orlando decision is verified o= n the list I hope we can adopt the draft as base for the work.

 

Thanks to everyone who provided comment= s during the meeting!

 

Regards,

 

Christer

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

-------------------------------------= -------------------------------- 

This transmission (including any atta= chments) may contain confidential information, privileged material (includi= ng material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this informa= tion by anyone other than the intended recipient is prohibited. If you have= received this transmission in error, please immediately reply to the sende= r and delete this information from your system. Use, dissemination, distribution, or reproduction of this tra= nsmission by unintended recipients is not authorized and may be unlawful. _= ______________________________________________

 


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

 




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

 

--_000_7594FB04B1934943A5C02806D1A2204B13314DESESSMB209ericsso_-- From ivo.sedlacek@ericsson.com Mon Mar 25 02:33: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 9E8A121F887D for ; Mon, 25 Mar 2013 02:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RW4hoHNOPCcY for ; Mon, 25 Mar 2013 02:33:11 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4D10F21F8883 for ; Mon, 25 Mar 2013 02:33:10 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-d2-515019d540f6 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F0.22.10459.5D910515; Mon, 25 Mar 2013 10:33:09 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.208]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0318.004; Mon, 25 Mar 2013 10:33:08 +0100 From: Ivo Sedlacek To: Roger Marshall , "ecrit@ietf.org" Thread-Topic: draft-holmberg-ecrit-country-emg-urn - ready to be WG draft? Thread-Index: Ac4nUUc9Pn9t8t+zTf6VhqEr+na1BwB6k5Gg Date: Mon, 25 Mar 2013 09:33:07 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061010A9DC0@ESESSMB301.ericsson.se> References: 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.20] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B310790061010A9DC0ESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvje5VyYBAg3/LJCwaFz1ltTh8dSmT A5PHkiU/mTw2bD3FHMAUxWWTkpqTWZZapG+XwJXxb+ds5oLbVhX7rl5mbWA8ZdzFyMkhIWAi sWPTeUYIW0ziwr31bCC2kMAhRok7j9W7GLmA7CWMEjcn/2UCSbAJ6ElM3HKEtYuRg0NEIEji 3E0bkLCwgKfEn89TWEFsEQEvid7Ov4wQtpFEx/1vLCA2i4CqxIdnE5hBbF4Bb4mlS34wQ+zy k+g78xDM5hTwl5i2YB47iM0oICtx9U8v2BxmAXGJW0/mM0HcKSCxZM95ZghbVOLl43+sELai xNXpy5kg6vMlPi56wQ6xS1Di5MwnLBMYRWYhGTULSdksJGUQcT2JZ6dmQdnaEssWvmaGsHUl Lj1cx4osvoCRfRUje25iZk56ueEmRmDkHNzyW3cH46lzIocYpTlYlMR5w1wvBAgJpCeWpGan phakFsUXleakFh9iZOLglGpgTIjlZu+5wCP2uei+ys9lAqf8zqiUXLPsdA98qJvHOfd3gdVr Ib3a/hNf9NQty/b77bBJCpHdzxP7/sPBDVsdrfeLXtV+fjfp366ZTLUfpC1y9a7qCJyaLrOo os1MZF7o1nvH6rzWZLzZ1ZdU/vfhy9nMoZVTjyl5LN10Rnp/yM+X2Wz8d3OWK7EUZyQaajEX FScCAGWfaUtqAgAA Subject: Re: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG 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: Mon, 25 Mar 2013 09:33:12 -0000 --_000_39B5E4D390E9BD4890E2B310790061010A9DC0ESESSMB301ericsso_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable As an author of the draft, I obviously support the draft being accepted as = a ECRIT work group item. 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-bounces@ietf.org] On Behalf Of R= oger Marshall Sent: 23. b=F8ezna 2013 0:02 To: ecrit@ietf.org Subject: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG draf= t? Given the discussion at IETF86 around service URNs, as described in Christe= r's draft, draft-holmberg-ecrit-country-emg-urn, and based on the goodly level of interest as shown in the room and as captured in the minutes, [taken fro= m posted ecrit minutes], "the wg chairs asked for a show of interest in this = work? <12 hands up>, with ". Please weigh in on the question posed now to the list. Should draft-holmberg-ecrit-country-emg-urn be accepted as a ECRIT work gro= up item? Roger & Marc 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_39B5E4D390E9BD4890E2B310790061010A9DC0ESESSMB301ericsso_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

As an author of the draft, = I obviously support the draft being accepted as a ECRIT work group item.

 

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: ecrit-bo= unces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Roger Marshall
Sent: 23. b=F8ezna 2013 0:02
To: ecrit@ietf.org
Subject: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be = WG draft?

 

Given the discussion at IETF86 around service URNs, = as described in Christer’s

draft, draft-holmberg-ecrit-country-emg-urn, and bas= ed on the goodly level

of interest as shown in the room and as captured in = the minutes, [taken from

posted ecrit minutes], “the wg chairs asked fo= r a show of interest in this work?

<12 hands up>, with <no opposition>̶= 1;.

 

Please weigh in on the question posed now to the lis= t.

 

Should draft-holmberg-ecrit-country-emg-urn be accep= ted as a ECRIT work group item?

 

 

Roger & Marc

CONFIDENTIALITY NOTICE: The information contained in this mess= age may be privileged and/or confidential. If you are not the intended reci= pient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or= copying of this communication or any attachment(s) is strictly prohibited.= If you have received this message in error, please notify the sender immed= iately, and delete it and all attachments from your computer and network.

--_000_39B5E4D390E9BD4890E2B310790061010A9DC0ESESSMB301ericsso_-- From dan@mongrain.org Mon Mar 25 06:28: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 680E021F892D for ; Mon, 25 Mar 2013 06:28:01 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxDRlxTOfe8M for ; Mon, 25 Mar 2013 06:28:00 -0700 (PDT) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id AA08821F8901 for ; Mon, 25 Mar 2013 06:28:00 -0700 (PDT) Received: by mail-ia0-f174.google.com with SMTP id b35so5382939iac.19 for ; Mon, 25 Mar 2013 06:28:00 -0700 (PDT) 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:content-type:x-gm-message-state; bh=5z6EyoxEEX8MGvWp0rgeq69/BehZN1rU7l1FdjtkAsI=; b=RLq580azP6Vcg3C0r6x+ljZD2EckqoE99BAuRj4uIuArm4d80LAQoGXMdL/reyaX3M dhmx87GLCo/wUo/RZ0CspqpRzvC9Qk5Dd8YjPnvqXv48e6d3wDQyTytgE5MtEG37fNb0 9sb4HftZ9PTZWfs+66uPPLEfSTISzbBmwWnLtSbh2TRaFIR7sJWlzI16JtBO0LbRVBY2 mpJHiXq4LcS9O2UiSVLZ/IBIMR3r4Kf7pTqrnxHtx+FT7eNF5mpcYOAAFwud+mmB3W76 bPh54WoLrB1twxFgbybfn5AUlCNenAw9YjX6Bd6HNyeZS8D8KRY222APo0HTfuFUaPZZ O0ZQ== MIME-Version: 1.0 X-Received: by 10.50.17.166 with SMTP id p6mr11379243igd.12.1364218080260; Mon, 25 Mar 2013 06:28:00 -0700 (PDT) Received: by 10.50.193.133 with HTTP; Mon, 25 Mar 2013 06:28:00 -0700 (PDT) X-Originating-IP: [209.87.237.3] In-Reply-To: <7A5CECA875B00640B202F1DBA1815D230E782985@vie196nt> References: <20130325131520.25773.10212.idtracker@ietfa.amsl.com> <7A5CECA875B00640B202F1DBA1815D230E782985@vie196nt> Date: Mon, 25 Mar 2013 09:28:00 -0400 Message-ID: From: Dan Mongrain To: ecrit@ietf.org Content-Type: multipart/alternative; boundary=14dae9340cc911fb0804d8bfc681 X-Gm-Message-State: ALoCoQlQz7MF4gussfzUNiOFIAsWo1DpvcfnBjyteCJ3Pe0Tpb85F6yunuJYyQV4oaPV7anFsqEM Subject: [Ecrit] Fwd: FW: New Version Notification for draft-mongrain-ecrit-service-coverage-scope-urn-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, 25 Mar 2013 13:28:01 -0000 --14dae9340cc911fb0804d8bfc681 Content-Type: text/plain; charset=ISO-8859-1 I submitted version 00 of my draft that documents Service Coverage Scope in Service URN. I decided to call it Service Coverage Scope instead of Jurisdiction Scope only because it could be used to specify a service that is not government provided. For example, I want to find a restaurant and I am looking for the neighbourhood pizza joint (not a national chain). I would then specify Service URN "urn:service:restaurant.pizza.A5" (whatever the standard for restaurant Service URN would look like). On the other hand, if I want the national pizza chain, I would specify "urn:service:restaurant.pizza.country". I though of creating a .international Service Area Scope but decided to hold off and get comments first, especially since this is not necessary for Public Safety. The is the Interpol that would fit the requirement for .international but they do not accept emergency calls (as far as I know). I also did not include .A6 (street level) as I am not sure it makes sense, but again, willing to add as it costs nothing to do so. This is my first Internet draft so please be indulgent. Thanx, Dan -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: March-25-13 9:15 AM To: MONGRAIN Daniel Subject: New Version Notification for draft-mongrain-ecrit-service-coverage-scope-urn-00.txt A new version of I-D, draft-mongrain-ecrit-service-coverage-scope-urn-00.txt has been successfully submitted by Daniel Mongrain and posted to the IETF repository. Filename: draft-mongrain-ecrit-service-coverage-scope-urn Revision: 00 Title: Service Coverage Scope for Service URN Creation date: 2013-03-25 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-mongrain-ecrit-service-coverage-scope-urn-00.txt Status: http://datatracker.ietf.org/doc/draft-mongrain-ecrit-service-coverage-scope-urn Htmlized: http://tools.ietf.org/html/draft-mongrain-ecrit-service-coverage-scope-urn-00 Abstract: This document specifies a mechanism to specify a Service Coverage Scope in a Service URN [RFC5031] when multiple providers provide the same service for the same location. The IETF Secretariat --14dae9340cc911fb0804d8bfc681 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I submitted version 00 of my draft that documents Service Coverage Scope in= Service URN.=A0 I decided to call it Service Coverage Scope instead of Jur= isdiction Scope only because it could be used to specify a service that is = not government provided.=A0 For example, I want to find a restaurant and I = am looking for the neighbourhood pizza joint (not a national chain).=A0 I w= ould then specify Service URN "urn:service:restaurant.pizza.A5" (= whatever the standard for restaurant Service URN would look like).=A0 On th= e other hand, if I want the national pizza chain, I would specify "urn= :service:restaurant.pizza.country".=A0 I though of creating a .interna= tional Service Area Scope but decided to hold off and get comments first, e= specially since this is not necessary for Public Safety.=A0 The is the Inte= rpol that would fit the requirement for .international but they do not acce= pt emergency calls (as far as I know).=A0 I also did not include .A6 (stree= t level) as I am not sure it makes sense, but again, willing to add as it c= osts nothing to do so.

This is my first Internet draft so please be indulgent.

Thanx,Dan


-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: March-25-13 9:15 AM
To: MONGRAIN Daniel
Subject: New Version Notification for draft-mongrain-ecrit-service-coverage= -scope-urn-00.txt


A new version of I-D, draft-mongrain-ecrit-service-coverage-scope-urn-00.tx= t
has been successfully submitted by Daniel Mongrain and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-mongrain-ecrit-service-coverage-scope-urn Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Service Coverage Scope for Service URN
Creation date: =A0 2013-03-25
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 6
URL: =A0 =A0 =A0 =A0 =A0 =A0 = http://www.ietf.org/internet-drafts/draft-mongrain-ecrit-service-coverage-s= cope-urn-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatr= acker.ietf.org/doc/draft-mongrain-ecrit-service-coverage-scope-urn
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf= .org/html/draft-mongrain-ecrit-service-coverage-scope-urn-00


Abstract:
=A0 =A0This document specifies a mechanism to specify a Service Coverage =A0 =A0Scope in a Service URN [RFC5031] when multiple providers provide the=
=A0 =A0same service for the same location.




The IETF Secretariat


--14dae9340cc911fb0804d8bfc681-- From pkyzivat@alum.mit.edu Mon Mar 25 06:35: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 E6A4A21F8DC1 for ; Mon, 25 Mar 2013 06:35:22 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wHo2HtcY72c for ; Mon, 25 Mar 2013 06:35:22 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 0B63321F8D02 for ; Mon, 25 Mar 2013 06:35:20 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta03.westchester.pa.mail.comcast.net with comcast id FlKL1l00P0mv7h053pbLP4; Mon, 25 Mar 2013 13:35:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id FpbK1l01B3ZTu2S3XpbKLw; Mon, 25 Mar 2013 13:35:19 +0000 Message-ID: <51505297.4010308@alum.mit.edu> Date: Mon, 25 Mar 2013 21:35:19 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: ecrit@ietf.org References: <7594FB04B1934943A5C02806D1A2204B13233A@ESESSMB209.ericsson.se> <155970D1DA8E174F9E46039E10E2AA35D33564@XMB103ADS.rim.net> In-Reply-To: <155970D1DA8E174F9E46039E10E2AA35D33564@XMB103ADS.rim.net> 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=1364218520; bh=g51jmFrYO6XyXgQai7AB9q5KXg6xy1oIrmB1W2m07F8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=G5s2D6bdGnHCZMRI/x8CeuV7vJbvn5CAIbHvx3/SsCZSEOcXchciPOcWyQOS4gV+y z6GFERy7yexZ0WUehITog8iTO5+/+2nEfilO2fUOo45hSW1BIrE2jTyY6dfvebwVZv dAxC4UQ3YPq+QcgO8rCchOl5VqgLi2edM8Cj+tKXO59wh1cdb+CT47kI1TkN3B1zPh kb38FqBdtvn3aIbQCh6fbzfwI841At9S9bEbbaWzoPGk4EztXbVqQtTW9NGCo2ALSN UHOFn3OH8jWMVlsqn/qKPAt9v8mwSrmmCPldmuYdSCRbaklAXzhFGcNg7YBNKEHr3U 5e0/g1ZXOAz7g== Subject: Re: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG 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: Mon, 25 Mar 2013 13:35:23 -0000 On 3/24/13 9:39 AM, John-Luc Bakker wrote: > I support the work with the following note. > > I agree with relaxing the rules, however in addition it would still be useful to create a new subtree within which regulators can define emergency service URNs. Emergency service URNs, for which no consensus exists (yet), can be located within this subtree. So would you then expect that a urn created without consensus would be renamed if/when it gained consensus? That smells much like an X- header. We have learned that was a bad idea. Thanks, Paul > Regards, > > JL > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Saturday, March 23, 2013 4:18 AM > To: Roger Marshall; ecrit@ietf.org > Subject: Re: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG draft? > > > I obviously support this :) > > Regards, > > Christer > ________________________________________ > From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] on behalf of Roger Marshall [RMarshall@telecomsys.com] > Sent: Saturday, 23 March 2013 1:02 AM > To: ecrit@ietf.org > Subject: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG draft? > > Given the discussion at IETF86 around service URNs, as described in Christer's draft, draft-holmberg-ecrit-country-emg-urn, and based on the goodly level of interest as shown in the room and as captured in the minutes, [taken from posted ecrit minutes], "the wg chairs asked for a show of interest in this work? > <12 hands up>, with ". > > Please weigh in on the question posed now to the list. > > Should draft-holmberg-ecrit-country-emg-urn be accepted as a ECRIT work group item? > > > Roger & Marc > > CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > --------------------------------------------------------------------- > 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 your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From Daniel.MONGRAIN@frequentis.com Mon Mar 25 06:39:07 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 0816221F8DCD for ; Mon, 25 Mar 2013 06:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MExUe1Txj5Ml for ; Mon, 25 Mar 2013 06:39:04 -0700 (PDT) Received: from mail1.frequentis.com (mail1.frequentis.com [195.20.158.50]) by ietfa.amsl.com (Postfix) with ESMTP id 47E4621F8DD4 for ; Mon, 25 Mar 2013 06:39:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,905,1355094000"; d="scan'208,217";a="15784975" Received: from vie190nt.frequentis.frq ([172.16.1.190]) by mail1.frequentis.com with ESMTP; 25 Mar 2013 14:39:03 +0100 Received: from vie196nt.frequentis.frq ([172.16.1.196]) by vie190nt.frequentis.frq ([172.16.1.190]) with mapi id 14.02.0328.009; Mon, 25 Mar 2013 14:39:03 +0100 From: MONGRAIN Daniel To: Roger Marshall , "ecrit@ietf.org" Thread-Topic: draft-holmberg-ecrit-country-emg-urn - ready to be WG draft? Thread-Index: Ac4nUUc9Pn9t8t+zTf6VhqEr+na1BwCDM/RQ Date: Mon, 25 Mar 2013 13:39:02 +0000 Message-ID: <7A5CECA875B00640B202F1DBA1815D230E782A27@vie196nt> References: In-Reply-To: Accept-Language: en-CA, en-US, de-AT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.23.192.17] Content-Type: multipart/alternative; boundary="_000_7A5CECA875B00640B202F1DBA1815D230E782A27vie196nt_" MIME-Version: 1.0 Subject: Re: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG 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: Mon, 25 Mar 2013 13:39:07 -0000 --_000_7A5CECA875B00640B202F1DBA1815D230E782A27vie196nt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Dan ____________________________________________________ Dan Mongrain, eng. Senior Systems Engineer, Public Safety FREQUENTIS USA Inc. 9017 Red Branch Road, Suite 102 Columbia Maryland 21045 Phone +1-301-657-8001 Mobile +1-819-744-0491 Fax +1-301-657-8002 Web www.frequentis.com/usa E-Mail dan.mongrain@frequentis.com Incorporated in the State of Maryland EIN: 52-2178926 CAGE Code: 1XKR9 ____________________________________________________ Confidentiality Notice: This email message, including any attachments, is f= or the sole use of the intended recipient(s) and contains confidential and = privileged information. Any unauthorized review, use, disclosure or distrib= ution is prohibited. If you are not the intended recipient, please contact = the sender by reply email and destroy all copies of the original message an= d associated attachments. From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of R= oger Marshall Sent: March-22-13 7:02 PM To: ecrit@ietf.org Subject: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be WG draf= t? Given the discussion at IETF86 around service URNs, as described in Christe= r's draft, draft-holmberg-ecrit-country-emg-urn, and based on the goodly level of interest as shown in the room and as captured in the minutes, [taken fro= m posted ecrit minutes], "the wg chairs asked for a show of interest in this = work? <12 hands up>, with ". Please weigh in on the question posed now to the list. Should draft-holmberg-ecrit-country-emg-urn be accepted as a ECRIT work gro= up item? Roger & Marc 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_7A5CECA875B00640B202F1DBA1815D230E782A27vie196nt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

Dan<= /p>

 

___________________________= _________________________
Dan Mongrain, eng.
Senior Systems Engineer, Public Safety<= /span>
FREQUENTIS USA Inc.

9017 Red Branch Road, Suite 102 Columbia Ma= ryland 21045
Phone   +1-301-657-8001<= br> Mobile   +1-819-744-0491
Fax      &nbs= p;+1-301-657-8002
Web      www.freque= ntis.com/usa
E-Mail    dan.mongrain@frequentis.com=

Incorporated in the State of Maryland

EIN: 52-2178926 CAGE Code: 1XKR9
____________________________________________________

Confidentiality Notice:<= /span> This email message, including any attac= hments, is for the sole use of the intended recipient(s) and contains confidential= and privileged information. Any unauthorized review, use, disclosure or di= stribution is prohibited. If you are not the intended recipient, please con= tact the sender by reply email and destroy all copies of the original message and associated attachments.<= span lang=3D"EN-US" style=3D"font-size:12.0pt;font-family:"Times New R= oman","serif";color:#1F497D">

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On Behalf Of Roger Marshall
Sent: March-22-13 7:02 PM
To: ecrit@ietf.org
Subject: [Ecrit] draft-holmberg-ecrit-country-emg-urn - ready to be = WG draft?

 

Given the discussion at IETF86 = around service URNs, as described in Christer’s

draft, draft-holmberg-ecrit-cou= ntry-emg-urn, and based on the goodly level

of interest as shown in the roo= m and as captured in the minutes, [taken from

posted ecrit minutes], “t= he wg chairs asked for a show of interest in this work?

<12 hands up>, with <n= o opposition>”.

 

Please weigh in on the question= posed now to the list.

 

Should draft-holmberg-ecrit-cou= ntry-emg-urn be accepted as a ECRIT work group item?

 

 

Roger & Marc

CONFIDENTIALITY NOTICE: The information contain= ed in this message may be privileged and/or confidential. If you are not th= e intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, = distribution or copying of this communication or any attachment(s) is stric= tly prohibited. If you have received this message in error, please notify t= he sender immediately, and delete it and all attachments from your computer and network.

--_000_7A5CECA875B00640B202F1DBA1815D230E782A27vie196nt_-- From Daniel.MONGRAIN@frequentis.com Mon Mar 25 06:51: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 5186921F8CA6 for ; Mon, 25 Mar 2013 06:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-2-G62Qfv-k for ; Mon, 25 Mar 2013 06:51:17 -0700 (PDT) Received: from mail1.frequentis.com (mail1.frequentis.com [195.20.158.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6845521F8C5D for ; Mon, 25 Mar 2013 06:51:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,905,1355094000"; d="scan'208,217";a="15785162" Received: from vie191nt.frequentis.frq ([172.16.1.191]) by mail1.frequentis.com with ESMTP; 25 Mar 2013 14:51:15 +0100 Received: from vie196nt.frequentis.frq ([172.16.1.196]) by vie191nt.frequentis.frq ([172.16.1.191]) with mapi id 14.02.0328.009; Mon, 25 Mar 2013 14:51:15 +0100 From: MONGRAIN Daniel To: Dan Mongrain , "ecrit@ietf.org" Thread-Topic: [Ecrit] Fwd: FW: New Version Notification for draft-mongrain-ecrit-service-coverage-scope-urn-00.txt Thread-Index: AQHOKVrOHxl3EwHmxkGCItT516pWxZi2YxoQ///ykACAABWgQA== Date: Mon, 25 Mar 2013 13:51:14 +0000 Message-ID: <7A5CECA875B00640B202F1DBA1815D230E782A61@vie196nt> References: <20130325131520.25773.10212.idtracker@ietfa.amsl.com> <7A5CECA875B00640B202F1DBA1815D230E782985@vie196nt> In-Reply-To: Accept-Language: en-CA, en-US, de-AT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.23.192.17] Content-Type: multipart/alternative; boundary="_000_7A5CECA875B00640B202F1DBA1815D230E782A61vie196nt_" MIME-Version: 1.0 Subject: Re: [Ecrit] Fwd: FW: New Version Notification for draft-mongrain-ecrit-service-coverage-scope-urn-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, 25 Mar 2013 13:51:19 -0000 --_000_7A5CECA875B00640B202F1DBA1815D230E782A61vie196nt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry, I forgot to mention that I did not specify a IANA section as I am no= t sure how to proceed. I certainly do not want the IANA to have to add a S= ervice Coverage Scope to each and every Service URN that gets registered (w= ould become unwieldy and not every combination of Service Coverage Scope an= d Service URN would be used). We could create a registry for Service Cover= age Scope so one could find everything to be found for Service URN in the r= egistry. But then again, other than possible .international and .A6, the l= ist of Service Coverage Scopes is finite so registration is not necessary. Thoughts? Dan ____________________________________________________ Dan Mongrain, eng. Senior Systems Engineer, Public Safety FREQUENTIS USA Inc. 9017 Red Branch Road, Suite 102 Columbia Maryland 21045 Phone +1-301-657-8001 Mobile +1-819-744-0491 Fax +1-301-657-8002 Web www.frequentis.com/usa E-Mail dan.mongrain@frequentis.com Incorporated in the State of Maryland EIN: 52-2178926 CAGE Code: 1XKR9 ____________________________________________________ Confidentiality Notice: This email message, including any attachments, is f= or the sole use of the intended recipient(s) and contains confidential and = privileged information. Any unauthorized review, use, disclosure or distrib= ution is prohibited. If you are not the intended recipient, please contact = the sender by reply email and destroy all copies of the original message an= d associated attachments. From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of D= an Mongrain Sent: March-25-13 9:28 AM To: ecrit@ietf.org Subject: [Ecrit] Fwd: FW: New Version Notification for draft-mongrain-ecrit= -service-coverage-scope-urn-00.txt I submitted version 00 of my draft that documents Service Coverage Scope in= Service URN. I decided to call it Service Coverage Scope instead of Juris= diction Scope only because it could be used to specify a service that is no= t government provided. For example, I want to find a restaurant and I am l= ooking for the neighbourhood pizza joint (not a national chain). I would t= hen specify Service URN "urn:service:restaurant.pizza.A5" (whatever the sta= ndard for restaurant Service URN would look like). On the other hand, if I= want the national pizza chain, I would specify "urn:service:restaurant.piz= za.country". I though of creating a .international Service Area Scope but = decided to hold off and get comments first, especially since this is not ne= cessary for Public Safety. The is the Interpol that would fit the requirem= ent for .international but they do not accept emergency calls (as far as I = know). I also did not include .A6 (street level) as I am not sure it makes= sense, but again, willing to add as it costs nothing to do so. This is my first Internet draft so please be indulgent. Thanx, Dan -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: March-25-13 9:15 AM To: MONGRAIN Daniel Subject: New Version Notification for draft-mongrain-ecrit-service-coverage= -scope-urn-00.txt A new version of I-D, draft-mongrain-ecrit-service-coverage-scope-urn-00.tx= t has been successfully submitted by Daniel Mongrain and posted to the IETF repository. Filename: draft-mongrain-ecrit-service-coverage-scope-urn Revision: 00 Title: Service Coverage Scope for Service URN Creation date: 2013-03-25 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-mongrain-ecrit-s= ervice-coverage-scope-urn-00.txt Status: http://datatracker.ietf.org/doc/draft-mongrain-ecrit-servi= ce-coverage-scope-urn Htmlized: http://tools.ietf.org/html/draft-mongrain-ecrit-service-co= verage-scope-urn-00 Abstract: This document specifies a mechanism to specify a Service Coverage Scope in a Service URN [RFC5031] when multiple providers provide the same service for the same location. The IETF Secretariat --_000_7A5CECA875B00640B202F1DBA1815D230E782A61vie196nt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry, I forgot to mentio= n that I did not specify a IANA section as I am not sure how to proceed.&nb= sp; I certainly do not want the IANA to have to add a Service Coverage Scope to each and every Service URN that gets registered (would b= ecome unwieldy and not every combination of Service Coverage Scope and Serv= ice URN would be used).  We could create a registry for Service Covera= ge Scope so one could find everything to be found for Service URN in the registry.  But then again, other t= han possible .international and .A6, the list of Service Coverage Scopes is= finite so registration is not necessary.

 <= /p>

Thoughts?

 <= /p>

Dan

 <= /p>

___________________________= _________________________
Dan Mongrain, eng.
Senior Systems Engineer, Public Safety<= /span>
FREQUENTIS USA Inc.

9017 Red Branch Road, Suite 102 Columbia Ma= ryland 21045
Phone   +1-301-657-8001<= br> Mobile   +1-819-744-0491
Fax      &nbs= p;+1-301-657-8002
Web =      www.freque= ntis.com/usa
E-Mail    dan.mongrain@frequentis.com=

Incorporated in the State of Maryland

EIN: 52-2178926 CAGE Code: 1XKR9
____________________________________________________

Confidentiality Notice:<= /span> This email message, including any attac= hments, is for the sole use of the intended recipient(s) and contains confidential= and privileged information. Any unauthorized review, use, disclosure or di= stribution is prohibited. If you are not the intended recipient, please con= tact the sender by reply email and destroy all copies of the original message and associated attachments.

 <= /p>

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On Behalf Of Dan Mongrain
Sent: March-25-13 9:28 AM
To: ecrit@ietf.org
Subject: [Ecrit] Fwd: FW: New Version Notification for draft-mongrai= n-ecrit-service-coverage-scope-urn-00.txt

 

I submitted version 0= 0 of my draft that documents Service Coverage Scope in Service URN.  I= decided to call it Service Coverage Scope instead of Jurisdiction Scope on= ly because it could be used to specify a service that is not government provided.  For example, I want to find= a restaurant and I am looking for the neighbourhood pizza joint (not a nat= ional chain).  I would then specify Service URN "urn:service:rest= aurant.pizza.A5" (whatever the standard for restaurant Service URN would look like).  On the other hand, if I want the natio= nal pizza chain, I would specify "urn:service:restaurant.pizza.country= ".  I though of creating a .international Service Area Scope but = decided to hold off and get comments first, especially since this is not necessary for Public Safety.  The is the Interpol t= hat would fit the requirement for .international but they do not accept eme= rgency calls (as far as I know).  I also did not include .A6 (street l= evel) as I am not sure it makes sense, but again, willing to add as it costs nothing to do so.

This is my first Internet draft so please be indulgent.

Thanx,
Dan

-----Original Message= -----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: March-25-13 9:15 AM
To: MONGRAIN Daniel
Subject: New Version Notification for draft-mongrain-ecrit-service-coverage= -scope-urn-00.txt


A new version of I-D, draft-mongrain-ecrit-service-coverage-scope-urn-00.tx= t
has been successfully submitted by Daniel Mongrain and posted to the
IETF repository.

Filename:        draft-mongrain-ecrit-service-coverage-= scope-urn
Revision:        00
Title:           Service Coverage Scope for Servic= e URN
Creation date:   2013-03-25
Group:           Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-mongrain-ecrit-service-coverage-s= cope-urn-00.txt
Status:          http://datatracker.ietf.org/doc/draft-mongrain-ecrit-service-coverage-sco= pe-urn
Htmlized:        http:= //tools.ietf.org/html/draft-mongrain-ecrit-service-coverage-scope-urn-00


Abstract:
   This document specifies a mechanism to specify a Service Cover= age
   Scope in a Service URN [RFC5031] when multiple providers provi= de the
   same service for the same location.




The IETF Secretariat

 

--_000_7A5CECA875B00640B202F1DBA1815D230E782A61vie196nt_-- From keith.drage@alcatel-lucent.com Mon Mar 25 07:35: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 01D6511E80AD for ; Mon, 25 Mar 2013 07:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yU17jE6ocRUv for ; Mon, 25 Mar 2013 07:35:43 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2B01711E80A6 for ; Mon, 25 Mar 2013 07:35:43 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r2PEXkxv014462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Mar 2013 09:35:41 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r2PEQpSx024666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Mar 2013 10:26:52 -0400 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 25 Mar 2013 10:26:52 -0400 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 25 Mar 2013 15:26:40 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-02 Thread-Index: AQHOJLRQ9xRXvhZrpEuXVCWma3y2d5itGeWAgAlmHKA= Date: Mon, 25 Mar 2013 14:26:40 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B01ABFB@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B12C63C@ESESSMB209.ericsson.se> <155970D1DA8E174F9E46039E10E2AA35D24AAE@XMB103ADS.rim.net> <51488A33.10405@alum.mit.edu> In-Reply-To: <51488A33.10405@alum.mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg-urn-02 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 Mar 2013 14:35:44 -0000 It would make sense to allow both these options. Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: 19 March 2013 15:54 > To: ecrit@ietf.org > Subject: Re: [Ecrit] Draft new version: draft-holmberg-ecrit-country-emg- > urn-02 >=20 > This is a good question. > It appears that the answer is NO. :-( >=20 > The current registry only has the service name, a few words of > descrption, and a reference. The expert review for new registrations > doesn't seem to require a document, so there may not be anything to > reference for new registrations. >=20 > There seem to be a couple of possibilities: >=20 > Change to require a specification, and provide instructions for IANA to > reference it. >=20 > OR, change the registration template to require a longer description of > the service, and change the IANA table to include it. >=20 > Thanks, > Paul >=20 > On 3/19/13 11:11 PM, John-Luc Bakker wrote: > > Hi Christer, > > > > Thanks for this. > > > > When a new URN is adopted via expert review, a description of the calle= r > > expectation in terms of services rendered (for the new URN) cannot be > > found in RFC 5031. > > > > For example, for the existing URN urn:service:sos.mountain, the RFC > > includes: > > > > The 'mountain' service refers to mountain > > > > rescue services (i.e., search and rescue activities that occur i= n > > > > a mountainous environment), although the term is sometimes also > > > > used to apply to search and rescue in other wilderness > > > > environments. > > > > Will the caller expectation in terms of services rendered be documented > > somewhere? > > > > Apologies if this query was already addressed during the ECRIT session = ... > > > > Kind regards, > > > > JL > > > > *From:*ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] *On Behal= f > > Of *Christer Holmberg > > *Sent:* Tuesday, March 19, 2013 6:52 AM > > *To:* ecrit@ietf.org > > *Subject:* [Ecrit] Draft new version: > > draft-holmberg-ecrit-country-emg-urn-02 > > > > Hi, > > > > Based on the Orlando decision to move forward with the > > relax-the-5031-registration-policy alternative for allowing emg URNs fo= r > > services offered in one country only, I've submitted an "official" new > > version (-02) of draft-holmberg-ecrit-country-emg-urn. Aside from some > > minor changes caused by the new version of xml2rfc, the draft is > > identical to the pre-02 version I distributed before the meeting. > > > > As was indicated in the meeting, additional text will still be needed, > > but once the Orlando decision is verified on the list I hope we can > > adopt the draft as base for the work. > > > > Thanks to everyone who provided comments during the meeting! > > > > Regards, > > > > Christer > > > > --------------------------------------------------------------------- > > 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 tha= n > > the intended recipient is prohibited. If you have received this > > transmission in error, please immediately reply to the sender and delet= e > > this information from your system. Use, dissemination, distribution, or > > reproduction of this transmission by unintended recipients is not > > authorized and may be unlawful. > > > > > > _______________________________________________ > > 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 RMarshall@telecomsys.com Mon Mar 25 10:56: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 9CADB21F9165 for ; Mon, 25 Mar 2013 10:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.585 X-Spam-Level: X-Spam-Status: No, score=-101.585 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, GB_I_LETTER=-2, J_CHICKENPOX_36=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdPvjR+ySomE for ; Mon, 25 Mar 2013 10:56:52 -0700 (PDT) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) by ietfa.amsl.com (Postfix) with ESMTP id 66D9021F907B for ; Mon, 25 Mar 2013 10:56:52 -0700 (PDT) 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 r2PHuhXP021299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 25 Mar 2013 10:56:43 -0700 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.178]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Mon, 25 Mar 2013 10:56:43 -0700 From: Roger Marshall To: Christer Holmberg , "ecrit@ietf.org" Thread-Topic: IETF86: Minutes for Ecrit, 03/13/2013 Thread-Index: Ac4nTukMYxlSoYNRRaS58RAGew+JXQAWHs/DAHag6XA= Date: Mon, 25 Mar 2013 17:56:43 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B132359@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B132359@ESESSMB209.ericsson.se> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ecrit] IETF86: Minutes for Ecrit, 03/13/2013 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 Mar 2013 17:56:54 -0000 Thanks Christer. Change made to minutes and new version uploaded to MM. -roger. -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Saturday, March 23, 2013 2:20 AM To: Roger Marshall; ecrit@ietf.org Subject: RE: IETF86: Minutes for Ecrit, 03/13/2013 Hi, A minor correction to bullet 2): Hannes will fix the nits to draft-ietf-ecr= it-psap-callback. Regards, Christer ________________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] on behalf of Roger Ma= rshall [RMarshall@telecomsys.com] Sent: Saturday, 23 March 2013 12:45 AM To: ecrit@ietf.org Subject: [Ecrit] IETF86: Minutes for Ecrit, 03/13/2013 Minutes w/summary, ECRIT WG Meeting, IETF86 Orlando, 03/13/2013, 13:00-15:0= 0 If you have any additions or modifications to these minutes, please let Roger & Marc know via email. These minutes will be updated to the IETF86 meeting materials page. Thank you goes to Jean Mahoney for note-taking, and, thanks also to Robert Sparks for serving as RAI AD these past years. Chairs: Roger Marshall, rmarshall@telecomsys.com Marc Linsner, mlinsner@cisco.com Summary 1. Revisions shown to former milestone dates will be posted to the list, th= en submitted, based on comments received in the working group meeting. It was agreed that the current date for rough-location should be pushed out a year= . 2. Christer agreed to fix the nits to draft-ietf-ecrit-psap-callback-08, th= en chairs will submit to IESG for processing. 3. Richard provided status on the rough-location, stating that it's progres= s is dependent on a liaison response for direction. 4. Brian agreed to additional-data next action discussing new block or URI = on the wg email list. 5. For data-only draft, when a CAP message is by reference or value, Brian agreed to rework the draft to make it like the additional-data draft, using a Call-Info header with a URL that can be a cid. 6. Ecall draft, it was proposed that document be made separate drafts, so that service URNs just need expert review. Brian would be agreeable subjec= t to wg consensus (tested on the list). 7. The discussion around trustworthy-location was that some parts needed to be lifted out and put into other drafts, then ask for an intense review onc= e Bernard submits version -05. 8. Draft rph-reg-policy suggests changes that avoid adding a new top level requires standard track, but would make it by expert review. Adam Roach stated that the RPH Registry Management Policy draft be raised in sipcore. 9. For draft-holmberg-ecrit-country-emg-urn, the proposal to handle this with expert review was proffered, and the wg chairs asked for a show o= f interest in this work? <12 hands up>, with , which showed a decent amount of interest. Actual drafts discussed: Additional Data related to an Emergency Call draft-ietf-ecrit-additional-data Data-Only Emergency Alerts using the SIP draft-ietf-ecrit-data-only-ea Internet Protocol-based In-Vehicle Emergency Call draft-rosen-ecrit-ecall Trustworthy Location Information draft-ietf-ecrit-trustworthy-location RPH Registry Management Policy to IETF Review draft-rosen-rph-reg-policy-00.txt/ URN For Country Specific Emergency Services draft-holmberg-ecrit-country-emg-urn/ ----------------------------------------------------------------------- Agenda Bashing, Draft Status Update (10 min) Presentation: http://www.ietf.org/proceedings/86/slides/slides-86-ecrit-5.p= ptx Presenters: Marc Linsner, Roger Marshall Note taker: Jean Mahoney Jabber scribe: Hannes Tschofenig Jabber log: http://www.ietf.org/jabber/logs/ecrit/2013-03-13.html The ECRIT working group presented the outgoing RAI area director Robert Spa= rks a bottle of tequila as a token of their appreciation. On behalf of the GEOPRIV working group, which didn't meet, Richard Barnes p= resented Robert with geographically-specific chocolates and a chocolate bar= with privacy rules and which, according to its label, may cause an emergen= cy if consumed. ACTION: Robert Sparks to report on how he gets the tequila home. Note well presented. The agenda has been modified - the presentation "Extensions to the Emergenc= y Services Architecture for dealing with Unauthenticated and Unauthorized D= evices (15 min)" was canceled. Document status presented: draft-ietf-ecrit-psap-callback-08* would be good to correct nits first, the= n send to IESG Milestones presented: Have been updated but not submitted. Hannes Tschofenig - what's the status of the Imprecise Location draft? Richard Barnes - Liaison to see if pending NC direction. Hannes - the March milestones need to be updated. I also requested a WGLC o= n [?], maybe in July. ACTION: provide feedback on the mailing list before the update is submitted= . ----------------------------------------------------------------------- Additional Data related to an Emergency Call (10 min) http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ Presentation: http://www.ietf.org/proceedings/86/slides/slides-86-ecrit-1.p= ptx Presenter: Brian Rosen Intention: Discuss if ready for WGLC Sllide 3 - Open Items: Brian - We need some text on when it is appropriate to use either a new blo= ck or URI and type with registry in device block when handling device-speci= fic data. The answer has to do with the following issues: - things that are widely applicable and large structure - need separate bl= ock with more IETF review - URI - first come first served What kind of review should it get? It's allowable to send a block by value but not a device block with url, yo= u can't send that by value. What about A huge thing sent by value? - I worr= y about that. It should be covered in the considerations section. Any reactions? Randall Gellens - There can be side effects from sending large data by valu= e, but for device, you can only send by value. Hannes - You don't want to be restrictive on the process of adding new bloc= ks. You can shoot yourself in the foot. Brian - It's expert review - not RFC. Hannes - that's not that restrictive. Martin Thomson - it's not a restrictive space. Brian - Right. We think we're done. Get it out before the intermediary [?] = (interim? but Marc indicated later in the meeting that there wasn't an inte= rim). Marc - Anyone willing to review it? We'll take it to the list= . ACTION: Discuss when it is appropriate to use either a new block or URI and= type with registry in device block when handling device-specific data on t= he mailing list. ----------------------------------------------------------------------- Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the S= ession Initiation Protocol (10 min) http://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ Presentation: http://www.ietf.org/proceedings/86/slides/slides-86-ecrit-2.p= ptx Presenter: Brian Rosen Intention: Discuss latest changes Slides presented. James Polk - On slide 3, do you mean any SIP request? Including CANCEL? Brian - it's not a request, it's a transaction. CANCEL is a bad example. Ce= rtainly UPDATE. Bernard Aboba - you could include a URL. Fetch an updated version if you wa= nted to. Brian - sure. Now I need to define a mime type or a new header. Now it's a = just a [...] Martin - I was going to suggest using Call-Info. Where to get the sub and t= he authorization? Send a message saying I'm here [...]. I think it's a fin= e idea. Brian - I should put the mechanism with the original INVITE. It will be eas= y. I can define [...] In the Call-Info, for further info, subscribe here - = URL and call info. Randall - what about the mechanism in additional-data [...] Brian - I'm going to reuse that. Roger - Summarize what Randall said. Brian - Send a CAP message by reference or value. Like the additional-data = draft - A Call-Info header with a URL that can be a CID. I will rework the = draft to that. Randall - you just need a definition of the MIME type and [...] Brian - make the CAP message a block of additional data. Great idea. ----------------------------------------------------------------------- Internet Protocol-based In-Vehicle Emergency Call (20 min) http://datatracker.ietf.org/doc/draft-rosen-ecrit-ecall/ Presentation: http://www.ietf.org/proceedings/86/slides/slides-86-ecrit-6.p= pt Presenter: Hannes Tschofenig Intention: Discuss whether candidate for WG adoption Slides presented. Marc, as indvidual - How does this draft contrast with the data-only draft? Hannes - It complements data-only. There are some additional structures. Th= e eCall spec talks about 2 data elements - a minimal set (covered in the ex= ample on slide 4). The other is more extensive and lines up with additional= -data and data-only. The data-only plays a role when there's no media. Brian - additional-data provides a mechanism for carrying sensor-related da= ta. We have extensions for carrying data. data-only provides CAP - alert re= lated - which says, "you need to pay attention because". I don't know how t= his adds. We have a place to put the data and a place to put the alert. Wha= t isn't covered? Hannes - This defines 2 service URNs for eCall. It provides description of = how it relates to eCall. How to use this work for their purpose. Randall - With every situation for eCall, the voice channel is the paramoun= t importance. Hannes - The draft doesn't reference the data-only draft because I had the = same impression. eCall doesn't spec how to [?]. Henning - In the United States, there are researchers that collect data tha= t include deceleration, airbags inflated, tension on seatbelt. Doesn't seem= to fit into a CAP model. Hannes - it fits into Additional Data. Henning Schulzrinne - we should talk with those folks. How to make it fit = in. They are using VOIP for emergency calls. 2nd - there's a blurring betwe= en true emergency calls - sending an ambulance for instance - and when you = want to do more prevention. Reporting that the ABS/stability systems go on = - can indicate black ice. Or fog lights go on - fog - the information could= go to highway patrol. Possibly a different service URN. It's safety relate= d. They can get warnings out. Need to send salt out. Act as data fusion cen= ter. Can be automated. This is stretching the 911 model. Can think about th= is. Hannes - We can describe that in doc as use cases. And double check with ad= ditional-data to see if we have schemas in place. But it's a different leve= l of detail. Henning Schulzrinne - try to get people to think ahead. Randall, to Henning - have those people get in touch with authors, review, = sign up on mail list. You raise the safety related issues. There's overlap = for reuse. The use cases should be in a new doc. I want this doc to be emer= gency calling. ACTION: Henning to contact the US researchers he mentioned to ask them to r= eview the document and to sign up for the ECRIT mailing list. Brian - I'm an author but I haven't been involved in the last 2 versions. F= irst point - the doc needs to be clearer on its intended purposes. It doesn= 't explain why you are defining new URNs. It's because they are routed diff= erently. Second point - why is it standards track? Because it's defining se= rvice URNs. Otherwise it's an informational document. Keith Drage - eCall is an emergency call. We have different architectures f= or delivering calls. Don't want non-emergency sent to the PSAP. Randall - that's why it should be in its own document. RFC - say URNs need = expert review, not standards track. Hannes - Is there interest in the working group? Brian - I would like to speak in favor as an author. It's a reference to us= e IETF mechanisms to do what they want to do. It's valuable. Marc - Then I heard Henning say we need to add others. Henning - I don't want to hold up anything for something speculative. Ensur= e that the doc is self-contained for all pieces for telematics for emergenc= y calling. I don't know if it's been considered by eCall. Separately - we n= eed to talk about the other component - a separate schema and URI. Hannes - I reference Additional Data. It would be good [?]. There's a limit= on the data they send for eCall. Marc - what do we think? Randall - we might want a separate doc so that service URNs just need exper= t review. Brian - do IETF consensus for it. I'd be happy to do that doc. Marc, as chair - how many people read the draft and are interested? Marc - We will take it to the list. ACTION: Discuss adopting the draft as a working group item on the mailing l= ist. Randall - [?] Brian - I request a call for a hum to downgrade the registry. Keith - we're going to talk about this later. Brian - I can wait. ----------------------------------------------------------------------- Extensions to the Emergency Services Architecture for dealing with Unauthen= ticated and Unauthorized Devices (15 min) http://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access/ Presenter: Hannes Tschofenig Intention: Discuss latest changes CANCELED. ----------------------------------------------------------------------- Trustworthy Location Information (15 min) http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/ Presenter: Bernard Aboba Intention: Discuss latest changes Slide 3 - Issue 4: Untrusted Location and Provider Intent. Martin Thomson - I worry when people look at how location info was received= to determine if it's trustworthy. The real info used to determine if it's = good is: when it was the info generated? What's the uncertainty? What's the= location? There are other things used to determine trust. The latter half = of the paragraph is important. Bernard - If it came from a LIS, ok. But if it came from some weird place, = what do I say in the pdif-lo? I want to tell the PSAP enough info to make a= judgment. Brian - It's on the right track. The basic info is: how you measured it, ho= w accurate it is, what the location is. Bernard - if not authoritative and measured a year ago. Brian - the timestamp of the measurement and the timestamp of when it was s= ent [?] Henning - It's difficult to know if the accuracy was determined in a global= way. For instance, GPS has this sort of accuracy. Or for that specific mea= surement. Wifi gives you this. In certain cases, it's more or less accurate= . But you tell me about the particular measurement. Primary and secondary -= aggregators - have munged up data magically, adding trust info. The smartp= hone vendors do this, and don't say how they do it. Just knowing source - l= ike the company and if they do a good job of preventing spoofing - it gives= you a sense. Bernard - We're not capturing that. we'll expand section 4. Martin - every location provided provides uncertainty on it. There are some= cells where locations are within 10 meters. With GPS, you can determine un= certainty and can report that. You need to make it explicit that you report= the measurement's uncertainty, not the technology's. The location info is = not technology specific - there's a lot of combination of data. Bernard - good point. "wifi location" term is meaningless. Henning - it's not a technology - saying which vendor which provided it is = shorthand for what data is blended. FCC no longer makes some of these disti= nctions. Slide 4 - Issue 9: Definition of Trustworthy Russ Housley - I worry that the term "Secure" is more vague than "trustwort= hy". You are trying to say with authentication, integrity or both. But not = confidentiality. Bernard - We're not talking about privacy here. Russ - Define the security services - authentication, integrity or both. Henning - our model is different than a traditional security system. Our mo= del is more statistical, a risk assessment model. As a PSAP, I care about t= he following: out of a million locations, how many are wrong? How many are = maliciously modified? How many of these issues can I detect reasonably? If = you can detect it. Except for large scale man-in-the-middle attacks, this i= s generally determined one by one. This is risk assessment. If your adversa= ry can compromise GPS satellites - then your data can't be trustworthy. Bernard - How about the end - "securely obtained from a trusted source"? Richard - It needs to say what we are and aren't doing. Would like to guara= ntee the position of the call. Henning - There are levels of trust - origin assertion that you verified. I= f you were to ask a PSAP director to define trustworthy, he would care abou= t correctness, not that there's an adversary. A wifi access point has been = moved to a new Starbuck's branch, for instance. That's far removed from the= trustworthy computing model. They are concerned more with incompetence tha= n malice. Richard - Say in doc that we're reducing the problem from the security prob= lem to the positioning problem. Henning - it's a framing informational doc. Need to start at a high goal - = what is trustworthy. I need to have confidence in data in provided, that so= meone is responsible for improving the data (the locations of people callin= g from a certain mall always show that they're over there), and that muckin= g with data is difficult. PSAPs conflate all of those. The solutions are di= fferent. Martin - it's hard work. The biggest part is managing where the location in= fo comes from and patching it when it changes. It's complicated and expensi= ve. Slide 6 - Issue 8 Solutions Martin - I've commented on section 3.2 on the list. What a list provider wo= uld do, but not what we want to do in this situation. You're talking about = authorization from the LIS end of things. Bernard - We have an operational concern - how does the PSAP do this? But c= ircumstance [?] location hiding. Martin - Move it to a doc on location hiding, it doesn't belong here. Bernard - is it worth talking about access control at all? Martin - no, it can be cut. Brian - I'm not sure I agree on this. I care about the solution. Sending it= by reference to some server, and we know who we're talking about. The choi= ce of credentials becomes a problem. The PSAP can't maintain credentials fo= r everything. Then the PSAP has to provide credentials to you. Can't ignore= this. Bernard - if using TLS [?] Brian - It needs text on where credentials come from. Section 3.3 (proxy ad= ded location) needs more work. If the access network ... and doesn't trust = ... and it adds a proxy. The proxy adds location. Because it's more trustwo= rthy, I don't need the other. The intermediary doesn't have the trust. Coul= d expand the text. Bernard - Please provide text. Martin - Add the text and the PSAP credentials to the rough-loc draft. It's= confusing in this doc. Slide 10 - Next steps Bernard - Would like an intense review to get into -06 Marc - when you submit -05, we'll ask for reviewers. ----------------------------------------------------------------------- Resource Priority Header (RPH) Registry Management Policy to IETF Review (5 min) http://datatracker.ietf.org/doc/draft-rosen-rph-reg-policy-00.txt/ Presentation: http://www.ietf.org/proceedings/86/slides/slides-86-ecrit-3.p= ptx Presenter: Brian Rosen Intention: Discussion Brian - This is IESG approved, but 4412 requires standards track to define = a new RPH namespace. I wrote this draft to downgrade the IANA policy to mak= e it consensus rather than standards track. Adam Roach - Please comment on sipcore list. Marc, as chair - quickly. Brian - sos only requires expert review. Adding a new top level requires st= andard track, this is a proposal to change that. Adding [?] expert review, = Hannes' doc can be informational. There are no changes to the registry poli= cy. Richard - please summarize [?] Marc - I'll have to find it. Let Christer go on with his presentation. ----------------------------------------------------------------------- URN For Country Specific Emergency Services (20 min) http://datatracker.ietf.org/doc/draft-holmberg-ecrit-country-emg-urn/ Presentation: http://www.ietf.org/proceedings/86/slides/slides-86-ecrit-0.p= pt Presenter: Christer Holmberg Intention: New draft presentation Slide 4 - alternative 1 Brian - we've recreated X- or P headers. Christer - We've been told to do this on the list. Slide 6 - alternative 3 Keith - I don't think this solves the problem of "we may never have to move= it". You have one country that wants it. Or three countries that want it, = but they don't exist. For example, road side assistance. You may need to co= ver 2 or more values. The first person in says - I have service offered by = the police. The second one - same service, same semantics, but not offered = by police. You are still going to have this problem. Brian - I don't know how to engineer around it. We want review, not first-c= ome-first-served. I support this proposal. Will there be a document that do= es just this? Christer - it updates 5031. BIran - want to downgrade in the same doc. Henning - There is not a demonstrated need at the moment. Brian - I don't want this to be held up because it's only defining service = URN. Henning - Don't want to argue about regional. For example, lower 48, not of= fered in Alaska. Only reason to do sub-services - don't get lower level. St= ill have a problem with an organizational hierarchy that changes over time = - think of the Department of Homeland Security. Advice to experts to consid= er - is it inherently a police function? Not enforcement of law. Could add = that advice. It may not be a big enough problem to create another label. Th= ere's no way to go up, no generic emergency service on top of it. Christer - to clarify - there may be a reason why due to hierarchy but the = semantics are the same and should also allow to register. Henning - that outcome is undesirable and should be avoidable. Brian - send text Henning - we don't want to imply [?] The notion of one country is somewhat = meaningless. Christer - and send xml version of 3631[?] Andrew Allen - who can apply? You have to check that they are a relevant au= thority. Christer - it's good to have guidance, but we can't say who can and can't a= pply. Brian - good idea, send text. The experts can consider who's asking. Keith - I sent to the list 2-3 weeks ago. In regard who is asked to reply. = the top level. If you don't apply if you can't offer. If you need to move s= ubtypes. For example sos.police.xyz and the police go away. The admin wants= the URNs, not the deployers, they are not involved in IETF. That's why we = need expert review. Richard - moving subtypes from one super-type to the other is not a big dea= l, just define the new one. I don't think "who's asking" is a problem. Chec= k out the wikipedia article on what emergency services are. We can just go = ahead and register these. Brian - this document doesn't do - adding sub-sub-service. There are differ= ent hierarchies of policy. Do you want a separate doc? Christer - I think we need a separate decision. Brian - I'm raising the issue. People recognize that this is a problem. Sta= te and local policy need different URNs. It doesn't have to be this doc. = I recommend that it is in this doc. Keith - To do that - just write a letter to IANA. Brian - only add sub-services after sos. I have an already registered servi= ce. sos.police -> sos.police.nnn If IANA doesn't have a problem. Keith - we want the same policy to apply to sub-sub-types. Marc, as chair - your coauthor sent request to IANA. Christer - I was informed just before the meeting. That isn't really about = this document. Marc - we'll handle this with expert review. How many people interested in = this work? <12 hands up> Marc - Any opposition? 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. From hgs@cs.columbia.edu Tue Mar 26 05:06: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 A5B6721F8A2A for ; Tue, 26 Mar 2013 05:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YCnEVvd4YE5 for ; Tue, 26 Mar 2013 05:06:36 -0700 (PDT) Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by ietfa.amsl.com (Postfix) with ESMTP id A74EC21F88CC for ; Tue, 26 Mar 2013 05:06:27 -0700 (PDT) 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 rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r2QC5emT012951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 26 Mar 2013 08:06:27 -0400 (EDT) From: Henning Schulzrinne Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Mar 2013 08:06:26 -0400 Message-Id: To: ECRIT Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5 Subject: [Ecrit] FCC CSRIC III reports of possible interest 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 Mar 2013 12:06:36 -0000 h= ttp://www.fcc.gov/encyclopedia/communications-security-reliability-and-int= eroperability-council-iii=