From ecrit-bounces@ietf.org Thu Jun 09 12:38:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgQ2s-0001Vg-F2; Thu, 09 Jun 2005 12:38:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgPfw-0004g9-Rn for ecrit@megatron.ietf.org; Thu, 09 Jun 2005 12:14:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17781 for ; Thu, 9 Jun 2005 12:14:34 -0400 (EDT) Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DgQ1R-0002IH-EC for ecrit@ietf.org; Thu, 09 Jun 2005 12:36:49 -0400 Received: (qmail 43652 invoked by uid 1014); 9 Jun 2005 16:14:24 -0000 Received: from mtam@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.83. spamassassin: 2.63. Clear:RC:1(65.202.222.12):. Processed in 0.060999 secs); 09 Jun 2005 16:14:24 -0000 Received: from unknown (HELO exchange.corp.sentito.com) (65.202.222.12) by airwolf.sentito.com with SMTP; 9 Jun 2005 16:14:24 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 9 Jun 2005 12:14:17 -0400 Message-ID: Thread-Topic: The "sos" draft Thread-Index: AcVtDklT3t+cZG9pQ96kV2sJ9YqVDA== From: "Mimi Tam" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 X-Mailman-Approved-At: Thu, 09 Jun 2005 12:38:17 -0400 Subject: [Ecrit] The "sos" draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2058573406==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============2058573406== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56D0E.4D2D6401" This is a multi-part message in MIME format. ------_=_NextPart_001_01C56D0E.4D2D6401 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi there, =20 I saw Richard Stastny's mentioning of this "sos" draft in the ECRIT mail archive (excerpted below), where can I find this "sos" draft, please? =20 p.s. sent query e-mail to Richard but mail got bounced back. =20 Thanks very much in advance for your help...Mimi=20 =20 =20 =20 Stastny Richard wrote: > I basically like this approach, because it also contains the > possiblitly to deviate at any point to national specifics and > also to feed into national specific TDM solutions via ESRP > acting as gateways, hiding the mapping and routing required > totally from IP based emergency calls. >=20 > Just a minor question (maybe I missed it, I was recently busy > with other things and trying to catch up): >=20 > What is the meaning of the somebody and foo userparts in the > sip URI.? Shouldn't this be sos or sos:fire? =20 Not necessarily. The 'sos' designation is only necessary until the call reaches the first ESRP. After that, the receiving ESRPs presumably can recognize the limited set of URLs as being an emergency service vs. the general PSAP administrator. Obviously, there's nothing wrong with using sip:sos at emergency.ny.gov. =20 Implementations clearly have to be careful not to lose information, e.g., about the emergency service originally requested, for jurisdictions where fire and police, for example, use different identifiers. The media feature tag (sip.emergency-service) described in the 'sos' draft can ensure that. =20 =20 ------_=_NextPart_001_01C56D0E.4D2D6401 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi =
there,
 
I saw =
Richard Stastny’s mentioning of this “sos” draft in =
the ECRIT mail archive (excerpted below), where can I find this =
“sos” draft, =
please?
 
p.s. sent =
query e-mail to Richard but mail got bounced =
back.
 
Thanks =
very much in advance for your help…Mimi =

 
 
 
Stastny =
Richard wrote:
> I =
basically like this approach, because it also contains =
the
> =
possiblitly to deviate at any point to national specifics =
and
> also =
to feed into national specific TDM solutions via =
ESRP
> =
acting as gateways, hiding the mapping and routing =
required
> =
totally from IP based emergency =
calls.
> =

> Just =
a minor question (maybe I missed it, I was recently =
busy
> with =
other things and trying to catch =
up):
> =

> What =
is the meaning of the somebody and foo userparts in =
the
> sip =
URI.? Shouldn't this be sos or =
sos:fire?
 
Not =
necessarily. The 'sos' designation is only necessary until the =
call
reaches =
the first ESRP. After that, the receiving ESRPs presumably =
can
recognize =
the limited set of URLs as being an emergency service vs. =
the
general =
PSAP administrator. Obviously, there's nothing wrong with =
using
sip:sos =
at emergency.ny.gov.
 
Implementations clearly have to be careful =
not to lose information,
e.g., =
about the emergency service originally requested, =
for
jurisdictions where fire and police, for =
example, use different
identifiers. The media feature tag =
(sip.emergency-service) described =
in
the 'sos' =
draft can ensure that.

 

 

------_=_NextPart_001_01C56D0E.4D2D6401-- --===============2058573406== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============2058573406==-- From ecrit-bounces@ietf.org Thu Jun 09 14:02:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgRMa-0002Sa-Vw; Thu, 09 Jun 2005 14:02:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgRMZ-0002SV-Le for ecrit@megatron.ietf.org; Thu, 09 Jun 2005 14:02:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29585 for ; Thu, 9 Jun 2005 14:02:42 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgRi5-0000Yk-6j for ecrit@ietf.org; Thu, 09 Jun 2005 14:24:57 -0400 Received: from [192.168.1.56] ([212.122.58.178]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j59I2aCl008129 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 9 Jun 2005 14:02:38 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <82AFBD19-3879-419F-8FF4-83773259251C@cs.columbia.edu> Content-Transfer-Encoding: quoted-printable From: Henning Schulzrinne Subject: Re: [Ecrit] The "sos" draft Date: Thu, 9 Jun 2005 14:03:09 -0400 To: Mimi Tam X-Mailer: Apple Mail (2.728) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org It needs to be revived, but it's at http://www.cs.columbia.edu/sip/=20 drafts/sipping/draft-ietf-sipping-sos-00.txt On Jun 9, 2005, at 12:14 PM, Mimi Tam wrote: > Hi there, I saw Richard Stastny=92s mentioning of this =93sos=94 draft = in =20 > the ECRIT mail archive (excerpted below), where can I find this =20 > =93sos=94 draft, please? p.s. sent query e-mail to Richard but mail = got =20 > bounced back. Thanks very much in advance for your help=85Mimi =20 > Stastny Richard wrote:> I basically like this approach, because it =20 > also contains the> possiblitly to deviate at any point to national =20 > specifics and> also to feed into national specific TDM solutions =20 > via ESRP> acting as gateways, hiding the mapping and routing =20 > required> totally from IP based emergency calls.> > Just a minor =20 > question (maybe I missed it, I was recently busy> with other things =20= > and trying to catch up):> > What is the meaning of the somebody and =20= > foo userparts in the> sip URI.? Shouldn't this be sos or sos:fire? =20 > Not necessarily. The 'sos' designation is only necessary until the =20 > callreaches the first ESRP. After that, the receiving ESRPs =20 > presumably canrecognize the limited set of URLs as being an =20 > emergency service vs. thegeneral PSAP administrator. Obviously, =20 > there's nothing wrong with usingsip:sos at emergency.ny.gov. =20 > Implementations clearly have to be careful not to lose =20 > information,e.g., about the emergency service originally requested, =20= > forjurisdictions where fire and police, for example, use =20 > differentidentifiers. The media feature tag (sip.emergency-service) =20= > described inthe 'sos' draft can ensure that. > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 14 08:28:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiAX0-0005sL-BT; Tue, 14 Jun 2005 08:28:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhtdA-00075y-1C for ecrit@megatron.ietf.org; Mon, 13 Jun 2005 14:25:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05878 for ; Mon, 13 Jun 2005 14:25:50 -0400 (EDT) Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DhtzT-0001hd-LG for ecrit@ietf.org; Mon, 13 Jun 2005 14:48:57 -0400 Received: (qmail 23070 invoked by uid 1014); 13 Jun 2005 18:25:22 -0000 Received: from mtam@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.83. spamassassin: 2.63. Clear:RC:1(65.202.222.12):. Processed in 0.051013 secs); 13 Jun 2005 18:25:22 -0000 Received: from unknown (HELO exchange.corp.sentito.com) (65.202.222.12) by airwolf.sentito.com with SMTP; 13 Jun 2005 18:25:22 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 13 Jun 2005 14:27:20 -0400 Message-ID: Thread-Topic: SIP to CAS/MF CAMA trunks Thread-Index: AcVwRYlZazDTDhhISyC6+7t4kDrWxQ== From: "Mimi Tam" To: "ECRIT" X-Spam-Score: 0.1 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 X-Mailman-Approved-At: Tue, 14 Jun 2005 08:28:37 -0400 Subject: [Ecrit] SIP to CAS/MF CAMA trunks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1855341039==" Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1855341039== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57045.42C4554D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C57045.42C4554D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have a SIP E9-1-1 caller to an End Office which directed the call to a SIP Proxy sitting in front of a packet network where a CAMA trunk is connected to an E9-1-1 Tandem. =20 The originated 911 call is via VoIP and is in SIP. Signaling comes into this packet network and gets converted to in-band CAS/MF R1 Signaling before being trunked onto this CAMA trunk connected to the E9-1-1 Office. =20 My question is how can the Location info be converted into CAS/MF Signaling onto this CAMA trunk? =20 Thanks very much in advance....Mimi ------_=_NextPart_001_01C57045.42C4554D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have a SIP E9-1-1 caller to an End Office which = directed the call to a SIP Proxy sitting in front of a packet network where a = CAMA trunk is connected to an E9-1-1 Tandem.

 

The originated 911 call is via VoIP and is in SIP. = Signaling comes into this packet network and gets converted to in-band CAS/MF R1 Signaling before being trunked onto this CAMA trunk connected to the = E9-1-1 Office.

 

My question is how can the Location info be converted = into CAS/MF Signaling onto this CAMA trunk?

 

Thanks very much in = advance….Mimi

------_=_NextPart_001_01C57045.42C4554D-- --===============1855341039== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1855341039==-- From ecrit-bounces@ietf.org Tue Jun 14 08:58:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiB06-0002S0-3d; Tue, 14 Jun 2005 08:58:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiB03-0002Rc-Ph for ecrit@megatron.ietf.org; Tue, 14 Jun 2005 08:58:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10954 for ; Tue, 14 Jun 2005 08:58:38 -0400 (EDT) Received: from mta3.prod1.dngr.net ([216.220.209.222] helo=mfe2.prod.danger.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiBMX-0006VU-Ca for ecrit@ietf.org; Tue, 14 Jun 2005 09:21:54 -0400 Received: from [10.253.3.252] (HELO localhost.localdomain) by mfe2.prod.danger.com (CommuniGate Pro SMTP 4.1.6) with ESMTP id 315603114; Tue, 14 Jun 2005 05:58:14 -0700 Date: Tue, 14 Jun 2005 08:58:12 -0400 Subject: Re: [Ecrit] SIP to CAS/MF CAMA trunks X-Mailer: Danger Service Content-Transfer-Encoding: 7bit In-Reply-To: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Mimi Tam , ECRIT Mime-Version: 1.0 References: From: Brian Rosen Message-Id: <1118753894.1D9F587B@dk12.dngr.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org It can't. Location doesn't come across the CAMA trunk. You have to take off the location and make it show up in the ALI database query. See the NENA i2 solutionb for how this will work. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 14 10:23:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiCK0-0000Iv-C4; Tue, 14 Jun 2005 10:23:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiByD-00051u-Qc for ecrit@megatron.ietf.org; Tue, 14 Jun 2005 10:00:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19422 for ; Tue, 14 Jun 2005 10:00:48 -0400 (EDT) Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DiCKh-0002gL-Hu for ecrit@ietf.org; Tue, 14 Jun 2005 10:24:05 -0400 Received: (qmail 1681 invoked by uid 1014); 14 Jun 2005 14:00:36 -0000 Received: from mtam@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.83. spamassassin: 2.63. Clear:RC:1(65.202.222.12):. Processed in 0.129536 secs); 14 Jun 2005 14:00:36 -0000 Received: from unknown (HELO exchange.corp.sentito.com) (65.202.222.12) by airwolf.sentito.com with SMTP; 14 Jun 2005 14:00:35 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Which NENA i2, please? -- (RE: [Ecrit] SIP to CAS/MF CAMA trunks) Date: Tue, 14 Jun 2005 10:02:33 -0400 Message-ID: Thread-Topic: Which NENA i2, please? -- (RE: [Ecrit] SIP to CAS/MF CAMA trunks) Thread-Index: AcVw4MiM/LKyF140Twq9ybfzCRe81wACHSEQ From: "Mimi Tam" To: "Brian Rosen" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 14 Jun 2005 10:23:19 -0400 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Thanks so much Brian for the confirmation. I did look at NENA Specs but did not come across the specifics on how Location should be made to show up in the ALI database query. Could you provide me a link to the NENA i2 Spec with the solutionb that you mentioned in your previous e-mail? Thanks again & much obliged...Mimi -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, June 14, 2005 8:58 AM To: Mimi Tam; ECRIT Subject: Re: [Ecrit] SIP to CAS/MF CAMA trunks It can't. Location doesn't come across the CAMA trunk. You have to take off the location and make it show up in the ALI database query. See the=20 NENA i2 solutionb for how this will work. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 14 16:09:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiHjS-00082i-2V; Tue, 14 Jun 2005 16:09:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiHjP-00082P-Rh for ecrit@megatron.ietf.org; Tue, 14 Jun 2005 16:09:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26540 for ; Tue, 14 Jun 2005 16:09:54 -0400 (EDT) Message-Id: <200506142009.QAA26540@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiI5y-0004iZ-5T for ecrit@ietf.org; Tue, 14 Jun 2005 16:33:14 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DiHj8-00032h-DA; Tue, 14 Jun 2005 15:09:38 -0500 From: "Brian Rosen" To: "'Mimi Tam'" , "'ECRIT'" Subject: RE: Which NENA i2, please? -- (RE: [Ecrit] SIP to CAS/MF CAMA trunks) Date: Tue, 14 Jun 2005 16:09:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcVw4MiM/LKyF140Twq9ybfzCRe81wACHSEQAAyDDVA= In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org The i2 spec is still in NENA internal review and is not available on the public website yet, sorry. Briefly, a special service provider called a "VoIP Positioning Center" will take the location from the caller and consult a database that returns a route to the correct PSAP from a street address. It will also retain the location for subsequent ALI query. It returns the route code and an "Emergency Services Query Key" which the VoIP carrier uses as ANI when the call is placed through the gateway to the correct selective router. The ESQK will cause the call to be routed to the right gateway and thence to the right PSAP. Since it is ANI, the PSAP will query the ALI with the ESQK. The ALI database provider will steer the query to the VPC that allocated the ESQK, and the VPC will respond with the location of the caller. This is very similar to how mobile E911 works in North America (the Mobile Position Center -MPC- allocates an ESRK to a call, which is steered back to it for response). The interface between the ALI and the MPC/VPC is called "e2+" and is documented in NENA 05-001, which is on the NENA website. We don't expect most VoIP carriers to run their own VPCs, because among other things, a VPC needs a relationship with 6000+ PSAPs for nationwide coverage, but they could. The interface between the VoIP carrier and the VPC could be all SIP (with location in a PIDF-LO) or what the i2 spec calls the "V2" interface which is an XML based query (location in, route code and ESQK out). This is all very North American centric and out of scope for ecrit. Brian -----Original Message----- From: Mimi Tam [mailto:mtam@sentito.com] Sent: Tuesday, June 14, 2005 10:03 AM To: Brian Rosen; ECRIT Subject: Which NENA i2, please? -- (RE: [Ecrit] SIP to CAS/MF CAMA trunks) Thanks so much Brian for the confirmation. I did look at NENA Specs but did not come across the specifics on how Location should be made to show up in the ALI database query. Could you provide me a link to the NENA i2 Spec with the solutionb that you mentioned in your previous e-mail? Thanks again & much obliged...Mimi -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, June 14, 2005 8:58 AM To: Mimi Tam; ECRIT Subject: Re: [Ecrit] SIP to CAS/MF CAMA trunks It can't. Location doesn't come across the CAMA trunk. You have to take off the location and make it show up in the ALI database query. See the NENA i2 solutionb for how this will work. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 16 12:46:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DixVa-0005wj-Ad; Thu, 16 Jun 2005 12:46:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DixVZ-0005wU-2b for ecrit@megatron.ietf.org; Thu, 16 Jun 2005 12:46:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09697 for ; Thu, 16 Jun 2005 12:46:18 -0400 (EDT) Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DixsS-0003kM-Rj for ecrit@ietf.org; Thu, 16 Jun 2005 13:10:07 -0400 Received: (qmail 79702 invoked by uid 1014); 16 Jun 2005 16:46:05 -0000 Received: from mtam@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.83. spamassassin: 2.63. Clear:RC:1(65.202.222.12):. Processed in 0.03797 secs); 16 Jun 2005 16:46:05 -0000 Received: from unknown (HELO exchange.corp.sentito.com) (65.202.222.12) by airwolf.sentito.com with SMTP; 16 Jun 2005 16:46:05 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Jun 2005 12:46:01 -0400 Message-ID: Thread-Topic: SIP End Office Feature Server/Registrar sending out LNP or subscribed#? Thread-Index: AcVw4MiM/LKyF140Twq9ybfzCRe81wACHSEQAAyDDVAAXY62gA== From: "Mimi Tam" To: "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] SIP End Office Feature Server/Registrar sending out LNP or subscribed#? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Will a SIP Feature Server where a SIP endpoint is registered to and made a 911 call sends out the LNP# in the INVITE as the caller's number or the subscriber# that a VoIP carrier provides? If it sends out the subscriber# on the original INVITE, a routing Proxy on the call path will have to look up a database to find a match for this subscriber# to get the LNP to use as the DN/ANI to be outpulsed out to say, a CAMA trunk down the line to a PSAP. Any info on this will be much appreciated. Thanks...Mimi Tam -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, June 14, 2005 4:10 PM To: Mimi Tam; 'ECRIT' Subject: RE: Which NENA i2, please? -- (RE: [Ecrit] SIP to CAS/MF CAMA trunks) The i2 spec is still in NENA internal review and is not available on the public website yet, sorry. Briefly, a special service provider called a "VoIP Positioning Center" will take the location from the caller and consult a database that returns a route to the correct PSAP from a street address. It will also retain the location for subsequent ALI query. It returns the route code and an "Emergency Services Query Key" which the VoIP carrier uses as ANI when the call is placed through the gateway to the correct selective router. The ESQK will cause the call to be routed to the right gateway and thence to the right PSAP. Since it is ANI, the PSAP will query the ALI with the ESQK. The ALI database provider will steer the query to the VPC that allocated the ESQK, and the VPC will respond with the location of the caller. This is very similar to how mobile E911 works in North America (the Mobile Position Center -MPC- allocates an ESRK to a call, which is steered back to it for response). The interface between the ALI and the MPC/VPC is called "e2+" and is documented in NENA 05-001, which is on the NENA website. We don't expect most VoIP carriers to run their own VPCs, because among other things, a VPC needs a relationship with 6000+ PSAPs for nationwide coverage, but they could. The interface between the VoIP carrier and the VPC could be all SIP (with location in a PIDF-LO) or what the i2 spec calls the "V2" interface which is an XML based query (location in, route code and ESQK out). This is all very North American centric and out of scope for ecrit. Brian -----Original Message----- From: Mimi Tam [mailto:mtam@sentito.com]=20 Sent: Tuesday, June 14, 2005 10:03 AM To: Brian Rosen; ECRIT Subject: Which NENA i2, please? -- (RE: [Ecrit] SIP to CAS/MF CAMA trunks) Thanks so much Brian for the confirmation. I did look at NENA Specs but did not come across the specifics on how Location should be made to show up in the ALI database query. Could you provide me a link to the NENA i2 Spec with the solutionb that you mentioned in your previous e-mail? Thanks again & much obliged...Mimi -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, June 14, 2005 8:58 AM To: Mimi Tam; ECRIT Subject: Re: [Ecrit] SIP to CAS/MF CAMA trunks It can't. Location doesn't come across the CAMA trunk. You have to take off the location and make it show up in the ALI database query. See the=20 NENA i2 solutionb for how this will work. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 16 12:59:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dixhr-0000LO-7N; Thu, 16 Jun 2005 12:59:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dixhp-0000JU-EQ for ecrit@megatron.ietf.org; Thu, 16 Jun 2005 12:59:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10813 for ; Thu, 16 Jun 2005 12:58:59 -0400 (EDT) Message-Id: <200506161658.MAA10813@ietf.org> Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Diy4l-0004SS-Cp for ecrit@ietf.org; Thu, 16 Jun 2005 13:22:47 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp) by dx28.winwebhosting.com with esmtpa (Exim 4.44) id 1DixhT-00087g-B5; Thu, 16 Jun 2005 11:58:43 -0500 From: "Brian Rosen" To: "'Mimi Tam'" , "'ECRIT'" Subject: RE: [Ecrit] SIP End Office Feature Server/Registrar sending out LNP orsubscribed#? Date: Thu, 16 Jun 2005 12:58:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcVw4MiM/LKyF140Twq9ybfzCRe81wACHSEQAAyDDVAAXY62gAAAjGxA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org You really need to get these questions answered on a NENA list, and not this list. You use the subscribers actual phone number in the "From:". There are fields in the SS7 for both the subscribers number, used as the call back number, and the ESQK query key which will be used for the ALI dip. There would not be an entry in the ALI for the subscriber because most VoIP systems allow both nomadic operation and non-local TN assignment. LNP is the least of the problems. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Mimi Tam Sent: Thursday, June 16, 2005 12:46 PM To: ECRIT Subject: [Ecrit] SIP End Office Feature Server/Registrar sending out LNP orsubscribed#? Will a SIP Feature Server where a SIP endpoint is registered to and made a 911 call sends out the LNP# in the INVITE as the caller's number or the subscriber# that a VoIP carrier provides? If it sends out the subscriber# on the original INVITE, a routing Proxy on the call path will have to look up a database to find a match for this subscriber# to get the LNP to use as the DN/ANI to be outpulsed out to say, a CAMA trunk down the line to a PSAP. Any info on this will be much appreciated. Thanks...Mimi Tam -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, June 14, 2005 4:10 PM To: Mimi Tam; 'ECRIT' Subject: RE: Which NENA i2, please? -- (RE: [Ecrit] SIP to CAS/MF CAMA trunks) The i2 spec is still in NENA internal review and is not available on the public website yet, sorry. Briefly, a special service provider called a "VoIP Positioning Center" will take the location from the caller and consult a database that returns a route to the correct PSAP from a street address. It will also retain the location for subsequent ALI query. It returns the route code and an "Emergency Services Query Key" which the VoIP carrier uses as ANI when the call is placed through the gateway to the correct selective router. The ESQK will cause the call to be routed to the right gateway and thence to the right PSAP. Since it is ANI, the PSAP will query the ALI with the ESQK. The ALI database provider will steer the query to the VPC that allocated the ESQK, and the VPC will respond with the location of the caller. This is very similar to how mobile E911 works in North America (the Mobile Position Center -MPC- allocates an ESRK to a call, which is steered back to it for response). The interface between the ALI and the MPC/VPC is called "e2+" and is documented in NENA 05-001, which is on the NENA website. We don't expect most VoIP carriers to run their own VPCs, because among other things, a VPC needs a relationship with 6000+ PSAPs for nationwide coverage, but they could. The interface between the VoIP carrier and the VPC could be all SIP (with location in a PIDF-LO) or what the i2 spec calls the "V2" interface which is an XML based query (location in, route code and ESQK out). This is all very North American centric and out of scope for ecrit. Brian -----Original Message----- From: Mimi Tam [mailto:mtam@sentito.com] Sent: Tuesday, June 14, 2005 10:03 AM To: Brian Rosen; ECRIT Subject: Which NENA i2, please? -- (RE: [Ecrit] SIP to CAS/MF CAMA trunks) Thanks so much Brian for the confirmation. I did look at NENA Specs but did not come across the specifics on how Location should be made to show up in the ALI database query. Could you provide me a link to the NENA i2 Spec with the solutionb that you mentioned in your previous e-mail? Thanks again & much obliged...Mimi -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, June 14, 2005 8:58 AM To: Mimi Tam; ECRIT Subject: Re: [Ecrit] SIP to CAS/MF CAMA trunks It can't. Location doesn't come across the CAMA trunk. You have to take off the location and make it show up in the ALI database query. See the NENA i2 solutionb for how this will work. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 21 20:25:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkt3Q-0006cX-9h; Tue, 21 Jun 2005 20:25:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkt3O-0006cP-Jz for ecrit@megatron.ietf.org; Tue, 21 Jun 2005 20:25:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00628 for ; Tue, 21 Jun 2005 20:25:17 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DktRN-00043p-Tm for ecrit@ietf.org; Tue, 21 Jun 2005 20:50:08 -0400 Received: from [192.168.0.31] (pool-141-153-173-119.mad.east.verizon.net [141.153.173.119]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5M0PEW7003536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 21 Jun 2005 20:25:15 -0400 (EDT) Message-ID: <42B8AFEE.4090209@cs.columbia.edu> Date: Tue, 21 Jun 2005 20:25:18 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ECRIT WG Content-Type: multipart/mixed; boundary="------------060403010401060605000105" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 3.1 (+++) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Subject: [Ecrit] [Fwd: I-D ACTION:draft-schulzrinne-ecrit-lump-00.txt] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --------------060403010401060605000105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I submitted a very drafty draft that tries to distill some of the discussion items from the recent interim meeting into a location-to-URL mapping protocol. Short summary: Describes an architecture of how to build a global resolution system that scales, is deployable and can be made reliable without "and then magic happens" and without waiting for a "root" to be agreed upon. Uses SOAP since I didn't want to invent yet another RPC-like protocol. I intentionally left out the WSDL details as those are relatively easy to add later. I suspect terminology and description need a fair amount of work, so I'd appreciate both comments on the approach and requests for clarification (or suggestions). Henning --------------060403010401060605000105 Content-Type: message/rfc822; name="I-D ACTION:draft-schulzrinne-ecrit-lump-00.txt" Content-Disposition: inline; filename="I-D ACTION:draft-schulzrinne-ecrit-lump-00.txt" Return-Path: Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by papermate.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j5LK7gtN006419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Jun 2005 16:07:42 -0400 (EDT) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j5LK7XSZ023921; Tue, 21 Jun 2005 16:07:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkom2-0005Ob-Mz; Tue, 21 Jun 2005 15:51:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkolE-0005CA-QA for i-d-announce@megatron.ietf.org; Tue, 21 Jun 2005 15:50:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24798 for ; Tue, 21 Jun 2005 15:50:15 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dkp90-0007R6-2I for i-d-announce@ietf.org; Tue, 21 Jun 2005 16:14:50 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dkol0-0002ZA-0v for i-d-announce@ietf.org; Tue, 21 Jun 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 21 Jun 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: I-D ACTION:draft-schulzrinne-ecrit-lump-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.6.21.25 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Location-to-URL Mapping Protocol (LUMP) Author(s) : H. Schulzrinne Filename : draft-schulzrinne-ecrit-lump-00.txt Pages : 19 Date : 2005-6-21 LUMP (Location-to-URL Mapping Protocol) maps geographic locations, described as PIDF-LO objects containing civic or geospatial information, to one or more URLs. It is based on a standard RPC mechanism and supports updates. Clusters are used to ensure scaling and reliability. A flooding mechanism distributes top-level routing information. Naming authority can be delegated in any tree-like fashion, with multiple independent authorities for each level. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-lump-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-schulzrinne-ecrit-lump-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-schulzrinne-ecrit-lump-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-21123725.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-schulzrinne-ecrit-lump-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-schulzrinne-ecrit-lump-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-21123725.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --------------060403010401060605000105 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --------------060403010401060605000105-- From ecrit-bounces@ietf.org Thu Jun 23 04:58:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlNXm-0000OP-Gj; Thu, 23 Jun 2005 04:58:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlNXj-0000OD-BQ for ecrit@megatron.ietf.org; Thu, 23 Jun 2005 04:58:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18092 for ; Thu, 23 Jun 2005 04:58:37 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DlNw0-0008Ss-Kq for ecrit@ietf.org; Thu, 23 Jun 2005 05:23:46 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] [Fwd: I-D ACTION:draft-schulzrinne-ecrit-lump-00.txt] X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 23 Jun 2005 10:57:10 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B2046@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] [Fwd: I-D ACTION:draft-schulzrinne-ecrit-lump-00.txt] Thread-Index: AcV2wW1G/+0+7zgQTBCTlz8V3vexOQBBsUwA From: "Stastny Richard" To: "Henning Schulzrinne" , "ECRIT WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Henning, here my first take on your nice draft on LUMP. I have not come to a final conclusion yet, but I have some=20 questions and remarks (in an unordered list): Resolver architecture and synchronisation: You are basically proposing an architecture different from DNS, but using some of the concepts, as you state=20 on page 5. This will need a great deal on additional protocol and development work to implement behind the scenes.=20 It will also need some basic administrative oversight to link these finally together globally, also you point out this can also be implemented bottom-up. Do you have any ideas already what is required here? VSP? What is a VSP (Voice service Provider?) I thought access to emergency services is more general? Introductory example In your introductory example you are mixing access by end-user, ESRP and VSP proxy, which is very confusing. On one hand the end-user gets the LUMP servers announced by DHCP (I though this is done by the access provider), but he then uses the VSP proxy as "ESRP" t query the resolver. I understand he may query the LUMP server to get the dialstring.emergency, but why is he then not using the LUMP directly? I would also like to see more potential scenarios LUMP system architecture As mentioned above, the LUMP system architecture need to be defined and implemented in a separate RFC, because it should be able to interwork globally Is there any work done already or a prototype implementation? Protocol Operations Query input: services First: the input values possible here need to be standardized Currrently I see dialstring and emergency defined (sos is gone?) Next question: is there a wildcard possible e.g. emergency.* And should the next labels be defined, some of them or none? There should also be a defined name for "general" emergency number (unified?), because a country may have both options. e.g. emergency.fire, emergency.police, etc. is commonly known but others are not. Since it is a national matter to define which short code is treated as access to an emergency service some countries overdid it (e.g. Austria). We have defined 9 (nine) emergency numbers: 112 - unified - European emergency access -> done by police 122 - fire 133 - police 144 - ambulance 128 - gas emergency 140 - mountain 141 - doctor (Notarzt) 142 - psychologicial (Telefonseelsorge) 147 - kids No, we do not have coast or marine ;-) Since you do not know what they come up with tomorrow, standardization is difficult So IMHO an additional query is necessary: emergency services available, where you do not get the URIs, but the names: e.g query services and you get back the above list: now you may query emergency.kids or dialstring.emergency.kids or you query=20 dialstring.emergency:* and get back the whole list I think this is enough for a first take Best regards Richard Richard Stastny OeFEG tel:+43 664 420 4100 enum:+43 780 203 211 callto://fordprefect http://voipandenum.blogspot.com =20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Henning Schulzrinne > Sent: Wednesday, June 22, 2005 2:25 AM > To: ECRIT WG > Subject: [Ecrit] [Fwd: I-D ACTION:draft-schulzrinne-ecrit-lump-00.txt] >=20 > I submitted a very drafty draft that tries to distill some of the > discussion items from the recent interim meeting into a location-to-URL > mapping protocol. >=20 > Short summary: Describes an architecture of how to build a global > resolution system that scales, is deployable and can be made reliable > without "and then magic happens" and without waiting for a "root" to be > agreed upon. Uses SOAP since I didn't want to invent yet another > RPC-like protocol. >=20 > I intentionally left out the WSDL details as those are relatively easy > to add later. I suspect terminology and description need a fair amount > of work, so I'd appreciate both comments on the approach and requests > for clarification (or suggestions). >=20 > Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 23 15:39:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlXY5-00026V-P7; Thu, 23 Jun 2005 15:39:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlXY4-00025e-3D for ecrit@megatron.ietf.org; Thu, 23 Jun 2005 15:39:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20119 for ; Thu, 23 Jun 2005 15:39:38 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlXwR-0005z4-Qn for ecrit@ietf.org; Thu, 23 Jun 2005 16:04:52 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j5NJdTcB008423 for ; Thu, 23 Jun 2005 21:39:29 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j5NJdToR013431 for ; Thu, 23 Jun 2005 21:39:29 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 23 Jun 2005 21:42:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Jun 2005 21:39:20 +0200 Message-ID: Thread-Topic: FW: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting in Paris, France Thread-Index: AcV4Kz1jWbRVgvGQQAm1kKnXUlu7mA== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 23 Jun 2005 19:42:41.0921 (UTC) FILETIME=[B8331710:01C5782B] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] FW: Internet-Drafts Submission Cutoff Dates for the 63rd IETF Meeting in Paris, France X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org please remember the draft submission deadlines: hannes ------------ There are two (2) Internet-Draft cutoff dates for the 63rd=20 IETF Meeting in Paris, France: July 11th: Cutoff Date for Initial (i.e., version -00)=20 Internet-Draft Submissions=20 All initial Internet-Drafts (version -00) must be submitted by Monday,=20 July 11th at 9:00 AM ET. As always, all initial submissions with a=20 filename beginning with "draft-ietf" must be approved by the=20 appropriate WG Chair before they can be processed or announced. The=20 Secretariat would appreciate receiving WG Chair approval by Tuesday,=20 July 5th at 9:00 AM ET. July 18th: Cutoff Date for Revised (i.e., version -01 and higher)=20 Internet-Draft Submissions=20 All revised Internet-Drafts (version -01 and higher) must be submitted=20 by Monday, July 18th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective=20 cutoff dates will not be made available in the Internet-Drafts=20 directory or announced until on or after Monday, August 1st at 9:00=20 AM ET, when Internet-Draft posting resumes. Please do not wait until=20 the last minute to submit. PLEASE NOTE THE CHANGE OF PROCEDURE: If you submit an initial or=20 revised Internet-Draft after their respective cutoff deadlines, then=20 your document will be retained and posted when Internet-Draft=20 processing resumes. You will no longer be required to resubmit the=20 document. Thank you for your understanding and cooperation. If you have any=20 questions or concerns, then please send a message to=20 internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 63rd IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_63.html. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 23 16:36:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlYQu-00010V-1G; Thu, 23 Jun 2005 16:36:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlYQs-0000ze-G5 for ecrit@megatron.ietf.org; Thu, 23 Jun 2005 16:36:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27637 for ; Thu, 23 Jun 2005 16:36:12 -0400 (EDT) Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlYTy-0001zq-1c for ecrit@ietf.org; Thu, 23 Jun 2005 16:39:31 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id j5NKE2bq001215 for ; Thu, 23 Jun 2005 22:14:02 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j5NKE299001863 for ; Thu, 23 Jun 2005 22:14:02 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 23 Jun 2005 22:17:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Jun 2005 22:14:01 +0200 Message-ID: Thread-Topic: agenda for the paris ecrit meeting Thread-Index: AcV4MBXBf4Fz/H+qR7SbI0seqF8fkQ== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 23 Jun 2005 20:17:22.0828 (UTC) FILETIME=[90844CC0:01C57830] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] agenda for the paris ecrit meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org hi all,=20 we will most likely have a 2 hour slot in paris. we would like to solicit suggestions for agenda items.=20 making progress with the requirements/security work is our highest priority. however, it would also be useful to investigate some issues raised during the interim meeting.=20 ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 23 23:01:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DleRW-0006Gl-MO; Thu, 23 Jun 2005 23:01:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DleRU-0006Gg-I9 for ecrit@megatron.ietf.org; Thu, 23 Jun 2005 23:01:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00066 for ; Thu, 23 Jun 2005 23:01:18 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dlepv-0005Ru-NY for ecrit@ietf.org; Thu, 23 Jun 2005 23:26:36 -0400 Received: from [192.168.0.31] (pool-141-153-173-119.mad.east.verizon.net [141.153.173.119]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5O319r0015196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jun 2005 23:01:18 -0400 (EDT) Message-ID: <42BB7771.6040209@cs.columbia.edu> Date: Thu, 23 Jun 2005 23:01:05 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Ecrit] [Fwd: I-D ACTION:draft-schulzrinne-ecrit-lump-00.txt] References: <32755D354E6B65498C3BD9FD496C7D461B2046@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B2046@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: ECRIT WG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Stastny Richard wrote: Thanks for your comments and questions. Please see some initial answers below. To keep this response (and any response') from becoming a mile long, I'm splitting my response. > Resolver architecture and synchronisation: > > You are basically proposing an architecture different > from DNS, but using some of the concepts, as you state > on page 5. This will > need a great deal on additional protocol and development > work to implement behind the scenes. I'm hoping that this is not the case. I believe that the protocol primitives provided are sufficient to query and update the mapping entries, as well as to replicate the data. Clearly, the WSDL is missing, but if you find fundamental functionality missing, let me know. > It will also need some basic administrative > oversight to link these finally together globally, also you > point out this can also be implemented bottom-up. Do you have > any ideas already what is required here? The basic decision that each node administrator will have to make is whom to peer with (or not). I suspect that's where some amount of administration will be needed, but it's certainly easier than BGP peering. Peering really only requires trusting that the peer has reasonable first-level entries. Robust implementations will need to do some amount of verification to detect overlapping "claims", but the system data at that level is likely to be a lot more static than, say, BGP routing information, as it doesn't depend on dynamic network behavior. > > VSP? > > What is a VSP (Voice service Provider?) I thought > access to emergency services is more general? Agreed; we may need to come up with a more generic term. Maybe CSP (communication service provider) will avoid voice bias. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 23 23:24:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlenz-0001Ab-IR; Thu, 23 Jun 2005 23:24:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlenx-0001AF-T8 for ecrit@megatron.ietf.org; Thu, 23 Jun 2005 23:24:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01748 for ; Thu, 23 Jun 2005 23:24:31 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlfCP-0006QR-33 for ecrit@ietf.org; Thu, 23 Jun 2005 23:49:50 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 23 Jun 2005 20:24:22 -0700 X-IronPort-AV: i="3.93,225,1115017200"; d="scan'208"; a="645594849:sNHT28520108" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j5O3OJvM010954; Thu, 23 Jun 2005 20:24:19 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Jun 2005 20:24:21 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.146.181]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Jun 2005 20:24:20 -0700 Message-Id: <4.3.2.7.2.20050623222214.02af83b8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Jun 2005 22:24:19 -0500 To: Henning Schulzrinne , Stastny Richard From: "James M. Polk" Subject: Re: [Ecrit] [Fwd: I-D ACTION:draft-schulzrinne-ecrit-lump-00.txt] In-Reply-To: <42BB7771.6040209@cs.columbia.edu> References: <32755D354E6B65498C3BD9FD496C7D461B2046@oefeg-s04.oefeg.loc> <32755D354E6B65498C3BD9FD496C7D461B2046@oefeg-s04.oefeg.loc> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 24 Jun 2005 03:24:20.0403 (UTC) FILETIME=[35C80830:01C5786C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ECRIT WG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org At 11:01 PM 6/23/2005 -0400, Henning Schulzrinne wrote: >Stastny Richard wrote: > >>VSP? >>What is a VSP (Voice service Provider?) I thought >>access to emergency services is more general? > >Agreed; we may need to come up with a more generic term. Maybe CSP >(communication service provider) will avoid voice bias. How about MSP (Multimedia Service Provider). This gives a better hint at what the purpose is instead of the perhaps too general "communication" SP >Henning > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit cheers, James ******************* Truth is not to be argued... it is to be presented. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 23 23:28:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlerZ-000292-Ke; Thu, 23 Jun 2005 23:28:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlerX-00028x-Ko for ecrit@megatron.ietf.org; Thu, 23 Jun 2005 23:28:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01933 for ; Thu, 23 Jun 2005 23:28:13 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlfFy-0006eD-VM for ecrit@ietf.org; Thu, 23 Jun 2005 23:53:32 -0400 Received: from [192.168.0.31] (pool-141-153-173-119.mad.east.verizon.net [141.153.173.119]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5O3SC6J017360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Jun 2005 23:28:13 -0400 (EDT) Message-ID: <42BB7DCA.10902@cs.columbia.edu> Date: Thu, 23 Jun 2005 23:28:10 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Ecrit] [Fwd: I-D ACTION:draft-schulzrinne-ecrit-lump-00.txt] References: <32755D354E6B65498C3BD9FD496C7D461B2046@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B2046@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 3.0 (+++) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Content-Transfer-Encoding: 7bit Cc: ECRIT WG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Stastny Richard wrote: > Introductory example > > In your introductory example you are mixing > access by end-user, ESRP and VSP proxy, which is > very confusing. > > On one hand the end-user gets the LUMP servers > announced by DHCP (I though this is done by > the access provider), but he then uses the > VSP proxy as "ESRP" t query the resolver. > > I understand he may query the LUMP server > to get the dialstring.emergency, but why is > he then not using the LUMP directly? > > I would also like to see more potential scenarios Yes, this clearly needs work; there are probably three+ scenarios being conflated into one. > > LUMP system architecture > > As mentioned above, the LUMP system architecture > need to be defined and implemented in a separate > RFC, because it should be able to interwork globally Can you explain a bit more what you mean by "architecture"? I do suspect that there are details of peering that would be handled nationally (e.g., by NENA), but the basic how-do-I-talk-to-my-neighbor should indeed be the same everywhere. > > Is there any work done already or a prototype implementation? Just starting, based on the Apache-related server tools. > > Protocol Operations > > Query input: services > > First: the input values possible here need to be standardized > > Currrently I see dialstring and emergency defined (sos is gone?) Indeed. I'm working on a related draft that describes a service URN, which would be the domain for this field, something like urn:service:sos.fire > > Next question: is there a wildcard possible e.g. emergency.* My current thinking is that 'urn:service:sos' implies a wildcard for all services that are below 'sos', say. I'm reluctant to add explicit wildcards since that tempts strange things like service:dialstring.*.fire, which is not very sensible. > > And should the next labels be defined, some of them or none? > There should also be a defined name for "general" emergency > number (unified?), because a country may have both options. Indeed. In Europe, we'd have something like service:sos --> equivalent to "112" service:sos.gas --> "128" in the US, we'd have service:sos --> "911" PSAP service:sos.fire --> "911" PSAP etc. This will be part of the service URN draft. > > e.g. emergency.fire, emergency.police, etc. is commonly known > but others are not. Since it is a national matter to define > which short code is treated as access to an emergency service > some countries overdid it (e.g. Austria). We have defined 9 (nine) > emergency numbers: > > 112 - unified - European emergency access -> done by police > 122 - fire > 133 - police > 144 - ambulance > 128 - gas emergency > 140 - mountain > 141 - doctor (Notarzt) > 142 - psychologicial (Telefonseelsorge) > 147 - kids > No, we do not have coast or marine ;-) Given that most of the Austrian navy and coast guard probably consists of inflatable warships, this makes sense. > > Since you do not know what they come up with tomorrow, > standardization is difficult I imagine a registry, not standardization. Adding new services is relatively harmless since the assumption is that an unknown service defaults to the "parent" service (i.e., if we were to define a fashion emergency for Italy, sos.fashion would default to sos elsewhere). One could argue for a client-based fallback ("first try sos.fashion, if that fails, try "sos" or instead consult your local department store"). > > So IMHO an additional query is necessary: > emergency services available, where you do not get the URIs, > but the names: > > e.g query services > and you get back the above list: > > now you may query > emergency.kids > or > dialstring.emergency.kids > > or you query > dialstring.emergency:* > > and get back the whole list I can see how this would be useful for dial strings, so that you can populate a user interface with virtual buttons for all the locally available services. > > > I think this is enough for a first take Thanks for the comments. > > Best regards > Richard > > > Richard Stastny > OeFEG > tel:+43 664 420 4100 > enum:+43 780 203 211 > callto://fordprefect > http://voipandenum.blogspot.com > > > >>-----Original Message----- >>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > > Of > >>Henning Schulzrinne >>Sent: Wednesday, June 22, 2005 2:25 AM >>To: ECRIT WG >>Subject: [Ecrit] [Fwd: I-D ACTION:draft-schulzrinne-ecrit-lump-00.txt] >> >>I submitted a very drafty draft that tries to distill some of the >>discussion items from the recent interim meeting into a > > location-to-URL > >>mapping protocol. >> >>Short summary: Describes an architecture of how to build a global >>resolution system that scales, is deployable and can be made reliable >>without "and then magic happens" and without waiting for a "root" to > > be > >>agreed upon. Uses SOAP since I didn't want to invent yet another >>RPC-like protocol. >> >>I intentionally left out the WSDL details as those are relatively easy >>to add later. I suspect terminology and description need a fair amount >>of work, so I'd appreciate both comments on the approach and requests >>for clarification (or suggestions). >> >>Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 24 06:38:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DllZt-0004e0-0S; Fri, 24 Jun 2005 06:38:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DllZo-0004df-RH for ecrit@megatron.ietf.org; Fri, 24 Jun 2005 06:38:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25765 for ; Fri, 24 Jun 2005 06:38:22 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DllyJ-00024F-S9 for ecrit@ietf.org; Fri, 24 Jun 2005 07:03:45 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 24 Jun 2005 12:37:01 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B204D@oefeg-s04.oefeg.loc> Thread-Topic: LUMP Admiistration Thread-Index: AcV4aXkmAuy5q+qHQ/y4c6osSDInNAAPKomg From: "Stastny Richard" To: "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Cc: ECRIT WG Subject: [Ecrit] LUMP Admiistration X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Henning, > > It will also need some basic administrative > > oversight to link these finally together globally, also you > > point out this can also be implemented bottom-up. Do you have > > any ideas already what is required here? >=20 > The basic decision that each node administrator will have to make is > whom to peer with (or not). I suspect that's where some amount of > administration will be needed, but it's certainly easier than BGP > peering. Peering really only requires trusting that the peer has > reasonable first-level entries. Robust implementations will need to do > some amount of verification to detect overlapping "claims", but the > system data at that level is likely to be a lot more static than, say, > BGP routing information, as it doesn't depend on dynamic network behavior. I do not think administration of LUMP will be simple. As we have seen with ENUM, IETF is not involved in administrative issue and the resulting discussion is still going on. Keeping in mind that with ENUM there is at least the DNS model of delegation to stick to. With LUMP the issue is much more complicated. Let's take the Austrian example: In the numbering ordinance is only defined what short codes have to be treated (technically) as emergency numbers. It is somebody else problem what the entities are where these numbers are routed to. In case of the US this is simple, because there is only 911 and the dispatch problem is hidden behind the scenes. If you have explicit call takers, the problem is directly related to the LUMP database. Who has the right to put an entry in LUMP? For the police, this is quite simple, because they have a proper hierarchy and are finally under the ministry of internal affairs. With fire this starts to detoriate in the rural area with the voluntary fire-fighters and gets completely out of hand with the competing ambulance services. Basically every village chief may decide on the ambulance service serving his area. To solve this problem is of course not within the scope of the IETF, but the administrative issues will need some time=20 to be solved both on the international and on the national level Finally the customer needs to be sure that the hierarchy and also the peering is done between trusted entities. Again keeping ENUM in mind, if I imagine all the legal papers and contract necessary to get this operational and propely administered .... regards Richard Richard Stastny OeFEG tel:+43 664 420 4100 enum:+43 780 203 211 callto://fordprefect http://voipandenum.blogspot.com =20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 24 06:51:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DllmE-00072t-UK; Fri, 24 Jun 2005 06:51:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DllmE-00072j-K9 for ecrit@megatron.ietf.org; Fri, 24 Jun 2005 06:51:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27135 for ; Fri, 24 Jun 2005 06:51:11 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DlmAk-0002dd-4R for ecrit@ietf.org; Fri, 24 Jun 2005 07:16:34 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] [Fwd: I-D ACTION:draft-schulzrinne-ecrit-lump-00.txt] X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 24 Jun 2005 12:49:52 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D461B204E@oefeg-s04.oefeg.loc> Thread-Topic: [Ecrit] [Fwd: I-D ACTION:draft-schulzrinne-ecrit-lump-00.txt] Thread-Index: AcV4bT6iUjdzaxLtRf+uLbNJmck6ngAO8vOA From: "Stastny Richard" To: "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: ECRIT WG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Henning, > Yes, this clearly needs work; there are probably three+ scenarios being > conflated into one. Yes, having some basic scenarios showing the extreme cases would help understanding. > My current thinking is that 'urn:service:sos' implies a wildcard for all > services that are below 'sos', say. I'm reluctant to add explicit > wildcards since that tempts strange things like > service:dialstring.*.fire, which is not very sensible. Agree, if a query retrieves all services below, this is fine with me > Can you explain a bit more what you mean by "architecture"? I do suspect > that there are details of peering that would be handled nationally > (e.g., by NENA), but the basic how-do-I-talk-to-my-neighbor should > indeed be the same everywhere. See my previous e-mail. We have to distinguish the technical part synchronizing the databases and what I really ment with "architecture" How are the parent-child relations managed? How is peering (trusted) achieved? How is it managed if different agencies manage in one level? > Given that most of the Austrian navy and coast guard probably consists > of inflatable warships, this makes sense. ;-) But do not forget Austria had quite a successful navy in the monarchy ;-) And I like the idea of sos.fashion One could get creative on this idea ;-) Regards Richard Richard Stastny OeFEG tel:+43 664 420 4100 enum:+43 780 203 211 callto://fordprefect http://voipandenum.blogspot.com =20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 24 09:46:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DloVh-00009h-J7; Fri, 24 Jun 2005 09:46:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DloVe-00009Z-QD for ecrit@megatron.ietf.org; Fri, 24 Jun 2005 09:46:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09383 for ; Fri, 24 Jun 2005 09:46:17 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlouC-0001mL-Dh for ecrit@ietf.org; Fri, 24 Jun 2005 10:11:40 -0400 Received: from [192.168.0.31] (pool-141-153-173-119.mad.east.verizon.net [141.153.173.119]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5ODk5oC010081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Jun 2005 09:46:14 -0400 (EDT) Message-ID: <42BC0E98.5090604@cs.columbia.edu> Date: Fri, 24 Jun 2005 09:46:00 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard References: <32755D354E6B65498C3BD9FD496C7D461B204D@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D461B204D@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 3.0 (+++) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Cc: ECRIT WG Subject: [Ecrit] Re: LUMP Admiistration X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Stastny Richard wrote: > Henning, > > I do not think administration of LUMP will be simple. As we have seen > with ENUM, IETF is not involved in administrative issue and the > resulting discussion is still going on. Keeping in mind that with > ENUM there is at least the DNS model of delegation to stick to. I actually wanted to avoid any ENUM model, precisely because of the hierarchy issue. Having a hierarchy with a world-wide root means that you need to agree on who runs the root early on. Judging from ENUM history, that seems a difficult problem. In the LUMP architecture, entities can peer regionally first and then later worry about global peering, without the problem of having to update all the DNS entries from a local ENUM tree to a global one. > > With LUMP the issue is much more complicated. Let's take the > Austrian example: In the numbering ordinance is only defined what > short codes have to be treated (technically) as emergency numbers. > > It is somebody else problem what the entities are where these numbers > are routed to. In case of the US this is simple, because there is only > 911 and the dispatch problem is hidden behind the scenes. This is not fundamentally different. Even in the US, somebody has to agree as to who serves which geographic area. It is not uncommon that police and fire jurisdictions are different, leading to the somewhat peculiar E911 concept of ESNs and ESZs (essentially, a number/zone for all possible combinations of fire/police/ambulance that occur). > > If you have explicit call takers, the problem is directly related > to the LUMP database. Who has the right to put an entry in LUMP? Unless you have police precinct captains battling over who patrols which section of Vienna, there seems to be a fairly natural division. This is not a LUMP problem - all proposals and discussion so far have assumed that there is some agreement, outside of contested international territory, as to who serves each area. LUMP can deal with overlap, but any unresolved overlap in any system is going to be confusing to users. We need to design systems that can handle overlap, but I don't think we are the right organization to deal with the administrative side. There are plenty of organizations, such as NENA, who are more operationally qualified. Again, this is not a LUMP issue as such. > > For the police, this is quite simple, because they have a proper > hierarchy and are finally under the ministry of internal affairs. > > With fire this starts to detoriate in the rural area with the > voluntary fire-fighters and gets completely out of hand with > the competing ambulance services. Basically every village chief > may decide on the ambulance service serving his area. I assume that if you dial the ambulance 3-digit number in Austria today, you don't get three village mayors competing for your services ("mine is cheaper", "mine has cup holders", "mine is endorsed by Arnold"). > > To solve this problem is of course not within the scope of > the IETF, but the administrative issues will need some time > to be solved both on the international and on the national level As far as I can tell, this is mainly a national issue. You could even imagine that only LUMP servers within a country peer and that there is some higher-level diplomatic exchange of pointer information beyond national boundaries, maybe by diplomatic cable or parchment paper. > > Finally the customer needs to be sure that the hierarchy and also > the peering is done between trusted entities. Certainly. This is why advertisements are signed. > > Again keeping ENUM in mind, if I imagine all the legal > papers and contract necessary to get this operational and > propely administered .... While there will always be some coordination, I don't think the ENUM analogy quite fits. Indeed, I've tried ao avoid some of the issues that make global ENUM difficult. (Quite frankly, this is why I moved away from the DNS hierarchy model in our original proposal - too difficult to bootstrap initially. I'd much rather rely on regional efforts that can be connected later, without impacting the clients.) > > regards > Richard > > Richard Stastny > OeFEG > tel:+43 664 420 4100 > enum:+43 780 203 211 > callto://fordprefect > http://voipandenum.blogspot.com > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 24 10:59:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlpeI-0002hS-Ac; Fri, 24 Jun 2005 10:59:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlpeH-0002hK-IY for ecrit@megatron.ietf.org; Fri, 24 Jun 2005 10:59:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15960 for ; Fri, 24 Jun 2005 10:59:15 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dlq2m-0004kT-0Z for ecrit@ietf.org; Fri, 24 Jun 2005 11:24:39 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 24 Jun 2005 17:02:11 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D4613BFA7@oefeg-s04.oefeg.loc> Thread-Topic: LUMP Admiistration Thread-Index: AcV4w5NlE3amp3lGQWO1LtqihdEKeQACPtCY From: "Stastny Richard" To: "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable Cc: ECRIT WG Subject: [Ecrit] Re: LUMP Admiistration X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Henning, =20 thany for your detailed answer. My major problem is the mapping of the different organizational structures of the agencies to LUMP. =20 You did not state it explicitly, but for the avoidance of doubt: =20 Is it possible e.g from a national parent server to have completly different child architectures for say police, fire and ambulance, according to their internal organizational structures and also run by different entities? =20 So each agency is reponsible for seting up their own sub-clusters? =20 Richard ________________________________ Von: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Gesendet: Fr 24.06.2005 15:46 An: Stastny Richard Cc: ECRIT WG Betreff: Re: LUMP Admiistration Stastny Richard wrote: > Henning, > > I do not think administration of LUMP will be simple. As we have seen > with ENUM, IETF is not involved in administrative issue and the > resulting discussion is still going on. Keeping in mind that with > ENUM there is at least the DNS model of delegation to stick to. I actually wanted to avoid any ENUM model, precisely because of the hierarchy issue. Having a hierarchy with a world-wide root means that you need to agree on who runs the root early on. Judging from ENUM history, that seems a difficult problem. In the LUMP architecture, entities can peer regionally first and then later worry about global peering, without the problem of having to update all the DNS entries from a local ENUM tree to a global one. > > With LUMP the issue is much more complicated. Let's take the > Austrian example: In the numbering ordinance is only defined what > short codes have to be treated (technically) as emergency numbers. > > It is somebody else problem what the entities are where these numbers > are routed to. In case of the US this is simple, because there is only > 911 and the dispatch problem is hidden behind the scenes. This is not fundamentally different. Even in the US, somebody has to agree as to who serves which geographic area. It is not uncommon that police and fire jurisdictions are different, leading to the somewhat peculiar E911 concept of ESNs and ESZs (essentially, a number/zone for all possible combinations of fire/police/ambulance that occur). > > If you have explicit call takers, the problem is directly related > to the LUMP database. Who has the right to put an entry in LUMP? Unless you have police precinct captains battling over who patrols which section of Vienna, there seems to be a fairly natural division. This is not a LUMP problem - all proposals and discussion so far have assumed that there is some agreement, outside of contested international territory, as to who serves each area. LUMP can deal with overlap, but any unresolved overlap in any system is going to be confusing to users. We need to design systems that can handle overlap, but I don't think we are the right organization to deal with the administrative side. There are plenty of organizations, such as NENA, who are more operationally qualified. Again, this is not a LUMP issue as such. > > For the police, this is quite simple, because they have a proper > hierarchy and are finally under the ministry of internal affairs. > > With fire this starts to detoriate in the rural area with the > voluntary fire-fighters and gets completely out of hand with > the competing ambulance services. Basically every village chief > may decide on the ambulance service serving his area. I assume that if you dial the ambulance 3-digit number in Austria today, you don't get three village mayors competing for your services ("mine is cheaper", "mine has cup holders", "mine is endorsed by Arnold"). > > To solve this problem is of course not within the scope of > the IETF, but the administrative issues will need some time > to be solved both on the international and on the national level As far as I can tell, this is mainly a national issue. You could even imagine that only LUMP servers within a country peer and that there is some higher-level diplomatic exchange of pointer information beyond national boundaries, maybe by diplomatic cable or parchment paper. > > Finally the customer needs to be sure that the hierarchy and also > the peering is done between trusted entities. Certainly. This is why advertisements are signed. > > Again keeping ENUM in mind, if I imagine all the legal > papers and contract necessary to get this operational and > propely administered .... While there will always be some coordination, I don't think the ENUM analogy quite fits. Indeed, I've tried ao avoid some of the issues that make global ENUM difficult. (Quite frankly, this is why I moved away from the DNS hierarchy model in our original proposal - too difficult to bootstrap initially. I'd much rather rely on regional efforts that can be connected later, without impacting the clients.) > > regards > Richard > > Richard Stastny > OeFEG > tel:+43 664 420 4100 > enum:+43 780 203 211 > callto://fordprefect > http://voipandenum.blogspot.com >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 24 22:00:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlzyD-00022u-Tl; Fri, 24 Jun 2005 22:00:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlzyC-00022X-TC for ecrit@megatron.ietf.org; Fri, 24 Jun 2005 22:00:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20290 for ; Fri, 24 Jun 2005 22:00:31 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dm0Mp-0005yL-8y for ecrit@ietf.org; Fri, 24 Jun 2005 22:26:01 -0400 Received: from [192.168.0.31] (pool-141-153-173-119.mad.east.verizon.net [141.153.173.119]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j5P20Kx7000879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Jun 2005 22:00:29 -0400 (EDT) Message-ID: <42BCBAA3.5070501@cs.columbia.edu> Date: Fri, 24 Jun 2005 22:00:03 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stastny Richard References: <32755D354E6B65498C3BD9FD496C7D4613BFA7@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D4613BFA7@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: ECRIT WG Subject: [Ecrit] Re: LUMP Admiistration X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Stastny Richard wrote: > Henning, > > thany for your detailed answer. My major problem is the mapping > of the different organizational structures of the agencies to LUMP. > > You did not state it explicitly, but for the avoidance of doubt: > > Is it possible e.g from a national parent server to have completly > different child architectures for say police, fire and ambulance, > according to their internal organizational structures and also > run by different entities? Yes, this is quite possible. You would have a top-level set of coverage entries that said something like region=Austria (by civic or geo coordinates) service=urn:sos:fire next=lump:feuerwehr.gov.at region=Vienna service=urn:sos:police next=lump:polizei.wien.gov.at region=Austria service=urn:sos:police next=lump:polizei.at (with the usual most-specific-one wins rule). > > So each agency is reponsible for seting up their own sub-clusters? Indeed. They would either inject a top-level record like the one above into the resolvers or an Austria-wide LUMP server would receive and route requests to the fire and police hierarchies. Essentially, mapping is taking the tuple (location, service) and mapping it to a (set of) URLs. This all needs to be written up better in the draft. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 30 02:00:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dns6I-0002BD-3L; Thu, 30 Jun 2005 02:00:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dns6F-0002B5-7A for ecrit@megatron.ietf.org; Thu, 30 Jun 2005 02:00:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15330 for ; Thu, 30 Jun 2005 02:00:29 -0400 (EDT) Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnsVr-0001B5-UC for ecrit@ietf.org; Thu, 30 Jun 2005 02:27:04 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Thu, 30 Jun 2005 02:00:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] WG: Action items needed for I-D:draft-schulzrinne-ecrit-requirements-00.txt Date: Wed, 29 Jun 2005 22:58:57 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750297F463@SEA-EXCHVS-2.telecomsys.com> Thread-Topic: [Ecrit] WG: Action items needed for I-D:draft-schulzrinne-ecrit-requirements-00.txt Thread-Index: AcVSfG5supQyJEqRSZGS41N9yJhQXwIyqlzgAB61AZAISQhYEAABAifw From: "Roger Marshall" To: "Tschofenig Hannes" , "Marc Linsner" , X-Spam-Score: 0.0 (/) X-Scan-Signature: e9d8c60d9288f2c774f26bab15869505 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hi. To send out an updated version (-01) of the ecrit requirements I-D, = requires that I follow up on a few outstanding action items which call = for rewritten text (ref: interim meeting 5/18 email update at bottom). The updated I-D will be posted once I get (agreed-to) responses based on = the following listing. 1. Items that I show still outstanding (need proposed text to be = submitted to ecrit mail-list): R5 - Keep (Henning to rewrite text) A1 - Keep (possible reword of A1, may split into two separate = requirements) [Needs owner] A3 - Keep (reword along with A1 into two separable requirements) [Needs = owner] A6 - Keep (possible reword per Ted Hardie composed text) L10 - Keep (Hannes to lead further investigation w/Nadine, Ted) I9 - Keep (rewrite, Henning to send text) D5 - Keep (rewrite, Marc Linsner to send text as, "to specify minimize = number of round trips rather than minimizing time") D9 - Keep (rewrite to include D8) [Needs owner] SD1 - Keep (rewrite, Tom Taylor to send extensibility requirement) 2. Action items completed (no action required): R6 - Keep (Ted Hardie to send candidate text as replacement for R6) = [Done, ref: Hardie email 5/17] L6 - Keep (Nadine to supply additional text) [Done, ref: Nadine email = 5/18] L9 - Keep (Nadine to rewrite, for clarity to say "as input to the = mapping protocol" [Done, ref: Nadine email 5/18] L28 - Keep (James Polk to provide reworded text) [Done, (reworded per = supplied text) ref. Polk email 5/14] I1 - Keep (reword as "Calls Must be routed to the PSAP responsible for = this particular geographic area") [Done.] I3 - Keep (rewrite, Henning will send text) [Done, ref: Henning email = 5/18, and Andrew email 5/25] I4 - Keep (rewrite, Henning and Patti McCalmont to collaborate on text) = [Done, ref: Henning email 5/18] I7 - Keep (rewrite, Brian Rosen to send text) [Done, ref: Rosen email = 5/18] I8 - Keep (rewrite, Henning to send text) [Done, ref: Henning email = 5/18] I10 - Keep (Brian to rewrite as standalone requirement) [Done, ref: = Rosen email 5/18] I25 - Keep (to be rewritten by Henning) [Done, ref: Henning email 5/18] I31 - Keep (rewrite, Ted Hardie to send text) [Done, ref: Hardie email = 5/18] D1 - Keep (rewrite, Henning to send text) [Done, (incl. as modified by = Ted) ref: Henning & Ted email, both 5/18] D7 - Keep (rewrite, Henning to send text) [Done, ref: Henning email = 5/18] 3. Other changes made: a. I13 [Replacement for original I13 (this had been marked "delete", but = received submitted text from Brian email 5/18)] b. L31 [New, added per Henning email 5/21, "Split Responsibility"] c. L32 [New, per following note] Note: based on discussion around L13, = Brian Rosen to write a new requirement to say that mapping function must = be independent of the call (and at the time of the call) [Done, ref. = Rosen email 5/17] d. Consolidated variety of terms, including ECC, iPSAP, IP-PSAP, PSAP = into a single term, "PSAP". =20 1. I chose to leave the term "ECC" in the Terminology section without = change, though it is no longer referenced in the I-D. 2. Deleted term iPSAP from terminology section, and merged its = definition in with definition for PSAP. e. James Polk submitted email on 5/10 (114 comments), which I will reply = to with itemized responses to for each of the comments. Many of these = are simple editorial fixes (which I appreciate), others may need to go = to the list, since we didn't have time to cover the complete list at the = last interim. Thanks. Roger Marshall -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Roger Marshall Sent: Wednesday, May 18, 2005 12:22 PM To: ecrit@ietf.org Subject: RE: [Ecrit] WG: Updated Req Review = ofI-D:draft-schulzrinne-ecrit-requirements-00.txt All: RE: ECRIT REQUIREMENTS REVIEW UPDATE: Below is a completed disposition status listing of ALL ecrit (I-D) = requirements, based on continued (5/18) interim ecrit meeting this = morning. These results are associated with review of requirements listed in:=20 draft-schulzrinne-ecrit-requirements-00.txt 3 categories (with qualifiers) of disposition are: 1. Keep (as written, or with required changes to text) 2. Move (into another document) 3. Delete (remove, possibly merge into other requirement) Note: Original requirement numbers will not be reused. New requirements will = be added onto the end of each section (in the next revision of the I-D). 3. High-Level Requirements R1 - Keep R2 - Keep R3 - Keep R4 - Keep R5 - Keep (Henning Schulzrinne to rewrite text) R6 - Keep (Ted Hardie to send candidate text as replacement for R6) R7 - Delete 4. Emergency Address A1 - Keep (possible reword of A1, may split into two separate = requirements) A2 - Move (Jon Peterson will advise Henning on destination for A2) A3 - Keep (reword along with A1 into two separable requirements) A4 - Keep A5 - Delete A6 - Keep (possible reword per Ted Hardie composed text) A7 - Delete 5. Identifying the Caller Location L1 - Move (L1, L2, & L3 to be put into a new document (to be created by = James Polk) with the goal of becoming an Informational RFC L2 - (see L1) L3 - (see L1) L4 - Move (into the Information doc) L5 - Move (Patti McCalmont to rewrite, consolidate with L11, move into = the Information doc) L6 - Keep (Nadine Abbott to supply additional text) L7 - Delete (out of scope) L8 - Delete (out of scope) L9 - Keep (Nadine to rewrite, for clarity to say "as input to the = mapping protocol" L10 - Keep (Hannes Tschofenig to lead further investigation w/Nadine, = Ted) L11 - Move (see L5) L12 - Delete (out of scope) L13 - Move (into the Information doc) Note: based on discussion around L13, Brian Rosen to write a new = requirement to say that mapping function must be independent of the call = (and at the time of the call) L14 - Delete (out of scope) L15 - Delete (out of scope) Note: based on discussion around L15, Brian Rosen to write a new = requirement re: default routing L16 - Delete (out of scope), (geopriv) L17 - Delete (out of scope) L18 - Delete (out of scope), (geopriv) L19 - Delete (out of scope), (geopriv) L20 - Delete (already discussed) L21 - Move (into Informational doc) [start of 5/18 discussion] L22 - (Change to:) Move (to Informational doc/BCP)=20 L23 - Delete L24 - (Change to:) Move (to Informational doc/BCP) L25 - Move (into Informational doc) L26 - Delete (out of scope) L27 - Delete (out of scope) L28 - Keep (James Polk to provide reworded text) L29 - Delete (out of scope) L30 - Delete (out of scope, covered elsewhere) 6. Identifying the Appropriate Emergency Call Center Note 1: Delete following paragraph from text block: "Note that the first proxy, the ESRP, doing the translation may not = be in the same geographic area as the UA placing the emergency call." Note 2: Consolidate following terms (throughout document): ECC; iPSAP, = IP-PSAP all become one term, PSAP. I1 - Keep (reword as "Calls Must be routed to the PSAP responsible for = this particular geographic area") I2 - Move (into Informational doc) I3 - Keep (rewrite, Henning will send text) I4 - Keep (rewrite, Henning and Patti McCalmont to collaborate on text) I5 - Delete (out of scope) I6 - Delete (out of scope) I7 - Keep (rewrite, Brian Rosen to send text) I8 - Keep (rewrite, Henning to send text) I9 - Keep (rewrite, Henning to send text) I10 - Keep (Brian to rewrite as standalone requirement) I11 - Delete (out of scope) I12 - Move (to Informational doc) I13 - Delete (out of scope) I14 - Delete (redundant, mapping can be done based on any PIDF-LO field = (see L9) I15 - Move (to Informational doc) I16 - Move (to Informational doc) I17 - Move (to Informational doc) I18 - Move (to Informational doc) I19 - Move (to Informational doc) I20 - Move (to Informational doc) I21 - Delete (per rewritten I3/I4 by henning) I22 - Move (to Informational doc) I23 - Delete I24 - Delete I25 - Keep (to be rewritten by Henning) I26 - Move (to Informational doc) I27 - Move (to Informational doc) I28 - Move (to Informational doc) I29 - Delete I30 - Move (to security document as an update) I31 - Keep (rewrite, Ted Hardie to send text) I32 - Delete I33 - Delete I34 - Move (to Informational doc) I35 - Delete (merged into I31) I36 - Move (to Informational doc, merge with Traceability) I37 - Delete (out of scope) I38 - Delete I39 - Delete (merge with L13) 7. Emergency Address Directory D1 - Keep (rewrite, Henning to send text) D2 - Move (to security doc) D3 - Move (to security doc) D4 - Delete (out of scope) D5 - Keep (rewrite, Marc Linsner to send text as, "to specify minimize = number of round trips rather than minimizing time") D6 - Delete (already covered in rewritten I3/I4 by Henning) D7 - Keep (rewrite, Henning to send text) D8 - Move (combine with D9) & Delete Motivation text D9 - Keep (rewrite to include D8) 8. Identifying the Caller C1 - Move (to Informational doc) C2 - Move (to Informational doc) C3 - Move (to Informational doc) 9. Call Setup and Call Features S1 - Move (to security doc) S2 - Move (to informational doc) S3 - Delete S4 - Move (to security doc) S5 - Move (to informational doc) S6 - Delete S7 - Move (to informational doc) S8 - Move (to informational doc) S9 - Delete (collapses into tracking and tracing I7) 10. Supplemental Information SD1 - Keep (rewrite, Tom Taylor to send extensibility requirement) SD2 - SD9 Delete (merge into rewritten SD1, above) 11. Security Considerations SEC1 - Move (to security document/discussion) SEC2 - Move (to security document/discussion) SEC3 - Move (to security document/discussion) [end of ecrit requirements I-D discussion for 5/18] Per chairs' instruction, please post rewrites (where noted) onto the = list for discussion by wg. Regards, Roger Marshall -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Tschofenig Hannes Sent: Friday, May 06, 2005 1:39 PM To: 'ecrit@ietf.org' Subject: [Ecrit] WG: I-D = ACTION:draft-schulzrinne-ecrit-requirements-00.txt hi all,=20 this document is an attempt to consolidate the requirements of the individual documents into a single document. as indicated at the ecrit working group meeting henning's document was used as the starting point. = the draft authors of the other requirements documents have tried to determine whether their requirements are already covered by henning's document. roger incorporated them if they weren't. roger also clean up = the terminology and removed non-relevant parts. thanks for the good work, = roger. please review the document carefully. we will spend some time at the = interim meeting to discuss the open issues.=20 ciao hannes -----Urspr=FCngliche Nachricht----- Von: i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] Im Auftrag von Internet-Drafts@ietf.org Gesendet: Freitag, 6. Mai 2005 21:44 An: i-d-announce@ietf.org Betreff: I-D ACTION:draft-schulzrinne-ecrit-requirements-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for Emergency Context Resolution=20 with Internet Technologies Author(s) : H. Schulzrinne, R. Marshall Filename : draft-schulzrinne-ecrit-requirements-00.txt Pages : 38 Date : 2005-5-6 =09 This document enumerates requirements for emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-requirements-= 00. txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-schulzrinne-ecrit-requirements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-schulzrinne-ecrit-requirements-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 30 09:06:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnykG-0003oW-17; Thu, 30 Jun 2005 09:06:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnykE-0003oR-Ap for ecrit@megatron.ietf.org; Thu, 30 Jun 2005 09:06:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08624 for ; Thu, 30 Jun 2005 09:06:16 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dnz9x-0006Ym-DS for ecrit@ietf.org; Thu, 30 Jun 2005 09:32:56 -0400 Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 30 Jun 2005 09:06:10 -0400 id 001F39AE.42C3EE42.00005CB1 Mime-Version: 1.0 (Apple Message framework v730) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5AB0D609-E4C4-4391-97D9-FD2BF8312991@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Thu, 30 Jun 2005 09:06:10 -0400 To: "'ecrit@ietf.org'" X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Subject: [Ecrit] Fwd: I-D ACTION:draft-hardie-ecrit-iris-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Hannes, Ted, and I have put together another version of our ecrit- iris draft. This is an XML-based interface capable of using UDP for fast exchanges and DNS SRV records for load-balancing and robustness. We made the following changes: o Added a validation flag so that the query interface may be used for address validation. o Updated the list of sos identifiers based on Richard's email. o Beefed up the introductory section for readability (though more of that will have to be done). -andy Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: June 28, 2005 3:50:02 PM EDT > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-hardie-ecrit-iris-01.txt > Reply-To: internet-drafts@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : An IRIS schema for Emergency Service contact URIs > Author(s) : T. Hardie, et al. > Filename : draft-hardie-ecrit-iris-01.txt > Pages : 25 > Date : 2005-6-28 > > This document describes an XML-based protocol for passing location > information to a server that returns emergency service contact > URIs. > It is intended to fit within a larger framework of standards. > Specifically, it presumes the existence of a URI scheme appropriate > for signalling that emergency service is required and > distinguishing > among emergency services if appropriate. It also presumes that an > entity requesting this response will be able to handle the URIs > returned as input to appropriate handlers. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-hardie-ecrit-iris-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body > of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-hardie-ecrit-iris-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-hardie-ecrit-iris-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2005-6-28150349.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 30 15:51:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do54O-0005U5-WC; Thu, 30 Jun 2005 15:51:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do54M-0005U0-7u for ecrit@megatron.ietf.org; Thu, 30 Jun 2005 15:51:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17953 for ; Thu, 30 Jun 2005 15:51:28 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do5U8-0001nH-AH for ecrit@ietf.org; Thu, 30 Jun 2005 16:18:11 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j5UJnHmD026311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Jun 2005 15:49:22 -0400 (EDT) Message-ID: <42C44CB8.5070106@cs.columbia.edu> Date: Thu, 30 Jun 2005 15:49:12 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Marshall References: <8C837214C95C864C9F34F3635C2A65750297F463@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A65750297F463@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: [Ecrit] R5 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Here's a proposal: R5. Minimum Connectivity An emergency call should succeed as long as there is a working network path between the caller and the PSAP. In particular, reliance during call set-up and calls on entities and network paths that are located elsewhere should be minimized. Example: A caller in New York who needs to contact a PSAP in the same city shouldn't have to get information from some entity in Texas to make that call, as the call would then fail if the New York to Texas path is unavailable. (To avoid this, the caller could, for example, have cached mapping information, use a local server that has the necessary information, or use other mechanisms to avoid such off-path dependencies.) I hope this is clearer. Roger Marshall wrote: > > R5 - Keep (Henning to rewrite text) _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 30 15:51:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do54U-0005Ue-6o; Thu, 30 Jun 2005 15:51:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do54T-0005UU-5n for ecrit@megatron.ietf.org; Thu, 30 Jun 2005 15:51:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17958 for ; Thu, 30 Jun 2005 15:51:35 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do5UF-0001nO-52 for ecrit@ietf.org; Thu, 30 Jun 2005 16:18:18 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j5UJoOmD026323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Jun 2005 15:50:24 -0400 (EDT) Message-ID: <42C44CFA.8030702@cs.columbia.edu> Date: Thu, 30 Jun 2005 15:50:18 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Roger Marshall References: <8C837214C95C864C9F34F3635C2A65750297F463@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A65750297F463@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: [Ecrit] I9 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org This is actually closely related to R5 and essentially captures the same requirement. > I9 - Keep (rewrite, Henning to send text) _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 30 16:02:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do5FB-0003Pi-4e; Thu, 30 Jun 2005 16:02:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do5F7-0003Pc-M8 for ecrit@megatron.ietf.org; Thu, 30 Jun 2005 16:02:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18615 for ; Thu, 30 Jun 2005 16:02:35 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do5ev-00023G-UD for ecrit@ietf.org; Thu, 30 Jun 2005 16:29:19 -0400 Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 30 Jun 2005 16:02:26 -0400 id 001502C4.42C44FD2.00004A32 In-Reply-To: <42C44CB8.5070106@cs.columbia.edu> References: <8C837214C95C864C9F34F3635C2A65750297F463@SEA-EXCHVS-2.telecomsys.com> <42C44CB8.5070106@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] R5 Date: Thu, 30 Jun 2005 16:02:19 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Is the PSAP running the mapping service? Because that is what this seems to require. Perhaps what you are really getting at is that no jurisdiction should be forced to rely on a mapping service they do not control. -andy On Jun 30, 2005, at 3:49 PM, Henning Schulzrinne wrote: > Here's a proposal: > > R5. Minimum Connectivity > > An emergency call should succeed as long as there is a working > network path between the caller and the PSAP. In particular, > reliance during call set-up and calls on entities and network paths > that are located elsewhere should be minimized. > > Example: A caller in New York who needs to contact a PSAP in the > same city shouldn't have to get information from some entity in > Texas to make that call, as the call would then fail if the New > York to Texas path is unavailable. (To avoid this, the caller > could, for example, have cached mapping information, use a local > server that has the necessary information, or use other mechanisms > to avoid such off-path dependencies.) > > I hope this is clearer. > > > Roger Marshall wrote: > > >> R5 - Keep (Henning to rewrite text) >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 30 16:12:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do5OO-0004jR-II; Thu, 30 Jun 2005 16:12:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do5OM-0004gy-7b for ecrit@megatron.ietf.org; Thu, 30 Jun 2005 16:12:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19314 for ; Thu, 30 Jun 2005 16:12:08 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do5oA-0002e6-E0 for ecrit@ietf.org; Thu, 30 Jun 2005 16:38:51 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j5UKC3mD027472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Jun 2005 16:12:04 -0400 (EDT) Message-ID: <42C4520E.8010707@cs.columbia.edu> Date: Thu, 30 Jun 2005 16:11:58 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] R5 References: <8C837214C95C864C9F34F3635C2A65750297F463@SEA-EXCHVS-2.telecomsys.com> <42C44CB8.5070106@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Andrew Newton wrote: > Is the PSAP running the mapping service? Because that is what this > seems to require. Not at all. You could imagine a server run by my ISP or my IT department (for an enterprise) that does the mapping. If it caches the relevant mapping entries, short-term disruptions of network connectivity from that ISP, say, to other places do not affect the mapping. The mapping service could be co-resident with the local outbound proxy, but doesn't have to be. There will be cases where this local mapping server doesn't have the mapping (say, I dial in from Uganda via a VPN and I've never dialed 9-1-1 from Uganda before), but those cases should be relatively rare. That's why I used the softer "should", rather than "must". I'm also not worried about long-term (days, weeks) outages. If the whole Internet is down for a week, there are likely going to be bigger problems than VoIP access to 911. Having it be run by the PSAP wouldn't help at all - the caller, by definition, doesn't know the PSAP, so it wouldn't know how to get there. ("Chicken-egg" and all that.) > > Perhaps what you are really getting at is that no jurisdiction should > be forced to rely on a mapping service they do not control. Not really. I hope the above makes this clear. Caching is key here. > > -andy > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 30 16:30:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do5fn-0003yE-4H; Thu, 30 Jun 2005 16:30:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do5fm-0003y5-18 for ecrit@megatron.ietf.org; Thu, 30 Jun 2005 16:30:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20622 for ; Thu, 30 Jun 2005 16:30:08 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do65a-00034h-G2 for ecrit@ietf.org; Thu, 30 Jun 2005 16:56:51 -0400 Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 30 Jun 2005 16:30:06 -0400 id 001502C4.42C4564E.00005031 In-Reply-To: <42C4520E.8010707@cs.columbia.edu> References: <8C837214C95C864C9F34F3635C2A65750297F463@SEA-EXCHVS-2.telecomsys.com> <42C44CB8.5070106@cs.columbia.edu> <42C4520E.8010707@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] R5 Date: Thu, 30 Jun 2005 16:30:00 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Jun 30, 2005, at 4:11 PM, Henning Schulzrinne wrote: > You could imagine a server run by my ISP You've just made an assumption that the path to an ISPs servers is a subset of any outbound path. This is not always true. > If it caches the relevant mapping entries What are the relevant mapping entries? > Caching is key here. If this requirement is about caching, then it should be clear that it is about caching. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 30 16:39:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do5oJ-0006da-W6; Thu, 30 Jun 2005 16:38:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do5oI-0006dV-Dy for ecrit@megatron.ietf.org; Thu, 30 Jun 2005 16:38:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21486 for ; Thu, 30 Jun 2005 16:38:56 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do6E7-0003Hw-Vj for ecrit@ietf.org; Thu, 30 Jun 2005 17:05:40 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j5UKcrmD028986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Jun 2005 16:38:54 -0400 (EDT) Message-ID: <42C45858.5000301@cs.columbia.edu> Date: Thu, 30 Jun 2005 16:38:48 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] R5 References: <8C837214C95C864C9F34F3635C2A65750297F463@SEA-EXCHVS-2.telecomsys.com> <42C44CB8.5070106@cs.columbia.edu> <42C4520E.8010707@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > You've just made an assumption that the path to an ISPs servers is a > subset of any outbound path. This is not always true. Certainly, but usually closely correlated. Imagine colocating this server with the ISPs DHCP or DNS servers. You aren't going to be doing much VoIP of any kind if those are unreachable... > >> If it caches the relevant mapping entries > > > What are the relevant mapping entries? Those serving its local customers. Except for VPNs, the coverage region of most ISPs is fairly limited in geography. > >> Caching is key here. > > > If this requirement is about caching, then it should be clear that it > is about caching. This is one particular solution; I didn't want to be solution-specific, but if nobody objects, making it more specific clearly helps. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 30 17:00:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do692-0005o3-7h; Thu, 30 Jun 2005 17:00:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do690-0005ny-2l for ecrit@megatron.ietf.org; Thu, 30 Jun 2005 17:00:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23236 for ; Thu, 30 Jun 2005 17:00:19 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do6Ym-0003lV-M5 for ecrit@ietf.org; Thu, 30 Jun 2005 17:27:03 -0400 Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 30 Jun 2005 17:00:16 -0400 id 001502DB.42C45D60.000056A9 In-Reply-To: <42C45858.5000301@cs.columbia.edu> References: <8C837214C95C864C9F34F3635C2A65750297F463@SEA-EXCHVS-2.telecomsys.com> <42C44CB8.5070106@cs.columbia.edu> <42C4520E.8010707@cs.columbia.edu> <42C45858.5000301@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] R5 Date: Thu, 30 Jun 2005 17:00:13 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Jun 30, 2005, at 4:38 PM, Henning Schulzrinne wrote: >> You've just made an assumption that the path to an ISPs servers is >> a subset of any outbound path. This is not always true. >> > > Certainly, but usually closely correlated. So what's the point of this being a requirement if there are many situations where it is not applicable? > Imagine colocating this server with the ISPs DHCP or DNS servers. Imagine business-class DSL where you don't care about either. >>> If it caches the relevant mapping entries >>> >> What are the relevant mapping entries? >> > > Those serving its local customers. Except for VPNs, the coverage > region of most ISPs is fairly limited in geography. What is the data in those entries? What are the keys and what are the values? > This is one particular solution; I didn't want to be solution- > specific, but if nobody objects, making it more specific clearly > helps. It doesn't. Perhaps we should start with the functional requirement before working on the solution. This requirement sounds like you have a solution looking for a problem. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 30 17:33:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do6fH-0003RF-MT; Thu, 30 Jun 2005 17:33:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do6fF-0003LU-BM for ecrit@megatron.ietf.org; Thu, 30 Jun 2005 17:33:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26099 for ; Thu, 30 Jun 2005 17:33:38 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do754-00053L-Bs for ecrit@ietf.org; Thu, 30 Jun 2005 18:00:23 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j5ULXTmD002004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Jun 2005 17:33:29 -0400 (EDT) Message-ID: <42C46523.6070603@cs.columbia.edu> Date: Thu, 30 Jun 2005 17:33:23 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] R5 References: <8C837214C95C864C9F34F3635C2A65750297F463@SEA-EXCHVS-2.telecomsys.com> <42C44CB8.5070106@cs.columbia.edu> <42C4520E.8010707@cs.columbia.edu> <42C45858.5000301@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > So what's the point of this being a requirement if there are many > situations where it is not applicable? Your and my perception may differ, but I still believe that the requirement is a valid one, for robustness purposes in times of network and infrastructure stress, and that this can be readily accomplished in the vast majority of today's network infrastructure. Yes, there will be cases where it isn't possible, but we're designing protocol requirements. Thus, I want to require from the protocol design that willing ISPs can easily offer such robustness to their customers. If the protocol doesn't support this readily, it can't be offered at all. > What is the data in those entries? What are the keys and what are the > values? I'm not sure I understand the question. Could be either individual entries (one street address) or, for geographic entries, regions (polygons). > >> This is one particular solution; I didn't want to be solution- >> specific, but if nobody objects, making it more specific clearly helps. > > > It doesn't. Perhaps we should start with the functional requirement > before working on the solution. This requirement sounds like you have > a solution looking for a problem. The functional requirement is as originally stated: Only require that the two end systems and closely related entities need to be involved. You could call this an instance of the fate-sharing design principle for the Internet. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 30 17:57:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do72i-0002Qo-1N; Thu, 30 Jun 2005 17:57:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do72g-0002Qj-M1 for ecrit@megatron.ietf.org; Thu, 30 Jun 2005 17:57:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27927 for ; Thu, 30 Jun 2005 17:57:52 -0400 (EDT) Received: from zak.hxr.us ([216.93.167.200] helo=zak.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do7SS-0005e8-Tj for ecrit@ietf.org; Thu, 30 Jun 2005 18:24:37 -0400 Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 30 Jun 2005 17:57:40 -0400 id 001502BD.42C46AD4.000062C9 In-Reply-To: <42C46523.6070603@cs.columbia.edu> References: <8C837214C95C864C9F34F3635C2A65750297F463@SEA-EXCHVS-2.telecomsys.com> <42C44CB8.5070106@cs.columbia.edu> <42C4520E.8010707@cs.columbia.edu> <42C45858.5000301@cs.columbia.edu> <42C46523.6070603@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] R5 Date: Thu, 30 Jun 2005 17:57:37 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Jun 30, 2005, at 5:33 PM, Henning Schulzrinne wrote: >> What is the data in those entries? What are the keys and what >> are the values? >> > > I'm not sure I understand the question. Could be either individual > entries (one street address) or, for geographic entries, regions > (polygons). And what good is caching this? If I've never made an emergency call from 234 Maple Dr., it won't be cached. If a call has never been made at the x,y,z coordinates for the shrubs in my front yard, it won't be cached. Just how often do you expect specific locations to be making emergency calls? Also, the idea of having the polygons cached means that you are not worried about security of just anybody knowing those polygons. > The functional requirement is as originally stated: Only require > that the two end systems and closely related entities need to be > involved. You could call this an instance of the fate-sharing > design principle for the Internet. The problem with this (closely related entities) is that measuring such a requirement is very subjective. If that is how you wish to measure them, then you ought to just say that the protocol be robust, efficient, and well engineered. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 30 18:07:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do7CB-0006m3-N6; Thu, 30 Jun 2005 18:07:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Do7C9-0006kw-Ii for ecrit@megatron.ietf.org; Thu, 30 Jun 2005 18:07:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28997 for ; Thu, 30 Jun 2005 18:07:36 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Do7bx-0005td-MV for ecrit@ietf.org; Thu, 30 Jun 2005 18:34:22 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j5UM7YmD003865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Jun 2005 18:07:35 -0400 (EDT) Message-ID: <42C46D20.5080301@cs.columbia.edu> Date: Thu, 30 Jun 2005 18:07:28 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] R5 References: <8C837214C95C864C9F34F3635C2A65750297F463@SEA-EXCHVS-2.telecomsys.com> <42C44CB8.5070106@cs.columbia.edu> <42C4520E.8010707@cs.columbia.edu> <42C45858.5000301@cs.columbia.edu> <42C46523.6070603@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org > And what good is caching this? If I've never made an emergency call > from 234 Maple Dr., it won't be cached. If a call has never been made > at the x,y,z coordinates for the shrubs in my front yard, it won't be > cached. Just how often do you expect specific locations to be making > emergency calls? For geo, only region caching makes sense. For civic, the testing process you will need to do for address validation and other functions ensures that almost all addresses will be (or can be) cached, even if that residence has never dialed 9-1-1 before. > > Also, the idea of having the polygons cached means that you are not > worried about security of just anybody knowing those polygons. That information is essentially public today, as it tends to conform to civic boundaries such as state, county or city lines. (It doesn't always, but you can almost always guess who will answer the 911 call today, at least with 50-50 odds.) I just visited the LAPD 911 center in downtown LA. They make no secret of their coverage region of about 4 million people. > The problem with this (closely related entities) is that measuring such > a requirement is very subjective. If that is how you wish to measure > them, then you ought to just say that the protocol be robust, > efficient, and well engineered. The requirement stated is far more specific than the general motherhood-and-apple-pie robustness requirements. This is why we're disagreeing :-) > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 30 21:17:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoA9x-0006mh-0d; Thu, 30 Jun 2005 21:17:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoA9v-0006mT-LB for ecrit@megatron.ietf.org; Thu, 30 Jun 2005 21:17:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26261 for ; Thu, 30 Jun 2005 21:17:33 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoAZm-0007rC-85 for ecrit@ietf.org; Thu, 30 Jun 2005 21:44:19 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j611GgGn017908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Jun 2005 18:16:43 -0700 (PDT) Received: from [192.168.1.4] (vpn-10-50-16-28.qualcomm.com [10.50.16.28]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j611GYhW022119; Thu, 30 Jun 2005 18:16:37 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <42C4520E.8010707@cs.columbia.edu> References: <8C837214C95C864C9F34F3635C2A65750297F463@SEA-EXCHVS-2.telecomsys.com> <42C44CB8.5070106@cs.columbia.edu> <42C4520E.8010707@cs.columbia.edu> Date: Thu, 30 Jun 2005 14:27:16 -0700 To: Henning Schulzrinne , Andrew Newton From: Ted Hardie Subject: Re: [Ecrit] R5 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.7 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Henning's proposal is: >R5. Minimum Connectivity > >An emergency call should succeed as long as there is a working network path between the caller and the PSAP. In particular, reliance during call set-up and calls on entities and network paths that are located elsewhere should be minimized. > >Example: A caller in New York who needs to contact a PSAP in the same city shouldn't have to get information from some entity in Texas to make that call, as the call would then fail if the New York to Texas path is unavailable. (To avoid this, the caller could, for example, have cached mapping information, use a local server that has the necessary information, or use other mechanisms to avoid such off-path dependencies.) > >I hope this is clearer. I think "working network path between the caller and the PSAP" isn't clear enough. Do you mean only that there is IP connectivity between the terminal and the PSAP's IP address? Taking SIP as the presumed contact method for a moment, would that imply that the terminal should be able to connect to the PSAP, even if its normal proxy is unavailable and the proxy for the PSAP is also unavailable? Or does the "working network path" imply that the proxies configured for these are also up and available? I'd also strongly suggest that "located elsewhere" mixes up network topology with geography, which is one of our constant sources of confusion. Can you recast this in terms of network topology? Something like: R.5. The ability to discover the correct PSAP should not require a level of connectivity substantially beyond that which would be needed to contact that PSAP. It is not required that the servers used for discovery be on-path to the call flow, but their reachability should be a strong consideration in devising deployment strategies. regards, Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 30 21:56:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoAle-0007BM-AE; Thu, 30 Jun 2005 21:56:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoAlc-0007BH-Uy for ecrit@megatron.ietf.org; Thu, 30 Jun 2005 21:56:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28641 for ; Thu, 30 Jun 2005 21:56:28 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoBBS-0002ux-VB for ecrit@ietf.org; Thu, 30 Jun 2005 22:23:15 -0400 Received: from [192.168.0.31] (pool-141-153-166-25.mad.east.verizon.net [141.153.166.25]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j611uPCe000773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Jun 2005 21:56:25 -0400 (EDT) Message-ID: <42C4A2C5.5010801@cs.columbia.edu> Date: Thu, 30 Jun 2005 21:56:21 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Ecrit] R5 References: <8C837214C95C864C9F34F3635C2A65750297F463@SEA-EXCHVS-2.telecomsys.com> <42C44CB8.5070106@cs.columbia.edu> <42C4520E.8010707@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Ted Hardie wrote: > Henning's proposal is: > > >>R5. Minimum Connectivity >> >>An emergency call should succeed as long as there is a working network path between the caller and the PSAP. In particular, reliance during call set-up and calls on entities and network paths that are located elsewhere should be minimized. >> >>Example: A caller in New York who needs to contact a PSAP in the same city shouldn't have to get information from some entity in Texas to make that call, as the call would then fail if the New York to Texas path is unavailable. (To avoid this, the caller could, for example, have cached mapping information, use a local server that has the necessary information, or use other mechanisms to avoid such off-path dependencies.) >> >>I hope this is clearer. > > > I think "working network path between the caller and the PSAP" isn't clear > enough. Do you mean only that there is IP connectivity between the terminal > and the PSAP's IP address? Taking SIP as the presumed contact method for > a moment, would that imply that the terminal should be able to connect > to the PSAP, even if its normal proxy is unavailable and the proxy for > the PSAP is also unavailable? Or does the "working network path" imply that > the proxies configured for these are also up and available? Yes, "working network path" = "current IP connectivity" + "ability to route SIP calls via outbound proxy [if necessary] and PSAP proxy". The basic rule is simple: "The look-up process should not add any additional network-related failure modes. In other words, if a caller knew the PSAP signaling address and can reach it via signaling and media, the usage of a mapping mechanism should not interfere with that reachability if network connectivity to parts of the mapping service is temporarily impaired." > > I'd also strongly suggest that "located elsewhere" mixes up network > topology with geography, which is one of our constant sources of > confusion. Can you recast this in terms of network topology? Agreed. Located elsewhere ==> maybe "located in parts of the network that are neither on the signaling nor media path from the caller to the PSAP". It's a bit longer... > > Something like: > > R.5. > > The ability to discover the correct PSAP should not require a level of connectivity > substantially beyond that which would be needed to contact that PSAP. It is > not required that the servers used for discovery be on-path to the call flow, > but their reachability should be a strong consideration in devising deployment > strategies. This is ok, although "call flow" is a bit mushy (and means something rather different in the SIP community, if you look at documents titled "call flows"). One could simply say "media and signaling path" instead. I believe these terms are widely understood, at least on the VoIP side of the world. > > > regards, > Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 30 22:37:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoBPE-0004qF-5g; Thu, 30 Jun 2005 22:37:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoBPA-0004q5-S1 for ecrit@megatron.ietf.org; Thu, 30 Jun 2005 22:37:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01477 for ; Thu, 30 Jun 2005 22:37:22 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoBp3-0007IW-E3 for ecrit@ietf.org; Thu, 30 Jun 2005 23:04:09 -0400 Received: from [10.0.1.3] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 30 Jun 2005 22:37:20 -0400 id 001502EA.42C4AC60.00001A9D In-Reply-To: <42C46D20.5080301@cs.columbia.edu> References: <8C837214C95C864C9F34F3635C2A65750297F463@SEA-EXCHVS-2.telecomsys.com> <42C44CB8.5070106@cs.columbia.edu> <42C4520E.8010707@cs.columbia.edu> <42C45858.5000301@cs.columbia.edu> <42C46523.6070603@cs.columbia.edu> <42C46D20.5080301@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] R5 Date: Thu, 30 Jun 2005 22:37:14 -0400 To: Henning Schulzrinne , Ted Hardie X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org On Jun 30, 2005, at 6:07 PM, Henning Schulzrinne wrote: >> And what good is caching this? If I've never made an emergency >> call from 234 Maple Dr., it won't be cached. If a call has never >> been made at the x,y,z coordinates for the shrubs in my front >> yard, it won't be cached. Just how often do you expect specific >> locations to be making emergency calls? >> > > For geo, only region caching makes sense. For civic, the testing > process you will need to do for address validation and other > functions ensures that almost all addresses will be (or can be) > cached, even if that residence has never dialed 9-1-1 before. Validation is not required everywhere. From the reaction to it as a requirement, I got the impression that only the US does this. Regardless, it isn't fail-safe either. I was told of an example where an old lady who lived in a house for a long time try to dial 911 for the first time and couldn't because her line had never been validated. Do these caches have timeouts? If not, how do the entries get updated? Are the caches big enough to hold all the information for the civic data? How does that work for ISPs like Verizon or Comcast you serve millions of customers over vast geographic, multi- jurisdictional areas? Are they expected to keep all the data for all the jurisdictions they serve cached all the time? >> Also, the idea of having the polygons cached means that you are >> not worried about security of just anybody knowing those polygons. >> > > That information is essentially public today, as it tends to > conform to civic boundaries such as state, county or city lines. > (It doesn't always, but you can almost always guess who will answer > the 911 call today, at least with 50-50 odds.) I just visited the > LAPD 911 center in downtown LA. They make no secret of their > coverage region of about 4 million people. At the interim meeting, Marc told me of a state where they did not want the information to be widely distributed below the state level. It is also one thing to have public information that requires somebody to go down to the courthouse to find or do some digging to get, and quite another to have it accessible from anywhere on the Internet in a common format with a common protocol. I'm sure some jurisdictions do not have these concerns, but that doesn't mean they all don't. On Jun 30, 2005, at 5:27 PM, Ted Hardie wrote: > R.5. > > The ability to discover the correct PSAP should not require a level > of connectivity > substantially beyond that which would be needed to contact that > PSAP. It is > not required that the servers used for discovery be on-path to the > call flow, > but their reachability should be a strong consideration in devising > deployment > strategies. I like this much better. On Jun 30, 2005, at 9:56 PM, Henning Schulzrinne wrote: > "The look-up process should not add any additional network-related > failure modes. In other words, if a caller knew the PSAP signaling > address and can reach it via signaling and media, the usage of a > mapping mechanism should not interfere with that reachability if > network connectivity to parts of the mapping service is temporarily > impaired." What you are implying is that each ISP maintain and run a mapping server. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 30 23:10:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoBuk-0007Ul-Pv; Thu, 30 Jun 2005 23:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoBuj-0007UZ-1q for ecrit@megatron.ietf.org; Thu, 30 Jun 2005 23:10:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03842 for ; Thu, 30 Jun 2005 23:09:56 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoCKZ-0008PB-Nf for ecrit@ietf.org; Thu, 30 Jun 2005 23:36:44 -0400 Received: from [192.168.0.31] (pool-141-153-166-25.mad.east.verizon.net [141.153.166.25]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j6139noQ023841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Jun 2005 23:09:52 -0400 (EDT) Message-ID: <42C4B3EE.3020400@cs.columbia.edu> Date: Thu, 30 Jun 2005 23:09:34 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] R5 References: <8C837214C95C864C9F34F3635C2A65750297F463@SEA-EXCHVS-2.telecomsys.com> <42C44CB8.5070106@cs.columbia.edu> <42C4520E.8010707@cs.columbia.edu> <42C45858.5000301@cs.columbia.edu> <42C46523.6070603@cs.columbia.edu> <42C46D20.5080301@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ecrit-bounces@ietf.org Errors-To: ecrit-bounces@ietf.org Andrew Newton wrote: > > Validation is not required everywhere. From the reaction to it as a > requirement, I got the impression that only the US does this. > Regardless, it isn't fail-safe either. I was told of an example where > an old lady who lived in a house for a long time try to dial 911 for > the first time and couldn't because her line had never been validated. That's fine; we're talking about increasing probability of success under adverse conditions. I would never claim that we can blow up the Internet to smithereens and still complete 100% of the 9-1-1 calls. > > Do these caches have timeouts? If not, how do the entries get > updated? Are the caches big enough to hold all the information for the > civic data? How does that work for ISPs like Verizon or Comcast you > serve millions of customers over vast geographic, multi- jurisdictional > areas? Are they expected to keep all the data for all the > jurisdictions they serve cached all the time? Let's take an estimate. There are about 120 million households in the US; let's assume that each has an entry size of about 100 bytes, which is larger than the maximum address size stipulated by the US Postal Service (64 bytes) and ignoring obvious data compression mechanisms, such as not storing "San Francisco" literally a million times. Makes 12 GB of data, which is less than the smallest regular iPod holds, for $299. Or, if you'd like, is about $12 of disk storage at current IDE prices. Thus, even if every Verizon POP in the US had cached the complete address table for the US, storage is going to be a trivial expense. Geo is not much different, as the number of PSAP service regions is about 6000. Clearly, caches have timeouts and need to be updated, but very slowly, since address-to-PSAP mappings don't change very frequently. > > At the interim meeting, Marc told me of a state where they did not want > the information to be widely distributed below the state level. I'm sorry to say that the basic design of ECRIT makes hiding such information difficult, caching or not. Since doing the lookup does not require to actually place a 911 call, I can easily do mappings from any address I care to, at my leisure. I don't have to test all addresses, just a few to get a very good idea whether, say, my local PSAP serves the county or just one community. > > It is also one thing to have public information that requires somebody > to go down to the courthouse to find or do some digging to get, and > quite another to have it accessible from anywhere on the Internet in a > common format with a common protocol. The digging in almost all places involves taking out the car atlas and looking for the county or city boundaries. You can also get this electronically courtesy of the Census (TIGER database). We all agree that there are some oddities, due to rate center boundaries and other historical artifacts, but any attack potential presumably doesn't rely on the fact that one can get a complete mapping from every street, just from many such addresses. If we're relying on hiding PSAP (or PSAP aggregate) URLs to protect the 9-1-1 infrastructure, we might as well start selling snake oil. Companies like MapInfo will also gladly sell you this information (we have used the product locally to do mappings Evinsa). > > I'm sure some jurisdictions do not have these concerns, but that > doesn't mean they all don't. Even if you could protect this somehow, this simply means that such jurisdictions would not get the benefit of fate sharing robustness. However, we're designing a protocol, so you are in effect arguing that nobody should since some might decide not to use it. I fail to see the logic of this. > > > >> "The look-up process should not add any additional network-related >> failure modes. In other words, if a caller knew the PSAP signaling >> address and can reach it via signaling and media, the usage of a >> mapping mechanism should not interfere with that reachability if >> network connectivity to parts of the mapping service is temporarily >> impaired." > > > What you are implying is that each ISP maintain and run a mapping server. This shouldn't be required, but I think that if a lawyer looks at the liability, this will seem like a very cheap way to stay out of the evening news. Since the requirements don't prescribe network architecture, I simply want to make sure that the protocol mechanisms we design allow very distributed and localized resolution. It is then up to operational folks to decide whether servers are placed next to each DNS server, closer to the core or next to each outbound proxy in a VSP. Thus, it doesn't have to be each POP. As a hypothetical design example, a system/protocol that relied on contacting a "root" server somewhere in some faraway network would probably fail to meet this requirement. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit