From keith.drage@alcatel-lucent.com Wed Apr 3 07:07: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 35EFD21F8E7F for ; Wed, 3 Apr 2013 07:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 YcwSk2n35tD8 for ; Wed, 3 Apr 2013 07:07:44 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 42C0721F8E77 for ; Wed, 3 Apr 2013 07:07:44 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r33E7fU5006940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Apr 2013 09:07:42 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r33E7e8S023231 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Apr 2013 10:07:41 -0400 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 3 Apr 2013 10:07:40 -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; Wed, 3 Apr 2013 16:07:27 +0200 From: "DRAGE, Keith (Keith)" 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: AQHOKVycr4jhRbWHdU2X9iiLkXu/CZjElCAQ Date: Wed, 3 Apr 2013 14:07:27 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B01FCBC@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <20130325131520.25773.10212.idtracker@ietfa.amsl.com> <7A5CECA875B00640B202F1DBA1815D230E782985@vie196nt> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B01FCBCFR712WXCHMBA11zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 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: Wed, 03 Apr 2013 14:07:45 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B01FCBCFR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The way this is currently drafted does not in my view present the problem c= orrectly. It implies that the user wants an identical service, but that the endpoints= (PSAPs) are somehow themselves addressed by different organisations. If th= e user wants an identical service then the URNs should not need to be disti= nctive. Rather I think the problem is that we have a miscellaneous bunch of subserv= ices which we do not wish to explicitly identify. Within any specific area,= it is well known that some are associated with say a national organisation= , and some with a local organisation. Thus for the police emergency call ex= ample used before, it would be well known that murder required the national= police force, but burglary required the local police force. Therefore rath= er than identify a subtype for each crime, we use a label that represents t= he wider organisation or the more local organisation. Regards Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of D= an Mongrain Sent: 25 March 2013 13:28 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_949EF20990823C4C85C18D59AA11AD8B01FCBCFR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The way this is currently drafted does= not in my view present the problem correctly.

 

It implies that the user wants an iden= tical service, but that the endpoints (PSAPs) are somehow themselves addres= sed by different organisations. If the user wants an identical service then the URNs should not need to be= distinctive.

 

Rather I think the problem is that we = have a miscellaneous bunch of subservices which we do not wish to explicitl= y identify. Within any specific area, it is well known that some are associated with say a nation= al organisation, and some with a local organisation. Thus for the police em= ergency call example used before, it would be well known that murder requir= ed the national police force, but burglary required the local police force. Therefore rather than identify a= subtype for each crime, we use a label that represents the wider organisat= ion or the more local organisation.

 

Regards

 

Keith

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Beh= alf Of Dan Mongrain
Sent: 25 March 2013 13:28 To: ecrit@ietf.org
Subject: [Ecrit] Fwd: FW: Ne= w Version Notification for draft-mongrain-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 only because it could be used to specify a service t= hat is not government provided.  For example, I want to find a restaur= ant and I am looking for the neighbourhood pizza joint (not a national chai= n).  I would then specify Service URN "urn:service:restaurant.pizza.A5" (whatever the standard for res= taurant Service URN would look like).  On the other hand, if I want th= e 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 sinc= e this is not necessary for Public Safety.  The is the Interpol that w= ould fit the requirement for .international but they do not accept emergenc= y 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<= /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_949EF20990823C4C85C18D59AA11AD8B01FCBCFR712WXCHMBA11zeu_-- From Daniel.MONGRAIN@frequentis.com Wed Apr 3 07:57: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 8A6E921F8D28 for ; Wed, 3 Apr 2013 07:57:52 -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 Cjp312nDsvc7 for ; Wed, 3 Apr 2013 07:57:51 -0700 (PDT) Received: from mail1.frequentis.com (mail1.frequentis.com [195.20.158.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5833321F8E62 for ; Wed, 3 Apr 2013 07:57:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,402,1363129200"; d="scan'208,217";a="15890511" Received: from vie191nt.frequentis.frq ([172.16.1.191]) by mail1.frequentis.com with ESMTP; 03 Apr 2013 16:57:48 +0200 Received: from vie196nt.frequentis.frq ([172.16.1.196]) by vie191nt.frequentis.frq ([172.16.1.191]) with mapi id 14.02.0328.009; Wed, 3 Apr 2013 16:57:47 +0200 From: MONGRAIN Daniel To: "DRAGE, Keith (Keith)" , 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///ykACADh8+gIAAKpDw Date: Wed, 3 Apr 2013 14:57:47 +0000 Message-ID: <7A5CECA875B00640B202F1DBA1815D230E787A6B@vie196nt> References: <20130325131520.25773.10212.idtracker@ietfa.amsl.com> <7A5CECA875B00640B202F1DBA1815D230E782985@vie196nt> <949EF20990823C4C85C18D59AA11AD8B01FCBC@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B01FCBC@FR712WXCHMBA11.zeu.alcatel-lucent.com> 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_7A5CECA875B00640B202F1DBA1815D230E787A6Bvie196nt_" 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: Wed, 03 Apr 2013 14:57:52 -0000 --_000_7A5CECA875B00640B202F1DBA1815D230E787A6Bvie196nt_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is not necessarily true in the US. While 9-1-1 is the well-known numb= er to be used to report an emergency, lots of state police advertise that t= hey can be called to report the same emergency. They have advertised speed= dial numbers (for example, *CSP for Colorado State Police or *ISP for Idah= o State Police) that are to be used to call for assistance when on a mobile= phone (see http://www.kansashighwaypatrol.org/about/state_contact.html). = Even if it was to report a traffic emergency, different police forces handl= e the emergency dependant on where the accident occurs (state police on fre= eways, local police on city streets). Here in the city of Ottawa in Canada= , there are three police forces that handle traffic: city police on city st= reets, Ontario Provincial Police for the freeway and Royal Canadian Mounted= Police for federal parkways! Good thing is that the only number to reach = them all is 9-1-1, PSAP call taker transfers the call. But just on the oth= er side of the river in the province of Qu=E9bec, QPP advertises *4141 for = emergencies (in addition to 9-1-1 which goes to city police). I am sure that in some countries service demarcation is clear between polic= e forces, in the US the lines are quite blurry. But I am happy to modify t= he text of the draft to make it more clear. Thanx, 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: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] Sent: April-03-13 10:07 AM To: Dan Mongrain; ecrit@ietf.org Subject: RE: [Ecrit] Fwd: FW: New Version Notification for draft-mongrain-e= crit-service-coverage-scope-urn-00.txt The way this is currently drafted does not in my view present the problem c= orrectly. It implies that the user wants an identical service, but that the endpoints= (PSAPs) are somehow themselves addressed by different organisations. If th= e user wants an identical service then the URNs should not need to be disti= nctive. Rather I think the problem is that we have a miscellaneous bunch of subserv= ices which we do not wish to explicitly identify. Within any specific area,= it is well known that some are associated with say a national organisation= , and some with a local organisation. Thus for the police emergency call ex= ample used before, it would be well known that murder required the national= police force, but burglary required the local police force. Therefore rath= er than identify a subtype for each crime, we use a label that represents t= he wider organisation or the more local organisation. Regards Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Dan M= ongrain Sent: 25 March 2013 13:28 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_7A5CECA875B00640B202F1DBA1815D230E787A6Bvie196nt_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This is not necessarily t= rue in the US.  While 9-1-1 is the well-known number to be used to rep= ort an emergency, lots of state police advertise that they can be called to report the same emergency.  They have advertised speed d= ial numbers (for example, *CSP for Colorado State Police or *ISP for Idaho = State Police) that are to be used to call for assistance when on a mobile p= hone (see htt= p://www.kansashighwaypatrol.org/about/state_contact.html).  Even i= f it was to report a traffic emergency, different police forces handle the = emergency dependant on where the accident occurs (state police on freeways, local police on city streets).  Her= e in the city of Ottawa in Canada, there are three police forces that handl= e traffic: city police on city streets, Ontario Provincial Police for the f= reeway and Royal Canadian Mounted Police for federal parkways!  Good thing is that the only number to reach th= em all is 9-1-1, PSAP call taker transfers the call.  But just on the = other side of the river in the province of Qu=E9bec, QPP advertises *4141 f= or emergencies (in addition to 9-1-1 which goes to city police).

 <= /p>

I am sure that in some co= untries service demarcation is clear between police forces, in the US the l= ines are quite blurry.  But I am happy to modify the text of the draft to make it more clear.

 <= /p>

Thanx,<= /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: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-luce= nt.com]
Sent: April-03-13 10:07 AM
To: Dan Mongrain; ecrit@ietf.org
Subject: RE: [Ecrit] Fwd: FW: New Version Notification for draft-mon= grain-ecrit-service-coverage-scope-urn-00.txt

 

The way this is currently draf= ted does not in my view present the problem correctly.

 

It implies that the user wants= an identical service, but that the endpoints (PSAPs) are somehow themselve= s addressed by different organisations. If the user wants an identical service then the URNs should not need to be distinctive.=

 

Rather I think the problem is = that we have a miscellaneous bunch of subservices which we do not wish to e= xplicitly identify. Within any specific area, it is well known that some are associated with say a national organisation, and some = with a local organisation. Thus for the police emergency call example used = before, it would be well known that murder required the national police for= ce, but burglary required the local police force. Therefore rather than identify a subtype for each crime, we = use a label that represents the wider organisation or the more local organi= sation.

 

Regards

 

Keith

 

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

 

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_7A5CECA875B00640B202F1DBA1815D230E787A6Bvie196nt_-- From Daniel.MONGRAIN@frequentis.com Mon Apr 8 12:08: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 5C2D521F94AF for ; Mon, 8 Apr 2013 12:08:40 -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_50=0.001, 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 nAtO7oyup2uo for ; Mon, 8 Apr 2013 12:08:39 -0700 (PDT) Received: from mail1.frequentis.com (mail1.frequentis.com [195.20.158.50]) by ietfa.amsl.com (Postfix) with ESMTP id B397221F93E2 for ; Mon, 8 Apr 2013 12:08:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,432,1363129200"; d="scan'208,217";a="15949206" Received: from vie190nt.frequentis.frq ([172.16.1.190]) by mail1.frequentis.com with ESMTP; 08 Apr 2013 21:08:36 +0200 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, 8 Apr 2013 21:08:36 +0200 From: MONGRAIN Daniel To: "ecrit@ietf.org" Thread-Topic: Accept Service Coverage Scope draft as WG item Thread-Index: Ac40i1jvKJikgEMpSu22uDGJ306Vow== Date: Mon, 8 Apr 2013 19:08:35 +0000 Message-ID: <7A5CECA875B00640B202F1DBA1815D230E78B270@vie196nt> 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_7A5CECA875B00640B202F1DBA1815D230E78B270vie196nt_" MIME-Version: 1.0 Subject: [Ecrit] Accept Service Coverage Scope draft as WG item 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, 08 Apr 2013 19:08:42 -0000 --_000_7A5CECA875B00640B202F1DBA1815D230E78B270vie196nt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Chairs, It has been two weeks since I submitted http://datatracker.ietf.org/doc/dra= ft-mongrain-ecrit-service-coverage-scope-urn/. Is it premature to respectf= ully request that this be accepted as a WG item? Discussions on the mailin= g list prior to the publication of the draft seemed to indicate that there = was a need for this item. Thanx, 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. --_000_7A5CECA875B00640B202F1DBA1815D230E78B270vie196nt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Chairs,
 
It has been two weeks since I submitted http://datatracker.ietf.org/doc/draft-mongrain-ecrit-service-c= overage-scope-urn/.  Is it premature to respectfully request that this be accepted as a WG item?&nb= sp; Discussions on the mailing list prior to the publication of the draft s= eemed to indicate that there was a need for this item.
 
Thanx,
Dan
 
____________________________________________________
Dan Mongrain, eng.
Senior Systems Engineer, Public Safety
FREQUENT= IS 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@freq= uentis.com

Incorporated in the State of Maryland
EIN: 52-2178926 C= AGE Code: 1XKR9
____________________________________________________
Confidentiality Notice: This email message, including = any attachments, is for the sole use of the intended recipient(s) and conta= ins confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If = you are not the intended recipient, please contact the sender by reply emai= l and destroy all copies of the original message and associated attachments.
 
 
 
 --_000_7A5CECA875B00640B202F1DBA1815D230E78B270vie196nt_-- From ivo.sedlacek@ericsson.com Tue Apr 9 10:21: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 54DB521F93DD for ; Tue, 9 Apr 2013 10:21:17 -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 cf0eBul0IYky for ; Tue, 9 Apr 2013 10:21:16 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 082FB21F93DC for ; Tue, 9 Apr 2013 10:21:13 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-f4-51644e0841ab Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id DA.5A.19728.80E44615; Tue, 9 Apr 2013 19:21:13 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.208]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0318.004; Tue, 9 Apr 2013 19:21:12 +0200 From: Ivo Sedlacek To: "DRAGE, Keith (Keith)" , 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: AQHOKVycr4jhRbWHdU2X9iiLkXu/CZjElCAQgAmkmTA= Date: Tue, 9 Apr 2013 17:21:12 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061010B15B1@ESESSMB301.ericsson.se> References: <20130325131520.25773.10212.idtracker@ietfa.amsl.com> <7A5CECA875B00640B202F1DBA1815D230E782985@vie196nt> <949EF20990823C4C85C18D59AA11AD8B01FCBC@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B01FCBC@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B310790061010B15B1ESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+JvrS6nX0qgwZqlzBb357SwWDQuespq 8bTxLKMDs0frs72sHkuW/GTyeLFNIYA5issmJTUnsyy1SN8ugSujc+YvtoLGLsaKyQfPsjYw /qvoYuTkkBAwkdgx8R0rhC0mceHeejYQW0jgMKPEtV0sXYxcQPZiRomjD5ewgyTYBPQkJm45 wgqSEBFoZJTYv+0TWLewQLHEr4nnmboYOYASJRKPrgSDhEUErCS+znrNAmKzCKhIdN/cwgRi 8wp4S+xavpIJYkE/k8Sud9MYQRKcAtESl788YAaxGQVkJa7+6QWLMwuIS9x6Mp8J4lIBiSV7 zjND2KISLx//g/pASaJxyRNWiPp8iYnrW1kglglKnJz5hGUCo8gsJKNmISmbhaQMIq4jsWD3 JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2Jkz03MzEkvN9rECIyog1t+q+5gvHNO5BCjNAeLkjhv uOuFACGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M3saya+qDVZ3/J9VfZ7pV6KX4pqyVy+jt X7XHXVOEVap39XOt5a/5q6NXvTcyf+mMuGrOauOuS9brZcS4W/c+9li0zyHm4Pl6EcaOdoWG k5UrVZ9xmfXE/KmaG3+10LLmo+vtyIm8Vx7M7lK/EeX3k2G5nsy3GUmyou19ocsnhE3dXOsl 81yJpTgj0VCLuag4EQCnRh3bdgIAAA== 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: Tue, 09 Apr 2013 17:21:17 -0000 --_000_39B5E4D390E9BD4890E2B310790061010B15B1ESESSMB301ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The draft states: For some given location, there may be multiple providers that supply the same given service. However, in case of the Czech republic, the responsibility and the services= of municipal police and of the national police are similar but not complet= ely same. E.g. municipal police does not handle murder cases. 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 D= RAGE, Keith (Keith) Sent: 3. dubna 2013 7:07 To: Dan Mongrain; ecrit@ietf.org Subject: Re: [Ecrit] Fwd: FW: New Version Notification for draft-mongrain-e= crit-service-coverage-scope-urn-00.txt The way this is currently drafted does not in my view present the problem c= orrectly. It implies that the user wants an identical service, but that the endpoints= (PSAPs) are somehow themselves addressed by different organisations. If th= e user wants an identical service then the URNs should not need to be disti= nctive. Rather I think the problem is that we have a miscellaneous bunch of subserv= ices which we do not wish to explicitly identify. Within any specific area,= it is well known that some are associated with say a national organisation= , and some with a local organisation. Thus for the police emergency call ex= ample used before, it would be well known that murder required the national= police force, but burglary required the local police force. Therefore rath= er than identify a subtype for each crime, we use a label that represents t= he wider organisation or the more local organisation. Regards Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Dan Mongrain Sent: 25 March 2013 13:28 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_39B5E4D390E9BD4890E2B310790061010B15B1ESESSMB301ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The draft states:

  

   For some given location, there may be multiple providers =
that supply
   the same given service. 

 

However, in case of the Cze= ch republic, the responsibility and the services of municipal police and of= the national police are similar but not completely same. E.g. municipal police does not handle murder cases.

 

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 DRAGE, Keith (Keith)
Sent: 3. dubna 2013 7:07
To: Dan Mongrain; ecrit@ietf.org
Subject: Re: [Ecrit] Fwd: FW: New Version Notification for draft-mon= grain-ecrit-service-coverage-scope-urn-00.txt

 

The way this is= currently drafted does not in my view present the problem correctly.<= /o:p>

 

It implies that= the user wants an identical service, but that the endpoints (PSAPs) are so= mehow themselves addressed by different organisations. If the user wants an identical service then the URNs should not need to be di= stinctive.

 

Rather I think = the problem is that we have a miscellaneous bunch of subservices which we d= o not wish to explicitly identify. Within any specific area, it is well known that some are associated with say a national organisation= , and some with a local organisation. Thus for the police emergency call ex= ample used before, it would be well known that murder required the national= police force, but burglary required the local police force. Therefore rather than identify a subtype for each = crime, we use a label that represents the wider organisation or the more lo= cal organisation.

 

Regards

 

Keith

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Dan Mongrain
Sent: 25 March 2013 13:28
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 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 examp= le, I want to find a restaurant and I am looking for the neighbourhood pizz= a joint (not a national chain).  I would then specify Service URN &quo= t;urn:service:restaurant.pizza.A5" (whatever the standard for restaurant Service URN would look like).  On the other h= and, 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.&= nbsp; 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 di= d not include .A6 (street level) as I am not sure it makes sense, but again, willing to add as it costs nothing to do s= o.

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_39B5E4D390E9BD4890E2B310790061010B15B1ESESSMB301ericsso_-- From martin.thomson@gmail.com Tue Apr 9 10:30:31 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02BD621F93DC for ; Tue, 9 Apr 2013 10:30:31 -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 MzkyAom-76Jx for ; Tue, 9 Apr 2013 10:30:29 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 378A021F93E8 for ; Tue, 9 Apr 2013 10:30:28 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hm14so3938552wib.4 for ; Tue, 09 Apr 2013 10:30:26 -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=1nRlhOKPuxbmi1eL8/MsrgpGv9LJ8uRkc3uKPyEdsgM=; b=w6f+HqSCyvfZhpvZnMWAc6Aavn74l1i/4LK5QDaVc9UkG7oxVeFHxchxee+2xQS9+S kQRXfMWoI4ggrW6yAJtBOQYaxJM+EeY6IqGkCjMG4o1RKUZNm/c8qWE57IcAM0fZ8fsF NLzikGGIjeIvWC3hjBsTJ0S9wOwif1Q2zQoEj4ddt2HZb56m6p2IAvNGcXzuoAP6t+Ij gVbhh/9rQOCSDPRzbQDK72zVE2ostoDw8l5cBEqE21yZr70ZwuZVPArqGPTgPWFGjwuU iP6RoS7T+4f3oWCV690FSN4dQuocOE2wxQN+RyG/fHH0DthEzyixdtC7k6fMPN0eOus5 iqMw== MIME-Version: 1.0 X-Received: by 10.180.105.99 with SMTP id gl3mr21454323wib.22.1365528626893; Tue, 09 Apr 2013 10:30:26 -0700 (PDT) Received: by 10.194.41.35 with HTTP; Tue, 9 Apr 2013 10:30:26 -0700 (PDT) In-Reply-To: <39B5E4D390E9BD4890E2B310790061010B15B1@ESESSMB301.ericsson.se> References: <20130325131520.25773.10212.idtracker@ietfa.amsl.com> <7A5CECA875B00640B202F1DBA1815D230E782985@vie196nt> <949EF20990823C4C85C18D59AA11AD8B01FCBC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <39B5E4D390E9BD4890E2B310790061010B15B1@ESESSMB301.ericsson.se> Date: Tue, 9 Apr 2013 10:30:26 -0700 Message-ID: From: Martin Thomson To: Ivo Sedlacek Content-Type: text/plain; charset=UTF-8 Cc: "ecrit@ietf.org" 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: Tue, 09 Apr 2013 17:30:31 -0000 On 9 April 2013 10:21, Ivo Sedlacek wrote: > However, in case of the Czech republic, the responsibility and the services > of municipal police and of the national police are similar but not > completely same. E.g. municipal police does not handle murder cases. That interesting, but is it relevant? e.g., would it be a problem if I contacted municipal police to report a murder? Keep in mind that we are talking about emergency contact, not debating the finer points of jurisdiction. If it is acceptable (and manageable) for murders to be reported to the local municipality, then a new URN might be unnecessary. If it is relevant, as is the case with matters of jurisdiction in some parts of the US (see example of local police v. highway patrol on a highway overpass), then it behooves us to provide a way for the distinction to be made by the person reporting the emergency. A new URN might be needed to allow for the distinction to be made. (That has usability issues, but that's not a problem that can be solved with engineering.) From Daniel.MONGRAIN@frequentis.com Tue Apr 9 10:51: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 7C96921F95EF for ; Tue, 9 Apr 2013 10:51:06 -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 dPCpO6hSO4JF for ; Tue, 9 Apr 2013 10:50:59 -0700 (PDT) Received: from mail1.frequentis.com (mail1.frequentis.com [195.20.158.50]) by ietfa.amsl.com (Postfix) with ESMTP id A8DC521F95E2 for ; Tue, 9 Apr 2013 10:50:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,441,1363129200"; d="scan'208,217";a="13356" Received: from vie191nt.frequentis.frq ([172.16.1.191]) by mail1.frequentis.com with ESMTP; 09 Apr 2013 19:50:58 +0200 Received: from vie196nt.frequentis.frq ([172.16.1.196]) by vie191nt.frequentis.frq ([172.16.1.191]) with mapi id 14.02.0328.009; Tue, 9 Apr 2013 19:50:57 +0200 From: MONGRAIN Daniel To: Ivo Sedlacek , "DRAGE, Keith (Keith)" , 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: AQHONUamcqdbPyP9wEOCvG68ORkxsZjOKH4w Date: Tue, 9 Apr 2013 17:50:56 +0000 Message-ID: <7A5CECA875B00640B202F1DBA1815D230E78E9EE@vie196nt> References: <20130325131520.25773.10212.idtracker@ietfa.amsl.com> <7A5CECA875B00640B202F1DBA1815D230E782985@vie196nt> <949EF20990823C4C85C18D59AA11AD8B01FCBC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <39B5E4D390E9BD4890E2B310790061010B15B1@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B310790061010B15B1@ESESSMB301.ericsson.se> 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_7A5CECA875B00640B202F1DBA1815D230E78E9EEvie196nt_" 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: Tue, 09 Apr 2013 17:51:07 -0000 --_000_7A5CECA875B00640B202F1DBA1815D230E78E9EEvie196nt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the case of reporting a murder in the Czech republic, we would create a = service URN of urn:service:sos.police.murder (only if such calls are consid= ered emergency calls) as the subservice distinction is important. Routing = of the call would then point to the national police. The Service Coverage = Scope draft addresses the case where there are two separate service provide= rs that provide the same service. With the wording "some given location" and "there may be" I am specifying t= hat the application is not universal. Usage of Service Coverage Scope is o= nly acceptable in areas where such a case exists. Thanx, 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: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] Sent: April-09-13 1:21 PM To: DRAGE, Keith (Keith); Dan Mongrain; ecrit@ietf.org Subject: RE: [Ecrit] Fwd: FW: New Version Notification for draft-mongrain-e= crit-service-coverage-scope-urn-00.txt The draft states: For some given location, there may be multiple providers that supply the same given service. However, in case of the Czech republic, the responsibility and the services= of municipal police and of the national police are similar but not complet= ely same. E.g. municipal police does not handle murder cases. Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of DRAGE= , Keith (Keith) Sent: 3. dubna 2013 7:07 To: Dan Mongrain; ecrit@ietf.org Subject: Re: [Ecrit] Fwd: FW: New Version Notification for draft-mongrain-e= crit-service-coverage-scope-urn-00.txt The way this is currently drafted does not in my view present the problem c= orrectly. It implies that the user wants an identical service, but that the endpoints= (PSAPs) are somehow themselves addressed by different organisations. If th= e user wants an identical service then the URNs should not need to be disti= nctive. Rather I think the problem is that we have a miscellaneous bunch of subserv= ices which we do not wish to explicitly identify. Within any specific area,= it is well known that some are associated with say a national organisation= , and some with a local organisation. Thus for the police emergency call ex= ample used before, it would be well known that murder required the national= police force, but burglary required the local police force. Therefore rath= er than identify a subtype for each crime, we use a label that represents t= he wider organisation or the more local organisation. Regards Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Dan Mongrain Sent: 25 March 2013 13:28 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_7A5CECA875B00640B202F1DBA1815D230E78E9EEvie196nt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the case of reporting = a murder in the Czech republic, we would create a service URN of urn:servic= e:sos.police.murder (only if such calls are considered emergency calls) as the subservice distinction is important.  Routing of the ca= ll would then point to the national police.  The Service Coverage Scop= e draft addresses the case where there are two separate service providers t= hat provide the same service.

 <= /p>

With the wording “s= ome given location” and “there may be” I am specifying th= at the application is not universal.  Usage of Service Coverage Scope = is only acceptable in areas where such a case exists.

 <= /p>

Thanx,<= /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: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com]
Sent: April-09-13 1:21 PM
To: DRAGE, Keith (Keith); Dan Mongrain; ecrit@ietf.org
Subject: RE: [Ecrit] Fwd: FW: New Version Notification for draft-mon= grain-ecrit-service-coverage-scope-urn-00.txt

 

The draft st= ates:

 <= /o:p>

   For some given location, there may b=
e multiple providers that supply
   the same given service.  <=
/o:p>

 <= /o:p>

However, in = case of the Czech republic, the responsibility and the services of municipa= l police and of the national police are similar but not completely same. E.g. municipal police does not handle murder cases.

 <= /o:p>

Kind regards=

 <= /o:p>

Ivo Sedlacek=

 <= /o:p>

This Communic= ation is Confidential. We only send and receive email on the basis of the t= erms set out at www.ericsson.com/email_disclaimer

 

The way this is currently draf= ted does not in my view present the problem correctly.

 

It implies that the user wants= an identical service, but that the endpoints (PSAPs) are somehow themselve= s addressed by different organisations. If the user wants an identical service then the URNs should not need to be distinctive.=

 

Rather I think the problem is = that we have a miscellaneous bunch of subservices which we do not wish to e= xplicitly identify. Within any specific area, it is well known that some are associated with say a national organisation, and some = with a local organisation. Thus for the police emergency call example used = before, it would be well known that murder required the national police for= ce, but burglary required the local police force. Therefore rather than identify a subtype for each crime, we = use a label that represents the wider organisation or the more local organi= sation.

 

Regards

 

Keith

 

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

 

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_7A5CECA875B00640B202F1DBA1815D230E78E9EEvie196nt_-- From pkyzivat@alum.mit.edu Tue Apr 9 11:14: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 A12E321F9322 for ; Tue, 9 Apr 2013 11:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[AWL=1.299, 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 rx496hgwostT for ; Tue, 9 Apr 2013 11:14:03 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7FC21F91D9 for ; Tue, 9 Apr 2013 11:14:03 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta05.westchester.pa.mail.comcast.net with comcast id Mmwf1l0041wpRvQ55uE2hD; Tue, 09 Apr 2013 18:14:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id MuE21l00Q3ZTu2S3euE2GT; Tue, 09 Apr 2013 18:14:02 +0000 Message-ID: <51645A66.80007@alum.mit.edu> Date: Wed, 10 Apr 2013 02:13:58 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: ecrit@ietf.org References: <20130325131520.25773.10212.idtracker@ietfa.amsl.com> <7A5CECA875B00640B202F1DBA1815D230E782985@vie196nt> <949EF20990823C4C85C18D59AA11AD8B01FCBC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <39B5E4D390E9BD4890E2B310790061010B15B1@ESESSMB301.ericsson.se> <7A5CECA875B00640B202F1DBA1815D230E78E9EE@vie196nt> In-Reply-To: <7A5CECA875B00640B202F1DBA1815D230E78E9EE@vie196nt> 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=1365531242; bh=g47smUuhH9dRe492qRCJC+M5ccqjo10EDoOuOc+mjnM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=AmXl/cmjc46a0bQws99lbX2Nal7rQa1uYFmX8fIpB9gab+c7kmLRFh44FZfJNxjDm z0JNWn0yilKwP5v73Z8s1+ahGOME25xGb5Uw60yV1l1HARuKZ4vCPdw2XHTKAJsnea uMolwX9zPOq4yopwoHfT50WtqC02GErp49sUfc9zgrNpi550zZHI1aW3Fumt5X52lM jd2UXI6yFMSjE2sfYrGmVDk+o7jgAZP+byfL4QrUMKuvgcMdfPHtcAQ0Ld6eupZlFB EdcA8AuJGGzG5oh6l9oM/N4nEIgwdw0t4MlEXnMinSq6lPnXvZ/DNeAEzIhwa4wm6n NDNNG0zS3Ny7Q== 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: Tue, 09 Apr 2013 18:14:05 -0000 As a bystander, I'm curious what UI is anticipated that makes use of the large number of these different service urns that are being proposed? If I'm a native in the Czech republic, do I have a special number that I call to report murders? (A number that is then translated by the phone to the urn.) If I happen to be visiting the Czech republic from the US and I see a murder, how do *I* know how to report it? Thanks, Paul On 4/10/13 1:50 AM, MONGRAIN Daniel wrote: > In the case of reporting a murder in the Czech republic, we would create > a service URN of urn:service:sos.police.murder (only if such calls are > considered emergency calls) as the subservice distinction is important. > Routing of the call would then point to the national police. The > Service Coverage Scope draft addresses the case where there are two > separate service providers that provide the same service. > > With the wording “some given location” and “there may be” I am > specifying that the application is not universal. Usage of Service > Coverage Scope is only acceptable in areas where such a case exists. > > Thanx, > > 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 > Webwww.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 for the sole use of the intended recipient(s) and contains > confidential and privileged information. Any unauthorized review, use, > disclosure or distribution is prohibited. If you are not the intended > recipient, please contact the sender by reply email and destroy all > copies of the originalmessage and associated attachments. > > *From:*Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] > *Sent:* April-09-13 1:21 PM > *To:* DRAGE, Keith (Keith); Dan Mongrain; ecrit@ietf.org > *Subject:* RE: [Ecrit] Fwd: FW: New Version Notification for > draft-mongrain-ecrit-service-coverage-scope-urn-00.txt > > The draft states: > > For some given location, there may be multiple providers that supply > > the same given service. > > However, in case of the Czech republic, the responsibility and the > services of municipal police and of the national police are similar but > not completely same. E.g. municipal police does not handle murder cases. > > 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 *DRAGE, Keith (Keith) > *Sent:* 3. dubna 2013 7:07 > *To:* Dan Mongrain; ecrit@ietf.org > *Subject:* Re: [Ecrit] Fwd: FW: New Version Notification for > draft-mongrain-ecrit-service-coverage-scope-urn-00.txt > > The way this is currently drafted does not in my view present the > problem correctly. > > It implies that the user wants an identical service, but that the > endpoints (PSAPs) are somehow themselves addressed by different > organisations. If the user wants an identical service then the URNs > should not need to be distinctive. > > Rather I think the problem is that we have a miscellaneous bunch of > subservices which we do not wish to explicitly identify. Within any > specific area, it is well known that some are associated with say a > national organisation, and some with a local organisation. Thus for the > police emergency call example used before, it would be well known that > murder required the national police force, but burglary required the > local police force. Therefore rather than identify a subtype for each > crime, we use a label that represents the wider organisation or the more > local organisation. > > Regards > > Keith > > ------------------------------------------------------------------------ > > *From:*ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] *On Behalf Of *Dan Mongrain > *Sent:* 25 March 2013 13:28 > *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 > 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 > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From br@brianrosen.net Tue Apr 9 11:30: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 16C1D21F93DA for ; Tue, 9 Apr 2013 11:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[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 qayJev7aRjGF for ; Tue, 9 Apr 2013 11:30:23 -0700 (PDT) Received: from mm2.idig.net (raphotoclub.ca [70.33.247.99]) by ietfa.amsl.com (Postfix) with ESMTP id 8A03C21F9494 for ; Tue, 9 Apr 2013 11:30:18 -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=ndDOWP+Dt5IOBRKtrVeU+9atcPbx25MaEfBXMz4hlJo=; b=RoZdaQEDqno44Z3wDnKjYnYtRstNvfWiOSJI3CF4mF4Y2K0NFKY06Tv+E6BkWA4wGLHDi2jDeomuSuMFfTJwxGIqkechJ7nID3ktTZuY2XAknEssNHRobBbggqKwsbnRBqN0QcOSDonmmCCG3wncS7YAFD46KzUD1KPG13WvRJI=; Received: from neustargw.va.neustar.com ([209.173.53.233]:34018 helo=[192.168.133.235]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UPdJB-0002gC-Ff; Tue, 09 Apr 2013 14:30:17 -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: <51645A66.80007@alum.mit.edu> Date: Tue, 9 Apr 2013 14:30:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6C99D10F-DEC1-4B07-AE40-44A723E14D9F@brianrosen.net> References: <20130325131520.25773.10212.idtracker@ietfa.amsl.com> <7A5CECA875B00640B202F1DBA1815D230E782985@vie196nt> <949EF20990823C4C85C18D59AA11AD8B01FCBC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <39B5E4D390E9BD4890E2B310790061010B15B1@ESESSMB301.ericsson.se> <7A5CECA875B00640B202F1DBA1815D230E78E9EE@vie196nt> <51645A66.80007@alum.mit.edu> To: Paul Kyzivat 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] 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: Tue, 09 Apr 2013 18:30:26 -0000 Let's use a case more familiar to you: Have you been on an highway that has a sign that says "State Police patrol this highway, call *77" "*77" is the dial string. The service boundary is the road. It leads = to a specific responder agency, distinct from local police. Brian On Apr 9, 2013, at 2:13 PM, Paul Kyzivat wrote: > As a bystander, I'm curious what UI is anticipated that makes use of = the large number of these different service urns that are being = proposed? >=20 > If I'm a native in the Czech republic, do I have a special number that = I call to report murders? (A number that is then translated by the phone = to the urn.) >=20 > If I happen to be visiting the Czech republic from the US and I see a = murder, how do *I* know how to report it? >=20 > Thanks, > Paul >=20 > On 4/10/13 1:50 AM, MONGRAIN Daniel wrote: >> In the case of reporting a murder in the Czech republic, we would = create >> a service URN of urn:service:sos.police.murder (only if such calls = are >> considered emergency calls) as the subservice distinction is = important. >> Routing of the call would then point to the national police. The >> Service Coverage Scope draft addresses the case where there are two >> separate service providers that provide the same service. >>=20 >> With the wording =93some given location=94 and =93there may be=94 I = am >> specifying that the application is not universal. Usage of Service >> Coverage Scope is only acceptable in areas where such a case exists. >>=20 >> Thanx, >>=20 >> Dan >>=20 >> ____________________________________________________ >> *Dan Mongrain, eng.** >> *Senior Systems Engineer, Public Safety >> FREQUENTIS USA Inc. >>=20 >> 9017 Red Branch Road, Suite 102 Columbia Maryland 21045 >> Phone +1-301-657-8001 >> Mobile +1-819-744-0491 >> Fax +1-301-657-8002 >> Webwww.frequentis.com/usa >> E-Mail dan.mongrain@frequentis.com = >>=20 >> Incorporated in the State of Maryland >>=20 >> EIN: 52-2178926 CAGE Code: 1XKR9 >> ____________________________________________________ >>=20 >> *Confidentiality Notice:*This email message, including any = attachments, >> is for the sole use of the intended recipient(s) and contains >> confidential and privileged information. Any unauthorized review, = use, >> disclosure or distribution is prohibited. If you are not the intended >> recipient, please contact the sender by reply email and destroy all >> copies of the originalmessage and associated attachments. >>=20 >> *From:*Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] >> *Sent:* April-09-13 1:21 PM >> *To:* DRAGE, Keith (Keith); Dan Mongrain; ecrit@ietf.org >> *Subject:* RE: [Ecrit] Fwd: FW: New Version Notification for >> draft-mongrain-ecrit-service-coverage-scope-urn-00.txt >>=20 >> The draft states: >>=20 >> For some given location, there may be multiple providers that = supply >>=20 >> the same given service. >>=20 >> However, in case of the Czech republic, the responsibility and the >> services of municipal police and of the national police are similar = but >> not completely same. E.g. municipal police does not handle murder = cases. >>=20 >> Kind regards >>=20 >> Ivo Sedlacek >>=20 >> This Communication is Confidential. We only send and receive email on >> the basis of the terms set out at www.ericsson.com/email_disclaimer >> >>=20 >> *From:*ecrit-bounces@ietf.org >> [mailto:ecrit-bounces@ietf.org] = >> *On Behalf Of *DRAGE, Keith (Keith) >> *Sent:* 3. dubna 2013 7:07 >> *To:* Dan Mongrain; ecrit@ietf.org >> *Subject:* Re: [Ecrit] Fwd: FW: New Version Notification for >> draft-mongrain-ecrit-service-coverage-scope-urn-00.txt >>=20 >> The way this is currently drafted does not in my view present the >> problem correctly. >>=20 >> It implies that the user wants an identical service, but that the >> endpoints (PSAPs) are somehow themselves addressed by different >> organisations. If the user wants an identical service then the URNs >> should not need to be distinctive. >>=20 >> Rather I think the problem is that we have a miscellaneous bunch of >> subservices which we do not wish to explicitly identify. Within any >> specific area, it is well known that some are associated with say a >> national organisation, and some with a local organisation. Thus for = the >> police emergency call example used before, it would be well known = that >> murder required the national police force, but burglary required the >> local police force. Therefore rather than identify a subtype for each >> crime, we use a label that represents the wider organisation or the = more >> local organisation. >>=20 >> Regards >>=20 >> Keith >>=20 >> = ------------------------------------------------------------------------ >>=20 >> *From:*ecrit-bounces@ietf.org >> [mailto:ecrit-bounces@ietf.org] *On Behalf Of *Dan Mongrain >> *Sent:* 25 March 2013 13:28 >> *To:* ecrit@ietf.org >> *Subject:* [Ecrit] Fwd: FW: New Version Notification for >> draft-mongrain-ecrit-service-coverage-scope-urn-00.txt >>=20 >> 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. >>=20 >> This is my first Internet draft so please be indulgent. >>=20 >> Thanx, >> Dan >>=20 >> -----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 >>=20 >>=20 >> 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. >>=20 >> 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-scop= e-urn >> Htmlized: >> = http://tools.ietf.org/html/draft-mongrain-ecrit-service-coverage-scope-urn= -00 >>=20 >>=20 >> 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. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From ivo.sedlacek@ericsson.com Tue Apr 9 11:37:34 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E21621F93DF for ; Tue, 9 Apr 2013 11:37:34 -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 vHj8M5iV5Auf for ; Tue, 9 Apr 2013 11:37:33 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 83F0321F93E8 for ; Tue, 9 Apr 2013 11:37:32 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-22-51645feb2a6c Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E5.D2.10459.BEF54615; Tue, 9 Apr 2013 20:37:31 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.208]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0318.004; Tue, 9 Apr 2013 20:37:30 +0200 From: Ivo Sedlacek To: Martin Thomson Thread-Topic: [Ecrit] Fwd: FW: New Version Notification for draft-mongrain-ecrit-service-coverage-scope-urn-00.txt Thread-Index: AQHONUfv1Jre+HPo606DVwoxQC+sgJjONJSQ Date: Tue, 9 Apr 2013 18:37:30 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061010B1638@ESESSMB301.ericsson.se> References: <20130325131520.25773.10212.idtracker@ietfa.amsl.com> <7A5CECA875B00640B202F1DBA1815D230E782985@vie196nt> <949EF20990823C4C85C18D59AA11AD8B01FCBC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <39B5E4D390E9BD4890E2B310790061010B15B1@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.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvre7r+JRAg3WvJSzuz2lhsWhc9JTV 4mnjWUaLa2f+MTqweLQ+28vqsXPWXXaPJUt+Mnm82KYQwBLFZZOSmpNZllqkb5fAlfFt2wSW gjssFRNXdbE3MJ5h6WLk5JAQMJGYv7KZGcIWk7hwbz1bFyMXh5DAYUaJt1s2MYIkhAQWM0o0 7dEGsdkE9CQmbjnCCmKLCOhKLDr7gB2kgVmgkVFiaesjsAZhgWKJ7svLWCCKSiSevu1jhrCN JBrXPGICsVkEVCTeLdkONohXwFvi0742RojNM5glTnz7wgaS4BQIlJjxZinYIEYBWYmrf3rB FjALiEvcejKfCeJsAYkle85DvSAq8fLxP1YIW0micckTIJsDqF5TYv0ufYhWRYkp3Q/ZIfYK Spyc+YRlAqPYLCRTZyF0zELSMQtJxwJGllWM7LmJmTnp5YabGIGRdHDLb90djKfOiRxilOZg URLnDXO9ECAkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMfealZF9Q2WGtSv/3dSq2VlTEzUd Czkiy2wuCKZdEQq79EB/xjuZMKXSwE+m96uTfix5UccQlGtaf6aZsfOTywmj5Sr3NspHLD33 8sojbivPbzsbz89wYDlb322qkP+T67H0X67SqX4fnPY0tjPN/W1wf65dG8dZ/+k3WWTOT69s fSdlmB2ixFKckWioxVxUnAgATEo/r3ICAAA= Cc: "ecrit@ietf.org" 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: Tue, 09 Apr 2013 18:37:34 -0000 PiBUaGF0IGludGVyZXN0aW5nLCBidXQgaXMgaXQgcmVsZXZhbnQ/ICBlLmcuLCB3b3VsZCBpdCBi ZSBhIHByb2JsZW0gaWYgSSBjb250YWN0ZWQgbXVuaWNpcGFsIHBvbGljZSB0byByZXBvcnQgYSBt dXJkZXI/DQoNCkluIEN6ZWNoIHJlcHVibGljLCBtdW5pY2lwYWwgcG9saWNlIHdpbGwgbmVlZCB0 byB0cmFuc2ZlciB0aGUgbXVyZGVyIHJlcG9ydCB0byB0aGUgbmF0aW9uYWwgcG9saWNlLiBJdCB3 aWxsIHJlc3VsdCBpbiBkZWxheSBvZiBhbnkgYWN0aW9uLg0KDQpLaW5kIHJlZ2FyZHMNCg0KSXZv IFNlZGxhY2VrDQoNClRoaXMgQ29tbXVuaWNhdGlvbiBpcyBDb25maWRlbnRpYWwuIFdlIG9ubHkg c2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQg YXQgd3d3LmVyaWNzc29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyIA0KDQo= From Daniel.MONGRAIN@frequentis.com Tue Apr 9 11:47: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 47ECE21F9355 for ; Tue, 9 Apr 2013 11:47:54 -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.001, 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 X4gKxy5e9X9u for ; Tue, 9 Apr 2013 11:47:53 -0700 (PDT) Received: from mail1.frequentis.com (mail1.frequentis.com [195.20.158.50]) by ietfa.amsl.com (Postfix) with ESMTP id B978D21F930C for ; Tue, 9 Apr 2013 11:47:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,441,1363129200"; d="scan'208";a="13869" Received: from vie190nt.frequentis.frq ([172.16.1.190]) by mail1.frequentis.com with ESMTP; 09 Apr 2013 20:47:45 +0200 Received: from vie196nt.frequentis.frq ([172.16.1.196]) by vie190nt.frequentis.frq ([172.16.1.190]) with mapi id 14.02.0328.009; Tue, 9 Apr 2013 20:47:44 +0200 From: MONGRAIN Daniel To: Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] Fwd: FW: New Version Notification for draft-mongrain-ecrit-service-coverage-scope-urn-00.txt Thread-Index: AQHONU4JTbIz575C8kCBuITQ4wacsZjOM4HQ Date: Tue, 9 Apr 2013 18:47:43 +0000 Message-ID: <7A5CECA875B00640B202F1DBA1815D230E78EAAB@vie196nt> References: <20130325131520.25773.10212.idtracker@ietfa.amsl.com> <7A5CECA875B00640B202F1DBA1815D230E782985@vie196nt> <949EF20990823C4C85C18D59AA11AD8B01FCBC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <39B5E4D390E9BD4890E2B310790061010B15B1@ESESSMB301.ericsson.se> <7A5CECA875B00640B202F1DBA1815D230E78E9EE@vie196nt> <51645A66.80007@alum.mit.edu> In-Reply-To: <51645A66.80007@alum.mit.edu> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: Tue, 09 Apr 2013 18:47:54 -0000 When a device enters an area, it can always interrogate the LoST service wi= th a listServicesByLocation request which will return the list of services = available for the given location. Since not all services are available at = all locations, then it can be expected that the list of services received s= hould be very manageable. The UI of the device could have an emergency cal= l page/menu/whatever which displays the available emergency services for th= e location of the device. The user would then pick the most appropriate se= rvice for the circumstances. The list of possible services returned is finite as service URN must be doc= umented in either an RFC or IANA registry, including a description of the s= ervice. The device's manufacturer could have pre-provisioned the device wi= th user-friendly icons and descriptions for all of the different service UR= Ns that could be returned so the user would see not service URNs but a user= -friendly interface (if there is a user-friendly icon for murder, that is).= As the device enters different jurisdictions, the device lists of emergen= cy services changes to reflect the services available in that area. Another way can be that the device is statically configured to show some/al= l emergency services. The user selects a service and the device makes a fi= ndService request to the LoST service. In the case that service is not ava= ilable for the given location, the LoST service can always return another s= ervice that should do the same. Maybe more overwhelming to the user to sh= ow all services but may still be usable. But definitely the first mechanis= m is preferable. Thanx, Dan ____________________________________________________ Dan Mongrain, eng. Senior Systems Engineer, Public Safety FREQUENTIS USA Inc. 9017 Red Branch Road, Suite 102 Columbia Maryland 21045 Phone=A0=A0 +1-301-657-8001 Mobile =A0=A0+1-819-744-0491 Fax=A0=A0=A0=A0=A0=A0=A0+1-301-657-8002 Web=A0=A0=A0=A0=A0 www.frequentis.com/usa E-Mail=A0=A0=A0 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. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of P= aul Kyzivat Sent: April-09-13 2:14 PM To: ecrit@ietf.org Subject: Re: [Ecrit] Fwd: FW: New Version Notification for draft-mongrain-e= crit-service-coverage-scope-urn-00.txt As a bystander, I'm curious what UI is anticipated that makes use of the=20 large number of these different service urns that are being proposed? If I'm a native in the Czech republic, do I have a special number that I=20 call to report murders? (A number that is then translated by the phone=20 to the urn.) If I happen to be visiting the Czech republic from the US and I see a=20 murder, how do *I* know how to report it? Thanks, Paul On 4/10/13 1:50 AM, MONGRAIN Daniel wrote: > In the case of reporting a murder in the Czech republic, we would create > a service URN of urn:service:sos.police.murder (only if such calls are > considered emergency calls) as the subservice distinction is important. > Routing of the call would then point to the national police. The > Service Coverage Scope draft addresses the case where there are two > separate service providers that provide the same service. > > With the wording "some given location" and "there may be" I am > specifying that the application is not universal. Usage of Service > Coverage Scope is only acceptable in areas where such a case exists. > > Thanx, > > 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 > Webwww.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 for the sole use of the intended recipient(s) and contains > confidential and privileged information. Any unauthorized review, use, > disclosure or distribution is prohibited. If you are not the intended > recipient, please contact the sender by reply email and destroy all > copies of the originalmessage and associated attachments. > > *From:*Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] > *Sent:* April-09-13 1:21 PM > *To:* DRAGE, Keith (Keith); Dan Mongrain; ecrit@ietf.org > *Subject:* RE: [Ecrit] Fwd: FW: New Version Notification for > draft-mongrain-ecrit-service-coverage-scope-urn-00.txt > > The draft states: > > For some given location, there may be multiple providers that supply > > the same given service. > > However, in case of the Czech republic, the responsibility and the > services of municipal police and of the national police are similar but > not completely same. E.g. municipal police does not handle murder cases. > > 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 *DRAGE, Keith (Keith) > *Sent:* 3. dubna 2013 7:07 > *To:* Dan Mongrain; ecrit@ietf.org > *Subject:* Re: [Ecrit] Fwd: FW: New Version Notification for > draft-mongrain-ecrit-service-coverage-scope-urn-00.txt > > The way this is currently drafted does not in my view present the > problem correctly. > > It implies that the user wants an identical service, but that the > endpoints (PSAPs) are somehow themselves addressed by different > organisations. If the user wants an identical service then the URNs > should not need to be distinctive. > > Rather I think the problem is that we have a miscellaneous bunch of > subservices which we do not wish to explicitly identify. Within any > specific area, it is well known that some are associated with say a > national organisation, and some with a local organisation. Thus for the > police emergency call example used before, it would be well known that > murder required the national police force, but burglary required the > local police force. Therefore rather than identify a subtype for each > crime, we use a label that represents the wider organisation or the more > local organisation. > > Regards > > Keith > > ------------------------------------------------------------------------ > > *From:*ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] *On Behalf Of *Dan Mongrain > *Sent:* 25 March 2013 13:28 > *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 > 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-sco= pe-urn > Htmlized: > http://tools.ietf.org/html/draft-mongrain-ecrit-service-coverage-scope-ur= n-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 > > > > _______________________________________________ > 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 ivo.sedlacek@ericsson.com Tue Apr 9 12: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 BBD3E21F98A6 for ; Tue, 9 Apr 2013 12:08:08 -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 FrzjAsh-c6Uw for ; Tue, 9 Apr 2013 12:08:08 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8A28121F989B for ; Tue, 9 Apr 2013 12:08:07 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-a2-516467164705 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 43.C5.10459.61764615; Tue, 9 Apr 2013 21:08:06 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.208]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0318.004; Tue, 9 Apr 2013 21:08:06 +0200 From: Ivo Sedlacek To: Paul Kyzivat , "ecrit@ietf.org" Thread-Topic: [Ecrit] Fwd: FW: New Version Notification for draft-mongrain-ecrit-service-coverage-scope-urn-00.txt Thread-Index: AQHONU4LT7dmsl8z9UuGC8bgBkmT5ZjOOEDQ Date: Tue, 9 Apr 2013 19:08:06 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061010B1683@ESESSMB301.ericsson.se> References: <20130325131520.25773.10212.idtracker@ietfa.amsl.com> <7A5CECA875B00640B202F1DBA1815D230E782985@vie196nt> <949EF20990823C4C85C18D59AA11AD8B01FCBC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <39B5E4D390E9BD4890E2B310790061010B15B1@ESESSMB301.ericsson.se> <7A5CECA875B00640B202F1DBA1815D230E78E9EE@vie196nt> <51645A66.80007@alum.mit.edu> In-Reply-To: <51645A66.80007@alum.mit.edu> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+Jvra5YekqgwfQODYvGRU9ZLVZsOMDq wOTx9/0HJo8lS34yBTBFcdmkpOZklqUW6dslcGVceHyCpeAob8Wa/hOMDYxPuLoYOTkkBEwk drx+yQxhi0lcuLeerYuRi0NI4DCjxO/pfVDOYkaJjg/3mECq2AT0JCZuOcIKYosIeEv8+f0N qIiDQ1igWGLlkkiIcInEmkMTGCFsI4mDX9rZQGwWARWJX68Xs4DYvECtDTebmSDmL2eWePxx C9h8TgEtic0PH4I1MArISlz90ws2iFlAXOLWk/lMEJcKSCzZcx7qalGJl4//sULYShKNS56w QtTrSCzY/YkNwtaWWLbwNTPEYkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFSN7bmJmTnq5 4SZGYDQc3PJbdwfjqXMihxilOViUxHnDXC8ECAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDs 2u/+bcrlbxtOsRc0LA72uPP6yvvTR17u8C3YnOCW8orPX+1CGMeqNaEzVri5PTTSm263NPjv jD2WabstWTt+FSX46Vv4//PdnrhRU1Wny7i38NDfZMUtYv8qz/cHutcLL1d21OPidVBir/jw 7sN27gNZP5lD75y1Cfb7aBHPc8lFK/BigqYSS3FGoqEWc1FxIgC8jm4dVAIAAA== 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: Tue, 09 Apr 2013 19:08:08 -0000 Hello, > As a bystander, I'm curious what UI is anticipated that makes use of the = large number of these different service urns that are being proposed? Normally, the UE selects the emergency service by dialling a number and the= dialled digits get translated to emergency URN without human involvement. = There may be other UI implementation thought. > If I'm a native in the Czech republic, do I have a special number that I = call to report murders? (A number that is then translated by the phone to t= he urn.) There is a number for the national police =3D 158. There is a number for the municipal police =3D 156. > If I happen to be visiting the Czech republic from the US and I see a mur= der, how do *I* know how to report it? Assuming a 3GPP compliant mobile phone is used then the roamed-to users can= use: 1) globally valid numbers 112 and 911 -> this translates to urn:service:sos= . This would be delivered to default PSAP. 2) any number for police emergency service which is configured in the (U)S= IM card (whatever valid in your own country) -> translates to urn:service:s= os.police. In Czech republic, this would be delivered to PSAP of national p= olice. 3) any number for police emergency service which is provided by the Czech = republic provider serving the UE (=3D 158) -> - translates to urn:service:s= os.police. In Czech republic, this would be delivered to PSAP of national p= olice. 4) 156 -> this is translated in network to the URN registered by IANA for t= he 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 From pkyzivat@alum.mit.edu Tue Apr 9 12:11:38 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F09B21F98B5 for ; Tue, 9 Apr 2013 12:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.004 X-Spam-Level: X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[AWL=0.433, 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 IMvAqzXmRPxA for ; Tue, 9 Apr 2013 12:11:37 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1BF21F9613 for ; Tue, 9 Apr 2013 12:11:37 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta09.westchester.pa.mail.comcast.net with comcast id MoB41l0061c6gX859vBcKX; Tue, 09 Apr 2013 19:11:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id MvBc1l00Y3ZTu2S3jvBce1; Tue, 09 Apr 2013 19:11:36 +0000 Message-ID: <516467E8.5040807@alum.mit.edu> Date: Wed, 10 Apr 2013 03:11:36 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Brian Rosen References: <20130325131520.25773.10212.idtracker@ietfa.amsl.com> <7A5CECA875B00640B202F1DBA1815D230E782985@vie196nt> <949EF20990823C4C85C18D59AA11AD8B01FCBC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <39B5E4D390E9BD4890E2B310790061010B15B1@ESESSMB301.ericsson.se> <7A5CECA875B00640B202F1DBA1815D230E78E9EE@vie196nt> <51645A66.80007@alum.mit.edu> <6C99D10F-DEC1-4B07-AE40-44A723E14D9F@brianrosen.net> In-Reply-To: <6C99D10F-DEC1-4B07-AE40-44A723E14D9F@brianrosen.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=1365534696; bh=Lp2Wgywu6pVt06Uy0Kwd0wHLJ7mDzmaleCCPrreahb0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GynOfCBqq+HVHPgqmAUgf+1B3QnUUH1YgeCx1G2P/9ViGVC+JKid1upDvDijexDx2 /zFgIVynLbZAfCQ1xXjNVmfJAtMhnj2RMvhHGd5MYW/gI1ZOFtrz0w6Bt5qPaEGemz n4SeMipmIiUwn5b1iSZmTeBhW2kgxeR4XhBr1TRdENkKmNw5ewNk5+35Mn8ysRn5M3 Gsc1Q0aJ9Nq5PQOK1MBbBPkE5UHosU6mJ4uCgktFhknqQiLCdo5OqlYyrGwJxrc4/+ 6oytxmR5l9Oj2W0FY+VgRMyRwGwmZBPMAhj9yPRjdVM1nYbTXPOvtTvQADBrI7duLm 8InvGMKtw2HwQ== Cc: ecrit@ietf.org Subject: Re: [Ecrit] 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: Tue, 09 Apr 2013 19:11:38 -0000 On 4/10/13 2:30 AM, Brian Rosen wrote: > Let's use a case more familiar to you: > > Have you been on an highway that has a sign that says > > "State Police patrol this highway, call *77" > > "*77" is the dial string. The service boundary is the road. It leads to a specific responder agency, distinct from local police. I understand that case. (I also suspect that it doesn't work very well - how many people will notice the sign and know when to use *77 instead of 911.) I guess there could also be billboards around town announcing "Call *789 if you witness a murder. But the more of these there are the less likely it is that callers will know to use them. Less is better. Thanks, Paul > Brian > > On Apr 9, 2013, at 2:13 PM, Paul Kyzivat wrote: > >> As a bystander, I'm curious what UI is anticipated that makes use of the large number of these different service urns that are being proposed? >> >> If I'm a native in the Czech republic, do I have a special number that I call to report murders? (A number that is then translated by the phone to the urn.) >> >> If I happen to be visiting the Czech republic from the US and I see a murder, how do *I* know how to report it? >> >> Thanks, >> Paul >> >> On 4/10/13 1:50 AM, MONGRAIN Daniel wrote: >>> In the case of reporting a murder in the Czech republic, we would create >>> a service URN of urn:service:sos.police.murder (only if such calls are >>> considered emergency calls) as the subservice distinction is important. >>> Routing of the call would then point to the national police. The >>> Service Coverage Scope draft addresses the case where there are two >>> separate service providers that provide the same service. >>> >>> With the wording “some given location” and “there may be” I am >>> specifying that the application is not universal. Usage of Service >>> Coverage Scope is only acceptable in areas where such a case exists. >>> >>> Thanx, >>> >>> 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 >>> Webwww.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 for the sole use of the intended recipient(s) and contains >>> confidential and privileged information. Any unauthorized review, use, >>> disclosure or distribution is prohibited. If you are not the intended >>> recipient, please contact the sender by reply email and destroy all >>> copies of the originalmessage and associated attachments. >>> >>> *From:*Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] >>> *Sent:* April-09-13 1:21 PM >>> *To:* DRAGE, Keith (Keith); Dan Mongrain; ecrit@ietf.org >>> *Subject:* RE: [Ecrit] Fwd: FW: New Version Notification for >>> draft-mongrain-ecrit-service-coverage-scope-urn-00.txt >>> >>> The draft states: >>> >>> For some given location, there may be multiple providers that supply >>> >>> the same given service. >>> >>> However, in case of the Czech republic, the responsibility and the >>> services of municipal police and of the national police are similar but >>> not completely same. E.g. municipal police does not handle murder cases. >>> >>> 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 *DRAGE, Keith (Keith) >>> *Sent:* 3. dubna 2013 7:07 >>> *To:* Dan Mongrain; ecrit@ietf.org >>> *Subject:* Re: [Ecrit] Fwd: FW: New Version Notification for >>> draft-mongrain-ecrit-service-coverage-scope-urn-00.txt >>> >>> The way this is currently drafted does not in my view present the >>> problem correctly. >>> >>> It implies that the user wants an identical service, but that the >>> endpoints (PSAPs) are somehow themselves addressed by different >>> organisations. If the user wants an identical service then the URNs >>> should not need to be distinctive. >>> >>> Rather I think the problem is that we have a miscellaneous bunch of >>> subservices which we do not wish to explicitly identify. Within any >>> specific area, it is well known that some are associated with say a >>> national organisation, and some with a local organisation. Thus for the >>> police emergency call example used before, it would be well known that >>> murder required the national police force, but burglary required the >>> local police force. Therefore rather than identify a subtype for each >>> crime, we use a label that represents the wider organisation or the more >>> local organisation. >>> >>> Regards >>> >>> Keith >>> >>> ------------------------------------------------------------------------ >>> >>> *From:*ecrit-bounces@ietf.org >>> [mailto:ecrit-bounces@ietf.org] *On Behalf Of *Dan Mongrain >>> *Sent:* 25 March 2013 13:28 >>> *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 >>> 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 >>> >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > From pkyzivat@alum.mit.edu Tue Apr 9 12: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 4705721F985C for ; Tue, 9 Apr 2013 12:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.112 X-Spam-Level: X-Spam-Status: No, score=-0.112 tagged_above=-999 required=5 tests=[AWL=0.325, 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 V9xxNifjrt3e for ; Tue, 9 Apr 2013 12:18:14 -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 CAE5121F9851 for ; Tue, 9 Apr 2013 12:18:13 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta03.westchester.pa.mail.comcast.net with comcast id MrJy1l0050xGWP853vJD84; Tue, 09 Apr 2013 19:18:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id MvJC1l0133ZTu2S3YvJC8p; Tue, 09 Apr 2013 19:18:13 +0000 Message-ID: <51646974.6060904@alum.mit.edu> Date: Wed, 10 Apr 2013 03:18:12 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: MONGRAIN Daniel References: <20130325131520.25773.10212.idtracker@ietfa.amsl.com> <7A5CECA875B00640B202F1DBA1815D230E782985@vie196nt> <949EF20990823C4C85C18D59AA11AD8B01FCBC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <39B5E4D390E9BD4890E2B310790061010B15B1@ESESSMB301.ericsson.se> <7A5CECA875B00640B202F1DBA1815D230E78E9EE@vie196nt> <51645A66.80007@alum.mit.edu> <7A5CECA875B00640B202F1DBA1815D230E78EAAB@vie196nt> In-Reply-To: <7A5CECA875B00640B202F1DBA1815D230E78EAAB@vie196nt> 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=1365535093; bh=51iIkQEMb//TPUNYp1K/4s7noOcbUdWxHr2lFLbCOo8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mVC36IvGvXm7aKSu6b8vYNTkYiS3HO8RgLNo6WF3Py4mhH7jjq9n3aWheu2GR2FH4 9dtn73Pp0JIbVUXRAeB3fdzE8qFX2D+zHXoZxTMh9Aj3iPQ+ytwiXAAJKa+9lRFGcN NpmXNqRzvir3JKFl1PPVxMkCvUd56ARRbkPZdWptwfnDTvAgBD6lgFTuwbOEtca4YK 3tKCvXKnPR/siabv19K6wzYwZ8je8ElsMVt0QFXRl0tZaM9chbYXoYxDFbfO4WeHAw 9hCACTVXolZD/z31zrQ1BDbkgktK5AAJdLEMF1p7j+RM0iiMS0XGwqfpOwSur+oDWS J9khWkbmMyQFA== Cc: "ecrit@ietf.org" 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: Tue, 09 Apr 2013 19:18:15 -0000 This is more what I was expecting to hear. Is this actually being done anywhere? Would be be legal. (Its my impression that emergency call buttons on phones are discouraged in the US.) Can it be done so it works no matter where I take my phone? I know it is not our place to specify the UI for this functionality. But it is easy to define things that almost guarantee poor UIs. So IMO it is helpful to at least consider that reasonable UA is feasible. Thanks, Paul On 4/10/13 2:47 AM, MONGRAIN Daniel wrote: > When a device enters an area, it can always interrogate the LoST service with a listServicesByLocation request which will return the list of services available for the given location. Since not all services are available at all locations, then it can be expected that the list of services received should be very manageable. The UI of the device could have an emergency call page/menu/whatever which displays the available emergency services for the location of the device. The user would then pick the most appropriate service for the circumstances. > > The list of possible services returned is finite as service URN must be documented in either an RFC or IANA registry, including a description of the service. The device's manufacturer could have pre-provisioned the device with user-friendly icons and descriptions for all of the different service URNs that could be returned so the user would see not service URNs but a user-friendly interface (if there is a user-friendly icon for murder, that is). As the device enters different jurisdictions, the device lists of emergency services changes to reflect the services available in that area. > > Another way can be that the device is statically configured to show some/all emergency services. The user selects a service and the device makes a findService request to the LoST service. In the case that service is not available for the given location, the LoST service can always return another service that should do the same. Maybe more overwhelming to the user to show all services but may still be usable. But definitely the first mechanism is preferable. > > Thanx, > 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 for the sole use of the intended recipient(s) and contains confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and associated attachments. > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: April-09-13 2:14 PM > To: ecrit@ietf.org > Subject: Re: [Ecrit] Fwd: FW: New Version Notification for draft-mongrain-ecrit-service-coverage-scope-urn-00.txt > > As a bystander, I'm curious what UI is anticipated that makes use of the > large number of these different service urns that are being proposed? > > If I'm a native in the Czech republic, do I have a special number that I > call to report murders? (A number that is then translated by the phone > to the urn.) > > If I happen to be visiting the Czech republic from the US and I see a > murder, how do *I* know how to report it? > > Thanks, > Paul > > On 4/10/13 1:50 AM, MONGRAIN Daniel wrote: >> In the case of reporting a murder in the Czech republic, we would create >> a service URN of urn:service:sos.police.murder (only if such calls are >> considered emergency calls) as the subservice distinction is important. >> Routing of the call would then point to the national police. The >> Service Coverage Scope draft addresses the case where there are two >> separate service providers that provide the same service. >> >> With the wording "some given location" and "there may be" I am >> specifying that the application is not universal. Usage of Service >> Coverage Scope is only acceptable in areas where such a case exists. >> >> Thanx, >> >> 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 >> Webwww.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 for the sole use of the intended recipient(s) and contains >> confidential and privileged information. Any unauthorized review, use, >> disclosure or distribution is prohibited. If you are not the intended >> recipient, please contact the sender by reply email and destroy all >> copies of the originalmessage and associated attachments. >> >> *From:*Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] >> *Sent:* April-09-13 1:21 PM >> *To:* DRAGE, Keith (Keith); Dan Mongrain; ecrit@ietf.org >> *Subject:* RE: [Ecrit] Fwd: FW: New Version Notification for >> draft-mongrain-ecrit-service-coverage-scope-urn-00.txt >> >> The draft states: >> >> For some given location, there may be multiple providers that supply >> >> the same given service. >> >> However, in case of the Czech republic, the responsibility and the >> services of municipal police and of the national police are similar but >> not completely same. E.g. municipal police does not handle murder cases. >> >> 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 *DRAGE, Keith (Keith) >> *Sent:* 3. dubna 2013 7:07 >> *To:* Dan Mongrain; ecrit@ietf.org >> *Subject:* Re: [Ecrit] Fwd: FW: New Version Notification for >> draft-mongrain-ecrit-service-coverage-scope-urn-00.txt >> >> The way this is currently drafted does not in my view present the >> problem correctly. >> >> It implies that the user wants an identical service, but that the >> endpoints (PSAPs) are somehow themselves addressed by different >> organisations. If the user wants an identical service then the URNs >> should not need to be distinctive. >> >> Rather I think the problem is that we have a miscellaneous bunch of >> subservices which we do not wish to explicitly identify. Within any >> specific area, it is well known that some are associated with say a >> national organisation, and some with a local organisation. Thus for the >> police emergency call example used before, it would be well known that >> murder required the national police force, but burglary required the >> local police force. Therefore rather than identify a subtype for each >> crime, we use a label that represents the wider organisation or the more >> local organisation. >> >> Regards >> >> Keith >> >> ------------------------------------------------------------------------ >> >> *From:*ecrit-bounces@ietf.org >> [mailto:ecrit-bounces@ietf.org] *On Behalf Of *Dan Mongrain >> *Sent:* 25 March 2013 13:28 >> *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 >> 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 >> >> >> >> _______________________________________________ >> 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 Daniel.MONGRAIN@frequentis.com Tue Apr 9 12:29: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 D5C3121F98D9 for ; Tue, 9 Apr 2013 12:29:41 -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 uRuag00p8Vjw for ; Tue, 9 Apr 2013 12:29:40 -0700 (PDT) Received: from mail1.frequentis.com (mail1.frequentis.com [195.20.158.50]) by ietfa.amsl.com (Postfix) with ESMTP id EF3FA21F9821 for ; Tue, 9 Apr 2013 12:29:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,441,1363129200"; d="scan'208";a="14235" Received: from vie190nt.frequentis.frq ([172.16.1.190]) by mail1.frequentis.com with ESMTP; 09 Apr 2013 21:29:39 +0200 Received: from vie196nt.frequentis.frq ([172.16.1.196]) by vie190nt.frequentis.frq ([172.16.1.190]) with mapi id 14.02.0328.009; Tue, 9 Apr 2013 21:29:38 +0200 From: MONGRAIN Daniel To: Paul Kyzivat Thread-Topic: [Ecrit] Fwd: FW: New Version Notification for draft-mongrain-ecrit-service-coverage-scope-urn-00.txt Thread-Index: AQHONVb8/iYYQKI1kkuQY4lttERTBJjORATA Date: Tue, 9 Apr 2013 19:29:37 +0000 Message-ID: <7A5CECA875B00640B202F1DBA1815D230E78EB7D@vie196nt> References: <20130325131520.25773.10212.idtracker@ietfa.amsl.com> <7A5CECA875B00640B202F1DBA1815D230E782985@vie196nt> <949EF20990823C4C85C18D59AA11AD8B01FCBC@FR712WXCHMBA11.zeu.alcatel-lucent.com> <39B5E4D390E9BD4890E2B310790061010B15B1@ESESSMB301.ericsson.se> <7A5CECA875B00640B202F1DBA1815D230E78E9EE@vie196nt> <51645A66.80007@alum.mit.edu> <7A5CECA875B00640B202F1DBA1815D230E78EAAB@vie196nt> <51646974.6060904@alum.mit.edu> In-Reply-To: <51646974.6060904@alum.mit.edu> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" 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: Tue, 09 Apr 2013 19:29:42 -0000 The emergency call button is discouraged because of the pocket dial issue (= some phones allow an emergency number to be dialled if you hold the button= long enough even in the case of the keypad/screen being locked). I do not= think there is any regulations regarding easing the calling of emergency a= ssistance as long as inadvertent dialling is reduced to a minimum/impossibl= e. An ecrit compliant device that interrogates LoST and intelligently disp= lays available services is feasible in my mind. Such a device would work w= herever ecrit support is deployed.=20 Dan ____________________________________________________ Dan Mongrain, eng. Senior Systems Engineer, Public Safety FREQUENTIS USA Inc. 9017 Red Branch Road, Suite 102 Columbia Maryland 21045 Phone=A0=A0 +1-301-657-8001 Mobile =A0=A0+1-819-744-0491 Fax=A0=A0=A0=A0=A0=A0=A0+1-301-657-8002 Web=A0=A0=A0=A0=A0 www.frequentis.com/usa E-Mail=A0=A0=A0 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. -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: April-09-13 3:18 PM To: MONGRAIN Daniel Cc: ecrit@ietf.org Subject: Re: [Ecrit] Fwd: FW: New Version Notification for draft-mongrain-e= crit-service-coverage-scope-urn-00.txt This is more what I was expecting to hear. Is this actually being done anywhere? Would be be legal. (Its my impression that emergency call buttons on=20 phones are discouraged in the US.) Can it be done so it works no matter where I take my phone? I know it is not our place to specify the UI for this functionality. But=20 it is easy to define things that almost guarantee poor UIs. So IMO it is helpful to at least consider that reasonable UA is feasible. Thanks, Paul On 4/10/13 2:47 AM, MONGRAIN Daniel wrote: > When a device enters an area, it can always interrogate the LoST service = with a listServicesByLocation request which will return the list of service= s available for the given location. Since not all services are available a= t all locations, then it can be expected that the list of services received= should be very manageable. The UI of the device could have an emergency c= all page/menu/whatever which displays the available emergency services for = the location of the device. The user would then pick the most appropriate = service for the circumstances. > > The list of possible services returned is finite as service URN must be d= ocumented in either an RFC or IANA registry, including a description of the= service. The device's manufacturer could have pre-provisioned the device = with user-friendly icons and descriptions for all of the different service = URNs that could be returned so the user would see not service URNs but a us= er-friendly interface (if there is a user-friendly icon for murder, that is= ). As the device enters different jurisdictions, the device lists of emerg= ency services changes to reflect the services available in that area. > > Another way can be that the device is statically configured to show some/= all emergency services. The user selects a service and the device makes a = findService request to the LoST service. In the case that service is not a= vailable for the given location, the LoST service can always return another= service that should do the same. Maybe more overwhelming to the user to = show all services but may still be usable. But definitely the first mechan= ism is preferable. > > Thanx, > 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= for the sole use of the intended recipient(s) and contains confidential an= d privileged information. Any unauthorized review, use, disclosure or distr= ibution is prohibited. If you are not the intended recipient, please contac= t the sender by reply email and destroy all copies of the original message = and associated attachments. > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of= Paul Kyzivat > Sent: April-09-13 2:14 PM > To: ecrit@ietf.org > Subject: Re: [Ecrit] Fwd: FW: New Version Notification for draft-mongrain= -ecrit-service-coverage-scope-urn-00.txt > > As a bystander, I'm curious what UI is anticipated that makes use of the > large number of these different service urns that are being proposed? > > If I'm a native in the Czech republic, do I have a special number that I > call to report murders? (A number that is then translated by the phone > to the urn.) > > If I happen to be visiting the Czech republic from the US and I see a > murder, how do *I* know how to report it? > > Thanks, > Paul > > On 4/10/13 1:50 AM, MONGRAIN Daniel wrote: >> In the case of reporting a murder in the Czech republic, we would create >> a service URN of urn:service:sos.police.murder (only if such calls are >> considered emergency calls) as the subservice distinction is important. >> Routing of the call would then point to the national police. The >> Service Coverage Scope draft addresses the case where there are two >> separate service providers that provide the same service. >> >> With the wording "some given location" and "there may be" I am >> specifying that the application is not universal. Usage of Service >> Coverage Scope is only acceptable in areas where such a case exists. >> >> Thanx, >> >> 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 >> Webwww.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 for the sole use of the intended recipient(s) and contains >> confidential and privileged information. Any unauthorized review, use, >> disclosure or distribution is prohibited. If you are not the intended >> recipient, please contact the sender by reply email and destroy all >> copies of the originalmessage and associated attachments. >> >> *From:*Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] >> *Sent:* April-09-13 1:21 PM >> *To:* DRAGE, Keith (Keith); Dan Mongrain; ecrit@ietf.org >> *Subject:* RE: [Ecrit] Fwd: FW: New Version Notification for >> draft-mongrain-ecrit-service-coverage-scope-urn-00.txt >> >> The draft states: >> >> For some given location, there may be multiple providers that suppl= y >> >> the same given service. >> >> However, in case of the Czech republic, the responsibility and the >> services of municipal police and of the national police are similar but >> not completely same. E.g. municipal police does not handle murder cases. >> >> 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 *DRAGE, Keith (Keith) >> *Sent:* 3. dubna 2013 7:07 >> *To:* Dan Mongrain; ecrit@ietf.org >> *Subject:* Re: [Ecrit] Fwd: FW: New Version Notification for >> draft-mongrain-ecrit-service-coverage-scope-urn-00.txt >> >> The way this is currently drafted does not in my view present the >> problem correctly. >> >> It implies that the user wants an identical service, but that the >> endpoints (PSAPs) are somehow themselves addressed by different >> organisations. If the user wants an identical service then the URNs >> should not need to be distinctive. >> >> Rather I think the problem is that we have a miscellaneous bunch of >> subservices which we do not wish to explicitly identify. Within any >> specific area, it is well known that some are associated with say a >> national organisation, and some with a local organisation. Thus for the >> police emergency call example used before, it would be well known that >> murder required the national police force, but burglary required the >> local police force. Therefore rather than identify a subtype for each >> crime, we use a label that represents the wider organisation or the more >> local organisation. >> >> Regards >> >> Keith >> >> ------------------------------------------------------------------------ >> >> *From:*ecrit-bounces@ietf.org >> [mailto:ecrit-bounces@ietf.org] *On Behalf Of *Dan Mongrain >> *Sent:* 25 March 2013 13:28 >> *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 >> 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-coverag= e-scope-urn-00.txt >> Status: >> http://datatracker.ietf.org/doc/draft-mongrain-ecrit-service-coverage-sc= ope-urn >> Htmlized: >> http://tools.ietf.org/html/draft-mongrain-ecrit-service-coverage-scope-u= rn-00 >> >> >> Abstract: >> This document specifies a mechanism to specify a Service Coverage >> Scope in a Service URN [RFC5031] when multiple providers provide th= e >> same service for the same location. >> >> >> >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> 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 RMarshall@telecomsys.com Fri Apr 12 11:16: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 36B7D21F8842 for ; Fri, 12 Apr 2013 11:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.398 X-Spam-Level: X-Spam-Status: No, score=-101.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_OEM_S_DOL=1.2, 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 ny8v-ft-20DK for ; Fri, 12 Apr 2013 11:16:00 -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 1312921F8C0C for ; Fri, 12 Apr 2013 11:15:59 -0700 (PDT) Received: from SEA-EXCAS-1.telecomsys.com (exc2010-local1.telecomsys.com [10.32.12.186]) by sea-mx-02.telecomsys.com (8.14.1/8.14.1) with ESMTP id r3CIFjXp002116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 12 Apr 2013 11:15:45 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.76]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Fri, 12 Apr 2013 11:15:45 -0700 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: Proposed Milestone date changes Thread-Index: AQHON6nA+tNuB4LdsUWc2A/WRo7Y0g== Date: Fri, 12 Apr 2013 18:15:45 +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_FBD5AAFFD0978846BF6D3FAB4C892ACC25A254SEAEXMB2telecomsy_" MIME-Version: 1.0 Cc: "Richard L. Barnes" Subject: [Ecrit] Proposed Milestone date changes 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, 12 Apr 2013 18:16:02 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC25A254SEAEXMB2telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ECRIT wg members: Note that the published charter listed below differs from some earlier prop= osed and accepted changes that were presented and accepted by the ECRIT wg = before IETF86 (see http://www.ietf.org/proceedings/86/slides/slides-86-ecri= t-5.pdf). The net changes are as shown below. Current (published) charter: (http://datatracker.ietf.org/wg/ecrit/charter= /) The following changes reflect, 1. some already agreed-to updates (but that were never officially posted), = and 2. (new & additional) proposed revisions based on present timing and recent= list activity. These changes are shown along with strikethrough. Some of= these proposed date changes have been made subjectively (by the ECRIT chai= r), including pushing out 'service-identifying labels' to Dec 2013. Goals and Milestones Done Submit 'Synchronizing Location-to-Service Translation (LoST) Protocol based= Service Boundaries and Mapping Elements' to the IESG for consideration as = an Experimental RFC Mar 20132014 Submit 'Using Imprecise Location for Emergency Call Routing' to the IESG fo= r consideration as an Informational RFC MarAug 2013 Submit 'Additional Data related to a Call for Emergency Call Purposes' to t= he IESG for consideration as a Standards Track RFC AprNov 2013 Submit 'Common Alerting Protocol (CAP) based Data-Only Emergency Alerts usi= ng the Session Initiation Protocol (SIP)' to the IESG for consideration as = an Experimental RFC Dec 2013 Submit 'Extensions to the Emergency Services Architecture for dealing with = Unauthenticated and Unauthorized Devices' to the IESG for consideration as = a Standards Track RFC Jun 2013 Submit 'Trustworthy Location Information' to the IESG for consideration as = an Informational RFC MarMay 2013 Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG for con= sideration as an Informational RFC AprDec 2013 Submit a draft 'Policy for defining new service-identifying labels' to the = IESG for consideration as BCP New: http://datatracker.ietf.org/doc/draft-holmberg-ecrit-country-emg-urn/ Apr 2014 Submit a draft 'URN For Country Specific Emergency Serv= ices' to the IESG for consideration as a Standards Track RFC Please take a minute to review to affirm (or not) w/comments to the list. Roger Marshall & Marc Linsner Ecrit Chairs 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_FBD5AAFFD0978846BF6D3FAB4C892ACC25A254SEAEXMB2telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

ECRIT wg members:=

 

Note that the published charter listed below differs= from some earlier proposed and accepted changes that were presented and ac= cepted by the ECRIT wg before IETF86 (see http://www.ietf.org/proceedings/86/slides/slides-86-ecrit-5.pdf). &nbs= p;The net changes are as shown below.

 

Current (publis= hed) charter:  (http://datatracker.ietf.org/wg/ecr= it/charter/)

 

The following changes reflect,

1. some already= agreed-to updates (but that were never officially posted), and<= /p>

2. (new & additional) proposed revisions based o= n present timing and recent list activity.  These changes are shown al= ong with strikethrough.  Some of these proposed date changes have been= made subjectively (by the ECRIT chair), including pushing out ‘service-identifying labels’ to Dec 2013.

Goals and Milestones

Done

Submit 'Synchronizing Location-to-Se= rvice Translation (LoST) Protocol based Service Boundaries and Mapping Elem= ents' to the IESG for consideration as an Experimental RFC

Mar 20132014

Submit 'Using Imprecise Location for= Emergency Call Routing' to the IESG for consideration as an Informational = RFC

MarAug= 2013

Submit 'Additional Data related to a= Call for Emergency Call Purposes' to the IESG for consideration as a Stand= ards Track RFC

AprNov= 2013

Submit 'Common Alerting Protocol (CA= P) based Data-Only Emergency Alerts using the Session Initiation Protocol (= SIP)' to the IESG for consideration as an Experimental RFC

Dec 2013

Submit 'Extensions to the Emergency = Services Architecture for dealing with Unauthenticated and Unauthorized Dev= ices' to the IESG for consideration as a Standards Track RFC

Jun 2013

Submit 'Trustworthy Location Informa= tion' to the IESG for consideration as an Informational RFC

MarMay= 2013

Submit 'Public Safety Answering Poin= t (PSAP) Callbacks' to the IESG for consideration as an Informational RFC

AprDec= 2013

Submit a draft 'Policy for defining = new service–identifying labels' to the IESG for consideration as BCP

 

New:

 

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

 

Apr 2014   &nb= sp;        Submit a draft ‘URN For Country Specific Emergency Se= rvices’ to the IESG for consideration as a Standards Track RFC

 

 

Please take a minute t= o review to affirm (or not) w/comments to the list.

 

Roger Marshall & M= arc Linsner

Ecrit Chairs

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_FBD5AAFFD0978846BF6D3FAB4C892ACC25A254SEAEXMB2telecomsy_-- From johnsonhammond2@hushmail.com Sat Apr 27 10:03: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 5EA0C21F97FE for ; Sat, 27 Apr 2013 10:03:52 -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=[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 Tu0j9vjUiD4X for ; Sat, 27 Apr 2013 10:03:52 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by ietfa.amsl.com (Postfix) with ESMTP id 18F1821F97C4 for ; Sat, 27 Apr 2013 10:03:52 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by smtp2.hushmail.com (Postfix) with SMTP id EE6DCE7C56 for ; Sat, 27 Apr 2013 17:03:50 +0000 (UTC) Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp2.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:03:50 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id A780614DBDE; Sat, 27 Apr 2013 17:03:50 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:03:50 -0400 To: ecrit@ietf.org From: johnsonhammond2@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427170350.A780614DBDE@smtp.hushmail.com> Subject: [Ecrit] Biggest Fake Conference in Computer Science 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, 27 Apr 2013 18:14:44 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From internet-drafts@ietf.org Mon Apr 29 08:34: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 A9F5C21F9DD2; Mon, 29 Apr 2013 08:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 8MWF5g3oyhj1; Mon, 29 Apr 2013 08:34:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 393E521F9A01; Mon, 29 Apr 2013 08:34:43 -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.44.p4 Message-ID: <20130429153443.30027.91020.idtracker@ietfa.amsl.com> Date: Mon, 29 Apr 2013 08:34:43 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-country-emg-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, 29 Apr 2013 15:34:45 -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 : URN For Country Specific Emergency Services Author(s) : Christer Holmberg Ivo Sedlacek Filename : draft-ietf-ecrit-country-emg-urn-00.txt Pages : 7 Date : 2013-04-16 Abstract: This document updates section 4.2 of RFC 5031, in order to allow the registration of service URNs with the 'sos' service type for emergency services that, at the time of registration, are offered in one country only. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-country-emg-urn There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-country-emg-urn-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hannes.tschofenig@gmx.net Mon Apr 29 14:22:34 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A5A21F9A6D for ; Mon, 29 Apr 2013 14:22:34 -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 S8gm+OziLJHU for ; Mon, 29 Apr 2013 14:22:28 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD6A21F9A6B for ; Mon, 29 Apr 2013 14:22:28 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LeOot-1UpkcR1hPB-00qBlA for ; Mon, 29 Apr 2013 23:22:26 +0200 Received: (qmail invoked by alias); 29 Apr 2013 21:22:26 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.109]) [88.115.219.140] by mail.gmx.net (mp027) with SMTP; 29 Apr 2013 23:22:26 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/gLHt5GfvgEOp1pmqEQRbAPyOrEgVcGjOpO4ytVw imvs5kCRr1cEaH Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Hannes Tschofenig In-Reply-To: <5A55A45AE77F5941B18E5457ECAC818801214088303D@SISPE7MB1.commscope.com> Date: Tue, 30 Apr 2013 00:22:21 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2B303721-4B60-4A10-BD16-18149CBED50C@gmx.net> References: <5A55A45AE77F5941B18E5457ECAC818801214088303D@SISPE7MB1.commscope.com> To: "Winterbottom, James" X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 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, 29 Apr 2013 21:22:34 -0000 Hi James,=20 I am trying to incorporate some of your review comments and I have a = couple of questions.=20 On Mar 18, 2013, at 5:41 AM, Winterbottom, James wrote: > Hi Authors, > =20 > 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. > =20 > 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 = document 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. I searched for an appropriate definition in IETF RFCs and it turns out = that others have defined this term either.=20 Do you have a recommendation what we should use? Do you think it is = really necessary to describe it? > =20 > 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 confused and when I tried to describe a DOCSIS, Fibre or DSL = service I couldn=92t. Here is a proposal to address 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-level = 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 Telephone 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 document. > =20 > 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. > =20 > In section 6.2, the definition for VoIP needs to be decoupled from the = access technology constraints, these are addressed in section 6.3. I passed this question forward to the NENA additional data group and to = the EENA NG 112 group.=20 > =20 > Section 6.3, for Nomadic, please can you emphasize that it cannot = change its point of network attachment. This does not necessarily mean = that the device cannot move. I added this text.=20 > =20 > Section 6.2 says =93VoIP Telephone Service: A type of service that = offers communication over internet protocol, such as Fixed, Nomadic, = Mobile, Unknown=94. Section 6.3 does not register =93Unknown=94 as an = allowable value, yet section 6.4 requires the = element to be included in the = element. I think that it needs to include a value of unknown in the = register. I added the "Unknown" category.=20 > =20 > Section 8.2. This schema has a sequence with one element in it, and = this element is optional. This doesn=92t make much sense. > =20 With the added extension point there may be more elements in there in = the future.=20 > None 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 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. Brian added those; will double-check.=20 > =20 > NITS > =3D=3D=3D=3D=3D > Page 5 second paragraph has a PDIF-LO rather than a PIDF-LO fixed.=20 Ciao Hannes > =20 > =20 > Cheers > James > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From gunnar.hellstrom@omnitor.se Mon Apr 29 23:18: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 3657821F9BFB for ; Mon, 29 Apr 2013 23:18:49 -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 czylGpuxV5a3 for ; Mon, 29 Apr 2013 23:18:42 -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 158AD21F9B93 for ; Mon, 29 Apr 2013 23:18:41 -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 ; Tue, 30 Apr 2013 08:18:33 +0200 (CEST) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-06-01.atm.binero.net (Postfix) with ESMTPA id 7A7243A166 for ; Tue, 30 Apr 2013 08:18:33 +0200 (CEST) Message-ID: <517F623C.9050909@omnitor.se> Date: Tue, 30 Apr 2013 08:18:36 +0200 From: Gunnar Hellstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: ecrit@ietf.org References: <5A55A45AE77F5941B18E5457ECAC818801214088303D@SISPE7MB1.commscope.com> <2B303721-4B60-4A10-BD16-18149CBED50C@gmx.net> In-Reply-To: <2B303721-4B60-4A10-BD16-18149CBED50C@gmx.net> Content-Type: multipart/alternative; boundary="------------030605080304090605050209" 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: Tue, 30 Apr 2013 06:18:49 -0000 This is a multi-part message in MIME format. --------------030605080304090605050209 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit ------------------------------------------------------------------------ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46708204288 On 2013-04-29 23:22, Hannes Tschofenig wrote: > Hi James, > > I am trying to incorporate some of your review comments and I have a couple of questions. > > On Mar 18, 2013, at 5:41 AM, Winterbottom, James wrote: > >> 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: >> ================= >> The term “Service Provider” is used extensively throughout this document but the term doesn’t 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. > I searched for an appropriate definition in IETF RFCs and it turns out that others have defined this term either. > > Do you have a recommendation what we should use? Do you think it is really necessary to describe it? I had a similar problem in another SDO recently. I used "service provider" or "communication service provider" for an organization handling calls and subscribers. The conclusion there was to change it to "Application Service Provider" with the following definition: *"Application Service Provider (ASP): *organization or entity that provides application-layer services, which may include voice, video and text communication" The reason for confusion was apparently that some thought of the network access service provider while others thought about the call control service provider when using the term "service provider". It stands out clear in section14.1.2. that it is a problem. The table with service provider types contains "service provider" as one of the types. At least this recursive use of the term needs to be broken. I briefly checked RFC 6881 and RFC 4504 to check how they handled "service provider" and found that you are in good company. The term is just used without definition and seems to mean an organization working on the SIP or other call control level and manages subscribers. I suggest that this definition is used: *"Application Service Provider (ASP): *organization or entity that provides application-layer services, which may include real-time communication" And then check through the occurrences and replace the ones that have the narrow meaning of "Application Service Provider". /Gunnar --------------030605080304090605050209 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288
On 2013-04-29 23:22, Hannes Tschofenig wrote:
Hi James, 

I am trying to incorporate some of your review comments and I have a couple of questions. 

On Mar 18, 2013, at 5:41 AM, Winterbottom, James wrote:


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:
=================
The term “Service Provider” is used extensively throughout this document but the term doesn’t 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.

I searched for an appropriate definition in IETF RFCs and it turns out that others have defined this term either. 

Do you have a recommendation what we should use? Do you think it is really necessary to describe it?
I had a similar problem in another SDO recently. I used "service provider" or "communication service provider" for an organization handling calls and subscribers.
The conclusion there was to change it to "Application Service Provider" with the following definition:

"Application Service Provider (ASP): organization or entity that provides application-layer services, which may include voice, video and text communication"

The reason for confusion was apparently that some thought of the network access service provider while others thought about the call control service provider when using the term "service provider".

It stands out clear in section 14.1.2. that it is a problem.
The table with service provider types contains "service provider" as one of the types.

At least this recursive use of the term needs to be broken.

I briefly checked RFC 6881 and RFC 4504 to check how they handled "service provider" and found that you are in good company. The term is just used without definition and seems to mean an organization working on the SIP or other call control level and manages subscribers.

I suggest that this definition is used:

"Application Service Provider (ASP): organization or entity that provides application-layer services, which may include real-time communication"
 

And then check through the occurrences and replace the ones that have the narrow meaning of "Application Service Provider".

 
/Gunnar

--------------030605080304090605050209-- From internet-drafts@ietf.org Tue Apr 30 04:20: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 849AD21F9A7F; Tue, 30 Apr 2013 04:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 r+DaCLkYng6A; Tue, 30 Apr 2013 04:19:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B82D921F992E; Tue, 30 Apr 2013 04:19:33 -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.44.p4 Message-ID: <20130430111933.31597.75173.idtracker@ietfa.amsl.com> Date: Tue, 30 Apr 2013 04:19:33 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-unauthenticated-access-06.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 11:20:09 -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 : Extensions to the Emergency Services Architecture for de= aling with Unauthenticated and Unauthorized Devices Author(s) : Henning Schulzrinne Stephen McCann Gabor Bajko Hannes Tschofenig Dirk Kroeselberg Filename : draft-ietf-ecrit-unauthenticated-access-06.txt Pages : 19 Date : 2013-04-30 Abstract: The IETF emergency services architecture assumes that the calling device has acquired rights to use the access network or that no authentication is required for the access network, such as for public wireless access points. Subsequent protocol interactions, such as obtaining location information, learning the address of the Public Safety Answering Point (PSAP) and the emergency call itself are largely decoupled from the underlying network access procedures. In some cases, however, the device does not have these credentials for network access, does not have a VoIP service provider, or the credentials have become invalid, e.g., because the user has exhausted their prepaid balance or the account has expired. This document provides a problem statement, introduces terminology and describes an extension for the base IETF emergency services architecture to address these scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-unauthenticated-access-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-unauthenticated-access-= 06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From br@brianrosen.net Tue Apr 30 06:59:57 2013 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A610421F9AB3 for ; Tue, 30 Apr 2013 06:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[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 Jf1PD0G7oOg7 for ; Tue, 30 Apr 2013 06:59:53 -0700 (PDT) Received: from mm2.idig.net (raphotoclub.ca [70.33.247.99]) by ietfa.amsl.com (Postfix) with ESMTP id 23C1721F9B08 for ; Tue, 30 Apr 2013 06:59:53 -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=kR0UqbIZtlq2fs+JnjV5aGvPKJkrJJZYdbkkMfrgF84=; b=jmYVhag/ixGW1HnHhB9htLUsYxwA7caV9FkS4hpua9+FbvrkAtv5nZXbOG1kZJ4n01urAtsD63dKbFkcXQ/TEg+ZL6imDpD7fMVnnLZ9EPR4ng+Z1+L1VjUlHodWifvk3QD33L2ilwGLx13BB/F+SdJikcv5y6YqGA6BEvgyFNo=; Received: from neustargw.va.neustar.com ([209.173.53.233]:27904 helo=[10.33.192.26]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UXB5z-0006Xt-Gv; Tue, 30 Apr 2013 09:59:51 -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: <2B303721-4B60-4A10-BD16-18149CBED50C@gmx.net> Date: Tue, 30 Apr 2013 09:59:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <30EDA794-B34C-4239-842E-429229DDF55E@brianrosen.net> References: <5A55A45AE77F5941B18E5457ECAC818801214088303D@SISPE7MB1.commscope.com> <2B303721-4B60-4A10-BD16-18149CBED50C@gmx.net> To: Hannes Tschofenig 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] 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: Tue, 30 Apr 2013 13:59:57 -0000 I have a problem with "packet data" as a high level service. That's = really a low level service grouping (DSL, FTTH), not a high level = service. Vonage, AIM, Google Talk, those are the high level services, = and none of them are "packet data". Brian On Apr 29, 2013, at 5:22 PM, Hannes Tschofenig = wrote: > Hi James,=20 >=20 > I am trying to incorporate some of your review comments and I have a = couple of questions.=20 >=20 > On Mar 18, 2013, at 5:41 AM, Winterbottom, James wrote: >=20 >> Hi Authors, >>=20 >> 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. >>=20 >> 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 = document 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. >=20 > I searched for an appropriate definition in IETF RFCs and it turns out = that others have defined this term either.=20 >=20 > Do you have a recommendation what we should use? Do you think it is = really necessary to describe it? >=20 >>=20 >> 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 confused and when I tried to describe a DOCSIS, Fibre or = DSL service I couldn=92t. Here is a proposal to address 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-level = 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 Telephone 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 document. >>=20 >> 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. >>=20 >> In section 6.2, the definition for VoIP needs to be decoupled from = the access technology constraints, these are addressed in section 6.3. >=20 > I passed this question forward to the NENA additional data group and = to the EENA NG 112 group.=20 >=20 >>=20 >> Section 6.3, for Nomadic, please can you emphasize that it cannot = change its point of network attachment. This does not necessarily mean = that the device cannot move. >=20 > I added this text.=20 >=20 >>=20 >> Section 6.2 says =93VoIP Telephone Service: A type of service that = offers communication over internet protocol, such as Fixed, Nomadic, = Mobile, Unknown=94. Section 6.3 does not register =93Unknown=94 as an = allowable value, yet section 6.4 requires the = element to be included in the = element. I think that it needs to include a value of unknown in the = register. >=20 > I added the "Unknown" category.=20 >=20 >>=20 >> Section 8.2. This schema has a sequence with one element in it, and = this element is optional. This doesn=92t make much sense. >>=20 > With the added extension point there may be more elements in there in = the future.=20 >=20 >> None 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 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. > Brian added those; will double-check.=20 >=20 >>=20 >> NITS >> =3D=3D=3D=3D=3D >> Page 5 second paragraph has a PDIF-LO rather than a PIDF-LO >=20 > fixed.=20 >=20 > Ciao > Hannes >=20 >>=20 >>=20 >> Cheers >> James >> _______________________________________________ >> 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 James.Winterbottom@commscope.com Tue Apr 30 15:59: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 2B62E21F84E9 for ; Tue, 30 Apr 2013 15:59:00 -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=[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 9UIX0YPz0rqs for ; Tue, 30 Apr 2013 15:58:56 -0700 (PDT) Received: from cdcsmgw01.commscope.com (cdcsmgw01.commscope.com [198.135.207.232]) by ietfa.amsl.com (Postfix) with ESMTP id CFAF021F8437 for ; Tue, 30 Apr 2013 15:58:55 -0700 (PDT) X-AuditID: 0a0404e8-b7f486d00000082e-02-51804cae6c3d Received: from CDCE10HC1.commscope.com ( [10.86.28.21]) by cdcsmgw01.commscope.com (Symantec Messaging Gateway) with SMTP id FB.21.02094.EAC40815; Tue, 30 Apr 2013 17:58:54 -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, 30 Apr 2013 17:58:53 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 1 May 2013 06:58:51 +0800 From: "Winterbottom, James" To: Brian Rosen , Hannes Tschofenig Date: Wed, 1 May 2013 06:58:49 +0800 Thread-Topic: [Ecrit] draft-ietf-ecrit-additional-data-07 Thread-Index: Ac5Fqv50SXJMFUMTT1GkNmF5EDCSzAASkidA Message-ID: <5A55A45AE77F5941B18E5457ECAC8188012140958BE6@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC818801214088303D@SISPE7MB1.commscope.com> <2B303721-4B60-4A10-BD16-18149CBED50C@gmx.net> <30EDA794-B34C-4239-842E-429229DDF55E@brianrosen.net> In-Reply-To: <30EDA794-B34C-4239-842E-429229DDF55E@brianrosen.net> 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+NgFrrKKsWRmVeSWpSXmKPExsXCFSYjqrvOpyHQ4PNpbYun96exWTQuespq sXTnPVYHZo/73/6yeyzetJ/NY8mSn0wBzFFcNimpOZllqUX6dglcGVte9DIXfNWrmPn+IHsD 42XVLkZODgkBE4lzm98wQ9hiEhfurWfrYuTiEBLYxSjxYuVuNpCEkMAGRont11IhEusYJbb+ Oc8OkmATsJM4vP4GWLeIQIjE22vLGUFsZgFViXONj1lAbBYBFYmj/xaC2cICFhIvl1xjgqi3 lLg6+z4bhG0kseL2JlYQm1cgSKL32xwmiGW7GSU2LHoH1swp4CRx+PQsMJsR6NTvp9YwQSwT l7j1ZD4TxAsCEkv2nId6R1Ti5eN/rBD1ohJ32tdDHacjsWD3JzYIW1ti2cLXzBCLBSVOznzC AvGxrkTTzq+sExglZiFZMQtJ+ywk7bOQtC9gZFnFKJ6cklycm15uYKiXnJ+bW5ycX5AKYm1i BMUiC8uLHYynN2gfYhTgYFTi4RW4XB8oxJpYVlyZe4hRkoNJSZS307EhUIgvKT+lMiOxOCO+ qDQntfgQowQHs5IIr89DoHLelMTKqtSifJiUBgeHwOkn908xSrHk5eelKknwLvcGGiFYlJqe WpGWmQNMRDClTBycIKN4gEadA6nhLS5IzC3OTIfIn2LU5pi19clrRo4Vm1++ZhQCGyclznsA pFQApDSjNA9u2itGcaAXhHk7QbI8wLQKN+cV0AomoBU7q0CuLS5JREhJNTDGWLtqLLcuF1Jb 4NB1XnWyhnfxlVNCKTtv1Gv+KkruOMzrMyVCXvmq9FbL1S2RmvPFQnJPs9702Zdu+SliXZvV YU7vryuWT+8KPtiTuOvIw0V2vMI/z4QqJNTerNzgWrX/ENscz4CNt7JnVd8vsDWxmTrpVLpo 7N2N+//mPlrpqbfyLIf/kkQlluKMREMt5qLiRABkUxxQaAMAAA== 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: Tue, 30 Apr 2013 22:59:00 -0000 I think you are hung-up on the term high-level, my implication is more that= these are higher-level than FTTH, coax, twisted-pair, GSM, UMTS. What I want/need the distinction between is a packet service and a circuit = service both of which can run on the same kind of "physical" access. My 3G = UMTS-based phone can operate in circuit-switched mode for calls or in HSDPA= + packet-mode for data services. Both of these come from the same operator.= My iPad however is HSDPA+ only, and so is only a packet device. This differentiation cannot be cleanly represented in the current represent= ation. What I tried to provide was a way to represent this, I am open to other rep= resentations providing they don't ram them all into the same enumerated typ= e. Cheers James -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, 1 May 2013 12:00 AM To: Hannes Tschofenig Cc: Winterbottom, James; ecrit@ietf.org Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-07 I have a problem with "packet data" as a high level service. That's really= a low level service grouping (DSL, FTTH), not a high level service. Vonag= e, AIM, Google Talk, those are the high level services, and none of them ar= e "packet data". Brian On Apr 29, 2013, at 5:22 PM, Hannes Tschofenig = wrote: > Hi James,=20 >=20 > I am trying to incorporate some of your review comments and I have a coup= le of questions.=20 >=20 > On Mar 18, 2013, at 5:41 AM, Winterbottom, James wrote: >=20 >> Hi Authors, >>=20 >> I have reviewed this document and have the following comments, some of w= hich I have already posted to the list and have not had a reply to. >>=20 >> 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= but the term doesn't seem to be obviously defined in the document, nor is = there is a reference to an external definition. To add to this, Service Pro= vider is a defined type in section 14.1.2, but used more generally througho= ut the rest of the document. This needs a clarification. >=20 > I searched for an appropriate definition in IETF RFCs and it turns out th= at others have defined this term either.=20 >=20 > Do you have a recommendation what we should use? Do you think it is reall= y necessary to describe it? >=20 >>=20 >> Section 6.2 seems to conflate several different concepts. I think that t= his because it bundles access technologies and telephone service type, thou= gh I suspect that it doesn't mean to, but in so doing it left me quite conf= used 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 accessTechno= logy and then a second one looking at any higher-level application run over= the access technology, call it applicationType or something similar. >> 2) Create a registry for accessTechnology at a minimum it would hav= e what is currently under the "Wireless Telephone System" field and I would= add: >> a. Twisted pair >> b. Coax >> c. Fibre >> 3) The other things listed are high-level services most of which ar= e okay except I would change or add the following: >> a. Drop wireline and call it circuit-switched. This would then allo= w me to have accessTechnology=3DGSM, applicationType=3Dcircuit-switched >> b. Add Packet-Data >> As it is currently written this section really only relates to conventio= nal telephony providers which I didn't think was the only aim of the docume= nt. >>=20 >> I think it would be worth emphasizing in this section that the nature of= the physical access technology does not necessarily dictate the mobility o= f the call. >>=20 >> In section 6.2, the definition for VoIP needs to be decoupled from the a= ccess technology constraints, these are addressed in section 6.3. >=20 > I passed this question forward to the NENA additional data group and to t= he EENA NG 112 group.=20 >=20 >>=20 >> Section 6.3, for Nomadic, please can you emphasize that it cannot change= its point of network attachment. This does not necessarily mean that the d= evice cannot move. >=20 > I added this text.=20 >=20 >>=20 >> Section 6.2 says "VoIP Telephone Service: A type of service that offers = communication over internet protocol, such as Fixed, Nomadic, Mobile, Unkn= own". Section 6.3 does not register "Unknown" as an allowable = value, yet section 6.4 requires the element to be included i= n the element. I think that it needs to include a v= alue of unknown in the register. >=20 > I added the "Unknown" category.=20 >=20 >>=20 >> Section 8.2. This schema has a sequence with one element in it, and this= element is optional. This doesn't make much sense. >>=20 > With the added extension point there may be more elements in there in the= future.=20 >=20 >> None of the schemas have extension points. While some of the discourse o= n the list over the last few days might suggest that this was deliberate, t= he discussion as I have followed it has been more to do with adding new blo= cks than it has been to allowing localized extensions to already defined bl= ocks. > Brian added those; will double-check.=20 >=20 >>=20 >> NITS >> =3D=3D=3D=3D=3D >> Page 5 second paragraph has a PDIF-LO rather than a PIDF-LO >=20 > fixed.=20 >=20 > Ciao > Hannes >=20 >>=20 >>=20 >> Cheers >> James >> _______________________________________________ >> 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 Apr 30 16:43: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 5DFE721F86EA for ; Tue, 30 Apr 2013 16:43:11 -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.300, 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 ai1KDPBFs3sw for ; Tue, 30 Apr 2013 16:43:05 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7C521F86DE for ; Tue, 30 Apr 2013 16:43:05 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r3UNgwOP016084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Apr 2013 18:42:58 -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 r3UNgtQs027870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Apr 2013 19:42:56 -0400 Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 30 Apr 2013 19:42:55 -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, 1 May 2013 01:42:53 +0200 From: "DRAGE, Keith (Keith)" To: "Winterbottom, James" , Brian Rosen , Hannes Tschofenig Thread-Topic: [Ecrit] draft-ietf-ecrit-additional-data-07 Thread-Index: Ac5Fqv50SXJMFUMTT1GkNmF5EDCSzAASkidAAAGlvmA= Date: Tue, 30 Apr 2013 23:42:52 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B031051@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <5A55A45AE77F5941B18E5457ECAC818801214088303D@SISPE7MB1.commscope.com> <2B303721-4B60-4A10-BD16-18149CBED50C@gmx.net> <30EDA794-B34C-4239-842E-429229DDF55E@brianrosen.net> <5A55A45AE77F5941B18E5457ECAC8188012140958BE6@SISPE7MB1.commscope.com> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC8188012140958BE6@SISPE7MB1.commscope.com> 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.39 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: Tue, 30 Apr 2013 23:43:11 -0000 Is it a clean differentiation. Your 3G phone currently can handle emergency data using a modem running ove= r the CS domain and you 3G phone can also support voice services using IMS = over GPRS. Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Winterbottom, James > Sent: 30 April 2013 23:59 > To: Brian Rosen; Hannes Tschofenig > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-07 >=20 > I think you are hung-up on the term high-level, my implication is more > that these are higher-level than FTTH, coax, twisted-pair, GSM, UMTS. >=20 > What I want/need the distinction between is a packet service and a circui= t > service both of which can run on the same kind of "physical" access. My 3= G > UMTS-based phone can operate in circuit-switched mode for calls or in > HSDPA+ packet-mode for data services. Both of these come from the same > operator. My iPad however is HSDPA+ only, and so is only a packet device. >=20 > This differentiation cannot be cleanly represented in the current > representation. >=20 > What I tried to provide was a way to represent this, I am open to other > representations providing they don't ram them all into the same enumerate= d > type. >=20 > Cheers > James >=20 >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, 1 May 2013 12:00 AM > To: Hannes Tschofenig > Cc: Winterbottom, James; ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-07 >=20 > I have a problem with "packet data" as a high level service. That's > really a low level service grouping (DSL, FTTH), not a high level service= . > Vonage, AIM, Google Talk, those are the high level services, and none of > them are "packet data". >=20 > Brian > On Apr 29, 2013, at 5:22 PM, Hannes Tschofenig > wrote: >=20 > > Hi James, > > > > I am trying to incorporate some of your review comments and I have a > couple of questions. > > > > On Mar 18, 2013, at 5:41 AM, Winterbottom, James wrote: > > > >> 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: > >> =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 but the term doesn't seem to be obviously defined in the documen= t, > 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= . > > > > I searched for an appropriate definition in IETF RFCs and it turns out > that others have defined this term either. > > > > Do you have a recommendation what we should use? Do you think it is > really necessary to describe it? > > > >> > >> 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 quit= e > 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 called > accessTechnology and then a second one looking at any higher-level > 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 "Wireless Telephone System" 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-switch= ed > >> 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 the physical access technology does not necessarily dictate the > mobility of the call. > >> > >> In section 6.2, the definition for VoIP needs to be decoupled from the > access technology constraints, these are addressed in section 6.3. > > > > I passed this question forward to the NENA additional data group and to > the EENA NG 112 group. > > > >> > >> Section 6.3, for Nomadic, please can you emphasize that it cannot > change its point of network attachment. This does not necessarily mean > that the device cannot move. > > > > I added this text. > > > >> > >> Section 6.2 says "VoIP Telephone Service: A type of service that offer= s > communication over internet protocol, such as Fixed, Nomadic, Mobile, > Unknown". Section 6.3 does not register "Unknown" as an allowable > value, yet section 6.4 requires the element t= o > be included in the element. I think that it needs > to include a value of unknown in the register. > > > > I added the "Unknown" category. > > > >> > >> Section 8.2. This schema has a sequence with one element in it, and > this element is optional. This doesn't make much sense. > >> > > With the added extension point there may be more elements in there in > the future. > > > >> None 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 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. > > Brian added those; will double-check. > > > >> > >> NITS > >> =3D=3D=3D=3D=3D > >> Page 5 second paragraph has a PDIF-LO rather than a PIDF-LO > > > > fixed. > > > > Ciao > > Hannes > > > >> > >> > >> Cheers > >> James > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From James.Winterbottom@commscope.com Tue Apr 30 16:59: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 B6FE921F843A for ; Tue, 30 Apr 2013 16:59:45 -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=[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 K-6JpVuR-G0F for ; Tue, 30 Apr 2013 16:59:41 -0700 (PDT) Received: from cdcsmgw02.commscope.com (cdcsmgw02.commscope.com [198.135.207.233]) by ietfa.amsl.com (Postfix) with ESMTP id 62FA621F8442 for ; Tue, 30 Apr 2013 16:59:41 -0700 (PDT) X-AuditID: 0a0404e9-b7f996d000000830-fa-51805aec13e7 Received: from CDCE10HC1.commscope.com ( [10.86.28.21]) by cdcsmgw02.commscope.com (Symantec Messaging Gateway) with SMTP id 0F.40.02096.CEA50815; Tue, 30 Apr 2013 18:59:40 -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, 30 Apr 2013 18:59:39 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 1 May 2013 07:59:37 +0800 From: "Winterbottom, James" To: "DRAGE, Keith (Keith)" , Brian Rosen , Hannes Tschofenig Date: Wed, 1 May 2013 07:59:35 +0800 Thread-Topic: [Ecrit] draft-ietf-ecrit-additional-data-07 Thread-Index: Ac5Fqv50SXJMFUMTT1GkNmF5EDCSzAASkidAAAGlvmAAALFNYA== Message-ID: <5A55A45AE77F5941B18E5457ECAC8188012140958BEB@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC818801214088303D@SISPE7MB1.commscope.com> <2B303721-4B60-4A10-BD16-18149CBED50C@gmx.net> <30EDA794-B34C-4239-842E-429229DDF55E@brianrosen.net> <5A55A45AE77F5941B18E5457ECAC8188012140958BE6@SISPE7MB1.commscope.com> <949EF20990823C4C85C18D59AA11AD8B031051@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B031051@FR712WXCHMBA11.zeu.alcatel-lucent.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: H4sIAAAAAAAAA02SfUgTYRzHeW538xyenVPzyYJgFEWmaRTMMBH/shRxpZb2R17b6RZ7405N TWgqJb2RFKTNP3yPCGtDMXxFUSKcmVFMM8OpewE3Qwksg9Ludmr77/Pc9/v7fn8P9+Ai6SIW jWv0xTSjp7QysQSV5B6IjF3JNyniJxag3O14KpZXtboxeUffPCZ3V02CFDTttmcIS3P8/BuU 1tY1LE5rb/+NZKH5kiQVrdWU0syJ5AKJ2vZqQWxcTSwb8NmDTKAu7h4IxiF5Cjrq58QC74Uf 5y0cS3Ap2Q9gd80jRDhYARwZWds+vAawcdiO8iNiMhmOWb6IeCGCfAhgjXMD4wUReRh+qHL6 TSh5CC71Dfq/h5NyuNw+jfAcQSZCe6NDLHAqdLXO+5kgL8AW97vtPewI9HR8CuKFYPIKXL0z BngG3LK/bJ2IUBYFv7qaEOESJGwfnBIJHAmXnZuY4I+E32otQPAfh80DP8QCx8DnLT6RUBwG x5+5/EtLyVhY3beO1QFoDqgwB4ybA8bNAePNAH0JopQqJasruhF/Mk5p0OlYpcFI89QF+D+K osu9YNIaMwpIHMhCiLDPtxRSjCply3WjYB+OyCKJmUsmhTT0mkFVrqZY9VWmREuzowDiIlkE kbHI2QkVVV5BM4Yd6SiOkxMuhw1Eo3qDnpZBojaPiwhj6CK6rFCj5R7UjhXBg/moEC7KyHsI 1kjpWE2RoNtADG7ucfkA/qJ72Qek/rjoKOI+byV5q7pEv5vmBVHcFcIJDa+GcO92N8fLVSBc RV8Fvy1bTP2Xok0gdehyy/qRgqX3U3NnLNMgQWVwZv4Zn9nTpqRC1ypns8OrswydqwcfZJf0 179N9rpOm1NBSoYn881Ga0Od5bp11pM+XY4ZzvpGNgcbem4Wlj7uHbd2L2at2O4y57xzWzn7 TVtPGjpyHJUhG7nxF1kFk+fqsTPO4qak8znp2u8ylFVTCcdEDEv9A4jZc/B0AwAA 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: Tue, 30 Apr 2013 23:59:45 -0000 That is true Keith, but I can also do a VoIP emergency call using an OTT pr= ovider. In this latter case my provider is only providing a packet data service of = UMTS. Cheers James -----Original Message----- From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]=20 Sent: Wednesday, 1 May 2013 9:43 AM To: Winterbottom, James; Brian Rosen; Hannes Tschofenig Cc: ecrit@ietf.org Subject: RE: [Ecrit] draft-ietf-ecrit-additional-data-07 Is it a clean differentiation. Your 3G phone currently can handle emergency data using a modem running ove= r the CS domain and you 3G phone can also support voice services using IMS = over GPRS. Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=20 > Of Winterbottom, James > Sent: 30 April 2013 23:59 > To: Brian Rosen; Hannes Tschofenig > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-07 >=20 > I think you are hung-up on the term high-level, my implication is more=20 > that these are higher-level than FTTH, coax, twisted-pair, GSM, UMTS. >=20 > What I want/need the distinction between is a packet service and a=20 > circuit service both of which can run on the same kind of "physical"=20 > access. My 3G UMTS-based phone can operate in circuit-switched mode=20 > for calls or in > HSDPA+ packet-mode for data services. Both of these come from the same > operator. My iPad however is HSDPA+ only, and so is only a packet device. >=20 > This differentiation cannot be cleanly represented in the current=20 > representation. >=20 > What I tried to provide was a way to represent this, I am open to=20 > other representations providing they don't ram them all into the same=20 > enumerated type. >=20 > Cheers > James >=20 >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, 1 May 2013 12:00 AM > To: Hannes Tschofenig > Cc: Winterbottom, James; ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-07 >=20 > I have a problem with "packet data" as a high level service. That's=20 > really a low level service grouping (DSL, FTTH), not a high level service= . > Vonage, AIM, Google Talk, those are the high level services, and none=20 > of them are "packet data". >=20 > Brian > On Apr 29, 2013, at 5:22 PM, Hannes Tschofenig=20 > > wrote: >=20 > > Hi James, > > > > I am trying to incorporate some of your review comments and I have a > couple of questions. > > > > On Mar 18, 2013, at 5:41 AM, Winterbottom, James wrote: > > > >> Hi Authors, > >> > >> I have reviewed this document and have the following comments, some=20 > >> of > which 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 but the term doesn't seem to be obviously defined in the=20 > document, nor is there is a reference to an external definition. To=20 > add to this, Service Provider is a defined type in section 14.1.2, but=20 > used more generally throughout the rest of the document. This needs a cla= rification. > > > > I searched for an appropriate definition in IETF RFCs and it turns=20 > > out > that others have defined this term either. > > > > Do you have a recommendation what we should use? Do you think it is > really necessary to describe it? > > > >> > >> Section 6.2 seems to conflate several different concepts. I think=20 > >> that > this because it bundles access technologies and telephone service=20 > type, though I suspect that it doesn't mean to, but in so doing it=20 > left me quite confused and when I tried to describe a DOCSIS, Fibre or=20 > DSL service I couldn't. Here is a proposal to address the current=20 > 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-level=20 > application run over the access technology, call it applicationType or=20 > something similar. > >> 2) Create a registry for accessTechnology at a minimum it would > have what is currently under the "Wireless Telephone System" field and=20 > 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,=20 > 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=20 > of the document. > >> > >> I think it would be worth emphasizing in this section that the=20 > >> nature > of the physical access technology does not necessarily dictate the=20 > mobility of the call. > >> > >> In section 6.2, the definition for VoIP needs to be decoupled from=20 > >> the > access technology constraints, these are addressed in section 6.3. > > > > I passed this question forward to the NENA additional data group and=20 > > to > the EENA NG 112 group. > > > >> > >> Section 6.3, for Nomadic, please can you emphasize that it cannot > change its point of network attachment. This does not necessarily mean=20 > that the device cannot move. > > > > I added this text. > > > >> > >> Section 6.2 says "VoIP Telephone Service: A type of service that=20 > >> offers > communication over internet protocol, such as Fixed, Nomadic, Mobile,=20 > Unknown". Section 6.3 does not register "Unknown" as an allowable=20 > value, yet section 6.4 requires the =20 > element to be included in the element. I think=20 > that it needs to include a value of unknown in the register= . > > > > I added the "Unknown" category. > > > >> > >> Section 8.2. This schema has a sequence with one element in it, and > this element is optional. This doesn't make much sense. > >> > > With the added extension point there may be more elements in there=20 > > in > the future. > > > >> None of the schemas have extension points. While some of the=20 > >> discourse > on the list over the last few days might suggest that this was=20 > deliberate, the discussion as I have followed it has been more to do=20 > with adding new blocks than it has been to allowing localized=20 > extensions to already defined blocks. > > Brian added those; will double-check. > > > >> > >> NITS > >> =3D=3D=3D=3D=3D > >> Page 5 second paragraph has a PDIF-LO rather than a PIDF-LO > > > > fixed. > > > > Ciao > > Hannes > > > >> > >> > >> Cheers > >> James > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit